Home / Recursos / Cumplimiento
Cumplimiento · Lectura de 9 min · Actualizado 2026-07-06
Guía de preparación para el artículo 12 de la Ley de IA de la UE (EU AI Act)
Qué exigen realmente en lo operativo las obligaciones de mantenimiento de registros y supervisión humana desde agosto de 2026 — y la evidencia que un auditor le pedirá producir.
Desde agosto de 2026, los sistemas de IA de alto riesgo en la UE deben mantener registros automáticos de su propio funcionamiento. La mayoría de las organizaciones descubre qué significa eso la primera vez que un auditor se los pide.
Qué exige realmente el artículo 12
El artículo 12 del EU AI Act es una obligación de mantenimiento de registros: los sistemas de IA de alto riesgo deben ser técnicamente capaces de registrar automáticamente eventos a lo largo de su vida útil. Los registros deben ser suficientes para identificar situaciones que puedan presentar riesgo, respaldar la vigilancia poscomercialización y permitir la trazabilidad del funcionamiento del sistema. En términos operativos, eso significa que cada inferencia — cada prompt, cada recuperación, cada respuesta del modelo, cada acción automatizada — necesita un registro duradero, con marca de tiempo, vinculado al usuario, la versión del modelo y las fuentes de datos implicadas. Una exportación semanal de títulos de chat no alcanza el listón. Tampoco basta con confiar en el panel de uso de un proveedor de nube, porque ese panel es el registro del proveedor, no el suyo, y normalmente registra metadatos de facturación en lugar de contexto de decisión.
El artículo 14 es la otra mitad
Mantener registros sin supervisión es un diario de decisiones sin vigilancia. El artículo 14 exige que los sistemas de alto riesgo estén diseñados para que personas físicas puedan supervisarlos eficazmente — comprender sus salidas, decidir no usarlas e intervenir o interrumpir el funcionamiento. Operativamente, eso significa que las acciones automatizadas de consecuencia deben pasar por una puerta de aprobación que un humano pueda ejercer realmente, y el ejercicio de esa puerta debe a su vez registrarse: quién aprobó, quién rechazó, cuándo y qué vio. Los requisitos de precisión y robustez del artículo 15 presuponen entonces que puede demostrar el comportamiento a lo largo del tiempo — lo que devuelve a los registros.
Qué pedirá un auditor
Las solicitudes de auditoría en este ámbito se están volviendo predecibles. Espere que le pidan producir:
- El registro completo de eventos de una interacción concreta en una fecha concreta — prompt, contexto recuperado, identidad y versión del modelo, salida y acciones posteriores.
- Evidencia de que el registro no ha sido alterado desde que se escribió — cadenas de hash o una prueba de manipulación equivalente, no solo marcas de tiempo de base de datos.
- La traza de supervisión humana: qué acciones requerían aprobación, quién tenía esa autoridad, y cada decisión de aprobación o rechazo.
- La política de retención y su aplicación — incluida la interacción de las solicitudes de supresión del artículo 17 del RGPD con su obligación de auditoría.
- Su registro de actividades de tratamiento del artículo 30 del RGPD, actualizado para cubrir la inferencia de IA como operación de tratamiento.
Una checklist práctica de preparación
Antes de agosto de 2026, verifique cuatro cosas. Primero, que el logging sea por llamada y automático — ni opcional, ni muestreado. Segundo, que los registros sean a prueba de manipulación: un registro de solo anexado cuya integridad pueda demostrarse, porque un log mutable suspende la prueba de trazabilidad en cuanto se cuestiona su integridad. Tercero, que la supervisión humana exista como punto de control aplicado en el sistema, no como un párrafo en un documento de políticas — el artículo 14 pregunta si una persona podría intervenir, y la respuesta honesta requiere un mecanismo de aprobación en la ruta de ejecución. Cuarto, que toda la cadena de evidencia esté bajo su control. Si su inferencia corre en infraestructura compartida, su traza de auditoría tiene una dependencia que usted no puede citar judicialmente bajo demanda.
Por eso la arquitectura importa aquí más que la política. El logging por llamada en un registro inalterable, con puertas de aprobación en las acciones de consecuencia, se corresponde uno a uno con los artículos 12 y 14 — y es mucho más fácil construirlo desde el principio que adaptarlo a posteriori sobre una API de nube que usted no opera.
Vea la evidencia del artículo 12 generarse en vivo →Guías relacionadas
Soberanía
La soberanía digital, en cifras: lo que las encuestas de Bitkom dicen a todo comprador de IA
La mitad de las empresas alemanas quedaría paralizada por una caída de la nube — y cuatro de cada diez ya aceptan sacrificios por alternativas soberanas. La demanda es real; el sacrificio ya no tiene por qué serlo.
7 min de lectura
Leer el análisis →Cumplimiento
IA soberana en Francia: lo que exigen ANSSI, CNIL y la doctrina del cloud de confiance
Francia ha convertido la IA de confianza en doctrina publicada — las recomendaciones de seguridad de ANSSI para IA generativa, las fichas RGPD de CNIL y el estándar SecNumCloud forman una lista de requisitos concreta para cualquier plataforma de IA empresarial.
6 min de lectura
Leer la guía →Cumplimiento
NIS2 y su stack de IA: ¿quién responde cuando un agente actúa?
NIS2 hace a la dirección personalmente responsable del riesgo de ciberseguridad — incluidos los agentes de IA que está a punto de desplegar. Esta es la lista operativa.
6 min de lectura
Leer la guía →