Observabilidad y evaluación de agentes IA en producción: cómo saber si funcionan de verdad

La mayoría de agentes IA que ves presentados en una demo no sobreviven seis meses en producción. No porque el modelo deje de funcionar: porque nadie sabe si realmente está funcionando. Si llevas tiempo buscando cómo poner observabilidad agentes IA empresa en serio, este post es para ti. En Everglow llevamos años implantando agentes IA en operaciones reales de cliente, y la diferencia entre un sistema fiable y un experimento caro casi siempre está en lo mismo: la capa de medición.

La buena noticia: no necesitas un equipo de plataforma de 20 personas para hacerlo bien. Necesitas criterio, métricas honestas y disciplina para mirarlas. La mala: si no lo montas tú, no lo monta nadie, y un día un agente empieza a alucinar contra tu base de clientes y te enteras por LinkedIn.

Por qué la observabilidad de agentes IA no es opcional

Un agente IA en producción es un sistema probabilístico que toma decisiones sobre datos vivos, con prompts, herramientas externas, memoria y, casi siempre, varias llamadas encadenadas a un LLM. Cada una de esas piezas puede fallar de forma silenciosa.

Un endpoint REST clásico falla con un 500 y te enteras. Un agente IA falla devolviendo una respuesta plausible pero incorrecta. No hay excepción. No hay stack trace. Solo un cliente confundido o un dato escrito mal en tu CRM. Si no instrumentas observabilidad desde el día uno, no estás operando un sistema, estás esperando que vaya bien.

La pregunta correcta no es “¿el agente responde?”. Es “¿de los últimos 1.000 inputs reales, en cuántos hizo exactamente lo que tenía que hacer?”. Sin esa cifra, todo lo demás es marketing interno.

En Everglow hemos asumido, después de bastantes implantaciones, que un agente sin observabilidad es deuda técnica disfrazada de innovación. Por eso forma parte del scope desde la primera semana, no como “fase 3 cuando haya presupuesto”.

Las cuatro capas que tienes que medir

Cualquier sistema serio de evaluación de un agente IA en producción se sostiene sobre cuatro capas. Si te falta alguna, tienes un punto ciego.

1. Telemetría técnica (lo más fácil, lo que casi todos olvidan)

Esto es la base. Logs estructurados de cada llamada, latencia, tokens, errores de red, código de estado de las tools externas. Si usas LangSmith, Langfuse, Helicone, Phoenix, Arize o tu propio stack en OpenTelemetry, da igual: lo importante es tenerlo.

Sin telemetría no puedes responder preguntas tan básicas como:

• Cuánto tarda el agente en cerrar una conversación
• Cuántos tokens consume por interacción media
• Cuántas veces falla la tool de tu CRM
• Si el coste por usuario activo está subiendo o bajando con el tiempo

Sin esto vuelas a ciegas y, cuando el CFO te pregunte por qué la factura de OpenAI subió un 40% este mes, no vas a saberlo.

2. Trazas completas (lo que diferencia un equipo serio)

Una traza es la reconstrucción paso a paso de lo que hizo el agente en una interacción concreta: qué prompt se construyó, qué documentos recuperó el RAG, qué herramientas llamó, qué argumentos pasó, qué devolvió cada paso, cómo razonó hacia el output final.

Sin trazas, debugar un agente es imposible. Literalmente. Cuando alguien te diga “el bot me respondió mal en el ticket #1837”, tienes que poder abrir esa traza y ver cada paso. Si no puedes, no estás operando un agente, estás rezándole.

Esto es especialmente crítico cuando el agente tiene varios pasos: clasificación, recuperación, llamada a herramienta, redacción, validación. Cada paso puede romperse de forma distinta y cada uno necesita su propia capa de inspección.

3. Evals (la capa que casi nadie monta y es la que más rinde)

Eval significa evaluación automatizada de outputs del agente contra un criterio. Es la diferencia entre “creo que funciona” y “sé que funciona en el 92% de los casos representativos”.

Hay tres tipos de evals que merece la pena montar:

• Evals deterministas: comprueban condiciones objetivas. ¿El agente devolvió el formato JSON correcto? ¿Citó al menos una fuente? ¿Mencionó el precio correcto del producto? Son las más fiables y las más baratas.
• Evals con LLM como juez: un segundo modelo evalúa la calidad de la respuesta del agente según una rúbrica. Útil para criterios subjetivos (tono, claridad, completitud) que un test unitario no puede capturar. Hay que calibrar al juez con humanos para que no te mienta.
• Evals con humano en el loop: una persona del negocio revisa una muestra semanal. Insustituible para detectar problemas que ningún test automático ve. Es caro pero es el único que captura sentido común.

Lo que casi nadie hace bien: mantener un dataset de evaluación que crece con el tiempo. Cada vez que detectas un caso problemático en producción, lo añades al dataset. Antes de cualquier cambio (de prompt, de modelo, de herramienta), pasas todo el dataset y comparas. Sin esto, cualquier “mejora” puede ser una regresión disfrazada.

4. Métricas de negocio (la única capa que de verdad importa)

Lo anterior te dice si el agente funciona técnicamente. Esto te dice si está moviendo el negocio.

Algunas que solemos instrumentar desde el principio:

• Tasa de resolución sin escalada humana (en agentes de soporte)
• Reducción de tiempo medio por ticket o por proceso
• Tasa de conversión asistida (en agentes comerciales)
• Coste por interacción frente a la línea base humana
• Net Promoter Score o satisfacción del usuario final tras interactuar con el agente
• Errores escalados o detectados en revisión a posteriori

Si tu agente puntúa bien en evals técnicas pero la métrica de negocio no se mueve, el problema no es el agente, es el caso de uso. Y antes de seguir invirtiendo, hay que pararse a pensar.

Guardarraíles: lo que evita que un error se convierta en un incidente

Observabilidad sin guardarraíles es darte cuenta tarde. Guardarraíles sin observabilidad es no darte cuenta nunca. Las dos cosas van juntas.

Estos son los guardarraíles mínimos que aplicamos en cualquier implantación seria:

• Validación de outputs: schema validation cuando el agente debe devolver JSON estructurado, regex o clasificadores para detectar respuestas tóxicas, PII filtering antes de devolver cualquier cosa al usuario.
• Confirmación humana en acciones críticas: si el agente va a enviar un email a un cliente, ejecutar un pago, crear un registro en el CRM, modificar una factura… debe haber un punto de confirmación. Al menos al principio. Quitar el humano solo cuando los evals te lo permitan.
• Límites duros: máximo número de iteraciones del bucle del agente, máximo de tokens por respuesta, máximo de llamadas a una tool externa por interacción. Sin esto, un bug puede costarte cuatro cifras en una madrugada.
• Detección de drift: si el comportamiento del agente cambia con respecto a la línea base (por un cambio del modelo, por nuevos datos, por un cambio sutil del prompt), debes enterarte. No al cabo de un mes.
• Modo seguro y rollback rápido: poder desactivar el agente y volver al flujo anterior en menos de 5 minutos. Si tu rollback requiere reunión de comité, no tienes rollback.

Un agente IA en producción es un servicio crítico, no un experimento. Trátalo como tratarías a tu pasarela de pagos: con observabilidad, alertas, runbooks y un humano disponible.

Alertas: lo que tienes que mirar sin mirar

Un buen sistema de observabilidad te avisa solo cuando algo va mal. No te obliga a entrar a un dashboard cada mañana. Estas son las alertas que recomendamos configurar desde el día uno:

• Caída de la tasa de éxito en evals automatizadas por debajo de un umbral (por ejemplo, 90%)
• Subida brusca de latencia media (señal de problemas con el proveedor del modelo o saturación)
• Subida brusca de coste por interacción (un cambio de prompt que duplica tokens, un loop infinito, un cliente abusando del sistema)
• Aumento de la tasa de escalada a humano (señal de que el agente está perdiendo capacidad para casos que antes resolvía)
• Errores 429 o 5xx del proveedor del LLM por encima de un umbral
• Output tóxico, PII expuesta o violación de guardarraíles detectada por validadores

Estas alertas deben ir a Slack, Teams o donde realmente miréis. Mandarlas a un email que nadie abre es decorativo.

Herramientas y stack mínimo que recomendamos

No hay una respuesta única. Depende del nivel de madurez, del volumen y del presupuesto. Pero para una empresa española mediana-grande que está empezando con agentes en producción, este stack mínimo suele funcionar:

• Tracing y evals: Langfuse o LangSmith. Open source el primero, gestionado el segundo. Ambos cubren lo esencial.
• Telemetría general: OpenTelemetry + Datadog/Grafana si ya lo tenéis. Si no, lo que ya esté en producción.
• Eval datasets: repositorio de casos en formato YAML o JSON versionado en Git, como cualquier otro artefacto de software. No en un Excel del SharePoint.
• Guardarraíles: Guardrails AI, NeMo Guardrails o validadores custom según el caso. Para producción crítica, no te fíes solo del prompt.
• Dashboards de negocio: Looker, Metabase, Power BI o el que ya use el equipo. Las métricas de negocio deben verse desde el mismo sitio que el resto de KPIs de la empresa.

Lo que nunca recomendamos: montar todo esto custom desde cero. Es trabajo que no añade valor diferencial y que te distrae del problema real, que es resolver el caso de uso del cliente.

Cómo lo hacemos en Everglow

En cada implantación de agente IA seguimos un patrón que ya no negociamos:

• Semana 1: instrumentación de logs y trazas básicas antes de que el agente toque ningún dato real.
• Semana 2: dataset de evaluación inicial con 30-50 casos representativos firmados con el cliente. Sin eso, no se pasa a piloto.
• Semana 3-4: piloto en producción con tráfico real limitado, humano confirmando acciones críticas, evals corriendo de forma continua.
• Semana 5-8: alertas, dashboards de negocio y revisión semanal de resultados. Iteración del agente basada en lo que muestra el sistema, no en lo que cree el comité.
• A partir de semana 9: ampliación de scope, retirada progresiva del humano en pasos donde los evals lo justifiquen.

Esta forma de trabajar nos ha permitido sostener agentes en producción durante años en clientes con tráfico serio, sin sustos. Y, sobre todo, detectar problemas antes que el cliente final. Esa es la única medida de éxito de la capa de observabilidad.

Como implantadora de IA, nuestro trabajo no termina cuando el agente responde bien en una demo. Termina cuando podemos enseñarle al cliente un dashboard donde se ve, semana a semana, que el sistema sigue cumpliendo lo que prometió y que cuando algo se desvía, alguien se entera a tiempo. Esa es la diferencia entre un proyecto de IA y un experimento caro.

Errores típicos que vemos al evaluar agentes IA

Después de implantar agentes en sectores muy distintos, los errores se repiten:

• Tratar la observabilidad como “fase 2” y nunca llegar a ella.
• Confiar solo en el ojo de un humano que mira el chat de vez en cuando.
• Confundir evals con tests unitarios. Los evals son probabilísticos, los tests son deterministas. Necesitas ambos.
• No versionar prompts ni datasets. Sin versiones, no hay forma de saber qué cambió cuando algo empeoró.
• Calibrar al LLM-juez una vez y olvidarse. Los jueces también drift.
• Medir solo métricas técnicas y nunca métricas de negocio. Termina en un agente “técnicamente impecable” que nadie usa.
• Confiar en el proveedor del modelo para decidir qué medir. Tu caso de uso es tuyo. Tus métricas también.

Cualquiera de estos errores es resoluble. Lo que no es resoluble es no haberse planteado nunca el problema.

Conclusión: si no lo mides, no lo tienes

Implantar IA en empresa sin observabilidad es como contratar a un comercial sin revisarle el pipeline. Igual está funcionando, igual no, y para cuando te enteras ya has perdido medio año.

Si estás pensando en poner agentes IA en producción, o si ya los tienes y empiezas a sospechar que no sabes del todo qué hacen, hablamos. En Everglow auditamos agentes existentes, montamos la capa de evaluación desde cero o entramos a operar el sistema completo, según haga falta. Puedes escribirnos por contacto y miramos tu caso concreto.

Lo que no recomendamos: seguir adelante sin instrumentar. En IA, lo que no se mide se rompe. Y cuando se rompe, ya es tarde.