Tu agente entrega una respuesta perfecta. ¿Puedes demostrar cómo llegó?

Auditar el proceso de un agente es poder reconstruir la ejecución: qué herramientas se llamaron, con qué datos, en qué versión del sistema y qué efecto tuvo en el producto. Que el agente genere una respuesta correcta no demuestra que esa ejecución también lo haya sido. Si no puedes reconstruir qué ha ocurrido durante el run, es muy difícil operarlo y depurarlo en producción.

Cada ejecución debería contar con un identificador (run_id, trace_id o equivalente) que permita correlacionar todas las acciones de ese proceso: usuario, agente, tenant (la cuenta de un cliente en tu SaaS), cada tool, la versión que corrió, de dónde salió el contexto, si un humano aprobó y qué cambió en el producto. Ese identificador no es lo mismo que una trace de observabilidad. En OpenTelemetry, una trace suele estar compuesta por spans y describe la topología de una petición; el run_id es el identificador de negocio que une esa petición con el efecto en tu producto. Los dos se pueden correlacionar, pero no son intercambiables.

OpenTelemetry ya describe qué se puede anotar en un sistema generativo: modelo, tokens, tools y, si lo habilitas de forma explícita, el contenido. Por defecto no se guarda el texto, porque ahí caben nombres, credenciales y datos del cliente.

Este artículo no entra en cómo montar un laboratorio de evaluaciones ni sustituye lo que ya cubrimos sobre permisos. Se centra en qué información tienes que poder recuperar cuando una ejecución ya ocurrió y el output, por sí solo, no basta para operarla. En el mapa de capas esto era una línea (evaluación y logs). Aquí es el trabajo.

El mito del output perfecto

La demo premia una respuesta que se lee bien. El piloto premia el efecto en el producto. El copiloto puede cerrar un hilo diciendo que ya actualizó el CRM, que creó la tarea o que cambió el estado de una oportunidad, y el chat queda impecable. Horas después el cliente (o el equipo de ventas) descubre que el registro no se movió. Nadie puede decir qué tool se llamó, con qué identificador, ni si un humano aprobó. Un agente puede usar la herramienta equivocada, mezclar el tenant en el contexto y aun así redactar un cierre que parece de alguien senior.

Eso no se ve en el chat. Se ve si puedes responder qué tool se usó, con qué argumentos, qué versión de prompt, qué documento leyó y quién aprobó. Si la respuesta es "se leyó bien", estás midiendo estilo. Es el mismo salto que una demo no es un agente: el output no es la prueba.

Una respuesta correcta no demuestra tres cosas. No demuestra que se usó la herramienta adecuada ni que se ejecutó bien: una tool puede consultar, buscar, calcular, leer una base de datos o escribir, y el registro tiene que decir cuál fue y con qué resultado. Tampoco demuestra que el contexto pertenecía a ese tenant, porque un resumen limpio puede apoyarse en la ficha del cliente de al lado. Y no demuestra que nadie tuvo que intervenir: si un humano corrigió el cambio de estado o reescribió el correo y eso no quedó escrito, el agente se lleva el mérito y el equipo se lleva el incidente.

Si no puedes verificar esas tres cuestiones, no tienes suficiente trazabilidad sobre la ejecución: tienes un chat que se lee bien y un proceso que no puedes auditar.

Qué tienes que poder reconstruir de una ejecución

Un registro útil no consiste en "guardar el prompt". Consiste en poder reconstruir qué ocurrió ante una incidencia, con nombres e identificadores, sin depender de conversaciones internas ni de la memoria de quienes estaban delante del chat. Lo mínimo es poder seguir la cadena de quien dispara la ejecución al efecto en el producto.

Si modificas el prompt el martes, deberías poder identificar qué versión estaba ejecutándose en cada run del lunes. El "sí" del modelo no cuenta como efecto: cuenta si se actualizó un registro, se creó una tarea, se envió un correo o se cambió el estado de una oportunidad.

No hace falta un producto de observabilidad el día 1, pero sí no tirar el rastro. Un log de eventos sueltos ("llamó a la API", "respondió") sin un identificador que los una es ruido. Si no puedes reconstruir esa cadena, cambias el prompt porque "parece que va mejor" y no sabes si bajaron los fallos o subió la factura.

Eso es lo que deberías poder abrir el lunes. En Devic se inspecciona en observabilidad: la ejecución, cada tool, los argumentos, el resultado y el error, correlacionados.

Qué tools llamó, con qué versión y cuántas veces

La tool es la puerta hacia tu producto. El registro es la prueba de que se usó esa puerta y no otra.

Para cada llamada quieres nombre, argumentos bien definidos (un schema limitado, no un campo libre), resultado o error, y número de intento. También la versión del sistema que la disparó: modelo, prompt y código del agente. Sin versión, el martes no puedes decir si el fallo es de este prompt o del de la semana pasada.

También debemos registrar los reintentos. Si una llamada a una herramienta devuelve un error y el agente vuelve a ejecutarla, necesitamos saber cuántos intentos se produjeron y cuál fue el resultado de cada uno, porque ahí se ve tanto el coste como una posible duplicidad (dos actualizaciones del mismo registro, dos correos, dos cambios de estado). El registro tiene que decir si aquella llamada fue la primera o la tercera.

En el piloto, no basta con anotar que "el agente usó tools". Graba la lista: get_account una vez, update_opportunity cero, o update_opportunity dos, y entonces tienes un problema distinto.

De dónde salió lo que el modelo leyó

El contexto no es memoria y no es estado. Eso ya lo separamos en el mapa. Aquí importa el origen: qué trozo, de qué fuente, de qué tenant y con qué fecha.

Si el modelo resume un artículo de ayuda, el registro dice qué artículo, no "buscó en la base". Si utiliza información procedente de un hilo de conversación, deberíamos poder identificar qué mensajes utilizó. Si incorpora información de un pedido o de una ficha de cliente, deberíamos poder identificar el order_id o el account_id correspondiente. Sin eso, "se inventó el importe" y "leyó el registro viejo" se parecen en el chat, y en el registro no.

El fallo típico es pegar el hilo entero en el siguiente prompt y llamarlo evidencia. Después no puedes identificar de dónde salió cada fragmento, ni olvidar o eliminar de forma selectiva la información de un cliente. La procedencia es un id y un tenant, no un volcado.

En el piloto, prioriza el origen de lo que dispara una acción. El resto del contexto de ese turno puede esperar.

Cuando un humano aprueba, eso también queda escrito

Un human in the loop (un humano en el circuito) no es una sensación de control. Es un evento: quién vio qué, qué aprobó, a qué hora y sobre qué recurso (opportunity_id, task_id, ticket_id).

En permisos la pregunta era cuándo hace falta esa persona. Aquí la pregunta es si puedes demostrarlo. "Marta lo validó" que no está en el registro es una conversación de pasillo, y el día del incidente Marta no recuerda el importe ni el estado que firmó.

Lo que se guarda de esa aprobación: identidad de quien aprueba, una referencia al contenido que vio, un hash para comprobar después que ese contenido no ha cambiado, la decisión y el identificador de la ejecución. El hash no sustituye al contenido: sirve para verificar integridad, no para reconstruir qué se presentó. Si no quieres almacenar el payload completo, guarda la referencia y el hash; no presentamos las dos cosas como equivalentes.

Si el flujo no tiene humano, el registro también debe decirlo. Debe quedar escrito cuándo una acción no requirió aprobación, para evitar ambigüedades posteriores sobre quién intervino en la ejecución.

Cómo reconstruir una ejecución después de un fallo

Reconstruir no es volver a pedirle lo mismo al modelo y esperar el mismo texto. El modelo no es determinista, y los sistemas externos pueden haber cambiado. Reproducir o hacer replay sería volver a ejecutar, total o parcialmente, las mismas condiciones, y no tiene por qué devolver el mismo resultado. Lo que sí puedes (y debes) hacer es abrir el mismo identificador y ver las mismas llamadas, el mismo contexto y la misma versión: eso es reconstruir una ejecución pasada.

Si no puedes hacer eso, no puedes arreglar con criterio. Discutís el prompt, y el fallo era un 500, un id de otro tenant o un reintento que aplicó el cambio dos veces.

Hay tres pruebas sencillas de que puedes reconstruirla: alguien que no escribió el agente abre el identificador y cuenta qué pasó; cambias el prompt y los runs viejos siguen nombrando la versión vieja; y el efecto en el sistema externo se correlaciona con la llamada concreta que lo provocó, no solo con la prosa del chat.

Para depurar una incidencia concreta, el detalle de una ejecución fallida suele ser más útil que un dashboard agregado, porque el dashboard resume y el registro cuenta. Los dos sirven y no se sustituyen. Si exportas varias ejecuciones, el riesgo no es "mezclar filas" por sí solo: es que los datos de un tenant queden accesibles para otro tenant o para alguien que no debería verlos.

Checklist: ¿puedes demostrar cómo llegó?

Antes de abrir el segundo tenant, el equipo debería poder responder estas preguntas:

¿Cada ejecución tiene un identificador que une usuario, agente y tenant?

¿Puedes nombrar la versión de prompt, modelo y agente de ese run?

¿Listas cada tool, con argumentos, resultado y número de intento?

¿Sabes de qué fuente y de qué tenant salió el contexto que disparó la acción?

¿Una aprobación humana queda como evento, o solo como recuerdo de alguien?

¿Alguien puede abrir la última ejecución problemática y contarla sin haber estado en el chat?

¿El efecto en el producto (registro, correo, estado de una oportunidad) aparece en el registro, no solo el "sí" del modelo?

Si no puedes responder a varias de estas preguntas, probablemente no tienes suficiente trazabilidad para reconstruir con garantías una ejecución. El output puede ser bueno, y aun así no es la prueba del proceso.

Qué no guardar: datos de cliente y claves

El registro que te salva el lunes puede filtrarte el martes. OpenTelemetry no recomienda capturar por defecto determinados contenidos sensibles, como prompts, mensajes o argumentos de herramientas; su captura debe habilitarse explícitamente, porque esos campos pueden contener información del cliente, importes o credenciales.

Tres reglas de piloto, no de un programa de compliance eterno. No pegues secretos: una clave API en el log es un incidente con retraso. Un tenant no debe poder acceder a la información de otro, y cualquier export tiene que respetar los mismos controles de acceso y aislamiento; la observabilidad multi-tenant es posible si hay segregación y permisos, lo que no es aceptable es un volcado en el que un cliente vea al de al lado. Y no guardes el cuerpo si te basta un id y una referencia: el account_id o el ticket_id, más una referencia al payload y su hash, suelen alcanzar para correlacionar. El documento entero rara vez hace falta.

La retención también es una decisión. Distintos tipos de logs pueden requerir políticas distintas, según la finalidad, la sensibilidad del dato y las obligaciones que apliquen. Si no lo fechas, lo acumulas, y lo que acumulas un día lo exporta alguien.

Cuando esas líneas existen, el resto es ingeniería. En Devic puedes inspeccionar esa cadena en observabilidad: ejecuciones, llamadas a herramientas, argumentos, resultados y errores, correlacionados por un identificador. El modelo se puede cambiar; la prueba de cómo se llegó a la acción no.

La respuesta puede ser correcta sin que eso demuestre que la ejecución también lo haya sido.