La observabilidad LLM y la pista de auditoría de un agente de IA pueden compartir un identificador de traza y aun así responder a preguntas distintas. Una traza de observabilidad registra cómo se ejecutó una llamada al modelo o un paso del agente: la operación, el modelo, los tokens, la latencia, los errores y, si la captura de contenido está activada, los mensajes. Una pista de auditoría registra por qué se permitió una acción, quién tenía autoridad sobre ella, qué versión de la política la decidió, qué cambió la herramienta y cómo puede verificarse el registro más adelante. Para un sistema de alto riesgo del Reglamento de IA de la UE, la pista de auditoría aporta la trazabilidad que pide el artículo 12, y la traza ayuda a los ingenieros a operar el sistema.
Esta guía compara ambos registros campo por campo, registra una acción sintética de las dos maneras, resume lo que el Reglamento de IA exige a los registros y enumera lo que hay que añadir a una plataforma de observabilidad. El marco de auditoría empresarial de agentes de IA sitúa el registro dentro del método de auditoría completo, y su papel de trabajo de auditoría completado prueba una acción desde el permiso hasta el resultado.
Qué registra la observabilidad LLM
Muchas herramientas de observabilidad LLM emiten o reciben datos de OpenTelemetry. Las convenciones semánticas de OpenTelemetry para IA generativa definen spans para inferencia, embeddings, recuperación, memoria y ejecución de herramientas, con atributos como gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.usage.input_tokens y gen_ai.tool.name. Las convenciones tienen estado Development, por lo que los nombres aún pueden cambiar.
En esas convenciones, el contenido es Opt-In. La entrada y la salida del modelo (gen_ai.input.messages, gen_ai.output.messages), los argumentos y resultados de las herramientas (gen_ai.tool.call.arguments, gen_ai.tool.call.result) y los documentos recuperados (gen_ai.retrieval.documents) solo se registran si alguien los activa. Una traza con la configuración por defecto puede mostrar que una herramienta se ejecutó y cuánto tardó, sin constancia de lo que se le pidió ni de lo que devolvió.
Estos datos sirven bien a ingeniería: encontrar un paso fallido, una recuperación lenta o un prompt costoso, y comparar versiones de prompts. Ese uso explica también las decisiones habituales de almacenamiento: muestreo para controlar el volumen, conservación fijada por el coste y almacenes que los operadores pueden editar o purgar.
Nos encontramos con esta diferencia en nuestro propio producto. En una prueba de concepto de alta de comercios en septiembre, el historial del caso enlazaba cada paso con Lineage Explorer, y los enlaces mostraban "Trace not found" para una ejecución detenida en una firma. La ejecución publicaba sus spans de traza solo al terminar, mientras que el recibo de la decisión pendiente ya existía. Cambiamos Lineage Explorer para que lea del registro de ejecución los pasos ya registrados cuando no hay traza publicada, y para que indique que la ejecución no ha terminado.
Qué añade una pista de auditoría
Un auditor, un supervisor o un equipo jurídico que revisa una acción del agente formula preguntas para las que la traza no fue diseñada. La tabla relaciona cada pregunta con un campo habitual de observabilidad y con el campo que la responde en el esquema de registro de auditoría de agentes de IA, neutral respecto al proveedor.
| Pregunta del auditor | Campo habitual de observabilidad | Campo de la pista de auditoría (audit event v1) | Carencia de la traza |
|---|---|---|---|
| ¿Para quién actuó el agente y quién responde del resultado? | gen_ai.agent.name, gen_ai.conversation.id, nombre del servicio | actors.requester, actors.delegated_user, actors.service_identity, actors.accountable_owner | La traza nombra el proceso del agente y rara vez a la persona que delegó o al responsable |
| ¿Qué versión se ejecutó? | gen_ai.request.model, gen_ai.response.model | components.agent.version, components.model.version, components.prompt_template.version, cada uno con configuration_digest | El nombre del modelo no identifica una versión aprobada del agente, del prompt y del orquestador |
| ¿Qué política decidió y se evaluó antes de la acción? | No hay span GenAI para decisiones de política | policy.policy_id, policy.policy_version, policy.policy_digest, policy.inputs_digest, policy.decision, policy.matched_rule_ids, policy.evaluated_at | Las comprobaciones de política aparecen, si acaso, como spans personalizados sin significado fijo |
| ¿Aprobó una persona con autoridad? | No hay span GenAI para aprobaciones | approval.required_role, approval.reviewer, approval.decision, approval.decided_at, approval.presented_evidence_digest | La traza no puede mostrar qué vio el revisor ni si tenía el rol |
| ¿Qué cambió la herramienta? | gen_ai.tool.name, gen_ai.tool.call.id; argumentos y resultado si se activan | tool_calls[].arguments_digest, result_digest, idempotency_key, downstream_effects[].before_state_digest, after_state_digest | No hay vínculo entre la llamada y el cambio de estado en el sistema de registro |
| ¿Está cada acción en la población? | Trazas muestreadas | sequence, lineage.ordered_event_ids, conciliación con el sistema de origen | El muestreo descarta registros por diseño |
| ¿Ha cambiado el registro desde que se escribió? | Ninguno | integrity.record_hash, integrity.previous_event_hash, integrity.signature | Los almacenes de trazas suelen ser editables y caducan según un calendario de almacenamiento |
Una acción sintética registrada de las dos maneras
El agente de crédito de un banco ficticio registra una disposición de crédito de 24.000 EUR. La traza de observabilidad del paso de herramienta tiene este aspecto. Los valores son sintéticos.
{
"name": "execute_tool set_disposition",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7",
"start_time": "2026-07-21T09:14:31.944Z",
"end_time": "2026-07-21T09:14:32.433Z",
"attributes": {
"gen_ai.operation.name": "execute_tool",
"gen_ai.tool.name": "set_disposition",
"gen_ai.tool.call.id": "call_01JZ8V4R1E7P3M9C5Q2T6N8D0A",
"gen_ai.agent.name": "Credit review agent"
},
"status": "OK"
}El evento de auditoría de la misma acción
El evento de auditoría de la misma llamada es el registro de ejecución completo sintético y público. Lleva el mismo trace_id y el mismo span_id, de modo que ambos registros se unen. Añade lo que falta en el span: el usuario que delegó y el responsable, la política credit-disposition-policy 4.2.1 con resultado require_approval por la regla manual-review-above-20000, la aprobación del analista sénior a las 09:14:31.902Z antes de la llamada de las 09:14:31.944Z, los digests de argumentos y resultado, los digests del estado anterior y posterior en core banking, el resultado de negocio y un hash del registro con firma Ed25519.
Un auditor puede verificar la firma, comprobar que la aprobación precedió a la llamada, volver a ejecutar la política sobre las entradas registradas y seguir la referencia del efecto hasta core banking. Con el span solo puede confirmar que una herramienta llamada set_disposition terminó sin error.
Qué exige el Reglamento de IA a los registros
El artículo 12, apartado 1, del Reglamento de IA de la UE exige que los sistemas de alto riesgo permitan técnicamente el registro automático de eventos durante toda su vida útil. El artículo 12, apartado 2, vincula ese registro a la detección de situaciones que puedan generar un riesgo o una modificación sustancial, a la vigilancia poscomercialización y a la supervisión del funcionamiento por el responsable del despliegue. El artículo 12, apartado 3, fija campos mínimos solo para los sistemas de identificación biométrica remota.
El artículo 19, apartado 1, obliga a los proveedores a conservar los registros generados automáticamente que estén bajo su control durante al menos seis meses, salvo que el Derecho de la Unión o nacional disponga otra cosa. El artículo 26, apartado 6, fija el mismo mínimo para los responsables del despliegue. Las medidas correctoras están en el artículo 20 y la gestión de la calidad, incluidos los procedimientos de conservación de registros, en el artículo 17.
Para la mayoría de los sistemas de alto riesgo, el Reglamento deja la lista de campos al proveedor. Para un agente, la trazabilidad de una decisión suele significar los campos de actor, versión, política, aprobación, efecto de la herramienta y resultado de la tabla anterior. El Reglamento (UE) 2026/1744, publicado el 24 de julio de 2026, trasladó la fecha de aplicación al 2 de diciembre de 2027 para los sistemas de alto riesgo del artículo 6, apartado 2, y del anexo III, y al 2 de agosto de 2028 para los del artículo 6, apartado 1, y del anexo I. La guía sobre el artículo 12 desarrolla la obligación.
Las cuatro capas de un paquete de evidencia
Un paquete de evidencia reúne la pista de auditoría de una decisión o de un periodo para que un revisor pueda comprobarla fuera del sistema que la produjo. La muestra del Evidence Room enseña una exportación.
- Registro de la decisión: identificador, hora, tipo de decisión, resultado y clasificación de riesgo. Todos los demás artefactos remiten a él.
- Contexto de entrada: lo que leyó el agente, con referencias y versiones de las fuentes; las versiones de modelo, prompt y política vigentes. La guía en inglés sobre cómo demostrar qué leyó un agente de IA describe el registro de lectura.
- Evidencia de gobernanza: decisiones de política con las reglas aplicadas, Decision Requests con revisor y justificación, escalados y anulaciones.
- Integridad: un manifiesto de artefactos con digests SHA-256, firmas, anclajes de sellado de tiempo y cadena de custodia, para que un revisor pueda verificar el paquete sin conexión.
Patrones de arquitectura para registros de calidad de auditoría
Estos patrones se aplican en el camino de la acción. Requieren que el agente llame a las herramientas a través de un punto de control que pueda evaluar la política y registrar el resultado.
Un campo que falta cuando se sella un registro no puede añadirse después. A comienzos de septiembre de 2026, una revisión del código de nuestra propia plataforma mostró que algunos registros de decisión y recibos sellados no identificaban al agente que actuaba. Los recibos sellados no pueden completarse a posteriori, así que cada día sin ese campo añadía registros que un auditor no podía vincular a un agente. Añadimos la identidad del agente a los registros de decisión y a los recibos sellados en dos días. Fije la lista de campos antes del primer registro de producción.
- Escribir en el momento de la decisión: registre la decisión de política antes de que la acción continúe y la aprobación antes de la llamada a la herramienta. Un registro reconstruido después a partir de logs no puede demostrar el orden con fiabilidad.
- Almacenamiento de solo anexión: guarde los eventos donde las entradas existentes no puedan editarse ni borrarse, y encadene cada registro con el anterior mediante un hash.
- Firmar y sellar: firme cada registro y selle las exportaciones con un manifiesto y una firma que un revisor pueda comprobar con claves publicadas.
- Mantener el contenido recuperable: un digest solo demuestra una coincidencia si el contenido puede presentarse después. Conserve la versión de la fuente o una copia protegida durante el periodo de conservación.
- Registrar lo que necesita la reproducción: entradas de la decisión, versión de política fijada y salida del modelo registrada. La guía en inglés sobre reproducción determinista de decisiones de agentes de IA enumera el conjunto completo y sus límites.
- Unir con la telemetría: incluya
trace_idyspan_iden el evento de auditoría para que ingenieros y auditores puedan pasar de un registro al otro.
Construir la capa de evidencia sobre la observabilidad existente
Los equipos que ya tienen trazas pueden añadir la capa de evidencia por fases.
- Fase 1, definir las preguntas: enumere los tipos de decisión con exposición jurídica o de auditoría y las preguntas que hará un auditor sobre cada uno.
- Fase 2, situar los puntos de control: dirija las llamadas a herramientas relevantes a través de un punto de control de políticas que registre actor, versión, política, aprobación y efecto.
- Fase 3, proteger la integridad: traslade los eventos de auditoría a un almacenamiento de solo anexión con hashes, firmas y exportaciones selladas.
- Fase 4, probar el registro: muestree acciones, verifique firmas, concilie la población y reproduzca decisiones. La lista de verificación de auditoría de agentes de IA y el papel de trabajo de auditoría aportan las pruebas.
Preguntas frecuentes
¿Pueden las herramientas de observabilidad LLM servir como pista de auditoría del Reglamento de IA?
Las trazas de observabilidad cubren una parte. En las convenciones GenAI de OpenTelemetry el contenido es Opt-In y no hay spans para decisiones de política ni para aprobaciones. Una pista de auditoría de un agente para el Reglamento de IA necesita además a la persona que delegó, la versión y el resultado de la política, la aprobación, el efecto de la herramienta en el sistema de registro, la integridad de la población y la evidencia de manipulación. Una la traza con un evento de auditoría que contenga esos campos.
¿Cómo creo pistas de auditoría para las acciones de agentes de IA?
Asigne un identificador de ejecución y registre las identidades del agente y de las personas, las versiones, lo que leyó el agente, las llamadas a herramientas y sus resultados, las decisiones de política, las aprobaciones, las salidas, los efectos secundarios y las marcas de tiempo. Escriba los registros en el momento de la decisión en un almacenamiento de solo anexión y selle las exportaciones con un manifiesto y firmas.
¿Cómo audito y reproduzco las decisiones de agentes de IA?
Seleccione una ejecución de una población conciliada, verifique su integridad, resuelva la versión de política registrada y vuelva a ejecutar la política sobre las entradas registradas sin acceso a herramientas. Compare el resultado y las reglas aplicadas con el registro. Pruebe por separado el efecto externo de la herramienta en el sistema posterior, porque una decisión reproducida no lo demuestra.
¿Qué es un paquete de evidencia?
Un paquete de evidencia reúne el registro de la decisión, el contexto de entrada, la evidencia de gobernanza y el material de integridad de una decisión o un periodo, para que un revisor pueda verificarlo fuera del sistema que lo produjo.
¿Qué artículos del Reglamento de IA regulan los registros?
El artículo 12 exige el registro automático de eventos en los sistemas de alto riesgo. El artículo 19, apartado 1, y el artículo 26, apartado 6, obligan a proveedores y responsables del despliegue a conservar los registros bajo su control durante al menos seis meses, salvo que otra norma disponga otra cosa. El artículo 17 regula la gestión de la calidad, incluida la conservación de registros.
¿Qué es el almacenamiento de solo anexión y por qué importa?
El almacenamiento de solo anexión acepta registros nuevos y rechaza la edición y el borrado de los existentes. Con encadenamiento de hashes y firmas, permite a un revisor detectar cualquier cambio en la pista después de escribirla.
Conclusiones clave
Mantenga la observabilidad para operar el sistema y añada un evento de auditoría en el camino de la acción para demostrar cómo se gobernó cada decisión. Una ambos registros por el identificador de traza. Registre lo que leyó el agente, la versión de la política, la aprobación, el efecto y una prueba de integridad para cada acción relevante. Use la lista de verificación de auditoría de agentes de IA para probar esos registros, la evaluación de preparación para encontrar carencias y Execution Lineage para ver cómo KLA une los registros de una ejecución.