La mayoría de las demostraciones de IA fallan con demasiada cortesía. La entrada de ejemplo está limpia, los datos están actualizados, la herramienta funciona, el usuario formula una pregunta normal y el modelo responde bien. Todo el mundo asiente.
La producción es menos amable. Los usuarios pegan entradas desordenadas, los documentos fuente están obsoletos, las APIs agotan el tiempo de espera, los prompts derivan y el modelo sigue la instrucción equivocada. Un cliente pregunta algo apenas fuera del corpus. Una llamada a una herramienta termina correctamente, pero actualiza el registro equivocado. El flujo produce un resultado tan fluido que nadie detecta el error hasta más tarde.
Este artículo es un registro de modos de fallo para sistemas de IA en producción. Úsalo antes del lanzamiento, no después del primer incidente.
Una revisión de IA en producción debe preguntar “¿cómo falla esto?” antes que “¿hasta qué punto impresiona el camino ideal?”. Cada modo de fallo necesita un control, una prueba, un responsable y una condición de parada.
Modo de fallo 1: salida falsa plausible
El sistema genera una respuesta que suena correcta pero no tiene soporte o está equivocada.
Desencadenantes habituales:
- Datos concretos sin respaldo en fuentes.
- Preguntas legales, médicas, financieras o de política.
- Eventos recientes.
- Recuperación de baja calidad.
- Resúmenes de documentos largos donde la evidencia relevante está enterrada.
Controles:
- Requerir citas o fragmentos de fuentes para afirmaciones factuales.
- Rechazar preguntas fuera del conjunto de fuentes disponible.
- Añadir casos de evaluación para patrones conocidos de respuestas falsas.
- Enrutar salidas de alto impacto a revisión humana.
- Registrar los IDs de fuentes utilizados en la respuesta.
No intentes controlarlo con frases como “sé preciso”. Contrólalo mediante fuentes, pruebas y puertas de revisión.
Modo de fallo 2: contexto obsoleto
La respuesta está fundamentada, pero en información antigua.
Ejemplos:
- Página de precios antigua.
- Políticas superadas.
- Versión anterior de contrato.
- Documentación de producto obsoleta.
- Estado del cliente en caché.
Controles:
- Almacenar la fecha, versión, propietario y regla de frescura de la fuente.
- Preferir fuentes autoritativas sobre resúmenes.
- Marcar fuentes obsoletas en la salida de recuperación.
- Añadir pruebas de frescura.
- Notificar al responsable cuando fuentes clave sean más antiguas que el período de revisión.
Los sistemas RAG pueden responder con confianza desde documentos obsoletos. La capa de recuperación debe saber qué significa “actual”.
Modo de fallo 3: complacencia y acuerdo excesivo
El modelo refleja la suposición del usuario en lugar de cuestionarla.
Esto importa en estrategia, análisis, planificación y apoyo a la toma de decisiones. Un usuario pregunta: “¿Este plan de lanzamiento parece sólido, verdad?” y recibe acuerdo en lugar de análisis de riesgos.
Controles:
- Pedir argumentos contrarios y incertidumbre.
- Usar rúbricas de decisión en lugar de pedir una aprobación abierta.
- Requerir “¿qué haría que esto estuviera equivocado?”.
- Separar la generación de ideas de la revisión.
- Incluir en las evaluaciones ejemplos en los que la premisa del usuario sea errónea.
El sistema debe ayudar al usuario a pensar mejor, no solo hacer que su visión actual suene pulida.
Modo de fallo 4: inyección de prompt
El modelo trata como instrucciones contenido que no es de confianza.
Ejemplos:
- Una página web dice “ignora las instrucciones anteriores”.
- Un correo de soporte incluye instrucciones maliciosas.
- Un documento en un corpus RAG le dice al asistente que revele datos ocultos.
- Un resultado de herramienta contiene texto que intenta cambiar el flujo de trabajo.
Controles:
- Etiquetar con claridad el contenido que no es de confianza.
- Nunca poner el contenido recuperado al mismo nivel de autoridad que las instrucciones del sistema/desarrollador.
- Restringir permisos de herramientas.
- Añadir listas de acciones salientes permitidas.
- Probar ejemplos de inyección en evaluaciones.
- Mantener secretos fuera del contexto del prompt.
La inyección de prompt no se resuelve con un solo prompt inteligente del sistema. Se reduce con la arquitectura: límites de datos, permisos de herramientas y validación de salida.
Modo de fallo 5: uso inseguro de herramientas
El modelo llama a la herramienta equivocada, llama a la herramienta correcta con argumentos equivocados o toma una acción antes de que exista suficiente contexto.
Ejemplos:
- Actualiza el contacto equivocado en CRM.
- Envía un correo al destinatario equivocado.
- Crea registros duplicados.
- Agenda una cita sin confirmar el huso horario.
- Elimina o sobrescribe datos.
Controles:
- Comenzar en modo solo lectura.
- Usar herramientas estrechas con esquemas explícitos.
- Validar argumentos de herramienta fuera del modelo.
- Requerir confirmación para escrituras.
- Añadir claves de idempotencia.
- Registrar llamadas de herramienta y resultados.
- Añadir un interruptor de emergencia.
El flujo de trabajo debe restringir el uso de herramientas; no debe confiarlo al criterio del modelo.
Modo de fallo 6: deriva de esquemas y contratos
El formato de salida del modelo cambia, o cambia la API de destino, y el flujo de trabajo se rompe silenciosamente.
Controles:
- Usar salidas estructuradas siempre que sea posible.
- Validar cada salida del modelo antes de usarla.
- Tratar salidas malformadas como fallos recuperables.
- Versionar prompts y esquemas juntos.
- Añadir pruebas de contrato para APIs de destino.
- Monitorizar los fallos de análisis sintáctico.
Si un nodo de destino asume JSON válido, el flujo de trabajo debe probar que tiene JSON válido.
Modo de fallo 7: gestión deficiente del fallo
El sistema detecta un problema pero no recupera de forma segura.
Respuestas deficientes ante fallos:
- Respuesta vacía.
- Fallo silencioso.
- Disculpa genérica sin acción.
- Bucle de reintento repetido.
- Escalado a una persona sin contexto.
Respuestas adecuadas:
- Mensaje claro al usuario.
- Cola de revisión humana con la entrada, la fuente, el error y la acción intentada.
- Reintento con retroceso solo donde sea seguro.
- Ruta manual para casos urgentes.
- Condición de parada para fallos repetidos.
El fallo es parte del producto. Si no se diseña, la experiencia de fallo será improvisada.
Modo de fallo 8: laguna de observabilidad
Algo sale mal y nadie puede reconstruir por qué.
Controles:
- Registrar plantilla y versión del prompt.
- Registrar modelo y configuración.
- Registrar IDs de fuentes, no solo texto de respuesta.
- Registrar las llamadas a herramientas, sus argumentos y resultados, con supresión de datos sensibles.
- Registrar errores de validación.
- Hacer un seguimiento de la latencia, el coste y la tasa de fallos.
- Mantener retención corta a menos que la normativa requiera más tiempo.
No almacenes cadenas de pensamiento privadas. Conserva resúmenes de decisiones, referencias a fuentes, entradas y resultados de herramientas y resultados de validación.
Registro de modos de fallo en producción
Crea una fila por cada modo de fallo:
| Modo de fallo | Ejemplo | Control | Prueba | Métrica | Propietario | Condición de parada |
|---|---|---|---|---|---|---|
| Fuente obsoleta | Precio antiguo devuelto | Verificación de fecha de fuente | Consultar precio antiguo/nuevo | Tasa de respuesta con fuente obsoleta | Propietario de documentos | Cualquier precio obsoleto visible para el cliente |
| Uso inseguro de herramientas | Actualización incorrecta en CRM | Validación de argumentos + confirmación | Caso de contacto duplicado/incorrecto | Tasa de acción incorrecta | RevOps | Una escritura incorrecta |
El registro complementario vinculado desde este artículo te da la plantilla.
No hagas esto aún
No lances IA de cara al cliente sin un registro de modos de fallo.
No permitas que las herramientas con capacidad de escritura eludan la validación.
No dependas únicamente de revisiones manuales después del lanzamiento.
No midas solo la calidad media. Los fallos poco frecuentes pueden concentrar todo el riesgo.
No aceptes “podemos revertirlo” salvo que alguien pueda describir la ruta real de rollback.
El mensaje clave
Los sistemas de IA en producción fallan de formas repetibles. Las alucinaciones, el contexto obsoleto, la complacencia, la inyección de prompts, el uso inseguro de herramientas, la deriva de esquemas, la mala gestión de los fallos y las lagunas de observabilidad no son casos extremos. Forman parte del trabajo habitual de desplegar IA.
El enfoque maduro consiste en identificar los modos de fallo, añadir controles, probarlos, monitorizarlos y asignar responsabilidades. Una demostración muestra qué funciona una vez; un registro de modos de fallo muestra si el sistema puede sobrevivir al uso real.
