Tu AI Agent No Está Fallando Cuando Lancea una Excepción. Está Fallando Cuando Escribe una Respuesta Perfecta que Es Completamente Incorrecta.
Y ningún test unitario del mundo va a detectarlo.
La industria asume que los AI Agents se evalúan como software tradicional: más tests = más calidad. Escribís tests unitarios. Probáis funciones helper. Validáis que el JSON parsea bien. Y cuando todo pasa, asumís que el agent funciona.
*Pero un AI Agent que pasa todos los tests unitarios puede estar tomando decisiones catastróficas con un 95% de confianza. *
El problema no es que fallen. Es que fallan bien. Con buena gramática. Con paso seguro. Sin lanzar ninguna excepción que un try-catch pueda atrapar.
Bienvenidos al verdadero problema de evaluar AI Agents en 2026.
---
Por Qué el Try-Catch Es un Error Categorial
El try-catch fue diseñado para errores de runtime. Null pointers. Timeouts. Conexiones fallidas. Excepciones que rompen el flujo de ejecución.
Pero un AI Agent que decide incorrectamente no lanza una excepción. Ejecuta código perfectamente válido que lleva a una decisión equivocada.
Piénsalo así: un conductor con GPS toma la salida equivocada en una autopista. El coche funciona perfectamente. El GPS da indicaciones claras. No hay ningún error en el sistema. Pero el destino es otro.
El software tradicional confunde "funcionar sin errores" con "funcionar correctamente". Para AI Agents, esas dos cosas no tienen correlación.
Veámoslo con código:
El primer test pasa. El segundo test es el que realmente importa. Y el 99% de los equipos solo escribe el primero.
---
El Peligro de la Alta Confianza en Decisiones Incorrectas
Los modelos de lenguaje generan tokens con probabilidades asociadas (logprobs). Cuando un modelo produce una respuesta con alta probabilidad en cada token, internamente "cree" que está en lo correcto.
Esto es análogo a un empleado que nunca duda de sí mismo pero se equivoca sistemáticamente. En evaluación de agents, el peor escenario no es el agent que duda (fallo visible, fácil de atrapar). Es el que ejecuta con convicción una acción dañina.
| Nivel de Confianza | Decisión Correcta | Decisión Incorrecta |
|-------------------|-------------------|-------------------|
| Confianza Alta | El agente funciona. Todo bien. | ⚠️ PELIGRO: Modo de fallo invisible. El agent actúa sin dudar. |
| Duda/Baja | El agente funciona pero es ineficiente. Pide clarificación constante. | El agente duda. El fallo es detectable. Se puede intervenir. |
El bucket crítico es "incorrecto + confianza alta". Fallos invisibles que el agente ejecutará sin dudar. No hay log. No hay error. No hay excepción. Solo una decisión equivocada ejecutada con total convicción.
---
El Sistema de 4 Buckets: Tu Evaluation Harness para AI Agents
Construí esto después de ver cómo agents en producción tomaban decisiones dañinas sin que nadie pudiera detectarlo a tiempo. No es teoría. Es el harness que uso hoy en producción.
El sistema clasifica cada acción del agent en una matriz 2x2 y te permite ver exactamente dónde está fallando tu sistema.
Bucket 1 — Taxonomía de Fallos Específica de tu Dominio
No todos los fallos son iguales. Tienes que definir los tuyos:
- Errores de hecho: información incorrecta (el agent dijo que la empresa está en Madrid cuando está en Barcelona)
- Errores de procedimiento: paso incorrecto en un workflow (cerró un ticket sin asignarlo)
- Errores de alucinación: información inventada (creó un cliente que no existe)
- Errores de omisión: no hacer algo que debía hacerse (no envió el email de confirmación)
Bucket 2 — Medir Confianza vs Precisión
Extrae los logprobs del modelo en cada respuesta y crúzalos con la corrección factual de la acción:
Bucket 3 — Logging Estructural de Decisiones
No loguees solo errores. Loguea cada decisión con su contexto completo:
Bucket 4 — Dashboard de 4 Cuadrantes
Creas un dashboard que clasifica cada ejecución en tiempo real y te permite ver patrones:
Si ves ejecuciones en el cuadrante "incorrecto + confianza alta", tienes un problema de arquitectura, no de modelo. El agent está aprendiendo patrones incorrectos con total seguridad.
---
Cómo Implementarlo en Producción (Sin Morir en el Intento)
Vale, sé lo que estás pensando: "Extraer logprobs y medir confianza es demasiado complejo para producción".
Es cierto que añade complejidad. Pero es la única manera de detectar el modo de fallo más peligroso. Empieza con un submuestreo del 10% de las ejecuciones. No necesitas medir todas.
Usa herramientas que ya soportan esto:
- LangSmith: tiene tracing nativo con logprobs y evaluación de decisiones
- Weights & Biases: soporta logging de confianza para modelos de lenguaje
- MLflow: tracking de experimentos con métricas personalizadas
---
Lo que la Gente se Equivoca al Decir (Y la Verdad)
"Pero si mi agent pasa los tests de integración y no lanza errores, está funcionando correctamente."
❌ Falso. Confundes funcionamiento técnico con corrección semántica. Un agent puede ejecutar código perfectamente (sin errores de runtime) mientras toma decisiones lógicamente incorrectas. El código puede ser impecable y la decisión catastrófica.
"Los logs tradicionales ya capturan los errores — solo necesito mejor logging."
❌ Falso. Los logs tradicionales capturan excepciones y errores de sistema. No capturan decisiones incorrectas con alta confianza porque desde la perspectiva del sistema, todo funcionó correctamente. No hay nada que loguear. Necesitas logging semántico que evalúe la corrección de la decisión, no solo la ejecución del código.
"Extraer logprobs y medir confianza es demasiado complejo para producción."
✅ Parcialmente cierto, pero manejable. Añade complejidad, pero es la única defensa contra el modo de fallo más peligroso. Empieza con un submuestreo del 10%. Usa herramientas como LangSmith que ya lo soportan. La alternativa es descubrir el fallo cuando el cliente te lo dice.
---
La Línea de Meta
El 2026 nos ha enseñado algo claro: los AI Agents no son software tradicional. No puedes evaluarlos con las mismas herramientas. Los tests unitarios miden si el código funciona. No miden si la decisión es correcta.
El Sistema de 4 Buckets no es opcional. Es la diferencia entre un agent que parece funcionar y uno que realmente funciona.
Empieza hoy. Define tu taxonomía de fallos. Extrae logprobs. Mide confianza vs precisión. Y pon un dashboard que te muestre dónde están tus agents fallando en silencio.
Porque el AI Agent perfectamente escrito que toma decisiones incorrectas con un 95% de confianza no es un bug. Es una bomba de relojería.
Artículos relacionados
- Evaluation Harness para AI Agents: El Sistema que Mide Si Tu Agent Realmente Funciona
- Por Qué El 90% de los AI Agents Se Rompen en Producción y Cómo Arreglarlo
- Error Recovery en AI Agents: Por Qué el Try-Catch No Es Suficiente y Cómo Implementar un Sistema de Clasificación que No Falle
- Error Recovery en AI Agents: El Framework que Transforma el 40% de Fallos en Aprendizaje
- Cómo Evaluar AI Agents en 2026: El Harness de 4 Buckets que Detecta Errores Silenciosos
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
