Artículo 12 de la Ley de IA de la UE: requisitos de registro para los sistemas de IA de alto riesgo
El Artículo 12 exige que la IA de alto riesgo registre eventos automáticamente. Reglas de biometría del Art. 12, apartado 3, conservación de proveedor frente a responsable del despliegue y el plazo del 2 dic 2027.
Todo sistema de IA de alto riesgo en virtud del Reglamento (UE) 2024/1689 debe construirse con la capacidad de registrar lo que hace, cuándo lo hace y en qué condiciones. El Artículo 12 es la disposición que convierte esto en un requisito de diseño — no en una ocurrencia tardía, no en un parche posterior al despliegue. Si está desarrollando o desplegando un sistema de IA de alto riesgo, necesita comprender qué exige el Artículo 12, cómo se conecta con sus obligaciones de conservación en virtud de los Artículos 19 y 26, y cuáles son las reglas específicas para los sistemas de identificación biométrica remota en virtud del Artículo 12, apartado 3.
El plazo de cumplimiento del Artículo 12 — como ocurre con todas las obligaciones de alto riesgo sobre los sistemas autónomos del Anexo III — es el 2 de diciembre de 2027, en virtud del Ómnibus Digital acordado en mayo de 2026. Esa fecha aplazó el plazo original del 2 de agosto de 2026. No es lejano. Diseñar la capacidad de registro lleva tiempo; debe especificarse junto con la arquitectura del sistema, no readaptarse seis meses antes del plazo.
Qué exige realmente el Artículo 12
El Artículo 12 hace una cosa específica: exige que los sistemas de IA de alto riesgo sean técnicamente capaces de registrar automáticamente eventos — los registros — a lo largo de toda su vida operativa. Esto es un requisito de diseño impuesto a los proveedores. Usted lo incorpora. El sistema, por su naturaleza, debe generar un registro de auditoría fiable de su propio funcionamiento.
Esto es distinto de la cuestión de quién conserva esos registros, durante cuánto tiempo y bajo qué obligaciones. El Artículo 12 es el requisito de capacidad. Las obligaciones de conservación residen en otra parte: el Artículo 19 cubre los registros que controla el proveedor; el Artículo 26 cubre la obligación del responsable del despliegue de conservar los registros que controla durante al menos seis meses. Confundir estas tres disposiciones es habitual — y de consecuencia. Son obligaciones distintas sobre actores distintos en puntos distintos de la vida del sistema.
Artículo 12, apartado 1: trazabilidad apropiada a la finalidad prevista
El Artículo 12, apartado 1, establece que el registro debe permitir un nivel de trazabilidad apropiado a la finalidad prevista del sistema. El planteamiento es deliberadamente proporcionado — un sistema del Anexo III de alcance estrecho utilizado en un proceso administrativo bien definido no necesita la misma profundidad de registro que un modelo de puntuación de riesgo que procesa miles de decisiones a diario. Lo que registre debe corresponderse con lo que importa para el perfil de riesgo de ese sistema.
En el texto se mencionan dos finalidades específicas. Primera, identificar situaciones en las que el sistema pueda estar presentando el tipo de riesgo que requeriría una acción en virtud del Artículo 79, apartado 1 — situaciones que impliquen un riesgo para la salud, la seguridad o los derechos fundamentales. Segunda, sustentar la obligación de vigilancia poscomercialización en virtud del Artículo 72, que recae sobre el proveedor. Los registros son la columna vertebral probatoria de la vigilancia poscomercialización. Sin ellos, un proveedor no puede cumplir el Artículo 72 de ningún modo significativo.
Una tercera finalidad, implícita, se desprende de la referencia del Artículo 12, apartado 1, a la trazabilidad: sustentar la investigación en caso de un incidente grave notificable en virtud del Artículo 73. Los informes de incidentes a la autoridad de vigilancia del mercado deben fundamentarse en hechos. Los registros son de donde provienen esos hechos.
Artículo 12, apartado 2: trazabilidad para la detección de riesgos y la modificación sustancial
El Artículo 12, apartado 2, especifica que los registros generados automáticamente deben permitir la trazabilidad al menos en la medida necesaria para:
- determinar si el sistema ha presentado, o podría presentar, el riesgo descrito en el Artículo 79, apartado 1; y
- sustentar la evaluación en los casos de modificación sustancial — el tipo de cambio que, en virtud del Artículo 43, desencadenaría una evaluación de la conformidad nueva o actualizada.
En la práctica, esto significa que su arquitectura de registro necesita capturar suficiente contexto para reconstruir lo que el sistema estaba haciendo en el momento pertinente: qué entradas recibió, bajo qué configuración operaba, si algún parámetro había cambiado y si un supervisor humano intervino o anuló un resultado. Un registro escaso que solo anote una marca de tiempo y una etiqueta de resultado de alto nivel no satisfará esto. El registro debe sustentar una revisión forense, no solo confirmar que el sistema se ejecutó.
El ángulo de la modificación sustancial merece especial atención. El Artículo 43 exige que los proveedores evalúen si un cambio en un sistema desencadena una nueva evaluación de la conformidad. Esa evaluación solo es creíble si puede comparar el comportamiento actual del sistema con su línea de base previa a la modificación. Los registros proporcionan esa comparación. Un proveedor que no puede demostrar qué hacía el sistema antes de un cambio, y qué hace después, no tiene una base fiable para la determinación de la modificación sustancial.
Artículo 12, apartado 3: registro mínimo obligatorio para la identificación biométrica remota
El Artículo 12, apartado 3, fija un suelo legal para una categoría específica: los sistemas de identificación biométrica remota del Anexo III, punto 1, letra a). Estos se enfrentan al mayor escrutinio de la lista del Anexo III, y los requisitos de registro lo reflejan. Para la identificación biométrica remota, los registros generados automáticamente deben anotar, como mínimo:
- El período de cada uso — concretamente, la fecha y hora de inicio y la fecha y hora de finalización de cada sesión operativa.
- La base de datos de referencia con la que se cotejaron los datos de entrada.
- Los datos de entrada que produjeron una coincidencia — el sistema debe registrar los datos específicos que dieron lugar a un resultado de identificación positivo, no solo que se produjo una coincidencia.
- La identidad de las personas físicas implicadas en la verificación de los resultados en virtud del Artículo 14, apartado 5 — los revisores humanos que comprobaron y confirmaron el resultado del sistema antes de actuar conforme a él.
Esto no es una lista de comprobación que los proveedores puedan aproximar o cumplir «sustancialmente». Es un mínimo legal. Un sistema de identificación biométrica remota cuyos registros no capturan los cuatro elementos incumple el Artículo 12, apartado 3, de plano. El cuarto elemento es particularmente importante: crea un rastro de rendición de cuentas para el mecanismo de supervisión humana exigido en virtud del Artículo 14. Si algo sale mal, el registro debe mostrar quién revisó el resultado y cuándo.
El requisito de registrar la identidad de las personas que verifican plantea también una cuestión práctica sobre la minimización de datos. La identidad del revisor es un dato personal; los datos de entrada que dan lugar a una coincidencia son casi con seguridad datos personales. Ambos son obligatorios en virtud del Artículo 12, apartado 3. Esa tensión es real y se aborda en la sección de interacción con el RGPD más abajo.
La cadena de registro: tres actores, tres obligaciones
Una imagen clara de quién es responsable de qué evita el fallo de cumplimiento más habitual en esta materia — los proveedores que suponen que los responsables del despliegue se ocuparán del registro, y los responsables del despliegue que suponen que el proveedor ya lo ha cubierto.
Proveedor (Artículo 12): diseña e incorpora la capacidad de registro en el sistema. Este es un requisito previo a la comercialización — el sistema debe tener la capacidad técnica de generar los registros exigidos de forma automática antes de introducirse en el mercado. El proveedor no puede descargar esta obligación de diseño en el responsable del despliegue. Si el sistema no puede registrar automáticamente al nivel de granularidad exigido, es no conforme antes de que se produzca un solo despliegue.
Proveedor (Artículo 19): conserva los registros que están bajo el propio control del proveedor. El plazo de conservación no se especifica en el propio Artículo 12 — lo determina el Artículo 19, que vincula la conservación de registros del proveedor a sus obligaciones de vigilancia poscomercialización en virtud del Artículo 72. En la práctica, los proveedores deberían conservar los registros durante la vida útil de servicio activo de cada versión del sistema, más un período razonable tras su retirada del servicio.
Responsable del despliegue (Artículo 26): conserva los registros generados durante el propio uso del sistema por el responsable del despliegue durante al menos seis meses, salvo que otra norma aplicable de la UE o nacional exija un período más largo. Esta es una obligación legal directa sobre el responsable del despliegue — no está condicionada a que el proveedor se lo indique, no puede excluirse por contrato y no se satisface con que el responsable del despliegue devuelva los registros al proveedor. El responsable del despliegue debe conservar los registros que controla.
La implicación práctica es que ambas partes necesitan establecer, antes de que el sistema entre en producción, qué registros controla cada una y qué obligaciones de conservación se derivan. Esa claridad pertenece al acuerdo contractual entre el proveedor y el responsable del despliegue — y ambas partes deben poder demostrar su cumplimiento a una autoridad de vigilancia del mercado de forma independiente entre sí.
Por qué importan los registros más allá de la propia Ley
La obligación de conservación automática de registros del Artículo 12 tiene un valor que se extiende mucho más allá del estricto cumplimiento de la Ley de IA de la UE. Cuatro áreas importan en la práctica:
Auditorías e inspecciones. Las autoridades nacionales de vigilancia del mercado pueden solicitar acceso a los registros en virtud del Artículo 74. Una autoridad competente que investigue un incidente específico puede exigir la presentación de registros para reconstruir la secuencia de los hechos. Un sistema que no puede producir registros estructurados y fiables dificulta la investigación y, de modo más práctico, da a la autoridad menos motivos para abordar con confianza la versión de los hechos del operador. Los operadores con archivos de registro limpios tienden a salir mejor parados en el contacto regulatorio que los que carecen de ellos.
Investigación de incidentes. Cuando algo sale mal con un sistema de IA de alto riesgo, la pregunta es siempre: ¿qué ocurrió y cuándo empezó? Los registros son la respuesta. Sin ellos, el análisis de la causa raíz es especulativo. Los proveedores con un registro sistemático pueden investigar con rapidez, aislar la anomalía, contener el problema e informar con exactitud en virtud del Artículo 73. El informe de incidentes que exige la Ley debe fundamentarse en pruebas. Los registros proporcionan esa prueba.
Prueba de conformidad. Los registros alimentan directamente el sistema de vigilancia poscomercialización en virtud del Artículo 72. Los proveedores deben establecer, documentar y mantener activamente ese sistema. Requiere datos — concretamente, datos de rendimiento del mundo real generados durante el uso efectivo. Los registros del Artículo 12 son esos datos. Un proveedor que afirma ejecutar un programa de vigilancia poscomercialización pero no puede mostrar los datos de registro subyacentes no está, en sustancia, ejecutando uno.
Sustentar el registro de supervisión humana del Artículo 14. La supervisión humana de la IA de alto riesgo se exige en virtud del Artículo 14. Esa supervisión solo es demostrable si queda registrada. Toda intervención — un revisor comprobando el resultado de un sistema, una anulación, una decisión de escalar — debería aparecer en los registros. El Artículo 12, apartado 3, hace esto explícito para los sistemas biométricos al exigir que se registre la identidad de la persona que verifica. Para otros sistemas de alto riesgo, la misma lógica se aplica como cuestión de práctica de cumplimiento eficaz aun cuando la norma no lo especifique como suelo.
El registro y el RGPD: una tensión genuina
Para la mayoría de los sistemas de IA de alto riesgo, los registros que exige el Artículo 12 contendrán datos personales. Los candidatos cuyos currículos procesó un sistema de cribado de selección de personal, las personas que un sistema de identificación biométrica remota cotejó, los usuarios cuyas consultas evaluó un sistema de admisibilidad a un servicio público — todos ellos aparecen, de alguna forma, en los registros conformes del Artículo 12. El RGPD y la Ley de IA de la UE se aplican simultáneamente, y tiran en direcciones opuestas en este punto.
El principio de minimización de datos del RGPD (Artículo 5, apartado 1, letra c), del RGPD) exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados». El Artículo 12, apartado 3, de la Ley de IA de la UE exige registrar los datos de entrada que produjeron una coincidencia en un sistema de identificación biométrica — que son por definición datos personales, y que deben conservarse durante al menos seis meses en virtud del Artículo 26. Eso no es minimización de datos; son datos cuya existencia y conservación son legalmente exigidas.
La solución no es ignorar una obligación en favor de la otra. Es documentar cuidadosamente la base jurídica. El tratamiento de datos personales en los registros del Artículo 12 es exigido por una obligación legal (la propia Ley de IA de la UE) — lo que proporciona la base jurídica en virtud del Artículo 6, apartado 1, letra c), del RGPD. El período de conservación lo determina el mínimo de seis meses del Artículo 26 (o más, si el Artículo 19 lo exige para el proveedor). Una vez que expira la obligación de conservación, los datos deberían eliminarse o anonimizarse — la base jurídica para seguir conservándolos deja de existir en ese momento.
Pasos prácticos: implemente controles de acceso en el almacén de registros para que los datos personales de los registros no sean accesibles al personal que no los necesite; aplique el cifrado en reposo; documente el tratamiento de los datos de registro en su Registro de las Actividades de Tratamiento en virtud del Artículo 30 del RGPD; y asegúrese de que sus procedimientos de derechos de los interesados tengan en cuenta el hecho de que pueden existir datos personales sobre ellos en los registros de operación de la IA que no pueden eliminarse durante la ventana de conservación.
Arquitectura de registro: qué significa «automático» en la práctica
El Artículo 12 exige que el registro sea automático. Esto es una restricción de diseño, no una sugerencia de flujo de trabajo. El propio sistema debe generar los registros — no un operador acordándose de pulsar exportar, no una revisión manual periódica, no una extracción analítica aguas abajo. El evento se anota en el momento en que ocurre, por el sistema, sin requerir una acción humana que lo desencadene.
Para la mayoría de los sistemas bien arquitecturados, esto no es técnicamente difícil. El reto está en especificar el alcance correcto en el momento del diseño:
Granularidad. ¿Qué nivel de evento hay que capturar? Para un sistema de alto volumen que toma miles de decisiones a diario, registrar cada inferencia individual con todo el detalle de entrada y salida puede generar volúmenes de almacenamiento que son poco prácticos de conservar durante seis meses. La respuesta no es reducir el registro — es diseñar un enfoque de registro escalonado que capture todos los eventos a nivel de resumen, y todo el detalle para una muestra defendible y documentada. Sea cual sea el enfoque, debe ser coherente con el requisito del Artículo 12, apartado 2, de que los registros sustenten la identificación de riesgos y la evaluación de la modificación sustancial.
Inmutabilidad. Los registros destinados a fines regulatorios deben ser a prueba de manipulación. Si un registro puede alterarse a posteriori — entradas eliminadas, marcas de tiempo ajustadas, resultados modificados retroactivamente — no tiene valor probatorio. Los controles técnicos deberían impedir la modificación tras la escritura. Como mínimo, la integridad del registro debería ser verificable mediante funciones hash o mecanismos similares.
Control de acceso. El acceso a los registros no es universal. Los datos personales de los registros están sujetos a los controles de acceso del RGPD. Los datos operativos confidenciales pueden estar sujetos a protecciones de propiedad intelectual. Diseñe el modelo de acceso a los registros al mismo tiempo que el esquema de registro — no trate el control de acceso como una preocupación de la fase de despliegue.
Conservación y eliminación. El suelo de seis meses del Artículo 26 se aplica a los registros en poder del responsable del despliegue. Configure las políticas de conservación de modo que los registros se archiven y eliminen automáticamente en el momento correcto. Los flujos de trabajo de eliminación manual son propensos a errores; los calendarios automatizados son más fiables y más defendibles.
Exportabilidad. Las autoridades competentes que solicitan registros en virtud del Artículo 74 necesitan poder leerlos. Un registro almacenado en un formato binario propietario que requiere las propias herramientas del proveedor para ser interpretado no está, en la práctica, disponible para un regulador. Diseñe la salida de los registros en un formato estructurado y documentado — JSON, CSV o un esquema documentado — con el que un auditor externo pueda trabajar de forma independiente.
Un ejemplo práctico: proveedor de tecnología de RR. HH., cribado de selección de personal
Una empresa de tecnología de RR. HH. de 60 personas construye y vende una herramienta de cribado de currículos a empleadores de Alemania y los Países Bajos. La herramienta clasifica a los candidatos frente a los requisitos del puesto y marca a quienes cumplen los criterios de umbral. Entra dentro del Anexo III, punto 4 (empleo, gestión de los trabajadores, acceso al autoempleo) y es de alto riesgo en virtud del Artículo 6.
La empresa es el proveedor. Sus obligaciones del Artículo 12 surgen en la fase de diseño, antes de que el producto salga al mercado.
El sistema debe ser capaz de registrar automáticamente: cada sesión de despliegue (hora de inicio y de finalización), la configuración del puesto aplicada durante esa sesión, los datos de los candidatos procesados y los resultados de clasificación generados. La granularidad debe ser suficiente para una revisión de vigilancia poscomercialización en virtud del Artículo 72 — si la exactitud de clasificación de la herramienta se degrada a lo largo de seis meses, los registros deben mostrar cuándo comenzó la deriva y bajo qué condiciones de entrada. La empresa también necesita documentar un procedimiento de evaluación de la modificación sustancial: si el modelo subyacente se reentrena, los parámetros de umbral cambian o el uso previsto se amplía a nuevos sectores, los registros proporcionan la línea de base de antes y después para esa evaluación.
Cada empleador que utiliza la herramienta es un responsable del despliegue. En virtud del Artículo 26, cada empleador debe conservar los registros generados durante su propio uso de la herramienta durante al menos seis meses. Un ciclo de selección que se cierra en marzo no da al empleador permiso para eliminar los registros de marzo en abril. El reloj de seis meses corre desde la fecha del tratamiento, no desde la fecha en que se cubrió la vacante.
Si un candidato impugna posteriormente la decisión de cribado del empleador — ya sea en virtud del derecho a la explicación del RGPD, en virtud del Derecho nacional sobre discriminación laboral o en respuesta a una investigación de una autoridad de vigilancia del mercado — esos registros son el fundamento fáctico de la defensa o de la investigación. Un empleador que no puede producirlos está en una posición débil con independencia de que su proceso fuera, en sustancia, justo.
Cómo ayuda Confir
El módulo de evaluación AIGM de Confir — Gobernanza y Vigilancia Poscomercialización, que cubre los Artículos 9, 72 y 73 — incluye la conservación de registros como un área de control estructurada. Cuando registra un sistema de alto riesgo, la evaluación basada en reglas correlaciona la arquitectura de registro de su sistema con los requisitos del Artículo 12: si el registro automático está incorporado, si los campos mínimos del Artículo 12, apartado 3, están cubiertos para los sistemas biométricos, y si su política de conservación del lado del responsable del despliegue cumple el suelo de seis meses del Artículo 26.
El registro de auditoría inmutable de Confir anota cada acción de cumplimiento — finalizaciones de evaluaciones, actualizaciones de documentación, aprobaciones de supervisión — con marcas de tiempo que no pueden alterarse. Ese registro es en sí mismo una prueba de su proceso de gobernanza, y puede exportarse si una autoridad de vigilancia del mercado solicita una demostración de cómo su organización gestiona sus obligaciones de la Ley de IA.
Los controles de conservación de registros aparecen como un elemento documentado en el paquete de documentación técnica del Artículo 11 / Anexo IV de Confir. El diseño del registro y la política de conservación terminan ambos en el mismo paquete de conformidad, no dispersos por sistemas separados que requieren una conciliación manual en el momento de la auditoría. confir.eu.
Sanciones
El incumplimiento del Artículo 12 entra dentro del nivel general de obligaciones de alto riesgo del Artículo 99, apartado 4. La multa máxima es de 15.000.000 € o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Para las empresas que reúnen los requisitos de pyme, el Artículo 99, apartado 6, limita la multa al menor de los dos importes — una protección de proporcionalidad genuina, pero no una razón para tratar el requisito de registro como opcional.
La obligación se aplica a partir del 2 de diciembre de 2027 para los sistemas autónomos del Anexo III. Esa es la fecha de cumplimiento, no la fecha de diseño. Si su sistema necesita completar la evaluación de la conformidad antes de salir al mercado a finales de 2027, la capacidad de registro debe diseñarse, implementarse y validarse considerablemente antes. La evaluación de la conformidad del Artículo 43 examinará el Artículo 12. Si la arquitectura de registro está ausente o es inadecuada en ese momento, la evaluación falla.
Conclusiones clave
El Artículo 12 es una obligación de diseño del sistema, no una administrativa. Incorpore la capacidad de registro desde el principio. Sepa qué registros controla el proveedor (Artículo 19) y cuáles controla el responsable del despliegue (Artículo 26, suelo mínimo de seis meses). Para la identificación biométrica remota del Anexo III, punto 1, letra a), los cuatro campos mínimos del Artículo 12, apartado 3, no son negociables. Diseñe registros que sean automáticos, inmutables, exportables y con control de acceso desde el primer día. Y trátelos como la columna vertebral probatoria de la vigilancia poscomercialización en virtud del Artículo 72 y de la respuesta a incidentes en virtud del Artículo 73 — porque eso es exactamente lo que son.
Guías relacionadas
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →