Cuando un equipo de producto decide incorporar capacidades de IA generativa a su plataforma, la conversación técnica suele centrarse en la selección del modelo, el diseño de prompts y la arquitectura de integración. Lo que raramente aparece en las primeras iteraciones es una estrategia coherente de observabilidad. El resultado es predecible: pocas semanas después del lanzamiento, el equipo SRE recibe alertas de latencia inexplicable, costes de inferencia que crecen de forma no lineal con el tráfico, y usuarios reportando respuestas inconsistentes sin que exista visibilidad sobre qué está ocurriendo en la cadena de llamadas al modelo.
Los sistemas basados en LLMs y agentes de IA introducen patrones de fallo y comportamientos operativos que no encajan bien en los marcos tradicionales de observabilidad. Un agente puede ejecutar múltiples llamadas encadenadas a diferentes modelos, consultar bases de datos vectoriales, invocar APIs externas para enriquecer contexto, y aplicar lógica de decisión basada en embeddings. Cada uno de estos pasos tiene su propia distribución de latencia, su tasa de error específica, y su impacto en coste. Observar este tipo de sistemas requiere extender las primitivas habituales de métricas, trazas y logs con señales específicas del dominio de IA.
Y no estamos hablando de un problema teórico. Según la encuesta global de IA de McKinsey de 2025, el 51% de las organizaciones que utilizan IA experimentaron al menos una consecuencia negativa por inexactitudes en los resultados de sus modelos. Gartner estima que solo el 18% de los equipos de ingeniería de software utilizaban plataformas de observabilidad y evaluación de IA en 2025, pero prevé que esa cifra alcance el 60% en 2028. El mercado específico de plataformas de observabilidad de LLMs alcanzó los 2.690 millones de dólares en 2026, con un crecimiento interanual del 36%. Los números dejan claro que la necesidad existe y que la industria está respondiendo, pero la madurez en la adopción todavía es baja.
Este artículo aborda los patrones de observabilidad necesarios para operar agentes de IA y LLMs en producción con criterio SRE. No se trata de monitorizar un endpoint más, sino de diseñar una estrategia que permita entender el comportamiento emergente de sistemas no deterministas, detectar degradaciones sutiles antes de que impacten en usuarios, y mantener el control sobre costes operativos que pueden escalar de forma impredecible.
El problema específico de observar sistemas de IA generativa
Los sistemas tradicionales de backend tienen comportamientos relativamente predecibles. Una petición HTTP a un servicio REST sigue un flujo conocido: validación, lógica de negocio, acceso a base de datos, serialización de respuesta. Las métricas habituales — tasa de peticiones, latencia en percentil 95 y tasa de error — cubren la mayoría de escenarios operativos. Los SLOs se definen sobre estas señales y los procedimientos operativos describen acciones correctivas claras.
Un agente de IA rompe estas asunciones. La misma pregunta de usuario puede desencadenar un número variable de llamadas al modelo dependiendo del contexto conversacional, la complejidad de la tarea, o decisiones internas del agente sobre cuándo iterar. La latencia no sigue una distribución normal: puede haber colas largas cuando el modelo genera respuestas extensas o cuando el agente decide que necesita más información y ejecuta llamadas adicionales. Los errores no son binarios: una respuesta técnicamente válida puede ser operativamente incorrecta si el modelo alucina, si el contexto recuperado es irrelevante, o si la cadena de razonamiento se desvía.
El coste de inferencia añade otra dimensión. A diferencia de un servicio tradicional donde el coste por petición es relativamente estable, en sistemas de IA el coste depende del número de tokens procesados, tanto en entrada como en salida. Un usuario que hace preguntas complejas con contexto extenso puede consumir diez veces más recursos que otro con consultas simples. Sin visibilidad sobre esta distribución, es imposible establecer presupuestos operativos realistas o detectar patrones de uso anómalos que disparen costes.
Señales clave para observabilidad de LLMs
La observabilidad efectiva de sistemas de IA requiere instrumentar señales que no existen en aplicaciones tradicionales. Estas señales deben capturarse en tiempo real y correlacionarse con el resto de telemetría del sistema para permitir análisis de causa raíz cuando algo falla.
Métricas de consumo de tokens
El número de tokens de entrada y salida por petición es la métrica fundamental de coste. Debe capturarse por endpoint, por usuario si el modelo de negocio lo requiere, y por tipo de operación. No basta con un contador agregado: necesitas distribuciones en percentiles para detectar valores atípicos. Un percentil 99 de tokens de salida que crece de forma sostenida puede indicar que el modelo está generando respuestas cada vez más largas, posiblemente porque el prompt no está bien acotado o porque el contexto recuperado es excesivo.
Igualmente importante es la ratio entre tokens de entrada y salida. Un agente que consume muchos tokens de entrada pero genera salidas cortas puede estar recibiendo contexto irrelevante de la base de datos vectorial. Un agente con salidas desproporcionadamente largas respecto a la entrada puede estar generando contenido redundante o excesivamente verboso.
OpenTelemetry ya define convenciones semánticas específicas para estos casos. Las GenAI Semantic Conventions (actualmente en fase experimental, versión 1.37+) estandarizan atributos como gen_ai.usage.input_tokens y gen_ai.usage.output_tokens, lo que permite que herramientas como Dynatrace, Datadog o Grafana interpreten estas métricas de forma consistente sin instrumentación ad hoc.
Latencia desagregada por fase
La latencia total de una petición a un agente de IA se compone de múltiples fases: recuperación de contexto desde bases de datos vectoriales, construcción del prompt, llamada al modelo, postprocesamiento de la respuesta, y posibles iteraciones adicionales. Observar solo la latencia extremo a extremo oculta dónde está el cuello de botella.
Instrumentar cada fase permite identificar si el problema está en la búsqueda vectorial, en el tiempo de inferencia del modelo, o en la lógica del agente. Un patrón frecuente es que la latencia de búsqueda vectorial crezca de forma no lineal con el volumen de embeddings almacenados, degradando la experiencia de usuario sin que el modelo en sí tenga ningún problema. Sin trazas desagregadas, este tipo de degradación pasa desapercibida hasta que los usuarios se quejan.
En plataformas como Dynatrace, que ofrece AI Observability con trazabilidad extremo a extremo del flujo de prompts, esta desagregación se obtiene de forma nativa al instrumentar con OpenTelemetry o con bibliotecas como OpenLLMetry de Traceloop. Datadog, por su parte, soporta las GenAI Semantic Conventions desde la versión 1.37 de su SDK de OpenTelemetry, mapeando automáticamente los spans de IA a su módulo de LLM Observability.
Tasa de reintento y cadenas de llamadas
Los agentes de IA suelen implementar lógica de reintento cuando la respuesta del modelo no cumple criterios de calidad o cuando necesitan información adicional. Esta capacidad es valiosa para mejorar resultados, pero introduce riesgo operativo. Un agente que reintenta demasiado puede entrar en bucles costosos, consumiendo tokens y latencia sin converger a una respuesta útil.
Observar el número de llamadas al modelo por petición de usuario, la tasa de reintentos, y la profundidad de cadenas de razonamiento permite detectar comportamientos anómalos. Si el percentil 95 de llamadas por petición pasa de dos a cinco en una semana, algo ha cambiado en el comportamiento del agente o en la calidad de las entradas. Las convenciones semánticas de OpenTelemetry para agentes GenAI definen operaciones como invoke_agent con spans que capturan cada invocación y herramienta utilizada, facilitando esta visibilidad.
Calidad de respuesta y detección de alucinaciones
Esta es la señal más difícil de capturar de forma automatizada. La calidad de una respuesta generada por un LLM no se reduce a métricas técnicas. Sin embargo, existen indicadores operativos útiles: la tasa de respuestas que incluyen frases de incertidumbre del modelo, la frecuencia con la que el agente declara que no puede responder, o la correlación entre respuestas y acciones posteriores del usuario pueden servir como señales tempranas de degradación.
Algunos equipos implementan validadores secundarios que evalúan la coherencia de la respuesta respecto al contexto proporcionado, o que verifican que la respuesta no contradiga información conocida. Estas validaciones tienen su propio coste de inferencia, pero aportan señales valiosas cuando se ejecutan sobre una muestra representativa del tráfico. OpenTelemetry contempla eventos de evaluación (gen_ai.evaluation.score) que permiten registrar estas valoraciones de calidad directamente como parte de la traza.
Trazas distribuidas en arquitecturas de agentes
Un agente de IA moderno raramente es un componente aislado. Forma parte de una arquitectura distribuida donde interactúa con bases de datos vectoriales, servicios de embeddings, APIs de modelos externos, cachés de contexto, y sistemas de orquestación. Observar este flujo requiere trazas distribuidas que capturen toda la cadena de dependencias.
OpenTelemetry proporciona primitivas para instrumentar estos flujos, pero la semántica específica de IA requiere atributos personalizados. Una traza de una petición a un agente debe incluir no solo los spans habituales de llamadas HTTP y consultas a base de datos, sino también spans específicos para cada interacción con el modelo: un hash del prompt (nunca el prompt completo en producción por privacidad y volumen), el número de tokens consumidos, el modelo específico invocado, y parámetros de configuración relevantes como temperatura o top-p. La especificación de OpenTelemetry recomienda explícitamente no capturar el contenido de prompts por defecto, ofreciendo la variable OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT como opt-in para entornos de desarrollo o preproducción.
La correlación entre trazas y métricas de coste es crítica. Cuando una traza individual muestra latencia anómala, necesitas poder ver inmediatamente cuántos tokens consumió y en qué fase se produjo el retraso. Dynatrace permite correlacionar automáticamente trazas con métricas de negocio y eventos de usuario a través de su motor Grail, lo que facilita entender el impacto real de una degradación técnica. En un entorno con Grafana, esta correlación se consigue enlazando Tempo (trazas) con Prometheus (métricas) y Loki (logs), aunque requiere configuración manual de las fuentes de datos cruzadas.
Un error frecuente es instrumentar solo la llamada al modelo y omitir la preparación del contexto. En muchos casos, el cuello de botella está en la recuperación de embeddings relevantes o en la construcción del prompt, no en la inferencia. Sin visibilidad sobre estas fases, el análisis de causa raíz se convierte en especulación.
Gestión de costes de inferencia como señal operativa
El coste de inferencia no es solo una métrica financiera, es una señal operativa que indica salud del sistema. Un crecimiento inesperado en el coste por petición puede deberse a múltiples causas: cambios en el comportamiento de usuarios, degradación en la calidad del contexto recuperado que obliga al agente a iterar más, o modificaciones en el prompt que aumentan la verbosidad del modelo.
Establecer presupuestos de coste por endpoint o por tipo de operación permite detectar anomalías antes de que se conviertan en problemas financieros. Si el coste medio por petición a un endpoint específico crece un treinta por ciento en dos días, necesitas investigar inmediatamente. Puede ser un cambio legítimo en el patrón de uso, o puede ser un error en la lógica del agente que está generando llamadas innecesarias.
La visibilidad sobre coste debe estar disponible en tiempo real, no solo en informes mensuales. Algunos equipos implementan alertas basadas en tasa de gasto por minuto, de forma similar a cómo se alertaría sobre tasa de errores. Dynatrace ofrece cálculo automático de costes por petición dentro de su módulo de AI Observability, con detección predictiva de cambios de comportamiento en el consumo mediante Davis AI. Esto permite reaccionar rápidamente ante comportamientos anómalos, como un usuario malintencionado que intenta consumir recursos o un error que genera bucles de inferencia.
Antipatrones habituales en observabilidad de IA
El primer antipatrón es tratar los sistemas de IA como cajas negras y observar solo las métricas de infraestructura subyacente. Saber que la CPU del pod está al ochenta por ciento no te dice nada sobre si el agente está funcionando correctamente. Necesitas señales específicas del dominio de IA.
El segundo antipatrón es no correlacionar métricas de coste con métricas de rendimiento. Un sistema puede tener latencias aceptables y tasa de error baja, pero estar consumiendo el doble de tokens necesarios porque el contexto recuperado es redundante. Sin esta correlación, el problema permanece invisible hasta que llega la factura.
El tercer antipatrón es no implementar muestreo inteligente de trazas. Capturar trazas completas de todas las peticiones a un agente de IA puede ser prohibitivamente caro, especialmente si los prompts son largos. El muestreo debe ser consciente del contexto: capturar siempre trazas de peticiones con latencia anómala, alta tasa de reintentos, o coste elevado, y muestrear de forma más agresiva el tráfico normal. OpenTelemetry permite configurar tail sampling en el Collector para implementar exactamente esta lógica.
El cuarto antipatrón es no establecer SLOs específicos para sistemas de IA. Los SLOs tradicionales de disponibilidad y latencia son insuficientes. Necesitas SLOs sobre calidad de respuesta, coste por petición, y tasa de éxito en la primera llamada. Sin estos SLOs, no tienes un marco objetivo para evaluar si el sistema está cumpliendo expectativas. Gartner lo formula de forma directa: sin mecanismos robustos de observabilidad y explicabilidad, las iniciativas de IA generativa quedarán limitadas a tareas internas de bajo riesgo, reduciendo severamente el retorno de inversión.
Integración con pipelines de observabilidad existentes
Los sistemas de IA no operan de forma aislada. Deben integrarse con los pipelines de observabilidad existentes de la organización. Esto significa que las métricas de tokens, las trazas de agentes, y los eventos de calidad deben fluir hacia las mismas plataformas que el resto de telemetría: Prometheus para métricas, backends compatibles con OpenTelemetry para trazas, y sistemas de agregación de logs.
La integración permite correlacionar comportamiento de agentes con eventos de infraestructura. Si el rendimiento de un agente se degrada al mismo tiempo que aumenta la latencia de la base de datos vectorial, la correlación es evidente. Sin integración, estos eventos se analizan de forma independiente y la causa raíz tarda más en identificarse.
Plataformas unificadas como Dynatrace simplifican esta integración al proporcionar un modelo de datos común (Grail) donde métricas de negocio, trazas distribuidas, y eventos de usuario coexisten. La app de AI Observability del Dynatrace Hub ofrece dashboards predefinidos que muestran simultáneamente tasa de error de un agente, coste de inferencia, y rendimiento del modelo, con soporte nativo para proveedores como OpenAI, Anthropic, Amazon Bedrock, Google Gemini y Azure AI Foundry, además de frameworks de orquestación como LangChain y LlamaIndex. Para entornos basados en Grafana, la combinación de Prometheus (métricas de tokens), Tempo (trazas) y Loki (logs) cubre un espectro similar, aunque con mayor esfuerzo de configuración y sin detección automática de anomalías.
Cuándo esta complejidad no está justificada
No todos los sistemas de IA requieren este nivel de observabilidad. Si estás ejecutando un modelo de clasificación simple con latencia predecible y coste fijo por petición, las métricas tradicionales pueden ser suficientes. La complejidad descrita en este artículo está justificada cuando operas agentes con comportamiento no determinista, cadenas de llamadas variables, y coste dependiente de contexto.
Tampoco tiene sentido implementar toda esta instrumentación desde el primer día. La estrategia correcta es empezar con métricas básicas de latencia y coste, y añadir señales específicas a medida que el sistema madura y los patrones de fallo se hacen evidentes. La observabilidad debe evolucionar con el sistema, no precederlo.
Si el sistema de IA no es crítico para el negocio y el coste de inferencia es marginal, la inversión en observabilidad avanzada puede no estar justificada. El criterio debe ser el mismo que para cualquier otro sistema: el nivel de observabilidad debe ser proporcional al riesgo operativo y al impacto en usuarios.
Para seguir aprendiendo
OpenTelemetry GenAI Semantic Conventions — Especificaciones de convenciones semánticas para sistemas de IA generativa, incluyendo atributos para spans, métricas y eventos de LLMs y agentes. Actualmente en fase experimental pero ya adoptadas por las principales plataformas. → https://opentelemetry.io/docs/specs/semconv/gen-ai/
Documentación de Dynatrace sobre AI Observability — Guía oficial sobre cómo instrumentar y observar aplicaciones basadas en LLMs y agentes con Dynatrace, incluyendo integración con OpenTelemetry y OpenLLMetry. → https://docs.dynatrace.com/docs/observe/dynatrace-for-ai-observability
LangSmith SDK y documentación — Plataforma de LangChain para observabilidad y evaluación de aplicaciones LLM, con trazabilidad de cadenas de agentes, evaluación de calidad y captura de feedback. Compatible con cualquier framework, no solo LangChain. → https://docs.langchain.com/langsmith/observability → SDK en GitHub: https://github.com/langchain-ai/langsmith-sdk
Documentación de Prometheus sobre instrumentación — Guías de la CNCF sobre cómo diseñar métricas personalizadas con Prometheus, aplicable a señales específicas de IA como consumo de tokens y latencia por fase. → https://prometheus.io/docs/practices/instrumentation/
«Designing Data-Intensive Applications» de Martin Kleppmann, O’Reilly Media (2ª edición, 2026, ISBN 978-1-0981-1906-5). Los capítulos sobre trazas distribuidas y arquitecturas de datos proporcionan fundamentos sólidos para diseñar pipelines de observabilidad en sistemas complejos.
«Site Reliability Engineering: How Google Runs Production Systems» editado por Betsy Beyer, Chris Jones, Jennifer Petoff y Niall Richard Murphy, O’Reilly Media (2016, ISBN 978-1-4919-2912-4). Los capítulos sobre SLOs y gestión de incidentes proporcionan marcos de decisión aplicables a definir objetivos de calidad para sistemas de IA en producción. Disponible de forma gratuita en https://sre.google/books/
