El artículo 12 del Reglamento de IA de la UE exige que los sistemas de IA de alto riesgo admitan el registro automático de eventos durante toda la vida útil del sistema. Los registros deben hacer que el sistema sea trazable al nivel adecuado para su finalidad prevista y respaldar la detección de riesgos, la supervisión posterior a la comercialización y la supervisión del responsable del despliegue. El artículo 19 asigna después a los proveedores la obligación de conservar los registros generados automáticamente que estén bajo su control. Para un agente de IA, una implementación defendible conecta la ejecución, el agente y la Release, las decisiones de política, las llamadas a herramientas, las decisiones humanas, los resultados y la evidencia de integridad. Esta guía separa el texto legal de la especificación técnica utilizada para producir registros revisables. Ofrece orientación práctica y no constituye asesoramiento jurídico.
Qué exigen los artículos 12 y 19
El artículo 12 se encuentra en el capítulo III, sección 2, que establece los requisitos para los sistemas de IA de alto riesgo. Su alcance depende de la clasificación del sistema y de su finalidad prevista. Un agente de atención al cliente o un asistente interno no queda sujeto al artículo 12 únicamente porque utilice un modelo de IA o pueda llamar a herramientas. Empiece por la base de requisitos del Reglamento de IA de la UE y documente la decisión de clasificación.
El Reglamento (UE) 2026/1744 modificó las fechas de aplicación de estas disposiciones de alto riesgo. Las secciones 1 a 3 del capítulo III se aplican desde el 2 de diciembre de 2027 a los sistemas clasificados conforme al artículo 6(2) y al anexo III, y desde el 2 de agosto de 2028 a los sistemas de productos clasificados conforme al artículo 6(1) y al anexo I. Las fechas posteriores dan tiempo para la implementación. Mantienen intacto el diseño de control de los artículos 12 y 19.
| Fuente | Requisito del reglamento | Especificación operativa | Prueba de evidencia |
|---|---|---|---|
| Artículo 12(1) | El sistema de IA de alto riesgo admite técnicamente el registro automático de eventos durante toda su vida útil. | Emitir registros desde el flujo de ejecución para cada ejecución gobernada y cada acción con consecuencias. Evitar un diseño que dependa de que una persona reconstruya el registro después del evento. | Ejecutar un Process representativo y conciliar la población de ejecuciones con los registros creados automáticamente. |
| Artículo 12(2)(a) | Los registros capturan eventos relevantes para identificar un riesgo conforme al artículo 79(1) o una modificación sustancial. | Registrar fallos, bloqueos y advertencias de política, accesos anómalos a herramientas, anulaciones, cambios de Release, resultados inesperados y sus efectos con identificadores estables. | Activar cada señal de riesgo definida y confirmar que el registro identifica la ejecución, versión, evento, hora y resultado afectados. |
| Artículo 12(2)(b) | Los registros facilitan el sistema de supervisión posterior a la comercialización del artículo 72. | Usar campos de evento que permitan consultar la población, analizar tendencias, correlacionar incidentes y enlazar con el plan de supervisión del proveedor. | Reproducir una métrica de supervisión desde los registros fuente y seguir una excepción hasta el plan de supervisión posterior a la comercialización. |
| Artículo 12(2)(c) | Los registros respaldan la supervisión del responsable del despliegue conforme al artículo 26(5). | Exponer el estado operativo, el contexto de las instrucciones de uso, la señal de riesgo, la referencia de notificación al proveedor, el evento de suspensión y la referencia del incidente grave cuando proceda. | Seguir un riesgo simulado desde su detección hasta la suspensión o resolución y verificar las referencias de notificación al proveedor y a la autoridad. |
| Artículo 12(3) | Para los sistemas de identificación biométrica remota del anexo III, punto 1(a), los registros incluyen cada periodo de uso, la base de datos de referencia, los datos de entrada coincidentes y las personas que verificaron los resultados conforme al artículo 14(5). | Crear campos específicos para el registro biométrico mínimo. Aplicar controles de acceso y normas de protección de datos a la información sensible. | Seleccionar un uso y verificar que las horas de inicio y fin, la referencia de la base de datos, la entrada coincidente y las identidades de los verificadores estén presentes y autorizadas. |
| Artículo 19(1) | Un proveedor conserva bajo su control los registros del artículo 12 durante un periodo apropiado a la finalidad prevista y de al menos seis meses, salvo que otra norma aplicable disponga lo contrario. | Asignar a cada registro controlado por el proveedor una clase de conservación, fuente, finalidad, periodo mínimo, comportamiento ante una retención legal, regla de acceso y ruta de eliminación verificada. | Inspeccionar la política de almacenamiento, demostrar que los registros cubiertos siguen disponibles durante los seis meses exigidos y probar después la retención legal y la eliminación autorizada al vencer el periodo configurado. |
| Artículo 26(6) | El responsable del despliegue aplica la misma regla mínima de seis meses a los registros generados automáticamente bajo su control, sujeto a las demás normas aplicables. | Definir la transferencia proveedor-responsable del despliegue: qué parte controla cada registro, cómo lo recopila e interpreta el responsable y cómo los contratos preservan el acceso. | Seguir un registro de producción desde su generación hasta el almacenamiento controlado por el responsable del despliegue y confirmar su recuperación, conservación y titularidad. |
Una especificación concreta de pista de auditoría para un agente de IA
El artículo 12 establece las finalidades del registro y proporciona una lista mínima concreta de campos para los sistemas de identificación biométrica remota del artículo 12(3). Para los demás sistemas de alto riesgo, el proveedor define un conjunto de campos que haga trazable el sistema para su finalidad prevista. La especificación siguiente es un punto de partida defendible para un agente que puede recuperar datos, tomar decisiones gobernadas por políticas, solicitar revisión humana y llamar a herramientas. El esquema de registro de auditoría para agentes de IA descargable convierte estas familias de eventos en un contrato versionado y neutral frente a proveedores, con registros completos, denegados y de fallo de integridad.
Capture referencias o hashes cuando una carga completa entre en conflicto con los requisitos de minimización de datos, confidencialidad o seguridad. Un registro útil conserva el significado del evento y una ruta controlada hacia la evidencia subyacente.
| Familia de eventos | Campos que se deben capturar | Finalidad del control | Prueba de aceptación |
|---|---|---|---|
| Identidad de ejecución | Tenant, identificadores de ejecución y correlación; identificador del agente; identificador, versión y hash de la Release; identificador y versión del Process; entorno; principal iniciador; sujeto en cuyo nombre se actúa; marcas de tiempo de inicio y fin | Definir el sistema, la versión, la autoridad y el periodo implicados en una ejecución. | Unir cada evento de una ejecución muestreada a un único registro de identidad sin depender solo de las marcas de tiempo. |
| Entrada y recuperación | Referencia de entrada o carga protegida; referencias de origen y registro; consulta o hash de recuperación; versión del modelo y de la plantilla de prompt; estado de redacción; hora del evento | Mostrar qué información entró en la ejecución y qué versión la interpretó. | Reconstruir el conjunto de entradas aprobado y demostrar que los campos protegidos siguen sujetos a controles de acceso. |
| Solicitud de herramienta | Nombre de herramienta; identificadores de llamada y gate; destino; argumentos o hash de argumentos; autoridad solicitada; clave de idempotencia; hora de solicitud | Identificar la acción con consecuencias propuesta por el agente antes de que ocurra un efecto externo. | Relacionar la solicitud con su resultado de política y demostrar que una entrega duplicada no puede crear un segundo efecto inexplicado. |
| Decisión de política | Identificador de decisión; tipo de gate; resultado allow, warn, require_approval o block; identificador, versión y hash del paquete de políticas; identificadores de reglas coincidentes; códigos de motivo; hora de decisión | Mostrar qué control gobernó la acción y la versión exacta evaluada. | Reevaluar una muestra fijada con los hechos registrados y explicar cualquier diferencia como cambio de versión. |
| Decisión humana | Identificador de Decision Request; rol requerido; identidad y autoridad del revisor; resultado de aprobar, rechazar o escalar; justificación; acuse de recibo; horas de solicitud y decisión | Conectar el juicio material con una persona responsable y con la acción retenida para revisión. | Demostrar que el revisor tenía autoridad en el momento de la decisión y que la solicitud de herramienta permaneció pausada hasta su resolución. |
| Resultado de herramienta y efecto empresarial | Estado; referencia o hash del resultado; error; decisión de política de salida; referencias al estado anterior y posterior; identificador de transacción posterior; hora de finalización | Distinguir una propuesta de una acción que llegó al sistema objetivo. | Conciliar el registro con el sistema posterior y explicar éxito, fallo, bloqueo, cancelación y reintento. |
| Señal de supervisión e incidente | Tipo de señal; gravedad; ejecución y Release afectadas; versión del umbral o detector; resolución; responsable; referencias de notificación e incidente | Respaldar la supervisión del artículo 72 y la respuesta operativa del artículo 26(5). | Reproducir la señal desde los registros fuente y seguirla hasta una resolución documentada. |
| Integridad y conservación | Hash del registro; hash del registro anterior cuando se use; firma e identificador de clave cuando se use; referencia del registro o manifiesto; clase de conservación; vencimiento; estado de retención; evento de eliminación | Detectar cambios posteriores y demostrar que el registro permaneció disponible durante el periodo aprobado. | Modificar un byte exportado y exigir que falle la verificación; probar por separado los controles de conservación, retención y eliminación. |
La conservación es un control del proveedor y del responsable del despliegue
El artículo 19(1) asigna a los proveedores el deber de conservar bajo su control los registros generados automáticamente del artículo 12. El artículo 26(6) establece el deber equivalente de los responsables del despliegue para los registros bajo su control. Ambos siguen la misma estructura: un periodo apropiado a la finalidad prevista, un mínimo de seis meses y una excepción cuando otra norma de la Unión o nacional aplicable establezca otra regla. Las entidades financieras conservan estos registros dentro de la documentación mantenida conforme a la legislación de la Unión aplicable a los servicios financieros.
El periodo de seis meses es un mínimo para los registros cubiertos por estas disposiciones. El artículo 18 exige por separado a los proveedores conservar durante diez años determinada documentación técnica y de conformidad. Son registros diferentes. Las normas de privacidad, empleo, sector, retención por litigio y derecho nacional pueden cambiar el periodo válido o los datos que pueden conservarse.
Elabore un registro de conservación antes de elegir una TTL de almacenamiento. Para cada clase de evidencia, documente su fuente jurídica o empresarial aprobada, finalidad, parte responsable, sistema de referencia, periodo mínimo y máximo, fecha de inicio, roles de acceso, regla de retención legal, método de eliminación y evidencia de prueba. La plantilla de política de conservación de registros de auditoría ofrece una estructura operativa.
- Asignar el control: nombre los registros controlados por el proveedor y por el responsable del despliegue, incluidas las copias creadas por un proveedor de observabilidad o un operador del runtime.
- Alinear las capas: el almacén de trazas, el registro de evidencia, el paquete exportado, el índice, la copia de seguridad y el ciclo de vida de las claves de cifrado necesitan periodos compatibles.
- Proteger el contenido: minimice los datos personales, separe las cargas sensibles de los metadatos ampliamente consultables y aplique acceso limitado a la finalidad.
- Probar la recuperación: un registro conservado es valioso cuando un revisor autorizado puede localizarlo, interpretarlo y exportarlo dentro del nivel de servicio exigido.
- Probar el vencimiento: demuestre que el sistema respeta una retención legal, registra la eliminación autorizada y elimina cada copia gobernada al terminar el periodo aprobado.
La trazabilidad con alteraciones detectables y la reconstrucción son controles de garantía
El artículo 12 menciona el registro automático y la trazabilidad. No prescribe ningún mecanismo criptográfico ni endpoint de reconstrucción. La trazabilidad con alteraciones detectables y la reconstrucción son controles de implementación que ayudan al proveedor a demostrar que el registro es suficientemente completo para utilizarse y que no ha cambiado.
Use reconstrucción para referirse a la reconstrucción del camino de control registrado. Volver a ejecutar un modelo o una herramienta externa puede producir un resultado diferente o repetir un efecto secundario. Una reconstrucción segura lee la secuencia, las versiones, los hechos de política, las decisiones humanas y las referencias de resultados almacenadas. Una simulación de política independiente puede reevaluar los hechos registrados con una versión fijada de la política sin enviar la acción.
| Prueba | Resultado esperado | Señal de fallo |
|---|---|---|
| Conciliación de población | Cada ejecución dentro del ámbito y cada acción con consecuencias tiene un registro, incluidos permisos ordinarios, bloqueos, fallos y cancelaciones. | El número de ejecuciones supera al de registros o hay registros sin ejecución de origen. |
| Orden causal | La decisión de política precede a la acción gobernada; una decisión humana requerida precede a la liberación; el resultado sigue a la ejecución. | Un efecto secundario no tiene un registro de control anterior o las marcas de tiempo no permiten establecer la secuencia. |
| Contexto fijado | El registro resuelve la Release del agente y del modelo, la versión del Process, la versión de política, las identidades y la autoridad activas en el momento del evento. | El revisor solo puede ver la configuración actual o debe deducir qué versión se ejecutó. |
| Conciliación del resultado | El resultado de la herramienta y el efecto empresarial coinciden con el origen posterior, incluido el comportamiento de reintentos e idempotencia. | La pista dice que terminó, pero el destino no tiene una transacción coincidente, o los efectos duplicados no tienen causas separadas. |
| Verificación de integridad | Los hashes, firmas, enlaces de cadena, pruebas de registro y comprobaciones de manifiesto se verifican cuando están configurados; una modificación controlada hace fallar la verificación. | Un artefacto editado sigue siendo válido o el verificador no identifica el archivo o registro afectado. |
| Reconstrucción segura | Un revisor puede leer la secuencia completa sin volver a ejecutar un efecto secundario con consecuencias. | La única ruta de reconstrucción envía la llamada original a la herramienta o depende de una respuesta de modelo no disponible. |
Cómo la evidencia del runtime de KLA corresponde a la especificación
KLA crea un Lineage Record para una ejecución gobernada y utiliza identificadores estables de ejecución y tenant para conectar los eventos del runtime. Los spans de ejecución pueden contener la versión y el hash del Process, los identificadores de Release del agente, el entorno, el principal iniciador, el sujeto en cuyo nombre se actúa y la identidad del cliente que llama registrada para la ejecución. Los spans de workflow registran resultados de nodos, resultados de política, identificadores y reglas de política, Decision Requests, identidades de revisores, marcas de tiempo y errores.
La pasarela de gobernanza de KLA evalúa los gates de entrada y salida de herramientas mediante el KLA Policy Engine cuando los operadores habilitan KLA_GOVERNANCE_GATEWAY para un entorno. La configuración de production del execution-worker versionada en el repositorio no habilita actualmente este camino. Cuando un gate está habilitado, su resultado usa los cuatro valores allow, warn, require_approval y block. Los recibos de decisión incluyen la ejecución, gate, herramienta, versión de política, hash del paquete de políticas, códigos de motivo, Decision Request, traza y hash de salida cuando corresponda. La pasarela sella el recibo del gate de entrada antes de ejecutar la herramienta gobernada y sella el recibo del gate de salida antes de devolver o retener el resultado. Un fallo al escribir evidencia impide que el gate avance.
| Necesidad de control | Componente de KLA | Evidencia producida | Límite que se debe verificar |
|---|---|---|---|
| Identidad estable de ejecución | Agents, Releases, Processes y Lineage Records | Identificadores de ejecución y tenant, versión y hash del Process, Release del agente, entorno, principal y correlación | Confirme que cada integración propaga los identificadores y que los campos opcionales de identidad están presentes para el Process revisado. |
| Secuencia automática de eventos | KLA Runtime y spans de ejecución de OpenTelemetry | Eventos de ejecución, nodo, política, aprobación, error, tiempo y resultado ordenados en un Lineage Record | Concilie la población de ejecuciones y confirme que las herramientas seleccionadas emiten las referencias de entrada, resultado y efecto posterior que exige la finalidad prevista. |
| Control de política y herramienta | Pasarela de gobernanza de KLA habilitada por entorno | Tipo de gate, versión de política, decisión, motivos, Decision Request, hash de argumentos, hash de salida y estado de idempotencia; identificadores de reglas coincidentes cuando la decisión require_approval evaluada los proporciona | Confirme que la pasarela está habilitada en el entorno revisado. Pruebe los cuatro resultados, la evidencia opcional de reglas coincidentes, el fallo del servicio de políticas, los argumentos cambiados tras la aprobación, los reintentos y la cancelación. |
| Decisión humana | Decision Desk y registros duraderos de aprobación | Rol requerido, identidad del revisor, decisión, justificación, marcas de tiempo, contexto de política y ejecución correlacionada | Pruebe la autoridad del revisor, las reglas de separación de funciones cuando estén configuradas y la secuencia completa de pausa a liberación. |
| Registro con alteraciones detectables | Registro de evidencia de solo anexado y recibos de gobernanza | Escrituras verificadas en el registro; firmas Ed25519 y enlaces de cadena de hashes cuando está habilitada la firma de recibos | Trate el estado de firma como un hecho observado del despliegue. Alerte ante degradación de firma y ejecute una prueba controlada de alteración. |
| Paquete portátil de revisión | Evidence Room y Sealed Evidence Bundles | Registros seleccionados de linaje, política, aprobación y registro con manifiesto, hashes, datos de inclusión Merkle y firmas para verificación sin conexión | Confirme la población exportada, el perfil de redacción, el resultado del verificador, la disponibilidad de claves y la cadena de custodia. |
| Conservación | Conservación de trabajos de Evidence Factory y configuración del almacenamiento de paquetes | Metadatos de conservación y vencimiento del trabajo de exportación y conservación configurada del almacenamiento de paquetes | Concilie estos controles de exportación con la conservación de los Lineage Records y registros de origen. Defina y pruebe el periodo exigido para el sistema clasificado y el sector. La capacidad del producto por sí sola no establece el periodo legal aprobado. |
Lista de comprobación de implementación
Convierta la especificación en un gate de release para cada sistema de IA de alto riesgo. Mantenga juntos el registro de clasificación, la finalidad prevista, el esquema de eventos, el registro de conservación, la revisión de privacidad, las pruebas y el plan de supervisión en el conjunto de documentación del anexo IV.
- Nombre al proveedor, responsable del despliegue, finalidad prevista, base del alto riesgo, límite del sistema, Releases del agente y del modelo y cada parte que controle una copia de los registros.
- Defina la población de ejecuciones dentro del ámbito y las acciones con consecuencias que necesitan registros completos de herramienta, política, decisión humana y resultado.
- Publique un esquema de eventos versionado con campos obligatorios, clasificaciones de datos, reglas de redacción, identificadores, orden de eventos permitido y comportamiento ante fallos.
- Haga automática la creación de registros en el flujo de ejecución y falle de forma cerrada cuando la falta de un recibo de control dejaría sin gobernar una acción con consecuencias.
- Concilie ejecuciones con registros y pruebe permisos ordinarios, advertencias, aprobaciones requeridas, bloqueos, errores, reintentos, cancelaciones y fallos del servicio de políticas.
- Defina la conservación del proveedor y del responsable del despliegue a partir del registro aprobado, con una prueba mínima de seis meses cuando se aplique el artículo 19 o el artículo 26(6).
- Ejecute pruebas de reconstrucción segura, conciliación de resultados, control de acceso, retención legal, eliminación, exportación y manipulación de un byte.
- Alimente el plan de supervisión del artículo 72 con los eventos definidos y conecte las señales con responsables, resoluciones, incidentes y acciones correctivas.
Preguntas frecuentes
¿Se aplica el artículo 12 del Reglamento de IA de la UE a todos los agentes de IA?
El artículo 12 se aplica a los sistemas de IA de alto riesgo. Un agente necesita primero una clasificación y una finalidad prevista documentadas. Las organizaciones pueden usar los mismos controles de registro para agentes de menor riesgo como decisión de gobernanza.
¿Qué eventos debe registrar un agente de IA conforme al artículo 12?
El artículo 12 exige eventos relevantes para detectar riesgos, identificar modificaciones sustanciales, supervisar después de la comercialización y supervisar al responsable del despliegue. Proporciona una lista mínima explícita de campos para los sistemas de identificación biométrica remota del artículo 12(3). Los demás sistemas necesitan un esquema adecuado a su finalidad. Para un agente que usa herramientas, la identidad de ejecución, las versiones, las entradas o referencias, las solicitudes de herramientas, los resultados de política, las decisiones humanas, los resultados, los errores y las marcas de tiempo forman una base defendible.
¿Durante cuánto tiempo deben conservarse los registros del artículo 12?
El artículo 19(1) exige a los proveedores conservar los registros generados automáticamente bajo su control durante un periodo apropiado a la finalidad prevista y de al menos seis meses, salvo que el Derecho de la Unión o nacional aplicable disponga lo contrario. El artículo 26(6) aplica la misma regla a los responsables del despliegue para los registros bajo su control. Otros registros y normas sectoriales pueden establecer periodos diferentes.
¿Exige el artículo 12 registros con alteraciones detectables?
El artículo exige registro automático y trazabilidad, pero no nombra un mecanismo criptográfico. El almacenamiento de solo anexado, los hashes, las firmas y la verificación independiente son controles de garantía que ayudan a detectar cambios y respaldan un proceso de evidencia defendible.
¿Exige el artículo 12 una reconstrucción?
El artículo no contiene un requisito expreso de reconstrucción. La reconstrucción segura es una prueba de aceptación útil: un revisor debería poder leer la secuencia registrada, las versiones, las decisiones y los resultados sin volver a ejecutar un modelo ni repetir un efecto secundario.
¿Pueden los registros ordinarios de una aplicación satisfacer el requisito?
Pueden contribuir cuando son automáticos, completos para la finalidad prevista, correlacionados en todo el sistema, interpretables, sujetos a controles de acceso, conservados durante el periodo aprobado y disponibles para la supervisión. Los mensajes de depuración específicos de un servicio suelen carecer de versiones de política, autoridad humana, resultados empresariales y conciliación de población.
¿Cómo respalda KLA un diseño de registro conforme al artículo 12?
KLA conecta spans de runtime, resultados de política, gates de herramientas, Decision Requests y resultados de ejecución en Lineage Records. Las exportaciones de Evidence Room seleccionan registros con metadatos de integridad para su verificación sin conexión. El proveedor y el responsable del despliegue siguen siendo responsables de la clasificación, suficiencia de campos, conservación, privacidad, supervisión y evaluación final de conformidad.
Conclusiones clave
Una implementación útil del artículo 12 comienza con la clasificación y la finalidad prevista y después registra automáticamente cada ejecución dentro del ámbito y cada acción con consecuencias. Los artículos 19 y 26(6) convierten la conservación en un control asignado. Un esquema de eventos versionado, identidades estables, contexto de políticas y decisiones humanas, referencias de resultados posteriores, conciliación de población, pruebas de alteración y reconstrucción segura hacen que esos registros sean útiles para la supervisión y la revisión. Consulte la guía de pistas de auditoría para agentes de IA para la arquitectura general de evidencia, la guía de documentación del anexo IV para el expediente técnico y el plan de supervisión posterior a la comercialización para el ciclo operativo.