Observabilidad de agentes de IA: tracing, métricas, logs y evals

La observabilidad de agentes de IA hace visible el funcionamiento interno de un agente autónomo mediante tracing (spans sobre el razonamiento y las llamadas a herramientas), métricas (latencia, tokens, costes, tasa de éxito), logs estructurados y evals continuas. Responde a por qué un agente decidió lo que decidió y es el requisito previo para poder depurar, asegurar y auditar agentes multipaso en producción.

A diferencia de un servicio web clásico, un agente no toma una única decisión de solicitud y respuesta, sino que en cada tarea pasa por varias rondas de razonamiento con llamadas a herramientas intercaladas. Precisamente esta naturaleza multietapa deja ciega a la monitorización convencional: un HTTP 200 no dice nada sobre si se llamó a la herramienta correcta con los argumentos correctos o si el modelo se desvió a mitad de camino.

Los tres puntos clave, de entrada:

• La observabilidad para agentes consta de cuatro pilares. Tracing, métricas, logs y evals. Encajan entre sí: la traza aporta la ruta, las métricas aportan la agregación, los logs aportan el contexto y las evals aportan el juicio de calidad.
• Sin tracing, los agentes son imposibles de depurar. Solo una traza jerárquica sobre todos los spans de razonamiento y de llamadas a herramientas muestra en qué paso se rompió una cadena de varias etapas.
• La residencia de datos es un criterio obligatorio. Como las trazas contienen prompts y respuestas, es decir, potencialmente datos de clientes, el backend de observabilidad es en sí mismo un objeto de cumplimiento para las empresas B2B en Europa (Langfuse autoalojado en la UE, Datadog EU, Honeycomb EU).

Por qué los agentes sin tracing son imposibles de depurar

Un agente es no determinista. La misma solicitud puede dar lugar a llamadas a herramientas distintas, a un número diferente de rondas de razonamiento y a resultados diferentes. Cuando una ejecución falla o produce una respuesta incorrecta en lo funcional, sin tracing no hay forma fiable de aislar la causa. Posibles fuentes de error en una sola solicitud:

• El LLM razonó mal y eligió una herramienta inadecuada.
• La herramienta se llamó con argumentos erróneos.
• El paso de recuperación (RAG) trajo los documentos equivocados.
• Un guardrail o un filtro de PII intervino y modificó el contexto.
• Una versión del modelo cambió en el servidor (las API gestionadas actualizan los modelos según el calendario del proveedor).

Un log de salida plano no distingue estos casos. El tracing hace visible cada uno de estos pasos como un span propio, ordenado en el tiempo y dentro de la cadena causal. Así, la depuración pasa de «adivinar a partir del resultado final» a «encontrar el span concreto que se rompió». En la arquitectura ocurre lo mismo: los service meshes ofrecen observabilidad a nivel de red, y los stacks de agentes compuestos por muchos microservicios (orquestador, servidor de herramientas, memory store, base de datos vectorial, servicio de recuperación, servicio de guardrails) solo se pueden controlar con una capa de observabilidad de extremo a extremo.

Los cuatro pilares de la observabilidad de agentes

Tracing: spans sobre el razonamiento y las llamadas a herramientas

Una traza representa una solicitud completa del agente como un árbol. El span raíz abarca toda la solicitud; de él cuelgan spans anidados para cada llamada al LLM, cada llamada a herramienta, cada paso de recuperación y cada comprobación de guardrail. Cada span lleva entradas y salidas, además de atributos como el nombre del modelo, los tokens de prompt y de completion, la latencia y, derivados de ellos, los costes. Esta estructura jerárquica es la diferencia decisiva frente al log de solicitudes clásico y plano.

Métricas: latencia, tokens, costes, tasa de éxito

Las métricas agregan datos de muchas trazas. Cuatro señales forman el núcleo:

• Latencia, de extremo a extremo y por ronda de llamadas a herramientas. Entre las regiones de Azure Germany West Central (Fráncfort) y East US, Microsoft mide una mediana de 94 ms de ida y vuelta (estadística de latencia de Azure, a fecha de julio de 2026). Un agente en Fráncfort que llama a una API en el este de EE. UU. paga ese tiempo en cada llamada. Con varias rondas de herramientas, se va sumando.
• Tokens (prompt y completion) por span como base para la atribución de costes.
• Costes por solicitud, por equipo y por caso de uso.
• Tasa de éxito, la proporción de tareas completadas correctamente.

Logs: contexto estructurado

Los logs estructurados completan los spans con contexto detallado: respuestas en bruto de las herramientas, reintentos, activaciones de guardrails, contextos truncados. Lo importante es la correlación: cada entrada de log debería poder asignarse a un span concreto mediante el ID de traza; si no, vuelve a aparecer un punto ciego.

Evals: la calidad como parte de la observabilidad

Las evals son la señal que el tracing por sí solo no ofrece: la evaluación sistemática de la calidad del resultado. Normalmente se evalúan la tasa de éxito, la corrección de las llamadas a herramientas (¿se llamó a la herramienta correcta con los argumentos correctos?) y la calidad de las respuestas, mediante heurísticas, un conjunto de datos de referencia o «LLM-as-a-Judge». Lo decisivo en contextos regulados: las evals y las versiones de prompt se etiquetan en el gateway o en la plataforma de observabilidad con versiones fijas del modelo. Así, cada juicio de calidad se puede asignar a una versión concreta de modelo y de prompt. Si un agente está clasificado como sistema de alto riesgo según el Reglamento de IA, esta asignación facilita las evidencias exigidas, por ejemplo sobre precisión y solidez según el art. 15 y sobre los procedimientos de validación y prueba que debe incluir la documentación técnica según el art. 11 y el anexo IV.

Matriz de señales y herramientas

La siguiente tabla asigna a cada señal de observabilidad su magnitud de medición y una herramienta típica (a fecha de 2026).

El stack de observabilidad para LLM: resumen de herramientas

Para la capa de observabilidad, las herramientas principales son estas (a fecha de 2026):

• LangSmith, la plataforma de tracing y evals del entorno de LangChain/LangGraph, como servicio gestionado. Muy sólida si el agente ya se basa en ese framework. Con un servicio gestionado, comprueba de antemano dónde se almacenan las trazas.
• Langfuse, open source y, según su documentación de autoalojamiento, operable en infraestructura propia, es decir, autoalojable en la UE (centro de datos propio o región de la UE). Encaja tanto con arquitecturas reguladas con observabilidad controlada por el cliente como con configuraciones cloud ligeras que mantienen las trazas en la UE conforme al RGPD.
• Arize Phoenix, observabilidad y evaluación bajo la Elastic License 2.0, autoalojable de forma gratuita y, por tanto, una alternativa a Langfuse.
• OpenTelemetry para LLM / OpenInference, el estándar de trazas neutral respecto al proveedor. Si instrumentas con las GenAI Semantic Conventions, el backend sigue siendo intercambiable: un argumento importante contra el lock-in. TGI de Hugging Face, por ejemplo, ya exportaba trazas de OpenTelemetry y métricas de Prometheus antes de que el proyecto pasara a modo de mantenimiento.
• Datadog EU / Honeycomb EU, backends de APM consolidados con región en la UE: Datadog opera el sitio EU1 en Alemania y Honeycomb almacena los datos según la región de EE. UU. o de la UE elegida. Ambos son la vía gestionada si los datos deben quedarse en la UE.

Un punto arquitectónico importante: el gateway de IA (LiteLLM, Portkey, Kong) a menudo ya asume parte de la observabilidad. Los gateways suelen encargarse del failover entre varios proveedores, la gestión de claves virtuales, los presupuestos por equipo, la observabilidad, los guardrails y el enmascaramiento de PII. En la práctica, el gateway atribuye tokens y costes, mientras que la plataforma de tracing guarda la ruta de razonamiento y las evals: juntos dan la imagen completa.

Ejemplo de traza: la ejecución de un agente, desglosada

El siguiente pseudoejemplo muestra cómo se ve la ejecución de un agente de soporte como árbol de spans. Las cifras son ilustrativas.

```
TRACE id=ag-7f3c "Solicitud del cliente: anular factura" total: 4.210 ms | 3.320 tokens | 0,041 USD
├─ SPAN llm.reason model=gpt-4.x 620 ms | in 540 / out 80 Tok "Plan: consultar cliente+factura"
├─ SPAN tool.crm_lookup mTLS, in-VPC 180 ms | status=200 args={cliente_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 resultados query="política de anulación B2B"

├─ SPAN llm.reason model=gpt-4.x 710 ms | in 1.980 / out 130 Tok "Anulación permitida, llamar a la herramienta"
├─ SPAN tool.invoice_void in-VPC 240 ms | status=200 args={factura:RE-2026-0317}
├─ SPAN guardrail.pii redaction 40 ms | 0 resultados
└─ SPAN llm.compose model=gpt-4.x 2.325 ms| in 380 / out 210 Tok texto de respuesta al cliente
EVAL tool_call_correct=PASS | answer_quality=0,92 | etiquetado: model=gpt-4.x, prompt=v7
```

Lo que consigue esta traza y un log de salida no: si la anulación hubiera fallado, el árbol muestra al instante si tool.invoice_void devolvió un estado de error, si retrieval.vector trajo la política equivocada o si el segundo span llm.reason tomó una decisión errónea. La mayor partida de latencia (llm.compose, 2.325 ms) se reconoce de inmediato como candidata a optimización. Y la línea de eval vincula el juicio de calidad a la versión del modelo y del prompt: la base para el rollback y la auditoría.

Relación con la monitorización del artículo pilar sobre seguridad

El tracing es una señal de depuración y también una señal de seguridad. Los agentes tienen un «radio de impacto» inusualmente alto: un agente comprometido puede llamar a muchas herramientas. La traza de extremo a extremo proporciona exactamente el registro de auditoría que hace trazable esta superficie de ataque: qué agente llamó a qué herramienta, cuándo y con qué identidad. Si un agente es un sistema de alto riesgo según el Reglamento de IA, esta traza constituye a la vez la base técnica para el registro automático de eventos que exige el art. 12. La traza complementa los controles del ámbito de la seguridad y la identidad: tráfico de salida con denegación por defecto, allowlist y registro en el gateway, una cuenta de servicio por cada par agente-herramienta en lugar de cuentas compartidas y la vinculación de cada llamada a la identidad del usuario mediante una cadena de token exchange. La observabilidad a nivel de red mediante un service mesh (mTLS, workload identity, traffic shaping) cierra el círculo. Los patrones detallados de medición y control sobre tráfico de salida, identidad y monitorización se tratan en el artículo pilar sobre seguridad; la capa de observabilidad aporta para ello la base de telemetría. La economía concreta de los tokens y el modelado de costes, por su parte, son objeto del artículo pilar sobre FinOps.

Para agencias y responsables B2B

Para las agencias de marketing que crean flujos de trabajo con agentes para sus clientes, la observabilidad es el entregable que separa un piloto de un sistema productivo auditable: solo la traza, las evals y un backend conforme con la normativa de la UE hacen que un agente sea operable, facturable y defendible ante la protección de datos del cliente. Para los responsables B2B en Europa: elige el backend de observabilidad con el mismo cuidado que la región cloud. Langfuse autoalojado, Datadog EU o Honeycomb EU mantienen los prompts y las respuestas dentro de la UE, y el tracing con OpenTelemetry, neutral respecto al proveedor, protege frente al lock-in. Blck Alpaca, desde Viena, diseña y opera infraestructura de agentes con esta capa de observabilidad desde el principio, incluidos tracing, entorno de evals y un backend conforme con el RGPD. Contacta con nosotros si quieres llevar un agente de la fase piloto a una operación productiva auditable.