Observabilidad para agentes de IA en produccion
Como diseno observabilidad para agentes de IA: trazas, logs, metricas, costes, errores, privacidad y mejora continua.
Un agente de IA en produccion no se puede gestionar solo mirando si "responde bien". Cuando el sistema usa herramientas, consulta datos, llama APIs, decide si escalar, consume tokens y ejecuta acciones reales, necesito saber que ha pasado en cada paso.
La observabilidad es lo que convierte una automatizacion con IA en un sistema operable. Sin ella, un fallo se convierte en una discusion: no se sabe si el problema fue el prompt, el modelo, una API, una credencial, el contexto recuperado, una regla de negocio o una decision humana que llego tarde.
En proyectos con n8n, LLMs, Python, FastAPI, Spring, web search y workflows conectados a procesos de empresa, disenaria la observabilidad desde el principio. No como un extra bonito, sino como una condicion para poder mantener el sistema.
Respuesta directa: que observar en un agente de IA
Un agente de IA debe observarse registrando trazas por ejecucion, entradas y salidas estructuradas, herramientas llamadas, errores clasificados, costes, latencia, decisiones de escalado, version de prompts y contexto usado, siempre minimizando datos sensibles.
La observabilidad debe responder preguntas concretas:
| Pregunta | Senal necesaria |
|---|---|
| Que pidio el usuario? | Entrada normalizada y canal |
| Que entendio el agente? | Intencion, entidades y confianza |
| Que contexto uso? | Fuente, version y fragmentos relevantes |
| Que herramienta llamo? | Nombre, parametros, resultado y error |
| Que coste tuvo? | Tokens, modelo, llamadas y coste estimado |
| Por que escalo? | Regla, confianza o dato faltante |
| Que respuesta dio? | Salida final y estado de ejecucion |
| Se puede depurar? | Correlation ID y traza completa |
Un agente observable no es el que guarda todo. Es el que guarda lo suficiente para entender, depurar, auditar y mejorar sin exponer datos innecesarios.
Por que la observabilidad en IA es distinta
En una API tradicional, muchas veces miro status codes, latencia, errores y throughput. En un agente de IA eso no basta.
Un agente puede fallar aunque el status code sea 200:
- clasifico mal la intencion;
- recupero contexto irrelevante;
- uso una fuente desactualizada;
- eligio una herramienta incorrecta;
- genero JSON invalido;
- respondio con tono incorrecto;
- gasto demasiados tokens;
- no escalo cuando debia;
- escalo demasiados casos faciles;
- mezclo datos de tenants distintos.
La observabilidad de IA debe mirar el proceso completo, no solo si la llamada termino.
Esto conecta con mi guia sobre como evaluo agentes de IA antes de produccion: si no puedo revisar trazas, tampoco puedo evaluar bien.
Logs, metricas, trazas y eventos
No usaria "logs" como palabra para todo. Separaria cuatro tipos de senales:
| Senal | Para que sirve |
|---|---|
| Logs | Entender detalles de una ejecucion concreta |
| Metricas | Ver tendencias, volumen, latencia, coste y errores |
| Trazas | Reconstruir el recorrido completo entre componentes |
| Eventos | Registrar cambios de estado importantes |
Un ejemplo de flujo observable podria ser:
request_received
-> intent_detected
-> context_retrieved
-> tool_called
-> validation_passed
-> response_sent
Cada paso deberia compartir un identificador comun. Sin ese identificador, seguir una ejecucion entre n8n, backend, proveedor LLM, CRM y sistema de notificaciones se vuelve demasiado lento.
Correlation ID: la pieza pequena que evita caos
Cada ejecucion deberia nacer con un correlation_id. Ese identificador debe viajar por todos los
componentes:
- webhook;
- workflow n8n;
- servicio FastAPI o Spring;
- llamada al LLM;
- herramienta externa;
- base de datos;
- log;
- notificacion;
- escalado humano.
Cuando algo falla, no quiero buscar "el mensaje de las 10:32". Quiero buscar un identificador y ver toda la historia.
{
"correlation_id": "exec_20260618_abc123",
"tenant": "restaurant_demo",
"workflow": "booking_agent",
"step": "tool_called",
"tool": "check_availability",
"status": "success",
"latency_ms": 842
}
Este tipo de estructura permite filtrar, medir y auditar. Tambien reduce mucho la dependencia de la memoria personal del desarrollador.
Que registraria en cada ejecucion
No guardaria prompts completos por defecto, ni datos personales sin necesidad. Pero si conservaria informacion operativa.
| Campo | Motivo |
|---|---|
| correlation_id | Seguir la ejecucion completa |
| tenant o cliente | Separar datos y costes |
| canal | Saber si viene de web, WhatsApp, email o API |
| workflow y version | Reproducir comportamiento |
| prompt version | Detectar regresiones |
| modelo | Comparar coste y calidad |
| intencion detectada | Revisar clasificacion |
| herramientas llamadas | Auditar acciones |
| estado final | completed, failed, escalated |
| motivo de error | Clasificar fallos |
| coste estimado | Control financiero |
| latencia total | Experiencia de usuario |
La clave es guardar datos estructurados, no solo texto libre. Si todo queda en frases sueltas, luego no se puede analizar bien.
Medir costes sin esperar a la factura
En agentes con LLMs, el coste no es un detalle secundario. Un workflow puede ser correcto y aun asi no ser viable si hace demasiadas llamadas o recupera demasiado contexto.
Mediria:
- tokens de entrada;
- tokens de salida;
- coste por modelo;
- numero de llamadas al LLM;
- numero de herramientas usadas;
- coste por ejecucion completada;
- coste por ejecucion escalada;
- coste por tenant;
- coste por canal;
- coste por caso de uso.
Esto permite tomar decisiones tecnicas:
| Problema | Posible accion |
|---|---|
| Mucho coste por contexto | Mejorar retrieval o resumir antes |
| Muchas llamadas al modelo | Unificar pasos o usar reglas |
| Salidas largas innecesarias | Limitar formato de respuesta |
| Casos escalados caros | Detectar antes y cortar ejecucion |
| Modelo caro para tarea simple | Cambiar a modelo mas pequeno |
La pregunta no es solo "cuanto cuesta?". Es "que parte del sistema esta consumiendo coste sin aportar valor?".
Clasificar errores para poder mejorar
Un error generico como failed no ayuda. Clasificaria los fallos por origen:
| Categoria | Ejemplo |
|---|---|
| Input | Faltan datos, formato invalido, ambiguedad |
| Modelo | JSON invalido, baja confianza, respuesta fuera de politica |
| Contexto | Fuente no encontrada, evidencia insuficiente |
| Herramienta | API caida, timeout, permiso denegado |
| Negocio | Accion no permitida, horario cerrado, limite superado |
| Seguridad | Datos sensibles, prompt injection, tenant incorrecto |
| Humano | Pendiente de aprobacion, rechazo, edicion manual |
Esta clasificacion convierte fallos en informacion accionable. Si el 40% de errores viene de datos incompletos, el problema puede estar en el formulario. Si viene de herramientas, puede faltar reintentos o circuit breakers. Si viene del modelo, puede hacer falta ajustar prompt, salida estructurada o evaluacion.
Observabilidad y privacidad
Observar no significa guardar todo. De hecho, guardar demasiado puede crear riesgos nuevos.
Aplicaria estas reglas:
- no registrar secretos;
- no guardar tokens de API;
- evitar prompts completos por defecto;
- enmascarar emails, telefonos e identificadores cuando sea posible;
- separar logs por tenant;
- definir retencion de datos;
- limitar acceso a trazas sensibles;
- registrar metadata antes que contenido completo;
- guardar muestras completas solo cuando haya una razon clara.
La observabilidad debe convivir con minimizacion de datos. Lo desarrollo tambien en seguridad y privacidad en agentes de IA para empresas.
Dashboards que si sirven
Un dashboard no deberia ser una pared de numeros. Deberia responder preguntas operativas.
Revisaria:
- ejecuciones por dia;
- tasa de finalizacion;
- tasa de escalado;
- principales motivos de escalado;
- coste por caso resuelto;
- latencia p50, p95 y p99;
- errores por integracion;
- tenants con mas fallos;
- prompts o versiones con regresiones;
- herramientas mas usadas;
- acciones corregidas manualmente.
Tambien crearia alertas concretas:
- subida brusca de errores;
- coste por ejecucion fuera de umbral;
- latencia demasiado alta;
- escalados por encima de lo normal;
- fallo repetido de una herramienta critica;
- muchos casos bloqueados por aprobacion humana.
Un buen dashboard ayuda a decidir. Si solo decora, no esta haciendo su trabajo.
De observabilidad a mejora continua
La observabilidad no sirve solo para apagar incendios. Sirve para mejorar el producto.
Con buenas trazas puedo detectar:
- prompts que generan mas escalados;
- herramientas que fallan con frecuencia;
- pasos que consumen demasiado coste;
- campos que los usuarios no rellenan;
- casos que siempre aprueba una persona;
- reglas demasiado estrictas;
- fuentes que aportan poca evidencia;
- tareas que se podrian automatizar mas.
Aqui conecta muy bien con el patron human-in-the-loop en agentes de IA: las decisiones humanas no solo resuelven casos, tambien generan datos para mejorar el sistema.
Checklist de observabilidad para agentes de IA
Antes de desplegar un agente, revisaria:
- Cada ejecucion tiene
correlation_id. - Se registra version de workflow, prompt y modelo.
- Las herramientas devuelven resultados estructurados.
- Los errores estan clasificados por categoria.
- Se mide coste por ejecucion y por tenant.
- Se mide latencia total y por paso.
- Hay trazas para reconstruir acciones reales.
- Los logs minimizan datos personales.
- Existen alertas para coste, errores y latencia.
- Los escalados humanos tienen motivo registrado.
- Las metricas permiten detectar regresiones.
- Hay una forma clara de pausar un workflow problematico.
Mi criterio final
Un agente de IA en produccion no esta terminado cuando responde. Esta terminado cuando se puede operar.
Para mi, eso significa poder ver que hizo, por que lo hizo, cuanto costo, donde fallo, que datos uso, que herramienta llamo y que persona intervino si fue necesario.
La observabilidad no hace que un agente sea mas espectacular en una demo. Hace algo mas importante: permite confiar en el sistema cuando ya hay usuarios, datos reales y decisiones que importan.