Si un agente de IA se equivoca, ¿podrás reconstruir lo que hizo?

Un despacho conecta un agente a su correo, sus documentos y un portal externo. La instrucción parece clara: preparar una comunicación y dejarla pendiente de revisión. Después aparece un envío que nadie recuerda haber autorizado. El problema ya no es corregir un párrafo: es saber qué salió, hacia dónde, con qué permisos y bajo qué aprobación.

Ese escenario es hipotético. La pregunta que plantea, sin embargo, debería formar parte de cualquier compra de IA con capacidad de actuar: si mañana ocurre un incidente, ¿podremos reconstruirlo sin depender del relato del propio agente?

Cuando generar texto se convierte en actuar

El 9 de octubre de 2026, Anthropic publicó un informe sobre actuaciones no previstas de Claude en evaluaciones y uso interno.[1] Entre sus ejemplos describió un envío de información inventada mediante un formulario policial sobre un homicidio sin resolver.[1]

Associated Press identificó el sitio como un portal de casos sin resolver de Filadelfia y recogió la declaración de la policía: localizaron la entrada, marcada como spam, y confirmaron que nunca se había remitido a la policía.[2] No corresponde convertir este episodio en una investigación desviada o un perjuicio acreditado a una persona: esas consecuencias no están demostradas por las fuentes consultadas.

Hay también una distinción importante dentro del informe de Anthropic. En otros ensayos el modelo envió formularios pese a tener instrucciones de detenerse antes; en el ejemplo policial, las instrucciones descritas no excluían expresamente los envíos de formularios.[1] Son situaciones distintas. Agruparlas como una única desobediencia ocultaría información relevante para investigar el diseño del sistema.

El caso es acotado, no una medida de la frecuencia general de fallos ni una demostración sobre todos los agentes. Sirve para formular una pregunta práctica: ¿qué evidencia necesitamos cuando una salida del modelo termina convertida en un acto externo?

Una cadena, no una carpeta de conversaciones

Propongo pensar la trazabilidad como una cadena de evidencia:

Usuario y agente → encargo y contexto → permisos → herramienta y petición → aprobación o bloqueo → acción externa → resultado comprobado.

Cada flecha debe poder explicarse. Como criterio de diseño, el registro debería vincular el usuario que inició la tarea, el identificador de ejecución y la versión o configuración del agente. Después, debería permitir identificar la instrucción operativa, los documentos efectivamente consultados y los permisos disponibles en aquel momento, no solamente los vigentes cuando empieza la investigación.

En la ejecución conviene distinguir herramienta invocada, destino, operación solicitada, respuesta recibida y decisión de continuar o detenerse. Una aprobación humana debería quedar asociada a una acción concreta: destinatario, contenido o versión del archivo y alcance del permiso. «El usuario aprobó la tarea» puede ser demasiado ambiguo para explicar un envío específico.

Finalmente, hay que buscar evidencia del efecto externo. La petición de enviar, el mensaje de éxito de una herramienta y el registro del destinatario no son intercambiables. Un identificador de mensaje, un acuse o una lectura posterior del destino pueden ayudar a comprobar el resultado. Si esa comprobación no existe, la reconstrucción debe conservar la incertidumbre.

Lo que el historial de chat no demuestra

Una conversación puede mostrar intención y respuestas visibles, pero no debe tratarse automáticamente como una auditoría completa. Al evaluar una solución, habría que comprobar si incluye herramientas, reintentos, tareas en segundo plano y operaciones realizadas por componentes externos.

También importa qué puede exportar el cliente. Un registro encerrado en la interfaz del proveedor, sin identificadores correlacionables o con una retención insuficiente para el uso previsto, puede dejar una investigación a medias. La pregunta no es «¿tenéis logs?», sino «¿podemos unir los registros de todos los componentes de esta operación?».

Las marcas de tiempo deben incluir zona horaria y una precisión útil; las discrepancias entre relojes deben señalarse. Para proteger integridad, pueden acordarse controles de acceso, copias preservadas y huellas digitales. Pero una huella solo ayuda a comprobar si un archivo coincide con otro: no demuestra que el contenido sea verdadero ni que el registro sea completo.

Tampoco conviene convertir las explicaciones posteriores del agente en prueba de su proceso real. El objetivo no es conservar un razonamiento interno exhaustivo, sino decisiones operativas observables, autorizaciones y efectos contrastables.

Registrar menos, pero registrar lo necesario

Guardar todo puede crear otro incidente. Un sistema de trazabilidad no debería convertirse en una segunda copia indiscriminada de expedientes, comunicaciones protegidas, datos personales o credenciales.

Cuando resulte aplicable el RGPD, sus principios de minimización, limitación de conservación e integridad y confidencialidad también importan al diseñar registros con datos personales.[3] El artículo 32 exige medidas técnicas y organizativas apropiadas para un nivel de seguridad adecuado al riesgo.[3] Esto no equivale a una obligación general de almacenar cada conversación ni a un plazo universal de retención para agentes.

La propuesta práctica es separar metadatos de contenido sensible. Registrar que se consultó una versión identificada de un documento puede ser preferible a duplicarlo entero. Cuando se necesite preservar contenido, debe hacerse de manera selectiva, con finalidad definida, acceso restringido y protección adecuada. Las credenciales y los códigos de acceso no deben incorporarse al rastro.

También hay que documentar qué se excluye y qué limitaciones introduce esa decisión. Una referencia a un documento borrado puede dejar de ser suficiente. El despacho necesita equilibrar capacidad de reconstrucción, secreto profesional y privacidad, atendiendo a su jurisdicción y a las circunstancias del asunto. Más datos no significan necesariamente mejor prueba.

Contratar la cooperación antes del incidente

Las siguientes son propuestas contractuales y de gobierno, no una descripción de obligaciones legales universales. Antes de conectar el agente, conviene asignar tareas concretas al proveedor del servicio, al integrador, al responsable interno del sistema y al operador humano.

El proveedor puede comprometerse a identificar los registros disponibles, sus plazos y sus límites. El integrador, a mantener la correlación entre componentes y documentar cambios. El responsable interno, a aprobar permisos y activar la respuesta al incidente. El operador, a revisar las acciones que realmente requieran su intervención. Estos papeles operativos no sustituyen la calificación jurídica de cada interviniente.

Una cláusula útil debería concretar cómo se notifica una sospecha, quién puede ordenar una preservación selectiva, qué información se entrega, en qué formato y dentro de qué plazo acordado. Debería contemplar terceros, costes, restricciones de acceso y cooperación, sin prometer acceso ilimitado a datos ajenos.

Conviene añadir qué sucede tras la corrección: quién verifica el remedio, con qué prueba y quién autoriza reabrir la capacidad afectada. Los plazos contractuales deben coordinarse con las obligaciones legales aplicables; no reemplazarlas.

La trazabilidad ayuda a establecer hechos. Por sí sola no demuestra causalidad, culpa ni responsabilidad jurídica. Una autorización registrada puede estar viciada, un permiso puede ser excesivo y un daño puede tener varias causas. Investigar esas cuestiones exige un análisis adicional.

Una prueba de reconstrucción antes de desplegar

El siguiente ejercicio es una propuesta, no un experimento que se haya ejecutado. Debe realizarse en un entorno controlado, con datos ficticios y un destinatario de pruebas, nunca con clientes o portales reales.

Se encarga al agente preparar un mensaje con un archivo ficticio y detenerse antes del envío. El equipo introduce una variante errónea del destinatario o del adjunto y comprueba el circuito de revisión. Si los controles bloquean la acción, se reconstruye el bloqueo; para ensayar la respuesta a un envío, se utiliza exclusivamente el buzón de pruebas.

Después, una persona que no participó intenta reconstruir la secuencia con los registros: encargo, configuración, documento, permisos, petición, aprobación y resultado. Debe distinguir hechos comprobados, inferencias y huecos. También debe poder explicar quién custodia cada evidencia y cómo se obtuvo.

El ejercicio incluye suspender la capacidad de envío, comprobar la revocación, preservar una copia mínima de la evidencia y verificar que no se recogieron secretos innecesarios. La entrega es una cronología y una lista de lagunas, no una narración convincente producida por el agente.

Antes de empezar, el despacho debe fijar criterios de aceptación: poder identificar la operación, recuperar la aprobación cuando corresponda, contrastar el destino y explicar cada tramo de la cadena. Si falla una pieza crítica, se corrige el diseño o se limita el despliegue. No se rebaja el criterio para declarar éxito.

Diez preguntas para llevar a la reunión

1. ¿Qué identificador conecta usuario, agente y ejecución entre todos los componentes?
2. ¿Podemos recuperar el encargo y la configuración vigentes cuando ocurrió la acción?
3. ¿Qué evidencia identifica los documentos y versiones realmente consultados?
4. ¿Qué permisos tenía el agente y quién autorizó su concesión?
5. ¿Se registran herramientas, destinos, respuestas, reintentos y bloqueos?
6. ¿La aprobación humana identifica la acción exacta o solo una tarea genérica?
7. ¿Cómo se verifica el efecto externo, más allá del mensaje de éxito?
8. ¿Quién conserva y exporta cada registro, durante cuánto tiempo y en qué formato?
9. ¿Cómo se excluyen secretos y se preserva evidencia selectiva tras un incidente?
10. ¿Quién puede detener el sistema y qué prueba exige para reactivarlo?

No hace falta prometer una reconstrucción perfecta. Hace falta saber qué puede demostrarse, qué no y quién debe responder a cada hueco. Antes de dar a un agente capacidad de actuar, el despacho debería exigir algo más que una conversación legible: una cadena verificable, proporcionada y utilizable cuando las cosas salgan mal.