Observabilidad de agentes de IA en producción: saber qué hace tu agente cuando ya nadie lo mira

Conviene deshacer primero una confusión frecuente. Las evals responden a una pregunta de laboratorio: dado un conjunto de casos de prueba que controlo, ¿qué porcentaje resuelve bien el agente? La observabilidad responde a una pregunta de campo: dado el tráfico real que no controlo, ¿qué está pasando? Son complementarias y ninguna sustituye a la otra: unas evals excelentes no detectan que el comportamiento del modelo subyacente cambió el martes, y una observabilidad excelente no te dice si la versión nueva del prompt es mejor que la anterior antes de desplegarla.

La relación entre ambas es un ciclo. Las trazas de producción alimentan el conjunto de evals con casos reales que no habías previsto; las evals validan los cambios antes de desplegar; y las evals continuas —ejecutadas periódicamente sobre muestras de producción— cierran el círculo detectando degradación en el mundo real. Los equipos que tratan evals y observabilidad como proyectos separados suelen acabar con dos herramientas y ningún ciclo.

La monitorización clásica de servicios gira en torno a latencia, errores y saturación. Con un agente hace falta eso y más, porque en la práctica conviven dos niveles de observabilidad. El técnico: latencia, errores, disponibilidad, tokens, coste, llamadas a herramientas, reintentos. Y el de comportamiento: si el agente resolvió de verdad la tarea, si eligió la herramienta correcta, si dio pasos de más, si escaló a humano cuando tocaba, si el usuario tuvo que repetir la pregunta, si están apareciendo tipos de petición nuevos.

La frase que resume por qué necesitas los dos: un agente puede estar perfectamente sano desde el punto de vista de infraestructura —respondiendo rápido, sin errores HTTP— y estar fallando como agente, o haciendo bien su trabajo a un coste absurdo. Estas son las cinco señales que cubren ambos niveles y que un equipo debería poder consultar en un panel, con su pregunta correspondiente. La tasa de éxito merece una nota previa: cómo se mide depende del caso de uso —una condición determinista, un resultado de negocio, el feedback del usuario, revisión humana o un juez LLM, que ayuda pero no es un oráculo—.

La unidad de observabilidad de un agente no es la petición HTTP: es la tarea, y una tarea son decenas de pasos —llamadas al modelo, invocaciones de herramientas, lecturas de contexto, decisiones de control—. Una traza es la reconstrucción completa de esa secuencia: qué entró en cada llamada, qué salió, cuánto tardó, cuántos tokens consumió y qué decidió hacer el agente a continuación. De ahí salen también las métricas que distinguen a un agente de un chatbot: número de pasos e iteraciones, reintentos, escalados y la tasa de acierto por herramienta. Si un agente depende de cinco herramientas, saber que el agente falla no basta: necesitas saber cuál de ellas está fallando, con qué frecuencia y qué hace el agente cuando ocurre. Sin trazas, depurar un incidente es arqueología; con ellas, es lectura.

La buena noticia es que no hay que inventar el formato. OpenTelemetry se está consolidando como la capa común de instrumentación para aplicaciones y agentes de IA: ya dispone de convenciones semánticas específicas para IA generativa y agentes —modelan la ejecución completa como un árbol de spans: la invocación del agente, cada llamada al modelo, cada ejecución de herramienta—, aunque es un área del estándar que sigue evolucionando con rapidez y conviene tratarla como tal. Instrumentar sobre ese estándar reduce la dependencia de una plataforma concreta, sin esperar que todas implementen hoy exactamente las mismas capacidades.

• Cada llamada al modelo: modelo e identificador de versión, tokens de entrada y salida, duración, parámetros relevantes.
• Cada llamada a herramienta: cuál, con qué argumentos, resultado o error, reintentos, timeouts y duración. De aquí sale la tasa de acierto por herramienta.
• El recorrido de la tarea: pasos e iteraciones, y las decisiones del bucle — por qué el agente siguió, reintentó, escaló a humano o terminó.
• Identificadores de correlación: tarea, sesión y usuario, para reconstruir la historia completa.
• La foto de versiones: agente, prompt, modelo, harness, herramientas disponibles y, si aplica, el índice o base de conocimiento. Una traza sin versiones explica qué ocurrió, pero puede no explicar por qué cambió.

Para quien nunca ha abierto una traza de agente en Langfuse, LangSmith o Phoenix, así se lee una tarea instrumentada — los tiempos y tokens son ilustrativos:

1. El usuario pide una tarea

   «prepara la propuesta para este cliente».

2. El agente interpreta la intención — 0,3 s.

3. Consulta la base de conocimiento — 0,5 s.

4. El modelo decide usar la herramienta del CRM — 1.240 tokens · 0,8 s.

5. Tool call buscarCliente() — 0,2 s · OK.

6. Tool call generarPropuesta() — 1,4 s · ERROR.

7. Reintento con argumentos corregidos — 1,1 s · OK.

8. El modelo redacta la respuesta final — 840 tokens · 1,2 s.

9. Tarea completada

   3 tool calls, 1 reintento, coste y latencia totales imputados a la tarea, resultado correcto.

El coste es la señal más particular de los sistemas con LLM, porque es la única que puede arruinar el caso de negocio sin que nada "falle". Un agente que resuelve la tarea dando cuatro vueltas de más no dispara ninguna alerta de errores: solo cuesta el triple. Y el modo de fallo extremo —el bucle que reintenta indefinidamente una herramienta rota— convierte un bug menor en una factura seria si nadie le puso techo.

Por eso el coste se gestiona en dos capas. La primera es contable: coste por tarea —y, mejor aún, coste por tarea exitosa, que suele decirle más a negocio que el coste por llamada al modelo: una versión que abarata cada llamada pero falla más tareas sale cara—, segmentado por tipo de tarea, por usuario o cliente cuando aplica, y comparado entre versiones para ver qué encareció cada cambio. La segunda es defensiva: límites que cortan la ejecución al superarse. Según el caso de uso convienen por tarea, por sesión, por usuario o cliente, o por periodo —no todos los agentes necesitan todos los niveles—, y los mecanismos son conocidos: techo de iteraciones y de tool calls, presupuesto de tokens o monetario, timeout total, circuit breaker sobre herramientas, backoff, fallback a un modelo más barato y escalado a humano. Un agente sin ningún límite de gasto es un sistema al que le falta una barrera de seguridad básica, independientemente de lo bien que funcione hoy.

Es el fenómeno más desconcertante para equipos que vienen del software tradicional: el sistema se degrada sin ningún despliegue. Las causas habituales son tres. El modelo subyacente puede cambiar de versión, quedar obsoleto o ser sustituido por el proveedor, y esos cambios pueden alterar el comportamiento de tu aplicación. Los datos sobre los que trabaja el agente cambian aunque el modelo no lo haga: la base de conocimiento envejece, los documentos del RAG se modifican, una API externa cambia su contrato, el knowledge layer se desincroniza. O el uso cambia: los usuarios descubren casos que no estaban en tu diseño y la distribución real de entradas se aleja de la que probaste. En la literatura verás estos fenómenos como deriva de modelo, de datos, de recuperación o de uso; el nombre importa menos que tener una señal que los delate.

Contra la deriva hay una defensa principal: evals recurrentes. Un subconjunto estable de casos de referencia ejecutado contra el sistema de producción con una frecuencia coherente con el volumen, la criticidad y el ritmo de cambio —continua o diaria en un sistema de alto tráfico, semanal en un agente interno tranquilo, y en cada despliegue siempre— detecta la degradación del modelo o del contexto aunque ningún usuario se haya quejado todavía. Y un muestreo periódico de tareas reales —revisado con juez LLM y con algo de ojo humano— detecta lo contrario: los casos nuevos que tus referencias no cubren, porque producción siempre contiene casos que el dataset original nunca anticipó. Cuando cualquiera de las dos señales cae del umbral, la conversación es concreta: qué cambió, desde cuándo, en qué casos.

• Fija la versión del modelo cuando el proveedor lo permita; si no, trata cada cambio de versión como un despliegue que hay que validar.
• Ejecuta una eval de referencia contra producción de forma recurrente — la frecuencia la marcan el tráfico y la criticidad, no una regla fija.
• Muestrea tareas reales cada semana y revisa una fracción con criterio humano.
• Vigila la distribución de entradas: longitud, idioma, tipo de petición. La deriva de uso precede a la caída de calidad.
• Registra el feedback explícito e implícito del usuario: correcciones, reintentos y abandonos son señal de calidad gratis.

El ecosistema se ha consolidado lo suficiente como para que la pregunta ya no sea si existe herramienta, sino cuál encaja con tu contexto. Los criterios que de verdad separan las opciones son cuatro: si necesitas alojarla tú mismo por sensibilidad de datos, si quieres evals y trazas en la misma plataforma, cuánto te ata al ecosistema de un framework concreto y si tu organización ya opera una plataforma de observabilidad que convenga aprovechar — los APM tradicionales ya no ofrecen solo visualización genérica de trazas: Datadog y Grafana tienen hoy productos específicos de observabilidad de LLM y agentes.

Para organizaciones con requisitos estrictos de datos —las trazas contienen prompts, y los prompts contienen información de negocio— la opción autoalojada tiene un atractivo evidente, y conecta con la misma lógica que lleva a algunas empresas a plantearse ejecutar los modelos en local: que el dato sensible no salga de casa.

Un panel que nadie mira no es observabilidad: es decoración. La diferencia la marcan las alertas, y en agentes las útiles no son las genéricas de infraestructura, sino las desviaciones respecto al comportamiento propio del sistema. El umbral correcto sale del baseline de cada agente y del riesgo del caso de uso, no de un porcentaje universal; lo que sí es universal es la lista de cosas que merecen despertarte.

El paso de madurez siguiente es convertir esas señales en SLO —objetivos de nivel de servicio— del agente, pactados con negocio: una tasa de éxito mínima, una latencia P95 máxima, un coste medio por tarea dentro de presupuesto, un tope de escalados a humano, disponibilidad de las herramientas críticas. Los números concretos son tuyos; la idea no: la observabilidad gana valor cuando deja de ser un panel que alguien mira de vez en cuando y se convierte en objetivos operativos medibles.

• El coste por tarea se separa de su línea base histórica.
• La latencia P95 sube de forma sostenida, o un componente concreto se vuelve lento.
• Una herramienta empieza a fallar, a devolver argumentos inválidos o a agotar timeouts.
• El número medio de iteraciones por tarea crece: el agente está dando vueltas.
• La tasa de éxito cae, o los escalados a humano aumentan.
• La eval de referencia cae por debajo del umbral acordado.
• Aparece en las trazas una versión de modelo o de prompt distinta de la esperada.

Nada de lo anterior exige un proyecto trimestral: puede implantarse de forma incremental, empezando por unas pocas piezas de alto impacto. Para un agente ya desplegado, este es el orden que convierte una caja negra en un sistema operable.

• Trazabilidad primero: cada llamada a modelo y a herramienta, con errores, latencias, tokens y la foto de versiones.
• Guardrails operativos: techo de pasos, timeout, presupuesto de ejecución y circuit breakers donde proceda.
• Definir el éxito: qué significa exactamente completar bien la tarea, y registrarlo como evento — sin esto no hay tasa de éxito posible.
• Dashboard mínimo: tasa de éxito, coste por tarea, latencia P95, errores por herramienta, iteraciones medias y escalados.
• Evaluación recurrente: el conjunto de referencia contra producción, con umbral y alerta por degradación.
• Cerrar el ciclo: convertir los fallos reales de producción en nuevos casos de eval.