Por qué los agentes de IA para la producción fallan en silencio y cómo detectar respuestas incorrectas

El fallo de producción más peligroso para un agente de IA no es una caída o un tiempo de espera excesivo. Es una respuesta que parece correcta, supera todas las verificaciones de estado y resulta ser errónea. El estudio de caso a continuación sigue la historia de una pequeña empresa de software que puso en producción doce agentes en un solo trimestre y solo mantuvo tres; explica qué diferenció a los que sobrevivieron del resto para que pueda diseñar sistemas de detección antes de implementarlos.

El equipo, las herramientas y las reglas básicas

La empresa era una compañía B2B de SaaS formada por unas cuarenta personas, incluidos nueve ingenieros; no se trataba de un laboratorio de investigación. Entre el 6 de enero y el 27 de marzo de 2026, el equipo lanzó doce agentes. Aquellos que funcionaban dentro del repositorio de código operaban en Claude Code; los demás eran agentes personalizados desarrollados con la API de Anthropic y alojados detrás de un pequeño servicio interno, de modo que cada agente compartía un único registro de auditoría y un único interruptor de apagado.

Dos reglas se aplicaron desde el primer día, y ambas resultaron valiosas de mantener:

• Cada agente registra cada acción en un canal de auditoría, incluidas las acciones de solo lectura.
• Cualquier miembro del equipo puede desactivar a cualquier agente en cualquier momento, sin necesidad de aprobación ni ticket.

El éxito se definió de manera intencionadamente exigente. Un agente solo contaba como exitoso si seguía en funcionamiento después de treinta días y alguien se oponía cuando se proponía su desactivación. Las métricas de uso pueden inflarse fácilmente debido a la novedad; es mucho más difícil falsificar la actitud de quienes defienden una herramienta de la que dependen.

Tabla de resultados: tres sobrevivientes, nueve desactivaciones

Tres agentes seguían en funcionamiento al final del trimestre:

• un generador de descripciones para solicitudes de integración
• un asistente para redactar tickets de soporte
• un recolector de contexto de incidentes

Nueve de ellos fueron desactivados en el transcurso de un mes: un revisor automático de códigos, un sistema para responder preguntas analíticas, un bot para actualizar dependencias, un herramienta para aislar pruebas inestables, un sistema de respuesta a correos electrónicos de clientes, un convertidor de notas de reuniones en tickets, una herramienta para actualizar documentación en wiki, un sistema de respuesta a anomalías en los registros y un publicador de changelogs.

La instrucción de seguridad que no sirvió de nada

Al igual que la mayoría de los equipos, este también comenzó con una instrucción de seguridad incluida en el prompt del sistema de cada agente, que le indicaba al modelo admitir su incertidumbre, evitar valores no verificables y citar una fuente para cada número:

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

En la práctica, esta instrucción casi no tuvo efecto, y esa es la lección más importante de todo el ejercicio. Se explica en detalle en el fallo analítico que se presenta a continuación.

Las permisos también se establecieron de forma conservadora: cada agente tenía solo acceso de lectura al inicio. A lo largo del trimestre, se le otorgó acceso de escritura a cuatro agentes. Tres de esos cuatro fueron desactivados posteriormente.

Lo que tenían en común los agentes sobrevivientes

El redactor de descripciones para solicitudes de pull request

Este agente, que funcionaba en Claude Code, podía leer la diferencia entre versiones y el problema relacionado, y luego escribir una descripción en el cuerpo de la solicitud de pull request. Un ingeniero la editaba y la fusionaba. Manejaba aproximadamente 35 solicitudes de pull request por semana, y las descripciones resultantes eran mejores que las que escribían los ingenieros a mano, sobre todo porque un desarrollador cansado tiende a escribir “arreglar error”, mientras que el agente no se cansa.

El redactor para la triage de soporte

Este agente leía cada ticket recibido, aplicaba una etiqueta y redactaba una respuesta como nota interna dentro del servicio de soporte. Nunca tuvo la capacidad de enviar nada. Aproximadamente el 60% de sus borradores se enviaban tras una ligera edición, y el tiempo medio de respuesta inicial pasó de poco más de cuatro horas a unos ochenta minutos.

Recopilador de contexto del incidente

Cada vez que una alerta avisaba a alguien, este agente publicaba exactamente un mensaje en el canal del incidente que contenía las tres implementaciones más recientes con fechas y horas, el cambio en la tasa de errores por servicio, y enlaces a cualquier incidente similar de los noventa días anteriores. No tomaba ninguna acción ni ofrecía diagnóstico alguno; simplemente recopilaba los paneles de control y enlaces que un ingeniero de guardia abriría de otra manera manualmente. Fue el agente menos sofisticado que el equipo desarrolló y también el que más valoraron.

Anatomía de un agente erróneo con total confianza

Sobre el papel, el agente de análisis era el mejor diseñado de los doce. Tenía acceso a una réplica de lectura, un documento de esquema escrito a mano en su contexto y una interfaz de Slack; su propósito era responder preguntas relacionadas con las métricas para que el equipo de datos dejara de ser interrumpido veinte veces al día.

El 3 de febrero alguien le pidió los ingresos semanales. Generó una consulta que unió los pedidos con los pagos, y al hacerlo trató las filas de reembolsos como cantidades positivas. El resultado fue aproximadamente un 12% demasiado alto, pero completamente creíble: la magnitud era correcta, la tendencia semana a semana también lo era, e incluso se podía observar el descenso estacional tras finalizar una promoción en enero.

Esa cifra inflada apareció en la publicación de métricas del lunes, y también en las dos siguientes publicaciones del mismo día. El error solo surgió el 24 de febrero, durante el cierre de enero, cuando la suma total del equipo financiero y la del agente no coincidían.

Considere lo que no ocurrió durante esas tres semanas: no hubo excepciones, ni alertas, ni aumento en la latencia. La consulta SQL era válida, las filas se recuperaban correctamente, y el agente citaba su fuente tal como lo exigía la instrucción. La monitorización convencional existe para detectar sistemas que dejan de funcionar, y este nunca dejó de hacerlo.

Es precisamente aquí donde falla la indicación relativa a las barreras de seguridad. Una instrucción para decir “No lo sé” cuando uno no está seguro solo funciona si el modelo cuenta con una señal interna que indique su propia incertidumbre. En este caso, el modelo no estaba incierto; simplemente se equivocó. Desde el exterior, cometer un error con confianza es indistinguible de tener razón, por lo que una indicación no puede filtrarlo.

Segue un punto general útil: una unión que cambia silenciosamente el signo o la multiplicidad de filas es un error clásico en el análisis, incluso para los humanos. La diferencia es que un analista humano suele tener idea de qué números verificará el departamento financiero, mientras que un agente no tiene interés en la conciliación a menos que se le proporcione uno.

Cuando se ignora a un agente correcto

El revisor de código automatizado falló de una manera que muchas equipos no anticipan: no estaba equivocado. Cada solicitud de integración recibía alrededor de 40 comentarios; la mayoría podían justificarse, y muchos eran críticas menores sobre la nomenclatura o el estilo de manejo de errores.

Dentro de tres semanas, los ingenieros ya resolvían sus comentarios sin leerlos. Luego surgió un problema realmente grave: una consulta sin su filtro de inquilino, y ese comentario quedó sepultado entre 38 observaciones sobre estilo. Una persona encontró el error en la fase de pruebas dos días después. El revisor tenía razón, pero el volumen excesivo había anulado su mensaje.

Por qué se desactivaron los nueve

Los fallos se clasificaron claramente:

• seis generaron resultados seguros pero incorrectos
• dos generaron resultados que nadie leyó
• uno se desactivó porque nadie podía determinar si realmente estaba haciendo algo

La regla de diseño: detenerse un paso antes de que actúe el ser humano

Los tres agentes que siguen en funcionamiento comparten una característica común, y no se trata del modelo, de la instrucción ni del marco de trabajo. Cada uno de ellos se detiene un paso antes de que ocurra una acción humana. Ellos generan un boceto, un resumen o un conjunto de contexto, y una persona realiza el paso final. Realizar ese paso obliga a la persona a leer el trabajo.

Cada agente que fue desactivado actuó por su cuenta o generó resultados que se convirtieron en acciones sin una revisión real. El agente de análisis es el ejemplo más claro: no tenía ningún acceso de escritura, sin embargo, sus recomendaciones llegaron directamente a las decisiones empresariales a través de personas que confiaban en él.

El límite resultante es sencillo: permitir que los agentes reúnan material, pero no dejar que controlen el paso final, donde un error se convierte en una consecuencia real.

Ese límite no es un juicio sobre la capacidad del modelo, y un modelo más potente no lo eliminará. Se trata de detección: el fallo típico de un agente es dar una respuesta plausible en lugar de colapsar, y la mayoría de los equipos cuentan con muy pocos recursos para identificar respuestas plausibles que son incorrectas.

El costo nunca fue el cuello de botella. Los doce agentes juntos consumieron un poco menos de 900 dólares en tokens durante el trimestre. El recurso escaso fue la atención humana.

Tres cambios que puede hacer esta semana

• Antes de lanzar, documente cómo se detectaría una respuesta incorrecta pero plausible. No cómo se notaría un colapso, sino cómo se sabría que la salida es errónea. Si no puede redactar esa frase, el agente debería redactar primero en lugar de actuar.

Reconciliar cada número que genera un agente con una segunda fuente según un calendario establecido. Una comparación automática semanal con las cifras financieras habría detectado el error en los ingresos ya en su segundo día, y su corrección habría tomado solo una tarde.

Entregar los resultados del agente en los lugares donde la gente ya los busca, y limitar su cantidad. Un canal completamente nuevo tiende a pasar desapercibido, y una pared de cuarenta comentarios suele ser ignorada, mientras que solo unos pocos comentarios bien enfocados reciben atención real.

Concilie la cifra con una segunda fuente

Compare la cifra del agente con el libro mayor y deténgase si la brecha supera medio punto porcentual o una unidad monetaria.

const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

Ejecute la comparación con un horario. El monitor de caídas sigue en verde; esta comprobación llama a una persona.

Puntos clave

• El modo de fallo que debe considerarse es una salida incorrecta pero plausible, no un tiempo de inactividad; la monitorización estándar no lo detectará.
• Las instrucciones sobre nivel de confianza no pueden detectar errores de los que el modelo no es consciente.
• El acceso solo de lectura no equivale a algo inofensivo: la salida que sirve para tomar decisiones es, en efecto, una acción.
• El volumen es un modo de fallo en sí mismo; una señal correcta ahogada en ruido no vale nada.
• Una prueba útil para cualquier agente es determinar si alguien se opondría a que se apagara mañana.

Lecturas relacionadas

• Pausar y reanudar agentes LangGraph con interrupt() y Command — Cómo interrupt() y Command de LangGraph se basan en puntos de control y hilos para pausar un agente a fin de obtener la aprobación, ediciones o entrada humana, y luego reanudarlo de forma segura más tarde.
• Verificar qué hacen los agentes de IA: permisos, puertas de aprobación y niveles de riesgo — Entienda por qué los agentes en acción necesitan una mentalidad de verificación, y cómo el principio de menor privilegio, la aprobación humana y la autonomía basada en riesgos ayudan a contener sus errores.
• Pausar y reanudar agentes de LangGraph con interrupt() y Command — Cómo LangGraph utiliza las funciones interrupt() y Command, junto con puntos de control y hilos, para pausar a un agente a fin de obtener la aprobación humana, realizar ediciones o recibir entrada, y luego reanudarlo de forma segura más tarde.
• Verificando lo que hacen los agentes de IA: permisos, controles de aprobación y niveles de riesgo — Aprenda por qué los agentes de actuación necesitan una mentalidad de verificación, y cómo el principio de mínimo privilegio, la aprobación humana y la autonomía basada en riesgos ayudan a contener sus errores.
• Herramientas de evaluación para aplicaciones de LLM: conjuntos de datos, puntuación y umbrales de regresión — Aprenda qué es un harness de evaluación de LLM, sus cuatro componentes principales, y cómo detecta regresiones en los prompts y compara los modelos de manera justa antes de que nada llegue a los usuarios.
• De GPT-1 a los modelos de razonamiento: qué cambió en cada generación para los desarrolladores — Trace la familia GPT desde el preentrenamiento de 2018 hasta los modelos de razonamiento, observe qué ideas aportó cada generación, y conozca como se denominan GPT-4o Vision y Structured Outputs de Python.