Puntos clave
- La observabilidad de agentes de IA es la disciplina de instrumentar, trazar y evaluar sistemas agénticos en producción. En 2026 es una especialidad propia, distinta del APM tradicional y del logging de llamadas sueltas a un LLM.
- Un agente falla en secuencias multi-turno y multi-herramienta: la respuesta equivocada del paso 10 suele originarse en una llamada del paso 3 o en una recuperación del paso 1. Sin traza completa, el diagnóstico es adivinación.
- La regla que ordena todo: los evals te dicen si el agente es bueno; la monitorización te dice qué cuesta. Necesitas ambos, y miden cosas distintas.
- Sin observabilidad, un agente en producción es un sistema no auditable. Es el motivo más frecuente por el que un piloto que funcionaba deja de funcionar y nadie sabe explicar por qué.
La observabilidad de agentes de IA consiste en registrar cada paso de la ejecución de un agente —razonamiento, llamadas a herramientas, recuperaciones y respuestas— y evaluar su calidad de forma sistemática. Se diferencia de la monitorización clásica en que el fallo no es una excepción, sino una decisión plausible pero incorrecta. Sin trazas por paso y evals automatizados, no hay forma de saber si un agente está funcionando.
Por qué un agente no se depura como una aplicación normal
En software tradicional, un fallo produce un error: una excepción, un código 500, un test en rojo. En un agente de IA, el fallo produce una respuesta bien redactada y equivocada. No hay stack trace. No hay señal.
Un agente encadena decisiones: interpreta la petición, elige qué herramienta usar, la invoca con unos parámetros, lee el resultado, decide el siguiente paso. Una ejecución real tiene fácilmente entre 5 y 30 pasos. Cuando el resultado final es malo, la causa raíz casi nunca está en el último paso: está en una recuperación pobre al principio o en un parámetro mal formado a mitad de cadena.
Lo que la observabilidad de agentes NO es: no es guardar el prompt y la respuesta final. Ese log sirve para una llamada suelta a un LLM, no para un sistema que toma decisiones encadenadas. Tampoco es el APM clásico: Datadog te dice que la petición tardó 4 segundos, no que el agente eligió la herramienta equivocada.
La analogía: depurar un agente sin trazas por paso es como investigar un accidente de avión teniendo solo la posición final del aparato, sin caja negra.
Los tres niveles: trazas, evals y monitorización
Se confunden constantemente y son tres cosas distintas.
1. Trazas (tracing). El registro estructurado de cada paso de una ejecución: qué recibió el agente, qué razonó, qué herramienta llamó, con qué parámetros, qué devolvió y cuánto tardó. Es la materia prima. Sin trazas no existe ninguno de los otros dos niveles. El estándar de facto en 2026 es OpenTelemetry con convenciones semánticas para GenAI, lo que evita atarse a un proveedor.
2. Evals (evaluaciones). La medición sistemática de la calidad de esas ejecuciones. Se dividen en dos:
- Evals offline: se ejecutan contra un dataset fijo de casos, antes de desplegar. Responden a "¿este cambio de prompt mejora o empeora?".
- Evals online: se ejecutan sobre tráfico real en producción, con muestreo. Responden a "¿el agente sigue funcionando bien esta semana?".
3. Monitorización operativa. Las métricas que sostienen el negocio: coste por ejecución, latencia p95, throughput, tasa de error, consumo de tokens. Son las que responden a "¿esto es sostenible a escala?".
| Nivel | Responde a | Cuándo se ejecuta | Sin esto pasa... |
|---|---|---|---|
| Trazas | Qué ocurrió exactamente | Siempre, en cada ejecución | No puedes diagnosticar nada |
| Evals offline | ¿Este cambio mejora? | Antes de cada despliegue | Cambias prompts a ciegas |
| Evals online | ¿Sigue funcionando hoy? | Muestreo sobre tráfico real | Degradación silenciosa |
| Monitorización | ¿Cuánto cuesta y cuánto tarda? | Continuo | Sorpresas de coste y latencia |
El error que más vemos: empresas que montan monitorización operativa (tienen dashboards de latencia y de tokens) pero no tienen evals. Saben perfectamente cuánto les cuesta un agente y no tienen ni idea de si acierta.
Qué medir realmente en un agente
Las métricas de un chatbot no sirven para un agente. Estas son las que importan, ordenadas por lo que suelen revelar primero:
- Precisión en la selección de herramienta. ¿Eligió la función correcta? Es el fallo número uno y el más barato de detectar.
- Validez de los parámetros. ¿Llamó a la función correcta con argumentos correctos? Un
buscar_clientecon el identificador equivocado devuelve datos válidos de otra persona: es el fallo más peligroso porque no parece un fallo. - Calidad de la recuperación (si hay RAG). ¿Los fragmentos recuperados contenían la respuesta? Si la recuperación falla, todo lo demás es ruido. Se mide con context recall y context precision.
- Fidelidad a la fuente (groundedness). ¿La respuesta se apoya en lo recuperado o el modelo rellenó huecos? Es la métrica que detecta alucinaciones en sistemas RAG.
- Tasa de finalización de tarea. ¿La ejecución terminó cumpliendo el objetivo, o se quedó en bucle, se rindió o pidió intervención?
- Pasos por tarea. Un agente que necesita 22 pasos para algo que debería costar 4 está mal diseñado, aunque acierte. Es un indicador temprano de degradación.
- Coste y latencia p95 por tarea completada. No por llamada: por tarea. Es la única unidad que se puede comparar con el proceso manual que sustituye.
- Tasa de escalado a humano. Cuándo el agente cede el control. Debería ser una métrica objetivo, no un fallo.
Una advertencia útil: usar un LLM como juez (LLM-as-a-judge) para puntuar respuestas es una técnica válida y hoy estándar, pero debe calibrarse contra etiquetas humanas en una muestra. Un juez no calibrado produce números que suben mientras la calidad baja.
Datos clave del mercado
- La observabilidad de agentes se ha consolidado en 2026 como disciplina de ingeniería propia, separada del APM tradicional, precisamente porque los agentes fallan en secuencias multi-turno donde la causa del error está varios pasos antes del síntoma (Arize, 2026).
- El 46% de las organizaciones señala la integración con sistemas existentes como su principal reto en despliegues de agentes, y el tiempo mediano hasta valor es de 5,1 meses. Los despliegues que no miden nada son los que engordan esa mediana.
- Solo el 31% de las empresas tiene al menos un agente en producción, frente a un 62% que experimenta con ellos. El salto de piloto a producción es, en la práctica, un problema de observabilidad y control.
Nuestra opinión: la brecha entre "experimentamos con agentes" y "tenemos agentes en producción" se explica sobre todo por la incapacidad de demostrar que el agente funciona de forma consistente. Y eso no se demuestra con demos, se demuestra con evals.
El stack: qué herramientas se usan en 2026
No hay una respuesta única, pero sí categorías claras:
- Plataformas de trazas y evals integradas: Langfuse (open source, self-hostable, la opción por defecto cuando hay requisitos de RGPD o dato sensible), LangSmith (si ya usas LangChain/LangGraph), Braintrust y Arize Phoenix/AX (fuertes en evaluación sistemática).
- Observabilidad general con módulo LLM: Datadog LLM Observability y similares, si tu equipo ya vive en esa herramienta y quieres una sola ventana.
- Open source ligero: Opik (Comet), MLflow para tracking de experimentos.
Nuestra recomendación pragmática: empieza con OpenTelemetry como capa de instrumentación y una plataforma que la consuma. Instrumentar con un estándar abierto te permite cambiar de proveedor de observabilidad sin reescribir el agente, y en un mercado que se consolida a esta velocidad eso vale más que cualquier funcionalidad concreta.
Si manejas dato personal o regulado, la decisión se simplifica: self-hosted. Las trazas de un agente contienen, por definición, todo lo que el agente ha visto. Eso incluye datos de clientes. Enviar trazas completas a un SaaS externo sin evaluar el tratamiento de datos es un problema de RGPD esperando a ocurrir.
Casos de uso habituales
Caso 1 — Degradación silenciosa tras un cambio de modelo.
- Problema: un agente de soporte empieza a escalar más casos a humanos tras una actualización de versión del modelo. Nadie relaciona ambas cosas durante semanas.
- Solución: evals online con muestreo diario y alerta sobre la tasa de finalización de tarea.
- Stack: OpenTelemetry + plataforma de evals + LLM-as-a-judge calibrado.
- Resultado: la caída se detecta en horas, no en semanas.
Caso 2 — Coste que se dispara sin que crezca el uso.
- Problema: el gasto en tokens sube un 40% mensual con el mismo volumen de peticiones.
- Solución: métrica de pasos por tarea. El agente había empezado a entrar en bucles de reintento por un cambio en una API externa.
- Stack: trazas por paso + alerta sobre percentil de pasos por ejecución.
- Resultado: se identifica la herramienta que devuelve errores mal formados y se corrige el reintento.
Caso 3 — Respuestas correctas sobre documentos equivocados.
- Problema: un agente RAG responde con seguridad usando fragmentos de la versión antigua de un procedimiento.
- Solución: medir context precision y añadir filtro por versión de documento en la recuperación.
- Stack: evaluación de recuperación + metadatos de versión en la base vectorial.
- Resultado: el problema se identifica como de recuperación, no de modelo, que es donde todos miraban.
Cómo implementarlo paso a paso
- Instrumenta antes de escalar. Añade trazas desde el primer prototipo, con OpenTelemetry si es posible. Instrumentar un agente que ya está en producción cuesta el triple y obliga a tocar código en caliente.
- Construye un dataset de evaluación con casos reales. 30-50 casos bien elegidos, sacados de tráfico real, valen más que 500 sintéticos. Incluye los casos raros que ya han fallado alguna vez.
- Define qué es "correcto" para cada caso. Este es el paso que la gente se salta y sin el cual nada de lo demás funciona. Si no puedes escribir el criterio de éxito, tampoco puedes automatizarlo.
- Automatiza los evals offline en el despliegue. Ningún cambio de prompt, modelo o herramienta llega a producción sin pasar el dataset. Trata los prompts como código.
- Activa evals online con muestreo. Un porcentaje del tráfico real evaluado a diario. Es lo que detecta la degradación que los tests offline no ven.
- Alerta sobre las métricas que importan: caída de finalización de tarea, subida de pasos por tarea, subida de escalados. No alertes sobre latencia y coste solamente.
- Cierra el bucle. Cada fallo detectado en producción se convierte en un caso nuevo del dataset de evaluación. Sin este paso, el sistema no mejora, solo se observa.
Errores comunes (y cómo evitarlos)
Error: montar la observabilidad después del incidente. → La realidad: cuando llega el incidente ya no tienes las trazas de lo que pasó. La instrumentación es preventiva por definición.
Error: registrar solo entrada y salida final. → La realidad: en una cadena de 15 pasos, el log de extremos no dice nada. Necesitas el paso intermedio donde se torció.
Error: confundir monitorización con evaluación. → La realidad: saber que el agente responde en 2 segundos y consume X tokens no dice si acierta. Son preguntas distintas y requieren instrumentos distintos.
Error: usar LLM-as-a-judge sin calibrar. → La realidad: un juez no contrastado contra etiquetas humanas puede dar 90% de acierto mientras los usuarios reales se quejan. Calibra sobre una muestra antes de fiarte del número.
Error: dataset de evaluación con casos fáciles. → La realidad: un dataset que el agente aprueba siempre no mide nada. Debe contener los casos ambiguos y los que ya han fallado.
Error: enviar trazas con datos personales a un SaaS sin evaluar el tratamiento. → La realidad: las trazas contienen todo lo que el agente ha visto. Con dato regulado, self-hosted o anonimización previa. No es un detalle de cumplimiento, es la decisión que condiciona la elección de herramienta.
Tiempos y esfuerzo realistas
- Instrumentación básica con trazas en un agente existente: 1-2 semanas, más si el agente se construyó sin abstracción de herramientas.
- Primer dataset de evaluación útil (30-50 casos con criterio de éxito definido): 1-2 semanas, y la mayor parte del tiempo se va en acordar qué es "correcto", no en escribir código.
- Evals automatizados en el pipeline de despliegue: 1 semana adicional una vez existe el dataset.
- Dónde está el esfuerzo real: no en las herramientas, que están maduras. Está en definir los criterios de calidad del negocio. Es una conversación de producto, no de infraestructura.
Métricas que medir desde el día 1: cobertura de trazas (porcentaje de ejecuciones instrumentadas completas), tasa de finalización de tarea, pasos por tarea, tasa de escalado a humano y coste por tarea completada. Si un agente lleva más de un mes en producción y no puedes contestar cuál es su tasa de acierto sobre casos reales, no está en producción: está suelto.
Preguntas frecuentes
¿Qué es la observabilidad de agentes de IA?
Es la práctica de instrumentar, trazar y evaluar sistemas agénticos en producción, registrando cada paso de la ejecución —razonamiento, llamadas a herramientas, recuperaciones y salidas— para poder diagnosticar fallos y medir calidad. Se diferencia del APM tradicional en que el fallo de un agente no es una excepción, sino una decisión plausible pero incorrecta.
¿Qué diferencia hay entre evals y monitorización?
Los evals miden si el agente hace bien su trabajo (precisión, fidelidad, finalización de tarea). La monitorización mide lo que cuesta operarlo (latencia, tokens, throughput, errores). Un agente puede tener métricas operativas perfectas y estar dando respuestas equivocadas.
¿Qué es un eval online y en qué se diferencia de uno offline?
Un eval offline se ejecuta contra un dataset fijo antes de desplegar y responde a "¿este cambio mejora?". Un eval online se ejecuta con muestreo sobre tráfico real y responde a "¿el agente sigue funcionando bien hoy?". Detectan problemas distintos y se necesitan los dos.
¿Sirve un LLM para evaluar a otro LLM?
Sí, es la técnica estándar en 2026 para evaluar a escala, pero debe calibrarse contra etiquetas humanas sobre una muestra. Un juez no calibrado produce puntuaciones estables que no se corresponden con la calidad percibida por los usuarios.
¿Puedo usar Datadog o New Relic para observar agentes de IA?
Sirven para las métricas operativas y para tener una sola ventana si tu equipo ya vive ahí, pero no cubren por sí solos la evaluación de calidad ni la traza semántica por paso. Lo habitual es combinar la herramienta corporativa con una plataforma específica de evals.
¿Cómo afecta el RGPD a las trazas de un agente?
Las trazas contienen, por definición, todo lo que el agente ha procesado, incluidos datos personales. Con dato regulado la opción sensata es una plataforma self-hosted o anonimización previa al envío. Es una decisión que conviene tomar antes de elegir herramienta, no después.
¿Cuántos casos necesito en un dataset de evaluación?
Entre 30 y 50 casos bien elegidos de tráfico real dan más señal que cientos de casos sintéticos. Lo importante es que incluyan los escenarios ambiguos y los fallos ya detectados, no los casos fáciles que el agente resuelve siempre.
¿Qué métrica avisa antes de que un agente se degrade?
Los pasos por tarea. Un aumento del número de pasos para resolver lo mismo suele preceder a la caída de la tasa de acierto y al aumento del coste, y aparece antes que las quejas de usuarios.
¿Tienes un agente en producción y no puedes demostrar que funciona?
En Naxia instrumentamos agentes con trazas por paso, datasets de evaluación construidos con tus casos reales y evals automatizados en el despliegue. Con estándares abiertos (OpenTelemetry) para que no dependas de un proveedor, y con opción self-hosted cuando hay dato regulado de por medio.
Si quieres pasar de "parece que funciona" a un número que puedas defender en un comité, habla con nosotros. Sin compromiso y sin powerpoints de 40 páginas.
O si prefieres, explora primero nuestro proceso de implementación.