Si un agente toma una decisión, ¿podés reconstruir después qué hizo y por qué?

Cuando un agente deja de responder preguntas y empieza a actuar sobre procesos reales, saber que “algo salió mal” no alcanza. La organización necesita reconstruir qué datos utilizó, qué herramientas invocó, bajo qué identidad actuó, qué reglas aplicaban y dónde intervino una persona.

En el software tradicional, observar un sistema suele significar monitorear disponibilidad, errores, latencia y performance.

Con Agentic AI aparece otra necesidad. No alcanza con saber que el sistema estaba funcionando, hay que entender qué hizo.

Un agente puede elegir entre diferentes herramientas, consultar distintas fuentes, ejecutar varios pasos y modificar su comportamiento según el contexto.
Dos ejecuciones similares no necesariamente recorren exactamente el mismo camino.

Por eso, cuando estos sistemas participan de procesos financieros, la observabilidad deja de ser solamente una disciplina operativa. También se convierte en una capacidad de gobierno.

Logging, tracing, observabilidad y auditoría no son lo mismo

Los conceptos suelen utilizarse juntos, pero conviene separarlos.

Logging

Registra eventos.
Por ejemplo, que un agente llamó una determinada herramienta o que una acción fue rechazada.

Tracing

Permite seguir una ejecución de punta a punta.
Ayuda a entender qué pasos realizó el agente y en qué orden.

Observabilidad

Combina múltiples señales para comprender qué está haciendo el sistema, cómo está funcionando y dónde aparece un problema.

Auditoría

Busca evidencia que permita demostrar qué ocurrió, bajo qué autoridad y de acuerdo con qué controles.

En Agentic AI estas capas se conectan, porque para auditar una acción necesitamos haberla observado y registrado previamente. No se puede reconstruir lo que nunca se capturó.

El resultado final cuenta solamente una parte de la historia

Supongamos que un agente modifica incorrectamente el estado de una operación. Conocer el resultado final responde una pregunta: ¿Qué ocurrió?

Pero probablemente Auditoría, Seguridad, Risk o el owner del proceso necesiten responder muchas más.

• ¿Qué agente ejecutó la acción?
  
• ¿Bajo qué identidad?
  
• ¿Qué usuario inició el proceso?
  
• ¿Qué datos consultó?
  
• ¿Qué herramientas utilizó?
  
• ¿Qué reglas estaban vigentes?
  
• ¿La acción requería aprobación?
  
• ¿Hubo una persona involucrada?
  
• ¿Se produjo una excepción?
  
• ¿Qué versión del agente estaba activa?
  
• ¿Había ocurrido algo similar antes?

El output no contiene necesariamente ninguna de esas respuestas. Por eso, diseñar observabilidad significa capturar el contexto de la ejecución, no solamente su resultado.

Qué conviene registrar en un agente de producción

No todos los casos requieren exactamente la misma telemetría, pero una arquitectura enterprise debería considerar al menos:

Identidad

Qué agente actuó y bajo qué credenciales o autorización.

Actor inicial

Qué persona, evento o sistema inició la ejecución.

Contexto

Qué información relevante estaba disponible al momento de tomar la acción.

Fuentes

Qué documentos, datos o sistemas fueron consultados.

Tools

Qué herramientas o APIs utilizó el agente.

Acciones

Qué operaciones realizó sobre sistemas reales.

Políticas

Qué límites o guardrails aplicaban.

Supervisión

Qué acciones necesitaron aprobación y quién intervino.

Excepciones

Qué situaciones salieron del flujo esperado.

Resultado

Qué produjo finalmente la ejecución.

Métricas

Tiempo, costo, calidad, errores y otros indicadores relevantes para operar el sistema.

Ese registro permite pasar de: “el agente hizo algo incorrecto” a: “podemos reconstruir exactamente qué ocurrió y dónde necesitamos intervenir”.

Observabilidad no significa guardar todo

Existe una tentación lógica: si queremos poder auditar, registremos absolutamente todo, pero en servicios financieros eso también puede generar problemas. Los logs pueden contener información sensible:

• Datos personales.
  
• Información financiera.
  
• Contenido confidencial.
  
• Credenciales o secretos si el sistema está mal instrumentado.

El objetivo no es capturar indiscriminadamente cada dato, sino diseñar una estrategia de observabilidad que permita reconstruir el comportamiento sin crear una nueva superficie innecesaria de exposición.

Eso implica definir:

• qué se registra
  
• qué se enmascara
  
• quién puede acceder
  
• cuánto tiempo se conserva
  
• cómo se protege
  
• y qué evidencia necesita realmente cada proceso.

Explicar no siempre significa conocer el razonamiento interno

Cuando una organización pregunta “¿por qué hizo esto?”, puede parecer que necesita acceder al razonamiento interno completo del modelo. No necesariamente.

Desde el punto de vista operativo y de auditoría, muchas veces es más útil poder reconstruir evidencia verificable:

• qué información recibió
  
• qué políticas aplicaban
  
• qué herramientas estaban disponibles
  
• qué acciones realizó
  
• qué reglas bloquearon o permitieron una operación
  
• qué aprobaciones existieron
  
• y cuál fue el resultado.

Auditabilidad no depende de leer la mente del modelo. Depende de poder reconstruir la ejecución. Ese enfoque es especialmente importante cuando el agente participa de procesos críticos.

La observabilidad también sirve para mejorar, no solamente para auditar

Si pensamos observabilidad únicamente como una exigencia de Risk o Compliance, perdemos una parte importante de su valor. También permite responder preguntas de negocio y operación.

• ¿Cuántas tareas completa correctamente?
  
• ¿Dónde necesita intervención humana?
  
• ¿Qué herramientas fallan con mayor frecuencia?
  
• ¿Qué procesos generan más excepciones?
  
• ¿En qué casos el agente tarda demasiado?
  
• ¿Qué decisiones son revertidas por una persona?
  
• ¿Dónde estamos gastando demasiado?
  
• ¿Aumentó realmente la productividad?

Esto convierte la observabilidad en una herramienta para optimizar el agente y medir su impacto. Un sistema que no puede ser observado tampoco puede mejorarse con disciplina.

Evaluar agentes requiere mirar comportamiento, no solo outputs aislados

En aplicaciones determinísticas, una prueba suele tener un resultado esperado bastante claro. Los agentes pueden comportarse de manera más variable, por eso, las evaluaciones necesitan contemplar no solo si la respuesta final fue correcta, sino también aspectos como: uso adecuado de herramientas; cumplimiento de políticas; consistencia; calidad de la información utilizada; cantidad de escalaciones; acciones bloqueadas; errores; y resultados de negocio.

Esto permite monitorear si el comportamiento cambia a medida que se actualizan modelos, prompts, herramientas, datos o políticas.
Un agente aprobado hoy no debería asumirse correcto para siempre.

Observabilidad y Human-in-the-Loop están conectados

Supongamos que una persona debe aprobar determinadas acciones.
Eso resuelve parte del control.
Pero si no registramos qué recomendó el agente; qué vio la persona; qué decidió;
qué acción se ejecutó finalmente; y quién fue responsable; la supervisión humana queda fuera del audit trail. Por eso, Human-in-the-Loop no debería ser una actividad informal. Tiene que formar parte del flujo observable.

Lo mismo ocurre cuando una persona revierte una decisión. Ese comportamiento es información valiosa para entender dónde los guardrails o las evaluaciones necesitan mejorar.

Observabilidad también protege a la organización cuando el agente funciona bien

Auditabilidad suele asociarse a incidentes, pero también permite demostrar que un sistema operó dentro de lo esperado.

• Que utilizó información autorizada.
  
• Que respetó límites.
  
• Que una decisión fue aprobada correctamente.
  
• Que un control se ejecutó.
  
• Que una excepción fue escalada.

Esto es especialmente relevante en procesos donde no alcanza con hacer lo correcto. También hay que poder demostrar que se hizo.

Agent sprawl hace más difícil observar

Con cinco agentes, puede ser posible revisar manualmente algunos comportamientos. Con cincuenta, deja de ser sostenible. Cada agente puede tener distintos logs; diferentes herramientas; métricas incompatibles; modelos de identidad distintos; owners diferentes.

La proliferación de agentes sin estándares comunes genera también una proliferación de evidencia fragmentada, por eso, antes de escalar conviene definir una base compartida de observabilidad. No necesariamente una única tecnología, sí un conjunto común de requisitos.

• Qué hay que registrar.
  
• Cómo identificar cada agente.
  
• Cómo correlacionar una ejecución.
  
• Cómo capturar tool calls.
  
• Cómo registrar aprobaciones.
  
• Cómo evaluar resultados.
  
• Cómo alertar ante excepciones.

La auditabilidad tiene que diseñarse antes del incidente

Cuando aparece un problema, ya es demasiado tarde para decidir qué hubiera sido útil registrar. Lo mismo ocurre ante una auditoría. Si la evidencia no fue generada durante la ejecución, difícilmente pueda reconstruirse después con precisión. Por eso, observabilidad y trazabilidad deberían formar parte de los criterios de producción. Igual que disponibilidad, seguridad, performance o recuperación.

8 preguntas para saber si un agente es realmente observable

1. ¿Podemos identificar qué agente ejecutó cada acción?
   
2. ¿Sabemos bajo qué identidad actuó?
   
3. ¿Podemos reconstruir qué datos y herramientas utilizó?
   
4. ¿Sabemos qué políticas y guardrails aplicaban?
   
5. ¿Podemos identificar dónde intervino una persona?
   
6. ¿Quedan registradas excepciones y escalaciones?
   
7. ¿Podemos evaluar calidad y comportamiento a lo largo del tiempo?
   
8. ¿La evidencia generada sirve realmente para operación, Risk y Auditoría?

Si la respuesta depende de revisar manualmente varios sistemas diferentes, todavía existe una brecha de observabilidad.

No alcanza con que el agente haga lo correcto

A medida que la IA gana capacidad de acción, aumenta también la necesidad de evidencia. La organización tiene que poder saber:

• qué ocurrió
  
• quién actuó
  
• sobre qué información
  
• con qué autoridad
  
• bajo qué reglas
  
• y con qué intervención humana.

La confianza en Agentic AI no se construye solamente evitando errores. También se construye pudiendo demostrar cómo opera.

En COA trabajamos observabilidad, trazabilidad y auditabilidad como parte de una arquitectura de Controlled Agents, no como una capa agregada después de llevar el agente a producción.

¿Qué tan preparada está tu organización para operar IA con control?

Realizá la Evaluación de Madurez de IA de COA e identificá fortalezas, brechas y capacidades que conviene desarrollar para escalar.

Si ya tenés un caso donde observabilidad, trazabilidad o auditoría se están convirtiendo en una barrera:

Preguntas frecuentes

¿Qué es observabilidad en Agentic AI?

Es la capacidad de comprender qué está haciendo un agente mediante logs, traces, métricas, evaluaciones y otros registros de su ejecución.

¿Cuál es la diferencia entre logging y observabilidad?

Logging registra eventos. Observabilidad utiliza distintos tipos de señales para entender el comportamiento general del sistema, detectar problemas y reconstruir ejecuciones.

¿Qué debería quedar registrado cuando un agente ejecuta una acción?

Entre otras cosas, identidad, contexto, datos utilizados, herramientas invocadas, acciones realizadas, guardrails aplicados, aprobaciones, excepciones y resultado.

¿Por qué la observabilidad es importante para Auditoría?

Porque permite generar evidencia sobre cómo operó el agente y reconstruir acciones, permisos, decisiones y supervisión.