flowchart LR
A[Solicitud] --> B[Clasificación]
B --> C[Búsqueda DPA]
C --> D[Documento recuperado]
D --> E[Comparación]
E --> F[Tool de registro]
F --> G[Human gate]
G --> H[Salida]
Observabilidad
Cómo saber qué hizo un agente y por qué: logs, traces, métricas y auditoría como base para supervisar, diagnosticar y reconstruir su trayectoria.
En la página anterior establecimos que la calidad de un agente no puede evaluarse mirando únicamente la respuesta final.
También necesitamos observar su trayectoria:
- qué información utilizó;
- qué herramienta seleccionó;
- qué resultado obtuvo;
- qué paso ejecutó después;
- dónde falló;
- cuándo pidió aprobación.
Pero aparece una dificultad evidente.
No podemos evaluar aquello que el sistema no deja ver.
Un agente puede producir un informe de excelente apariencia y, sin embargo, no existir ninguna forma razonable de reconstruir qué ocurrió entre la solicitud inicial y ese resultado.
Por eso las clases introducen la observabilidad como una condición de supervisión.
Idea central
Observabilidad significa disponer de información suficiente sobre la operación del sistema para reconstruir su comportamiento, diagnosticar fallas y evaluar su trayectoria.
En este handbook distinguiremos cuatro elementos:
logs · traces · métricas · auditoría.
Los tres primeros producen distintos tipos de rastros operacionales.
La auditoría utiliza esos rastros, junto con reglas y evidencia, para evaluar si el sistema operó como debía.
Observar no significa leer “la mente” del modelo
Conviene eliminar una confusión desde el comienzo.
Supervisar un agente no requiere ni debería reducirse a intentar inspeccionar una supuesta conciencia o pensamiento interno.
Lo importante para una arquitectura gobernable son eventos observables del sistema.
Por ejemplo:
entrada recibida
modelo o componente invocado
fuente recuperada
tool seleccionado
parámetros enviados
resultado de la herramienta
estado actualizado
acción bloqueada
aprobación recibida
salida entregadaEstos elementos permiten reconstruir causalmente qué ocurrió.
En algunas implementaciones pueden existir datos adicionales sobre procesos internos del modelo. No necesitamos depender de ellos para construir una disciplina básica de observabilidad.
Logs: qué ocurrió y cuándo
Un log es un registro de eventos.
Puede verse como un diario operacional.
Por ejemplo:
14:02 expediente creado
14:03 contrato abierto
14:04 DPA no encontrado
14:04 búsqueda documental ejecutada
14:05 DPA recuperado
14:06 revisión de privacidad activada
14:11 riesgo alto detectado
14:12 aprobación humana solicitada
14:19 aprobación recibida
14:20 expediente actualizadoCada línea describe un acontecimiento.
Qué puede registrar un log
Dependiendo del sistema:
- fecha y hora;
- usuario o servicio;
- acción;
- herramienta;
- resultado;
- error;
- cambio de estado;
- autorización;
- identificador de expediente.
El log responde especialmente bien a preguntas como:
¿qué ocurrió?
¿cuándo ocurrió?
¿quién o qué componente participó?
Lo que un log aislado no muestra bien
Una colección de eventos puede contener millones de líneas.
Si queremos reconstruir una ejecución específica necesitamos saber cuáles pertenecen a la misma trayectoria.
Ahí aparece la trace.
Traces: cómo se encadenaron los pasos
Una trace conecta los eventos y operaciones que forman parte de una misma ejecución.
Podemos imaginarla como el hilo que une una tarea de principio a fin.
La trace permite responder:
¿cómo llegó el sistema desde la entrada hasta el resultado?
Una trace puede mostrar
- llamadas al modelo;
- versiones o configuraciones relevantes;
- herramientas seleccionadas;
- parámetros;
- respuestas de herramientas;
- documentos recuperados;
- tiempos;
- errores;
- reintentos;
- transiciones entre agentes;
- aprobaciones.
Google destaca las traces como instrumento central para depurar agentes porque permiten seguir el camino completo de ejecución y localizar la causa de un fallo.
Ejemplo de diagnóstico
Resultado final:
“No existe cláusula de auditoría.”
Trace:
1. agente busca “audit” en contrato principal
2. búsqueda devuelve 0 coincidencias
3. agente concluye ausencia
4. anexo de seguridad nunca fue abiertoYa no tenemos solamente un error.
Tenemos una hipótesis causal concreta:
el sistema trató el universo documental como incompleto.
Logs y traces no son sinónimos
Una forma sencilla de distinguirlos es ésta:
| Elemento | Pregunta principal |
|---|---|
| Log | ¿Qué evento ocurrió? |
| Trace | ¿Cómo se conectaron los eventos de esta ejecución? |
Un evento de log puede pertenecer a una trace.
La trace agrega estructura relacional.
Métricas: qué ocurre de manera agregada
Los logs y traces permiten mirar ejecuciones concretas.
Las métricas permiten observar patrones a través de muchas ejecuciones.
Ejemplos:
- porcentaje de tareas completadas;
- tasa de errores por herramienta;
- tiempo promedio de resolución;
- costo por expediente;
- número de reintentos;
- porcentaje de casos escalados;
- porcentaje de outputs corregidos por personas;
- frecuencia de recuperación de fuentes incorrectas;
- tasa de aprobaciones rechazadas;
- número promedio de tool calls.
Del caso individual al patrón
Un usuario informa:
“El agente no encontró el DPA.”
La trace permite estudiar ese caso.
Una métrica puede revelar:
“En el último mes el agente falló al recuperar anexos en 18% de expedientes provenientes del repositorio X.”
La segunda observación cambia la naturaleza del problema.
Ya no parece una excepción aislada.
Puede existir una falla sistemática de integración.
Elegir métricas con sentido
Medir algo no significa que sea importante.
Podemos optimizar:
cantidad de contratos procesados por hora
mientras aumenta:
porcentaje de riesgos omitidos.
Por eso las métricas deben relacionarse con objetivos reales del sistema.
Google sugiere considerar, entre otras, tasas de finalización, satisfacción, latencia y costo, además de calidad. En trabajo jurídico puede ser útil añadir indicadores específicos:
- hallazgos sin evidencia;
- casos cerrados con información faltante;
- intervenciones humanas omitidas;
- errores por materia;
- fuentes desactualizadas utilizadas.
Auditoría: evaluar lo ocurrido contra reglas
La auditoría no es simplemente un cuarto tipo de telemetría.
Utiliza evidencia operacional para responder preguntas normativas o de control.
Por ejemplo:
¿el agente respetó el procedimiento autorizado?
¿utilizó únicamente las fuentes permitidas?
¿una acción externa tuvo aprobación previa?
¿la versión utilizada estaba autorizada?
¿el expediente conserva evidencia suficiente?
Podemos expresarlo así:
EVIDENCIA OPERACIONAL
logs + traces + métricas + artefactos
↓
REGLA / ESTÁNDAR
política + procedimiento + permiso + criterio
↓
AUDITORÍA
¿qué ocurrió y fue conforme?Auditoría no equivale a logging
Conservar muchos registros no significa automáticamente que el sistema sea auditable.
Para auditar necesitamos:
- identificar la ejecución;
- interpretar eventos;
- relacionarlos con reglas;
- conocer versiones relevantes;
- distinguir usuarios y componentes;
- conservar evidencia suficiente.
Un log desordenado puede existir sin producir una reconstrucción útil.
Diseñar identificadores para poder reconstruir
La observabilidad empieza antes de producir el primer log.
Para conectar eventos necesitamos identificadores consistentes.
Por ejemplo:
expediente_id = P-2026-041
run_id = R-88371
usuario = legal_27
agente = proveedor_ai_v3Con esos identificadores podemos relacionar:
- documentos abiertos;
- llamadas al modelo;
- herramientas;
- cambios de estado;
- aprobaciones;
- salida final.
Sin una clave común, los eventos pueden existir y aun así ser difíciles de reconstruir.
Versiones también son parte de la observabilidad
Si el comportamiento del sistema depende de configuración, puede ser relevante registrar:
- versión del agente;
- versión del prompt o política;
- modelo utilizado;
- versión de herramienta;
- fuente o documento vigente.
Supongamos que el mismo expediente produce respuestas distintas una semana después.
Sin información de versión no sabemos si cambió:
- el modelo;
- el criterio;
- el corpus;
- la herramienta;
- el propio documento.
La trazabilidad temporal permite explicar diferencias.
Monitoreo y observabilidad
En lenguaje cotidiano pueden parecer sinónimos, pero es útil distinguirlos.
Monitoreo pregunta por variables conocidas:
¿está funcionando?
¿cuántos errores hay?
¿cuánto tarda?
Observabilidad busca permitir responder preguntas nuevas cuando ocurre algo inesperado:
¿por qué este caso específico terminó en una ruta incorrecta?
Las métricas pueden avisar que existe un problema.
Los traces y logs permiten investigar la causa.
Esta relación puede expresarse así:
MÉTRICA
“aumentó la tasa de fallas”
↓
TRACE
“estas ejecuciones siguen una ruta distinta”
↓
LOG / EVENTO
“la herramienta devolvió error y el sistema lo trató como éxito”Un ejemplo jurídico completo
Imaginemos que un proveedor reclama que el equipo aprobó una excepción contractual.
El sistema registra:
Log
16:41 excepción propuesta
16:42 solicitud de aprobación creada
16:49 usuario_347 selecciona “aprobar”
16:50 estado contractual actualizadoTrace
Permite reconstruir:
- qué hallazgo generó la propuesta;
- qué cláusula se utilizó;
- qué alternativa preparó el agente;
- qué información vio la persona;
- qué acción ocurrió después de la aprobación.
Métricas
Muestran que:
- 7% de contratos requieren excepciones;
- 82% son aprobadas;
- tiempo medio de revisión humana: 12 minutos.
Auditoría
Compara la ejecución con la política:
“Toda excepción de responsabilidad superior al umbral X requiere aprobación del responsable jurídico.”
Entonces verificamos si el usuario que aprobó tenía ese rol.
Cada elemento responde una pregunta diferente.
Observabilidad y evidencia jurídica
No todo log será necesariamente “prueba” en un sentido jurídico formal.
Tampoco debemos asumir que un registro técnico es infalible.
Puede haber:
- errores de reloj;
- registros incompletos;
- identidades compartidas;
- eventos no capturados;
- cambios de configuración;
- retenciones insuficientes.
La observabilidad proporciona evidencia operacional que puede apoyar una reconstrucción.
Su valor dependerá de cómo fue diseñada, protegida y conservada.
El riesgo inverso: registrar demasiado
Una reacción intuitiva podría ser:
“Si la trazabilidad es importante, guardemos todo.”
Eso puede crear nuevos riesgos.
Los logs y traces pueden contener:
- prompts;
- fragmentos de contratos;
- datos personales;
- secretos comerciales;
- resultados de búsquedas;
- identificadores;
- parámetros de herramientas;
- contenido confidencial.
Por tanto debemos preguntar:
- ¿qué datos es necesario registrar?;
- ¿podemos registrar metadatos sin contenido completo?;
- ¿quién puede acceder?;
- ¿cuánto tiempo se conservan?;
- ¿cómo se protegen?;
Observabilidad y minimización deben diseñarse conjuntamente.
Observabilidad y supervisión humana
Una persona sólo puede supervisar aquello que el sistema hace visible.
Comparemos dos aprobaciones.
Aprobación opaca
El agente recomienda aprobar.
¿Confirmar? [Sí] [No]Aprobación observable
RECOMENDACIÓN
Aprobar con condición.
EVIDENCIA
Contrato §12.4 + DPA §6.
DESVIACIÓN
Plazo de notificación > estándar interno.
ACCIÓN PROPUESTA
Solicitar modificación.
TRAYECTORIA
Ver fuentes y pasos.La segunda interfaz permite una revisión más significativa.
Por eso observabilidad no es únicamente una preocupación de ingeniería. Puede determinar la calidad de la supervisión profesional.
De la observabilidad al aprendizaje organizacional
Los rastros operacionales también permiten descubrir problemas que no eran visibles durante el diseño.
Si muchas traces muestran que el agente siempre necesita una búsqueda adicional antes de revisar cierta cláusula, quizá falte incorporar una fuente de manera sistemática.
Si los usuarios rechazan casi todas las propuestas de una categoría, el problema puede estar en los criterios o en la interfaz.
Si una herramienta concentra la mayoría de los errores, la mejora prioritaria quizá no sea cambiar el modelo.
La observabilidad convierte el uso real en una fuente de aprendizaje sobre el sistema y sobre el propio proceso institucional.
Qué puede salir mal
Logs sin contexto
Registran eventos pero no permiten relacionarlos con un expediente.
Traces incompletas
Muestran llamadas al modelo pero omiten herramientas o aprobaciones.
Métricas de vanidad
Miden volumen sin medir errores o calidad.
Retención insuficiente
Cuando aparece un incidente ya no existe evidencia para reconstruirlo.
Retención excesiva
Aumenta exposición de datos innecesarios.
Auditoría sin criterio
No podemos determinar conformidad si las reglas del proceso nunca fueron definidas.
Qué debes recordar
Los logs registran eventos.
Las traces reconstruyen la secuencia de una ejecución.
Las métricas muestran patrones agregados.
La auditoría compara lo ocurrido con reglas y criterios.
Juntos permiten pasar de:
“el agente hizo algo extraño”
hacia:
“podemos reconstruir qué ocurrió, localizar dónde se desvió y evaluar si respetó los controles.”
El problema que todavía queda abierto
La observabilidad nos permite ver mejor el sistema.
Pero precisamente al observarlo podemos reconocer una realidad incómoda:
los agentes no sólo heredan riesgos conocidos de la IA generativa. También pueden encadenarlos y convertir errores informativos en acciones.
La siguiente página estudia seis riesgos especialmente relevantes:
confidencialidad, error plausible, sesgo, exceso de acción, falta de trazabilidad y dependencia operacional.