Un agente de IA en producción ejecuta docenas de llamadas a modelos de lenguaje por segundo, cada una con su contexto, su historial de conversación y sus parámetros de inferencia. Cada llamada genera tokens de entrada y salida, consume tiempo de procesamiento y puede fallar de formas que nunca habías visto: el modelo devuelve JSON malformado, se queda en bucle repitiendo la misma pregunta, o simplemente decide que la mejor respuesta es inventarse datos. Y tú necesitas saber qué está pasando. Así que activas la telemetría completa: trazas distribuidas, métricas por llamada, logs estructurados con el contenido de cada prompt y respuesta. A los tres días, tu factura de observabilidad ha crecido un 400% y tu equipo de finanzas quiere explicaciones.
La observabilidad de sistemas con agentes de IA tiene un problema de volumen que no se parece a nada que hayas gestionado antes. No es solo que generen más datos: es que cada interacción produce telemetría rica, contextual y difícil de resumir. Un endpoint REST tradicional genera una traza con cinco o diez spans. Un agente de IA que resuelve una consulta de usuario puede generar cincuenta spans anidados, cada uno con atributos que incluyen fragmentos de texto, embeddings, puntuaciones de relevancia y metadatos de modelo. Y si quieres entender por qué el agente tomó una decisión concreta, necesitas ese contexto completo. Pero almacenar y consultar ese contexto a escala de producción te sale carísimo.
No es un problema marginal. Según una previsión de IDC que cita New Relic, las empresas ejecutarán colectivamente más de mil millones de agentes de IA en 2029. Cada uno de ellos generando telemetría. Si la estrategia de captura que diseñas hoy no escala económicamente, el problema no se va a resolver solo: va a multiplicarse.
Por qué los agentes de IA rompen tu presupuesto de observabilidad
La telemetría tradicional asume que la mayoría de las peticiones son similares entre sí y que puedes muestrear agresivamente sin perder información crítica. Si monitorizas un API que devuelve datos de productos, capturar el 1% de las trazas te da suficiente señal para detectar problemas de latencia o errores. Los agentes de IA no funcionan así. Cada conversación es única, cada decisión del agente depende del contexto previo, y los fallos más interesantes son los casos extremos que nunca volverán a repetirse exactamente igual.
Imagina que tu agente de soporte técnico responde mal a una pregunta específica sobre compatibilidad de versiones. El usuario reformula la pregunta tres veces, el agente consulta la base de conocimiento en cada intento, y finalmente devuelve información contradictoria. Si estás muestreando al 1%, probablemente no capturaste esa interacción. Y aunque la hubieras capturado, necesitas ver el historial completo de la conversación para entender qué salió mal. Eso significa almacenar no solo la traza de la última llamada, sino las cinco o seis llamadas anteriores con sus respectivos contextos.
El segundo problema es el tamaño de los atributos. Una traza típica de microservicios tiene atributos pequeños: identificadores, códigos de estado, duraciones. Una traza de agente de IA incluye el prompt completo enviado al modelo, la respuesta generada, los fragmentos de documentación recuperados por el sistema de búsqueda semántica, y los metadatos de evaluación. Un solo span puede llevar varios kilobytes de datos. Multiplica eso por cincuenta spans por interacción y por miles de interacciones al día, y tu backend de trazas empieza a quejarse.
Conviene notar que quienes diseñan los estándares ya vieron venir este problema. Las convenciones semánticas de OpenTelemetry para GenAI —todavía en estado Development a mediados de 2026, bajo el namespace gen_ai.*— no capturan el contenido de los prompts y respuestas por defecto. No es un olvido: es una decisión de diseño para evitar fugas de datos personales y, de paso, contener el volumen. Si quieres el contenido literal, tienes que activarlo explícitamente con la variable OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT. Esa elección por defecto te dice mucho sobre el problema: capturar todo el texto es la excepción que pagas a conciencia, no el comportamiento gratuito.
El dilema del muestreo: perder señal o perder dinero
El muestreo tradicional se basa en decisiones tomadas al inicio de la traza: decides si vas a capturarla antes de saber si será interesante. Con agentes de IA, lo interesante suele estar al final. El agente puede funcionar perfectamente durante nueve pasos y fallar en el décimo porque el modelo alucinó un nombre de función inexistente. Si decidiste no capturar esa traza al principio, perdiste la oportunidad de entender qué pasó.
El muestreo basado en cola (tail-based sampling), donde decides si conservar una traza después de verla completa, ayuda pero no resuelve el problema del coste. Para tomar esa decisión al final, el colector necesita haber recibido y bufferizado todos los spans de la traza. Sigues generando y transmitiendo toda la telemetría desde tus agentes hasta tu capa de recolección. El ahorro llega en el almacenamiento e indexado a largo plazo, no en la ingesta ni en el procesamiento. Y si tu proveedor de observabilidad cobra por datos ingestados, no por datos retenidos, el muestreo en cola no te salva la factura.
Algunas organizaciones optan por muestrear solo las interacciones que terminan en error o que superan cierto umbral de latencia. Es razonable, pero te pierdes un tipo de fallo crítico en agentes de IA: las respuestas técnicamente correctas pero funcionalmente inútiles. El agente responde rápido, sin errores HTTP, con JSON bien formado, pero el contenido es genérico, evasivo o directamente irrelevante. Esos fallos solo los detectas analizando el contenido de las respuestas, no sus metadatos técnicos.
Telemetría semántica: observar lo que el agente dice, no solo lo que hace
Aquí es donde la observabilidad de agentes de IA se vuelve conceptualmente diferente. No basta con medir latencias, tasas de error y consumo de recursos. Necesitas evaluar la calidad semántica de las respuestas: ¿el agente respondió a la pregunta real del usuario? ¿La información es precisa? ¿El tono es apropiado? Estas son preguntas que no puedes responder con métricas numéricas tradicionales.
Algunos equipos implementan evaluadores automáticos que analizan las respuestas del agente y generan puntuaciones de calidad —detección de alucinaciones, relevancia, toxicidad—. El detalle incómodo es que esos evaluadores son, a su vez, llamadas a modelos de lenguaje. En la práctica esto tiene un precio literal: en Datadog LLM Observability, por ejemplo, las llamadas que hace un evaluador cuentan como LLM spans facturables igual que cualquier otra. Acabas observando tu sistema de observabilidad con más llamadas a IA, lo cual añade latencia, coste y complejidad. Es como poner un espejo delante de otro espejo: puedes hacerlo, pero en algún momento tienes que decidir dónde parar.
La alternativa es hacer esa evaluación de forma asíncrona y sobre una muestra. Capturas todas las interacciones en un formato ligero, almacenas solo los identificadores y metadatos básicos, y luego ejecutas análisis de calidad sobre un subconjunto representativo. Pierdes la capacidad de detectar problemas en tiempo real, pero ganas en viabilidad económica. Es una compensación que muchos equipos terminan aceptando después de ver su primera factura mensual.
Contexto distribuido en sistemas con memoria
Los agentes de IA modernos no son stateless. Mantienen contexto entre llamadas: historial de conversación, preferencias del usuario, estado de tareas en progreso. Ese contexto puede vivir en memoria, en bases de datos vectoriales, en cachés distribuidas o en servicios de gestión de sesiones. Cuando algo falla, necesitas correlacionar la telemetría del agente con el estado de ese contexto en el momento exacto del fallo.
OpenTelemetry ayuda con la propagación de contexto entre servicios, pero no resuelve el problema de capturar el estado interno del agente. Si tu agente decide que la mejor respuesta a una pregunta es consultar tres fuentes diferentes y combinar los resultados, necesitas ver qué recuperó de cada fuente, cómo las priorizó y por qué eligió esa estrategia de combinación. Esa información no vive en los spans de las llamadas HTTP subyacentes: vive en la lógica del agente, y tienes que instrumentarla explícitamente.
Esto lleva a muchos equipos a apoyarse en una capa de telemetría específica para agentes, separada de la observabilidad de infraestructura. El mercado se ha dividido en tres campos bastante claros. Por un lado, las plataformas APM tradicionales —Datadog, New Relic— que han añadido módulos de IA sobre su stack existente y brillan correlacionando el comportamiento del agente con la infraestructura sobre la que corre. Por otro, las plataformas de tracing nativas de IA como Langfuse o LangSmith, que capturan el flujo de decisiones del agente como un grafo de ejecución con mucho más detalle de calidad; LangSmith, por cierto, ya es agnóstica de framework y exporta e ingiere datos por OTLP. Y en tercer lugar, los gateways tipo Helicone o Portkey, que se sitúan entre tu aplicación y el proveedor del modelo para añadir enrutado, caché y control de coste con cambios mínimos de código. Los tres son útiles. Ninguno, por sí solo, responde a la vez a «¿esto funciona?», «¿esto es bueno?» y «¿esto cuánto cuesta?». Y cada uno que añades es otro sistema que mantener, otra interfaz que aprender, y otra fuente de verdad que puede no estar sincronizada con tus trazas distribuidas tradicionales.
Estrategias que funcionan sin arruinarte
La primera decisión sensata es separar la telemetría de depuración de la telemetría de producción. En desarrollo, capturas todo: prompts completos, respuestas completas, estados intermedios, evaluaciones de calidad. En producción, capturas solo lo mínimo necesario para detectar y diagnosticar problemas: identificadores de conversación, métricas de latencia y coste, flags de error, y muestras representativas de contenido.
La segunda es usar niveles de detalle adaptativos. Captura telemetría completa para las primeras interacciones de cada usuario nuevo, para interacciones que el agente marca como inciertas, y para cualquier flujo que termine en error o escalado a humano. Para el resto, captura solo agregados y muestras. Dynatrace y otras plataformas de observabilidad empresarial permiten configurar reglas de captura basadas en atributos de negocio, no solo en métricas técnicas, lo que hace viable este tipo de política sin escribir un colector a medida.
La tercera estrategia tiene que ver con dónde colocas el contenido pesado. Conviene desmontar un malentendido frecuente: OTLP, el protocolo de transporte de OpenTelemetry, ya soporta compresión gzip de forma nativa, así que «comprimir la telemetría» rara vez es la palanca que crees. El texto comprime bien, sí, pero el ahorro grande no está en exprimir el payload sino en no enviarlo entero. La propia especificación GenAI de OpenTelemetry contempla un patrón explícito para esto: en lugar de meter prompts y respuestas voluminosos dentro de los atributos del span, los subes a almacenamiento externo (un bucket de objetos, por ejemplo) y dejas en el span solo una referencia. Tus trazas siguen siendo navegables y baratas, y el contenido pesado vive donde el almacenamiento cuesta céntimos por gigabyte, no donde se factura por ingesta.
Y la cuarta, quizá la más importante: define qué preguntas necesitas responder y captura solo los datos que te permiten responderlas. Si tu pregunta clave es «¿cuánto nos cuesta cada conversación?», necesitas métricas de tokens consumidos por modelo y por usuario, no trazas completas. Si tu pregunta es «¿por qué el agente recomendó este producto y no otro?», necesitas el contexto de decisión, no la latencia de cada llamada a base de datos. La observabilidad efectiva no es capturar todo por si acaso: es capturar lo justo para operar con confianza.
El coste como métrica de producto
En sistemas tradicionales, el coste de infraestructura es un problema de operaciones. En sistemas con agentes de IA, el coste es una métrica de producto. Cada decisión de diseño del agente afecta directamente a cuánto gastas por interacción: cuántas veces consulta la base de conocimiento, qué modelo usa para cada tarea, cuánto contexto incluye en cada prompt. Y esas decisiones cambian constantemente mientras iteras sobre el comportamiento del agente.
Esto significa que tu observabilidad necesita exponer el coste como métrica de primera clase, no como un dato que consultas a final de mes en la factura de tu proveedor de IA. Necesitas ver el coste por conversación, por tipo de consulta, por usuario, en tiempo real. Y necesitas correlacionar ese coste con métricas de calidad: si reducir el contexto del prompt te ahorra un 30% pero empeora la precisión de las respuestas en un 15%, ¿vale la pena? Solo puedes responder esa pregunta si tu telemetría te muestra ambas dimensiones juntas.
Aquí el panorama ha madurado deprisa, y vale la pena mirar cómo lo resuelven las plataformas grandes porque revela las decisiones de modelo de negocio que hay debajo. Datadog LLM Observability, ya en disponibilidad general, vista el coste estimado por petición a partir de los tokens y las tablas de precios de cada proveedor, y permite cruzarlo con la factura real de OpenAI vía Cloud Cost Management. Más revelador todavía: factura únicamente por los LLM spans, no por los spans de herramientas, recuperación o decisión del agente. Es una elección deliberada para que el precio no se dispare a medida que tu agente se vuelve más autónomo y encadena más pasos internos. New Relic AI Monitoring va por la misma línea, con desglose de tokens por modelo y comparativas de coste entre modelos para decidir cuándo conviene degradar a uno más barato; su propio equipo interno de SRE usa esa telemetría para justificar el gasto de sus agentes en producción.
Lo que sí sigue siendo terreno en construcción es la unión entre coste y calidad. Las plataformas APM miden bien los tokens y la latencia, pero la evaluación fina de la calidad de las respuestas suele requerir herramientas dedicadas. Cruzar ambas dimensiones —cuánto gasto y cómo de bien responde— de forma automática y en una sola vista es justo donde están iterando ahora mismo los equipos que operan agentes a escala real.
Cuándo la observabilidad tradicional ya no basta
Si tu agente de IA es un componente más dentro de una aplicación tradicional, probablemente puedas seguir usando tus herramientas de observabilidad actuales con algunas extensiones. Pero si tu producto ES el agente, si la calidad de sus respuestas define tu propuesta de valor, entonces necesitas repensar tu estrategia de observabilidad desde cero.
La señal más clara de que has llegado a ese punto es cuando tus dashboards de Prometheus o Grafana te dicen que todo está bien, pero tus usuarios se quejan de que el agente no les ayuda. Las métricas técnicas no capturan la experiencia real. Un modelo puede devolver un 200 en 50 milisegundos y aun así alucinar, filtrar datos o responder una banalidad. Necesitas observabilidad que entienda el dominio del problema que tu agente resuelve, no solo la infraestructura sobre la que corre.
Y necesitas aceptar que no puedes tenerlo todo. No puedes capturar telemetría completa de cada interacción, almacenarla indefinidamente y consultarla en tiempo real sin que el coste se vuelva insostenible. Tienes que elegir: qué capturas siempre, qué capturas a veces, qué analizas en tiempo real y qué procesas en batch. Esas decisiones son tan importantes como cualquier decisión de arquitectura de tu sistema, porque definen qué puedes ver y qué permanece invisible cuando las cosas se rompen.
Para seguir aprendiendo
Convenciones semánticas de OpenTelemetry para spans de GenAI — La referencia normativa: qué atributos definir, cómo capturar (o no) el contenido de prompts y respuestas, y el patrón recomendado de subir el contenido pesado a almacenamiento externo en lugar de inflar los spans.
Documentación de observabilidad de LangSmith — Patrones específicos para trazar cadenas de llamadas a modelos y sistemas de recuperación aumentada, con foco en capturar el flujo de decisiones del agente. Agnóstica de framework e interoperable con OTLP.
Documentación de coste de Datadog LLM Observability — Cómo se modela el coste por traza y por span, desglose por modelo, proveedor y versión de prompt, y qué se factura realmente (y qué no) en un producto comercial maduro.
Observability Engineering, de Charity Majors, Liz Fong-Jones y George Miranda (O’Reilly) — Aunque no trata específicamente agentes de IA, establece los principios fundamentales de observabilidad que aplican cuando los sistemas se vuelven complejos e impredecibles. La base conceptual para todo lo demás.
