Observabilidad de agentes de IA: qué instrumentar primero

Actualizado: 2026-05-03

Un agente de IA mal instrumentado es una caja negra que gasta dinero. Las llamadas al modelo son caras, las llamadas a herramientas pueden ser caras también, y el flujo de decisión suele ser no determinista. Sin una instrumentación pensada para este tipo de sistema, cuando algo falla o cuando la factura llega más alta de lo esperado, el equipo se encuentra leyendo registros sueltos e intentando reconstruir la secuencia a mano. Después de año y medio operando agentes en productos con usuarios reales, este artículo recoge qué hay que instrumentar primero, qué estándares han ido emergiendo y qué errores caros se evitan teniendo trazas bien hechas desde el primer día.

Puntos clave

• Los agentes rompen el molde de la observabilidad tradicional en tres aspectos: una sola entrada puede desencadenar docenas de llamadas encadenadas, cada llamada tiene coste económico explícito en tokens, y el contenido de entradas y salidas es relevante para depurar.
• OpenTelemetry ha consolidado durante 2025 un conjunto de convenciones semánticas para IA generativa que define cómo nombrar los spans, qué atributos usar y cómo representar la relación entre el agente y las herramientas que invoca.
• Las cinco métricas agregadas a instrumentar siempre: coste por conversación, latencia extremo a extremo, tasa de finalización exitosa, número medio de pasos por conversación y tasa de uso de herramientas por paso.
• El fallo más caro en producción es no tener forma de responder a la pregunta “¿por qué esta conversación costó treinta euros?”.
• La ruta mínima recomendada: OpenTelemetry en el SDK del modelo, backend tipo Langfuse, cinco métricas de negocio básicas en un panel visible, evaluación automática sencilla sobre una muestra del tráfico.

Por qué los sistemas clásicos no bastan

La observabilidad tradicional se construyó alrededor de servicios HTTP síncronos: una petición entra, ocurren llamadas a base de datos y a otros servicios, y una respuesta sale. Las trazas distribuidas capturan ese árbol de llamadas, las métricas cuentan peticiones por segundo y percentiles de latencia, y los registros dan contexto. Con ese conjunto, un equipo acostumbrado puede responder a la mayoría de preguntas operativas.

Los agentes rompen ese molde en tres aspectos:

• Docenas de llamadas encadenadas: una sola entrada de usuario puede desencadenar decenas de llamadas al modelo encadenadas, con ramificaciones y bucles cuya estructura solo se conoce después de la ejecución.
• Coste económico explícito: cada llamada lleva asociado un coste en tokens de entrada y salida que importa tanto o más que la latencia.
• Contenido relevante para depurar: a diferencia de un JSON de API normal, el contenido de las entradas y salidas es necesario para entender por qué el agente tomó una decisión u otra.

La primera capa: traza por ejecución

Lo primero que hay que tener es una traza por cada ejecución de agente, con cada llamada al modelo y cada llamada a herramienta como span anidado. OpenTelemetry ha consolidado durante 2025 un conjunto de convenciones semánticas para IA generativa que define cómo nombrar los spans, qué atributos usar y cómo representar la relación entre el agente y las herramientas que invoca. Todos los SDK principales de LLM (OpenAI, Anthropic, Google, Azure) tienen ya instrumentación automática que emite estos spans con cambios mínimos de código.

Lo que hay que capturar en cada span de llamada al modelo:

• Nombre del modelo y parámetros de muestreo (temperatura, tope de tokens).
• Tokens de entrada y salida contados.
• Coste estimado en la moneda del proveedor.
• Tiempo de primera emisión si es streaming y tiempo total.
• Mensajes de entrada y texto o llamadas a función de salida.

Este último punto es delicado porque esos contenidos pueden incluir datos personales, y la configuración debe permitir redactarlos o hashearlos según la política de la organización.

Para cada llamada a herramienta, el span debe capturar el nombre de la herramienta, los argumentos, el resultado o error, y el tiempo invertido. El contexto de OpenTelemetry debe propagarse hasta las herramientas que llaman APIs externas para poder ver el árbol completo.

La segunda capa: métricas agregadas

Trazas sueltas no dan la foto. Hacen falta métricas agregadas que permitan mirar el comportamiento del sistema en conjunto. Las cinco que conviene instrumentar siempre son:

1. Coste por conversación en la moneda del proveedor.
2. Latencia de extremo a extremo vista por el usuario.
3. Tasa de finalización exitosa frente a abandono o error.
4. Número medio de pasos por conversación.
5. Tasa de uso de herramientas por paso.

Con esas cinco se puede responder a las preguntas operativas habituales sin bucear en trazas individuales: si el coste medio sube de repente, si una versión nueva del modelo empeora la tasa de finalización, si una herramienta nueva está dando problemas o se está sobreusando.

A partir de ahí vienen métricas más específicas del dominio. Si el agente tiene un camino feliz esperado (una reserva completada o una consulta resuelta), conviene instrumentar la tasa de éxito en ese camino. Si hay presupuestos por usuario, conviene alertar cuando una conversación se acerca al límite.

La tercera capa: evaluaciones sobre producción

La observabilidad clásica termina ahí, pero los agentes necesitan una capa más: evaluaciones que se ejecutan sobre las conversaciones reales o muestras de ellas para medir calidad. No basta con saber que la conversación terminó; hay que saber si terminó bien. Las técnicas en uso son variadas: anotación manual de muestras, juicios por modelo (LLM como juez) contra criterios definidos, detección de patrones específicos como rechazos innecesarios o alucinaciones detectables.

Lo que ha visto funcionar es una pirámide: una fracción pequeña de conversaciones evaluadas por humanos, una fracción mayor evaluada por un modelo juez, y el resto con métricas heurísticas baratas. Los tres niveles se calibran entre sí periódicamente para asegurar que el juez automático no se desvía de los humanos de referencia. Este enfoque complementa lo que describimos en testing con IA: el problema del determinismo: las evaluaciones sobre producción son la capa de observabilidad que los tests offline no pueden sustituir.

El patrón de fallo más común

El fallo más caro que aparece en equipos operando agentes en producción es no tener forma de responder a la pregunta “por qué esta conversación costó treinta euros”. La conversación ocurrió, el coste está en la factura, pero los registros no contienen el detalle suficiente para decir si fue un bucle del agente, un prompt del usuario que llenó la ventana de contexto, una herramienta mal configurada o un modelo escogido mal.

Sin esa trazabilidad el equipo no puede evitar que vuelva a pasar, y la factura mensual de LLM se convierte en una caja negra que crece sin explicación.

La cura es instrumentar desde el primer día, aunque parezca un sobrecoste. Los agentes empiezan pequeños y crecen rápido; montar las trazas cuando ya tienes miles de conversaciones diarias es mucho más caro que haberlo hecho al principio.

Una ruta mínima

Para un equipo que empieza hoy con un agente en producción, la ruta mínima recomendada es clara:

1. Activar instrumentación OpenTelemetry en el SDK del modelo usado, con las convenciones semánticas de IA generativa.
2. Enviar esas trazas a un backend que entienda conversaciones: Langfuse o similar funcionan bien, o un Grafana Tempo con paneles hechos a mano si prefieres auto-hospedado.
3. Definir cinco métricas de negocio básicas y ponerlas en un panel visible.
4. Instalar una evaluación automática sencilla, aunque sea un modelo juez con tres criterios, sobre una muestra del tráfico.

# Ejemplo mínimo con instrumentación OpenTelemetry automática
from opentelemetry import trace
from opentelemetry.instrumentation.openai_v2 import OpenAIInstrumentor
import openai

OpenAIInstrumentor().instrument()
tracer = trace.get_tracer("agente.reservas")

with tracer.start_as_current_span("conversacion", attributes={"usuario.id": uid}) as span:
    respuesta = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=mensajes,
        tools=herramientas,
    )
    span.set_attribute("agente.pasos", len(respuesta.choices[0].message.tool_calls or []))

Ese cuarteto cubre el ochenta por ciento del valor. Después se añaden capas más finas según crece el sistema: trazas propagadas a herramientas internas, presupuestos por usuario, evaluaciones comparativas entre versiones del modelo, alertas específicas.

Mi lectura

La observabilidad de agentes pasó en 2025 de ser un hueco incómodo a tener respuestas aceptables. Las convenciones semánticas de OpenTelemetry para IA generativa, la maduración de plataformas como Langfuse y Phoenix, y la incorporación de instrumentación automática en los SDK de los proveedores grandes hacen que el coste de entrada sea hoy asumible incluso para equipos pequeños. No hay excusa para operar agentes a ciegas.

Lo que falta todavía es estandarización plena en cómo representar estados intermedios del agente, ramificaciones de planificación y memoria persistente. En eso el ecosistema está moviéndose rápido y las convenciones cambiarán en los próximos dieciocho meses. Lo prudente para un equipo es adoptar las convenciones actuales asumiendo que habrá migración; la alternativa, construir algo propio desde cero, casi nunca envejece bien.

Conclusión

Instrumentar pronto, instrumentar con convenciones abiertas, y revisar cuando aparezcan versiones más consolidadas es la política que mejor ha funcionado. La observabilidad no es un añadido que se construye cuando el agente ya está en producción; es parte del diseño desde el primer día.