Para demostrar qué leyó un agente de IA antes de actuar, registre cada lectura como un evento propio y vincule cada dato de la decisión con uno de esos eventos. Un evento de lectura indica el sistema de origen, la herramienta o la recuperación que lo produjo, un resumen criptográfico (digest) de la solicitud y otro del resultado, la versión del registro de origen, la hora y el perímetro de datos. Después, un mapa de procedencia por campo indica, para cada valor que usó el agente, si procede del resultado de una herramienta, de un documento o del modelo. Con ambos, un auditor puede tomar una decisión y remontar cada entrada a un registro de origen que existía en ese momento.
Este artículo trata los cuatro tipos de lectura que hace un agente, la forma del registro para cada uno, un ejemplo sintético de KYC, la elección entre conservar el contenido o conservar un resumen criptográfico, y lo que KLA registra hoy. La guía de trazas de auditoría de agentes de IA cubre el registro completo de la ejecución. La reproducción determinista depende de estos mismos registros de lectura.
Por qué los auditores preguntan de dónde procede la información
Un agente que revisa el expediente de un cliente, redacta un memorando de crédito o cierra una alerta actúa a partir de lo que leyó. Cuando se cuestiona el resultado, las primeras preguntas se refieren a las entradas: qué registros vio el agente, si estaban actualizados, si tenía permiso para leerlos y qué datos de su respuesta inventó.
La normativa de protección de datos plantea una variante de la misma pregunta. Según el artículo 15, apartado 1, letra g), del RGPD, el interesado que ejerce su derecho de acceso tiene derecho, cuando los datos personales no se hayan obtenido de él, a "cualquier información disponible sobre su origen". El artículo 14, apartado 2, letra f), obliga al responsable del tratamiento a informar al interesado de "la fuente de la que proceden los datos personales". Un agente que extrae datos de clientes de varios sistemas dificulta esas respuestas, salvo que cada lectura quede registrada.
El Reglamento de IA de la UE menciona expresamente las entradas en los registros para una categoría. Para los sistemas de identificación biométrica remota del anexo III, punto 1, letra a), el artículo 12, apartado 3, exige registrar "la base de datos de referencia con la que el sistema ha cotejado los datos de entrada" y "los datos de entrada con los que la búsqueda ha arrojado una correspondencia". Para los demás sistemas de IA de alto riesgo, el artículo 12, apartados 1 y 2, exige un registro automático que facilite la trazabilidad, la detección de riesgos y el seguimiento poscomercialización, y deja los campos en manos del proveedor. Los registros de lectura son una forma de lograr esa trazabilidad en un agente.
Qué muestra una traza por defecto sobre las lecturas
Muchos equipos parten de sus datos de trazas. Las convenciones semánticas de OpenTelemetry para IA generativa, que tienen estado Development, definen un span de recuperación con gen_ai.data_source.id y gen_ai.retrieval.top_k, y un span de ejecución de herramienta con gen_ai.tool.name y gen_ai.tool.call.id.
Los atributos de contenido son Opt-In: gen_ai.retrieval.query.text, gen_ai.retrieval.documents, gen_ai.tool.call.arguments, gen_ai.tool.call.result y la entrada del modelo en gen_ai.input.messages. Una traza con la configuración por defecto puede mostrar que hubo una recuperación o una llamada a herramienta y cuánto duró, sin constancia de qué se pidió ni de qué se devolvió. Cuando la captura de contenido está activada, la traza guarda valores en bruto en un almacén dimensionado y conservado normalmente para depuración, sin versión de la fuente ni protección de integridad.
Las trazas siguen siendo útiles para el registro de lectura. Los campos trace_id y span_id unen un evento de lectura con el span que midió su duración.
Cuatro tipos de lectura y lo que necesita cada uno
Los agentes leen de cuatro maneras. Cada una necesita un registro algo distinto y cada una tiene una carencia habitual que rompe la traza de auditoría.
| Tipo de lectura | Ejemplo | Registro mínimo | Carencia habitual |
|---|---|---|---|
| Lectura de un sistema estructurado | Consulta de cliente en el CRM, saldo en el sistema central bancario, consulta SQL mediante un conector | ID y versión de la herramienta, resumen criptográfico de los argumentos, referencias de registro, resumen criptográfico del resultado, versión del registro de origen o fecha de referencia | Solo se registra el nombre de la herramienta; el resultado se descarta tras el paso |
| Lectura de un documento | Escaneo de pasaporte, extracto bancario, mandato firmado | ID del documento, suma de comprobación SHA-256, versión del objeto almacenado, hora de recepción, página y zona de cada valor citado | El archivo se sustituye con el mismo nombre, así que la suma de comprobación ya no se puede resolver |
| Recuperación | Pasajes del manual de políticas obtenidos de un índice vectorial | ID del índice y versión de compilación, resumen criptográfico de la consulta, ID de los fragmentos devueltos, puntuaciones y resúmenes criptográficos del contenido de los fragmentos, top_k | El índice se reconstruye y los ID de fragmento antiguos dejan de existir |
| Modelo o memoria | Un valor que el modelo escribió sin citar fuente; un dato recordado de la memoria del agente | Una etiqueta de fuente explícita model o memory; para la memoria, el ID del elemento y cuándo se escribió | Los valores sin fuente se guardan junto a los que la tienen, sin nada que los distinga |
Un registro de lectura y un mapa de procedencia por campo
El registro de lectura siguiente es sintético y neutral respecto al proveedor. Describe una consulta al CRM durante una revisión periódica de KYC. Los resúmenes criptográficos aparecen abreviados.
{
"read_id": "read_syn_0193_02",
"execution_id": "run_syn_0193",
"tool_call_id": "call_syn_0193_02",
"occurred_at": "2026-10-09T08:12:03.418Z",
"source": {
"system": "crm-eu",
"kind": "api",
"tool_id": "crm.customer.get",
"tool_version": "2026-09-30"
},
"request": {
"arguments_digest": "sha256:3b9e…41d0",
"record_refs": ["cust_syn_55120"]
},
"response": {
"result_digest": "sha256:c07a…9e12",
"source_record_version": "v41",
"as_of": "2026-10-09T08:12:03.390Z"
},
"boundary": {
"data_boundary_ref": "boundary_eu_kyc",
"purpose": "kyc-periodic-review"
},
"retention": {
"content_stored": "digest_only",
"content_location": "crm-eu record history"
}
}Vincule cada dato con su fuente
Los registros de lectura muestran lo que el agente pudo usar. El mapa de procedencia por campo muestra lo que usó. Adjúntelo al registro de la decisión para que cada campo de salida apunte a una sola fuente.
"field_provenance": {
"residence_country": {
"source": "tool",
"tool_call_id": "call_syn_0193_02",
"path": "$.address.country"
},
"id_document_expiry": {
"source": "document",
"document_id": "doc_syn_771",
"checksum_sha256": "8f14…a3c2",
"page": 1
},
"source_of_funds_summary": {
"source": "model"
}
}- Fuente de herramienta: el valor se lee de una ruta en un resultado de herramienta registrado. El revisor vuelve a calcular el resumen criptográfico del resultado y comprueba el valor en esa ruta.
- Fuente de documento: el valor cita un documento que el agente recibió en ese paso, por ID y suma de comprobación, con una página y, cuando existe, una zona de la página.
- Fuente del modelo: el valor no tiene fuente externa. Etiquételo para que el revisor lo trate como una afirmación del propio agente y lo compruebe como tal.
Ejemplo práctico: una revisión periódica de KYC sintética
Un banco ficticio de la UE utiliza un agente de actualización de KYC. El agente lee el perfil del cliente, el documento de identidad más reciente y el resumen de transacciones, y propone una calificación de riesgo que debe aprobar un analista de KYC. Todos los identificadores y valores siguientes son inventados.
| Entrada de la decisión | Valor usado | Fuente | Evidencia de procedencia | Comprobación del auditor y resultado |
|---|---|---|---|---|
| País de residencia | FR | Herramienta: crm.customer.get | call_syn_0193_02, resumen criptográfico del resultado, versión de registro v41 | El historial del CRM muestra que v41 era la vigente a las 08:12:03Z; el valor coincide. Conforme |
| Caducidad del documento de identidad | 2031-04-30 | Documento: doc_syn_771 | Suma de comprobación, página 1, zona localizada mediante la capa de texto | La versión del objeto almacenado coincide con la suma de comprobación; la fecha impresa coincide. Conforme |
| Depósitos en efectivo, últimos 90 días | 18.400 EUR | Herramienta: txn.summary.get | call_syn_0193_03, resumen criptográfico del resultado | Una nueva consulta al libro mayor del sistema central para el mismo periodo da 18.400 EUR. Conforme |
| Ocupación | Autónomo | Herramienta: crm.customer.get | call_syn_0193_02, versión de registro v41 | El CRM cambió a "Asalariado" en v43 dos días después. El agente usó el valor vigente en ese momento. Conforme, con una nota para el analista |
| Resumen del origen de los fondos | Párrafo narrativo | Modelo | source: model | Sin fuente. El registro de aprobación del analista debe mostrar que este párrafo se revisó como texto escrito por el agente. Excepción: la pantalla de aprobación no lo etiquetaba |
Conservar el contenido o conservar un resumen criptográfico
Un resumen criptográfico ocupa poco, puede guardarse con seguridad en un registro sellado y basta para demostrar una coincidencia. Por sí solo no demuestra nada: el auditor necesita los bytes originales para volver a calcularlo. Decida para cada fuente dónde estarán esos bytes durante el periodo de conservación.
- Resumen criptográfico más versión de la fuente: úselo cuando el sistema de origen conserve el historial de registros al menos durante el tiempo en que deba comprobarse la evidencia. Registre la versión o la fecha de referencia para poder resolver la lectura más adelante.
- Resumen criptográfico más copia en el almacén de evidencia: úselo cuando la fuente sea modificable, tenga un plazo de conservación inferior al de la evidencia o esté en manos de un tercero.
- Captura por campo: guarde solo los valores que usó la decisión, con sus rutas. Así, los datos personales del registro de evidencia se limitan a lo que necesita la decisión.
- Anonimización parcial y acceso: aplique al contenido de lectura almacenado la misma clasificación y la misma política de acceso que a la fuente. Registre el perfil de enmascaramiento junto con la lectura.
Qué registra KLA hoy sobre las lecturas
KLA registra las lecturas cuando pasan por una vía gobernada. Los puntos siguientes describen el comportamiento actual y sus límites.
Llamadas a herramientas gobernadas. Cuando un agente llama a una herramienta a través del entorno de ejecución de KLA, los recibos firmados de la llamada incluyen un resumen SHA-256 de los argumentos de la herramienta y del resultado liberado. Los recibos se escriben en el registro de evidencia de solo anexado de cada tenant y se recogen en el Sealed Evidence Bundle. El registro contiene el resumen criptográfico; el contenido leído permanece en el sistema de origen y en el almacenamiento del entorno de ejecución.
Procedencia por campo en los Process. Un Process puede declarar una fuente para cada campo que produce. Para una fuente de herramienta, KLA captura el valor en una ruta del resultado liberado y escribe ese valor. Para una fuente de documento, el agente cita un documento de la etapa, y la puerta de transición contrasta la cita con los documentos que la etapa recibió realmente con contenido. Una fuente declarada sin evidencia bloquea la transición con missing_field_provenance. La decisión de la puerta registra el mapa solo como referencias: {source: "tool", toolKey, callId}, {source: "document", documentId, documentType, checksumSha256, page, region} o {source: "model"}.
Document Intake. Cada documento de origen lleva checksum_sha256, object_version_id y received_at. La extracción registra un hash del texto de origen por campo, el modelo extractor y la versión del contrato de campos, y los eventos de recepción son de solo anexado. Cuando el worker localiza un valor citado, el registro conserva la página, las coordenadas del recuadro y el método (text_layer o vision), nunca el texto.
Límites. KLA no captura hoy los fragmentos de recuperación vectorial ni la ventana de contexto completa del modelo. Una recuperación que un agente ejecuta dentro de su propio código, fuera de una llamada a herramienta gobernada, no deja registro de lectura en KLA; para registrarla, hágala pasar por una herramienta gobernada. Los Data Boundaries se registran para la ejecución en su conjunto, sin versión del perímetro por lectura.
Lo que aprendimos al crear campos con fuente documental
Creamos campos con fuente documental para una prueba de concepto de alta de comercios en septiembre de 2026. Un campo como el número de registro mercantil debía citar el documento de alta del que procedía, y la puerta del Process rechazaba la transición cuando faltaba la cita.
Nuestra revisión de la primera implementación detectó que las citas se contrastaban con todos los documentos de la ejecución. Un agente podía citar un documento que no se le había mostrado en ese paso y la comprobación lo aceptaba. Cambiamos la comprobación para usar los documentos que la etapa recibió realmente con contenido. La misma revisión detectó que los valores capturados de resultados de herramientas se perdían cuando una ejecución se pausaba a la espera de una respuesta por correo electrónico; lo corregimos para que las capturas se mantengan durante la espera.
Dejamos por escrito un límite y lo mantuvimos. Una cita demuestra que al paso se le mostró el documento citado. Si el valor aparece en ese documento es otra cuestión. Para que esa segunda comprobación sea rápida, a finales de septiembre añadimos zonas de cita: el worker localiza el valor citado en la página y la página del caso lo recuadra para el revisor.
Localizar texto con un modelo planteó su propio problema. Un modelo al que se le pregunta si su propio recuadro es correcto tiende a darse la razón. Usamos una comprobación ciega: una segunda llamada transcribe el recuadro recortado sin ver el texto esperado, y el recuadro solo se conserva si la transcripción coincide. Las zonas son una ayuda de lectura construida a partir de contenido de página no fiable, así que nunca deciden una transición.
Procedimiento de auditoría de la procedencia de las lecturas
Aplique estos pasos a una muestra de decisiones basada en el riesgo. El papel de trabajo de auditoría de agentes de IA muestra el mismo método para la autoridad, la aprobación y el resultado.
- Enumere las entradas: para cada decisión de la muestra, enumere todos los datos que usó el agente a partir de su respuesta y del registro de la decisión.
- Resuelva la fuente: asocie cada dato con un evento de lectura, un documento o una etiqueta
model. Un dato sin entrada es una excepción. - Vuelva a calcular los resúmenes criptográficos: obtenga el contenido de origen en la versión registrada y vuelva a calcular el resumen del resultado o la suma de comprobación.
- Compruebe la secuencia temporal: confirme que cada lectura precede a la decisión y que la versión de la fuente era la vigente en el momento de la lectura.
- Compruebe la autorización: compare cada fuente y cada registro con el perímetro de datos y la finalidad vigentes para la ejecución.
- Compruebe el etiquetado: confirme que los datos procedentes del modelo se mostraron al revisor humano como escritos por el agente.
Preguntas frecuentes
¿Cómo puedo auditar de dónde obtuvo un agente de IA la información sobre un cliente?
Tome una decisión, enumere todos los datos del cliente que usó y remonte cada uno a una lectura registrada: la llamada a herramienta o el documento, la versión del registro de origen y un resumen criptográfico del resultado. Vuelva a calcular el resumen a partir de la fuente en esa versión. Cualquier dato sin registro de lectura, o etiquetado como escrito por el modelo, es una excepción o un valor que el revisor debe comprobar como afirmación del propio agente.
¿Cómo audito qué contenido usó un agente de IA para tomar una decisión?
Separe lo que el agente leyó de lo que usó. Los eventos de lectura muestran cada recuperación y cada resultado de herramienta; un mapa de procedencia por campo en el registro de la decisión vincula cada valor de salida con uno de ellos. Tome una muestra de decisiones, vuelva a calcular los resúmenes criptográficos y confirme que el contenido estaba dentro del perímetro de datos aprobado.
¿Muestra una traza de LLM lo que leyó un agente de IA?
Solo si la captura de contenido está activada. En las convenciones GenAI de OpenTelemetry, los documentos recuperados, los argumentos y resultados de herramientas y los mensajes de entrada del modelo son atributos Opt-In. Una traza por defecto muestra que hubo una lectura, sin constancia del contenido, de la versión de la fuente ni de su integridad.
¿Debe un registro de auditoría guardar el contenido que leyó un agente o solo un hash?
Guarde un resumen criptográfico en el registro sellado y conserve el contenido donde pueda aportarse durante todo el periodo de conservación: en el sistema de origen con una referencia de versión, o en el almacén de evidencia cuando la fuente sea modificable. Un resumen criptográfico sin contenido recuperable no se puede comprobar.
Conclusiones clave
La procedencia de una decisión de un agente se reduce a dos registros: un evento por lectura y un mapa que vincula cada dato de la decisión con una lectura, un documento o el modelo. Mantenga el contenido recuperable durante todo el tiempo en que deba comprobarse el registro y haga pasar la recuperación por llamadas gobernadas para que quede registrada. Para el formato del registro, empiece por el esquema del registro de auditoría de agentes de IA y el registro de ejecución de agentes de IA. Para ver cómo une KLA las lecturas con las decisiones y sus efectos, consulte Execution Lineage.