8 min de lectura
Ultima actualizacion:
Tu agente LLM no cayo. Devolvio una respuesta segura, bien formada. El usuario la acepto. Tres semanas despues, una auditoria interna muestra que el agente silenciosamente derivo hacia recomendar un SKU descontinuado a dos mil clientes. Ninguna excepcion se disparo. Ninguna alarma de latencia. Ninguna linea de log se marco a si misma como sospechosa. Este es el nuevo modo de fallo, y la mayoria de organizaciones de ingenieria estan ejecutando sistemas de IA en produccion sin las primitivas de observabilidad necesarias para detectarlo.
El APM tradicional trata el exito como una respuesta 200 dentro de un SLO. Los agentes rompen esa suposicion. Una respuesta puede ser sintacticamente valida, semanticamente incorrecta y economicamente catastrofica en la misma llamada. Si estas ejecutando agentes en rutas con impacto al cliente o a los ingresos en 2026, tu stack de monitoreo necesita un rediseno explicito, no un dashboard anadido al existente.
Las cuatro clases de fallo silencioso que debes instrumentar
Antes de elegir una herramienta, nombra los fallos. Cada decision de observabilidad mas abajo se remonta a una de estas cuatro clases. Si tu equipo no puede articular a que clase pertenecio un incidente reciente, no tienes observabilidad, tienes logs.
Deriva por alucinacion
El modelo fabrica un hecho, una cita, un identificador o una capacidad. La salida luce plausible. La deteccion requiere o un oraculo de verdad fundamental (raro en produccion) o una senal aguas abajo (pulgar abajo del usuario, ticket de soporte, reembolso). Para cuando llega la senal aguas abajo, ya enviaste el error a una poblacion. La mitigacion no es un solo chequeo; es una capa de extraccion de afirmaciones y verificacion que corre como parte del pipeline de respuesta, no como un batch diario.
Deriva en llamadas a herramientas
El agente elige la herramienta incorrecta, llama a la herramienta correcta con argumentos mal formados, o entra en bucle sobre una herramienta sin converger. La deriva en llamadas a herramientas es el fallo mas subinstrumentado en los stacks de produccion de 2026 porque la mayoria de equipos trazan la llamada al LLM pero no el recorrido del grafo de herramientas. La solucion es registrar cada decision de herramienta como un atributo de span (nombre de herramienta, hash de argumentos, indice de reintento, id de decision padre) y alertar sobre profundidad de bucle de herramienta por encima de un umbral, por clase de tarea.
Pico de coste
Un cambio en la longitud de contexto aguas arriba, una regresion en un sistema de recuperacion que devuelve documentos sobredimensionados, o un agente que adopta un nuevo patron de cadena de pensamiento pueden multiplicar por diez el coste de tokens por peticion en un solo deploy. El coste es observable en centimos por peticion y tokens por peticion; trata ambos como metricas SLO de primera clase con presupuestos por ruta, no como una linea de finanzas revisada mensualmente.
Outliers de latencia
La latencia P99 en sistemas de agentes esta dominada por reintentos, llamadas a herramientas y bucles de razonamiento, no por la llamada base al modelo. Un dashboard ingenuo de p50 o p95 ocultara al usuario en p99.5 que espero cuarenta y cinco segundos mientras el agente replanificaba tres veces. Las alarmas de latencia deben dividirse por etapa (planificacion, recuperacion, herramienta, generacion) y por ruta, no agregadas en todo el trafico del agente.
Patrones de instrumentacion que funcionan realmente en 2026
Tres enfoques dominan el mercado. Cada uno tiene un coste real y un beneficio real. La eleccion depende de la madurez de tu equipo de plataforma y de cuanto vendor lock-in puedes tolerar.
La primera opcion es un proveedor gestionado de trazado de agentes: LangSmith, LangFuse, Helicone, Arize Phoenix. Estos productos te dan una UI de trazas usable, comparacion de versiones de prompts y un flujo de captura de feedback en una tarde de integracion. El coste es el precio por traza que se vuelve doloroso pasados unos pocos millones de spans diarios, mas una imagen parcial: ven las llamadas que instrumentas, no el ciclo de vida mas amplio de la peticion.
La segunda opcion es OpenTelemetry con las convenciones semanticas GenAI que se estabilizaron a finales de 2025. Emites spans con los atributos estandar gen_ai.* (nombre de modelo, contadores de tokens, razon de finalizacion, llamadas a herramientas) y los enrutas a cualquier backend que ya pagues: Datadog, Honeycomb, Grafana Tempo, Tempo mas Loki. Esta es la respuesta correcta para cualquier organizacion que ya invirtio en OpenTelemetry y tiene un equipo de plataforma capaz de mantenerlo. Obtienes trazas unificadas a traves de tu stack completo con un trace id desde el borde hasta el LLM, la herramienta y la base de datos.
La tercera opcion es hibrida: proveedor gestionado para los flujos de prompt y evaluacion, OTel para la telemetria de produccion. Esto es donde aterrizan la mayoria de las organizaciones grandes de ingenieria en su segundo ano. El proveedor maneja el bucle de iteracion donde viven los ingenieros de producto y ML; OTel maneja el bucle SRE donde viven los ingenieros de guardia.
Alertas semanticas vs alertas operativas
Las alertas operativas son las que tu equipo SRE ya entiende: tasa de error, latencia, saturacion. Portalas a tu infraestructura de agentes con granularidad por ruta y habras cubierto aproximadamente el cuarenta por ciento del area superficial. El sesenta por ciento restante requiere alertas semanticas, que la mayoria de equipos nunca ha construido.
Una alerta semantica se dispara sobre el significado de la salida del agente, no sobre sus propiedades operativas. Ejemplos que se pagan a si mismos en un trimestre:
- Tasa de rechazo por encima de la linea base por ruta, indicando una regresion de prompt o un cambio de comportamiento del modelo tras una actualizacion del proveedor
- Densidad de citas por debajo del umbral en cualquier respuesta de un flujo regulado (legal, medico, financiero)
- Entropia de llamadas a herramientas por encima del umbral por sesion, indicando que el agente esta explorando en lugar de ejecutar
- Cambio en la distribucion de longitud de salida frente a una linea base rodante de siete dias, a menudo la primera senal de una regresion en la ventana de contexto
- Coincidencias de patrones PII en salidas del agente que nunca deberian contener PII
- Coste por tarea resuelta por encima del umbral de unidad economica del producto
Las alertas semanticas requieren un pequeno servicio de evaluacion que corre clasificadores ligeros sobre un flujo muestreado de salidas del agente. No los ejecutes en el hot path; muestrea uno a diez por ciento del trafico y agrega. El punto no es bloquear respuestas malas en tiempo real, el punto es saber dentro de quince minutos cuando el comportamiento de la poblacion cambia.
Revision de incidentes para sistemas de IA
La plantilla estandar de postmortem fue escrita para sistemas donde la causa raiz es una ruta de codigo o un valor de configuracion. Para fallos de agentes, la causa raiz suele ser un trio: una version de prompt, una version de modelo y una distribucion de contexto. Tu plantilla necesita tres campos que la original no tenia.
Primero, el linaje de prompt y modelo en el momento del incidente. Si no puedes reconstruir el prompt de sistema exacto, la lista de herramientas y el snapshot de modelo que uso una peticion, no puedes depurarla. Fija las versiones de modelo explicitamente; nunca llames a un alias movil como claude-sonnet-latest en produccion.
Segundo, una muestra representativa de entradas que dispararon el fallo, anonimizadas y almacenadas. Las metricas agregadas te dicen que algo esta mal; las entradas de muestra te permiten reproducir. Construye un pipeline de “exportar muestra de incidente” de un solo clic ahora, antes de necesitarlo a las tres de la manana.
Tercero, una estimacion explicita del radio de impacto. Cuantos usuarios vieron la salida mala, cuantos actuaron sobre ella, cuantas de esas acciones son reversibles. Para un sistema determinista, el radio de impacto suele conocerse por los logs. Para agentes, tienes que estimarlo desde trazas muestreadas y volumen de soporte al cliente; esta estimacion es en si misma una capacidad que construyes con el tiempo.
Recomendacion
Si estas ejecutando menos de diez mil llamadas de agente al dia y estas en una fase temprana en tu madurez de IA, empieza con un proveedor gestionado (LangFuse si el codigo abierto importa, LangSmith si vives en el ecosistema LangChain, Arize Phoenix si quieres ambos). Obten trazas, comparacion de prompts y un bucle de feedback en una semana. Aplaza el proyecto OTel.
Si estas ejecutando mas de cien mil llamadas de agente al dia o tienes cargas reguladas, construye primero la capa OTel, despues coloca el proveedor encima para el bucle de iteracion. Trata el stack del agente como un servicio de produccion de primera clase con rotacion de guardia, runbooks y la misma higiene de radio de impacto que aplicarias a un sistema de pagos.
En todos los casos, define tus cuatro clases de fallo silencioso para tu producto especifico, escribe al menos tres alertas semanticas y fija versiones de modelo. Esos tres pasos separan a los equipos que aprenden sobre fallos de agentes desde sus dashboards de los equipos que aprenden sobre ellos desde sus clientes.
Cuando aplica y cuando no
Este marco aplica cuando un LLM esta en una ruta donde las salidas incorrectas tienen impacto en el cliente o en los ingresos. Agentes solo internos, prototipos tras un feature flag para menos de cien usuarios y resumenes de un solo turno sobre contenido de bajo riesgo no necesitan este stack. Anadirlo prematuramente ralentizara tu velocidad de iteracion sin comprarte fiabilidad medible.
No aplica a sistemas RAG donde el LLM es una capa delgada de formato sobre recuperacion determinista. Alli, las metricas clasicas de calidad de busqueda (recall en k, MRR, click-through) cargan la mayor parte de la senal y la observabilidad de agentes es excesiva. Construyela cuando tu sistema gane uso de herramientas, planificacion multi-turno o autoridad de decision autonoma sobre recursos externos. Hasta entonces, tu monitoreo existente probablemente es suficiente.