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

Trazabilidad es poder reconstruir, después, qué hizo el agente en una tarea. Qué acción llamó, con qué datos, con qué versión del sistema y qué cambió en el producto. Una respuesta que se lee bien no demuestra que la ejecución fuera correcta. Si no puedes reconstruir la tarea, es difícil operarla y arreglarla en un entorno de verdad.

Cada tarea debería llevar un identificador (un run_id, un trace_id o el nombre que uséis) que una todo lo de ese proceso: la persona, el agente, la cuenta del cliente, cada acción, la versión que corrió, de dónde salió lo que el modelo leyó, si una persona aprobó y qué cambió en el producto. Ese identificador no es lo mismo que el rastro técnico de una petición. En OpenTelemetry, ese rastro (lo llaman traza) suele estar hecho de trozos que describen el camino de una llamada. El identificador de la tarea es el número de negocio que ata esa llamada al efecto en vuestro producto. Se pueden cruzar, pero no son intercambiables.

OpenTelemetry ya describe qué se puede anotar en un sistema generativo: el modelo, los tokens, las acciones y, si lo activas a propósito, el contenido. El texto va apagado por defecto, porque ahí caben nombres, claves y datos de cliente.

Este artículo no monta un laboratorio de pruebas y no sustituye lo que ya contamos de permisos. Habla de la información que tienes que poder recuperar cuando la tarea ya pasó y el texto final ya no basta para operarla. En el mapa de capas esto era una línea (comprobación y registro). Aquí es el trabajo.

El mito de la respuesta perfecta

La demo premia una respuesta que se lee bien. La prueba premia el efecto en el producto. El copiloto puede cerrar el hilo diciendo que ya actualizó el CRM, creó la tarea o cambió el estado de una oportunidad, y el chat se ve limpio. Horas después el cliente, o el equipo de ventas, ve que el registro no se movió. Nadie puede decir qué acción corrió, con qué identificador o si una persona aprobó. Un agente puede usar la acción equivocada, mezclar la cuenta de otro cliente en lo que lee y aun así escribir un cierre que suena de persona con experiencia.

Eso no se ve en el chat. Se ve si puedes responder qué acción corrió, con qué datos, qué versión de las instrucciones, qué documento leyó y quién aprobó. Si la respuesta es "se leía bien", estás puntuando el estilo. Es el mismo salto de una demo no es un agente: el texto no es la prueba.

Una respuesta correcta no demuestra tres cosas. No demuestra que se usó la acción correcta ni que salió bien: una acción puede buscar, calcular, leer una base o escribir, y el registro tiene que decir cuál fue y qué devolvió. Tampoco demuestra que lo que leyó era de esa cuenta, porque un resumen limpio puede apoyarse en el expediente del vecino. Y no demuestra que nadie tuvo que intervenir: si una persona corrigió el cambio de estado o reescribió el correo y eso no queda escrito, el agente se lleva el mérito y el equipo se lleva el incidente.

Si no puedes comprobar esas tres preguntas, no tienes bastante trazabilidad de la tarea. Tienes un chat que se lee bien y un proceso que no puedes revisar.

Qué hay que poder reconstruir

Un registro útil no es "guardamos las instrucciones". Es poder reconstruir qué pasó cuando algo sale mal, con nombres e identificadores, sin depender del chat interno ni de la memoria de quien miraba el hilo. Lo mínimo es poder seguir la cadena desde quien empieza la tarea hasta el efecto en el producto.

Si cambias las instrucciones el martes, deberías poder decir qué versión corría en cada tarea del lunes. El "sí" del modelo no es el efecto. El efecto es si se actualizó un registro, se creó una tarea, se envió un correo o cambió el estado de una oportunidad.

No hace falta un producto de observabilidad el primer día. Sí hace falta no tirar el rastro. Un registro de eventos sueltos ("llamó al sistema", "respondió") sin un identificador que los una es ruido. Si no puedes reconstruir esa cadena, cambias las instrucciones porque "parece 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 tarea, cada acción, los datos, el resultado y el error, unidos.

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

La acción es la puerta hacia vuestro producto. El registro es la prueba de que se usó esa puerta, no otra.

En cada llamada quieres un nombre, datos bien definidos (una lista cerrada, no un campo de texto libre), un resultado o un error, y un número de intento. También quieres la versión del sistema que la disparó: modelo, instrucciones y código del agente. Sin versión, el martes no puedes decir si el fallo es de estas instrucciones o de la semana pasada.

Los reintentos también van en el registro. Si una llamada devuelve error y el agente la repite, necesitas saber cuántos intentos hubo y qué devolvió cada uno, porque ahí aparecen el coste y los duplicados: dos actualizaciones del mismo registro, dos correos, dos cambios de estado. El registro tiene que decir si esa llamada era la primera o la tercera.

En la prueba, no anotes solo que "el agente usó acciones". Anota la lista: get_account una vez, update_opportunity cero, o update_opportunity dos veces, y entonces el problema es otro.

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

El contexto no es la memoria y no es el estado. Ya separamos esas tres cosas en el mapa. Aquí importa el origen: qué trozo, qué fuente, qué cuenta de cliente y qué fecha.

Si el modelo resume un artículo de ayuda, el registro dice qué artículo, no "buscó en la base de conocimiento". Si usa mensajes de un hilo, deberías poder identificar cuáles. Si carga un pedido o una ficha de cuenta, deberías poder identificar el order_id o el account_id. Sin eso, "se inventó el importe" y "leyó el registro viejo" se ven iguales en el chat, y no se ven iguales en el registro.

El fallo habitual es pegar el hilo entero en la siguiente pregunta y llamarlo prueba. Después no puedes decir de dónde salió cada fragmento, y no puedes olvidar o borrar la información de un cliente sin tocar la del resto. El origen es un identificador y una cuenta, no un volcado.

En la prueba, prioriza el origen de lo que dispara una acción. El resto de lo que el modelo leyó en ese turno puede esperar.

Si una persona aprueba, eso también queda escrito

Que una persona esté en medio no es una sensación de control. Es un hecho: 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 dio el visto bueno" 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 aprobó.

Lo que guardas de esa aprobación: quién aprobó, una referencia a lo que vio, una huella para comprobar después que ese contenido no cambió, la decisión y el identificador de la tarea. La huella no sustituye al contenido. Comprueba que no se alteró. No reconstruye lo que se mostró. Si no quieres guardar el paquete entero, quédate con la referencia y la huella. No son la misma cosa.

Si el flujo no tiene persona, el registro debería decirlo. También debería anotar cuándo una acción no necesitaba aprobación, para que después no haya duda de quién participó.

Cómo reconstruir una tarea cuando falla

Reconstruir no es volver a preguntarle lo mismo al modelo y esperar el mismo texto. El modelo no es determinista, y los sistemas de fuera pueden haber cambiado. Repetir la tarea sería volver a correr las mismas condiciones, enteras o en parte, 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 tarea pasada.

Si no puedes hacerlo, no puedes arreglar el problema a propósito. Se discute sobre las instrucciones, y el fallo era un error del sistema, un identificador de otra cuenta 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 las instrucciones y las tareas viejas siguen nombrando la versión vieja. El efecto en el sistema de fuera cuadra con la llamada concreta que lo causó, no solo con el párrafo del chat.

Para depurar una tarea fallida, el detalle de esa ejecución suele servir más que un panel agregado, porque el panel resume y el registro cuenta la historia. Los dos sirven y ninguno sustituye al otro. Si exportas varias tareas, el riesgo no es "filas mezcladas" por sí solo. Es que los datos de una cuenta queden a la vista de otra, o de alguien que no debería verlos.

Lista: ¿puedes enseñar cómo llegó ahí?

Antes de abrir la segunda cuenta de cliente, el equipo debería poder responder esto.

¿Cada tarea tiene un identificador que une a la persona, al agente y a la cuenta?

¿Puedes nombrar las instrucciones, el modelo y la versión del agente de esa tarea?

¿Listas cada acción, con datos, resultado y número de intento?

¿Sabes de qué fuente y de qué cuenta salió lo que disparó la acción?

¿La aprobación de una persona es un hecho escrito, o solo un recuerdo?

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

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

Si no puedes responder a varias, probablemente no tienes bastante trazabilidad para reconstruir una tarea con confianza. La respuesta puede ser buena, y aun así no es prueba del proceso.

Qué no guardar: datos de cliente y secretos

El registro que te salva el lunes te puede filtrar el martes. OpenTelemetry no recomienda capturar cierto contenido sensible por defecto, como las instrucciones, los mensajes o los datos de las acciones. Esa captura hay que encenderla a propósito, porque esos campos pueden llevar datos de cliente, importes o claves.

Tres reglas de la prueba, no un programa eterno de cumplimiento. No pegues secretos: una clave en el registro es un incidente aplazado. Una cuenta no debe poder ver la información de otra, y cualquier exportación tiene que respetar los mismos controles de acceso y de separación. Ver varias cuentas en un mismo sitio está bien si hay separación y permisos. Lo que no vale es un volcado en el que un cliente ve al vecino. Y no guardes el cuerpo si bastan un identificador y una referencia: el account_id o el ticket_id, más una referencia al paquete y su huella, suelen bastar para cruzarlo. El documento entero casi nunca.

Cuánto tiempo se guarda también es una decisión. Distintos tipos de registro pueden necesitar políticas distintas, según para qué sirven, lo sensibles que son y las obligaciones que apliquen. Si no le pones fecha, lo acumulas, y lo que acumulas alguien lo exporta un día.

Cuando esas líneas existen, el resto es ingeniería. En Devic esa cadena se inspecciona en observabilidad: tareas, llamadas a acciones, datos, resultados y errores, unidos por un identificador. Puedes cambiar el modelo. La prueba de cómo se llegó a la acción se queda.

Una respuesta correcta no demuestra que la ejecución fuera correcta.