EU AI Act Artículo 12
La brecha de evidencia del EU AI Act: lo que realmente exigirán los auditores
Los organismos notificados ya están señalando expectativas más estrictas
El ecosistema de evaluación de la conformidad se movilizó en torno a la fecha límite de designación de organismos notificados de agosto de 2025. TUV SUD comenzó a ofrecer certificados voluntarios de conformidad con la Ley de IA en noviembre de 2025. Team-NB advirtió sobre una potencial escasez de organismos designados con experiencia en IA. Aquellos que logren la designación aplicarán estándares rigurosos.
El AESIA sandbox regulatorio de España ha elaborado 16 guías de ejecución técnica que cubren métodos de documentación específicos. Los participantes reciben "informes de salida" que los evaluadores de conformidad deben "tener en cuenta positivamente", estableciendo un precedente temprano sobre cómo se ve la documentación aceptable.
Según el Anexo VII, los organismos notificados tendrán amplios poderes de acceso: acceso completo a conjuntos de datos de entrenamiento a través de API, derechos de prueba directos y, en casos excepcionales, acceso a los propios modelos entrenados. Los registros de acceso a su conjunto de datos se convertirán en objetivos de auditoría.
El patrón es claro: el texto vago se convierte en una práctica estricta
Todas las regulaciones importantes siguen la misma trayectoria. Los requisitos basados en principios evolucionan hacia expectativas de auditoría altamente específicas en un plazo de 2 a 4 años.
En qué evolucionó
- Divergencia UTC de 100 microsegundos (HFT)
- 1 milisegundo (trading algorítmico)
- Almacenamiento WORM por 5-7 años
- Reconstrucción de operaciones en 72 horas bajo demanda
Lección clave
La precisión temporal se volvió 1.000.000x más estricta
La 'grabación automática de eventos' del Artículo 12 se convertirá en un logging a prueba de manipulaciones y anclado criptográficamente dentro de 2‑4 años del inicio de la aplicación.
Cómo evolucionaron otras regulaciones de vagas a prescriptivas
Requisito original
"Fuente de tiempo precisa" para registros comerciales
En qué se convirtió
Divergencia UTC (HFT) de 100 microsegundos, almacenamiento WORM, retención de 5 a 7 años, reconstrucción de 72 horas
Los requisitos de precisión de tiempo se volvieron 1.000.000 de veces más estrictos de lo que implicaba el texto original
Requisito original
"Control interno adecuado" (sin definición)
En qué se convirtió
Marco COSO: 17 principios, 87 puntos de enfoque, 40% de tasas de deficiencia de auditoría de las 4 grandes
El texto basado en principios se volvió altamente prescriptivo a través de la práctica de auditoría
Requisito original
"Medidas técnicas adecuadas"
En qué se convirtió
Ahora se espera 2FA (multa del Hospital Haga), se requieren procedimientos de acceso documentados
El principio de responsabilidad hizo que la documentación en sí fuera un requisito de cumplimiento normativo
Requisito original
Requisitos de "documentación técnica"
En qué se convirtió
IEC 62304 registros de auditoría, control completo de versiones, trazabilidad desde los requisitos hasta las pruebas.
Los patrones de dispositivos médicos se están importando directamente a las expectativas de la Ley de IA
Lo que los auditores se están preparando para evaluar
Basado en prEN ISO/IEC 24970, prEN 18286 y las cuatro grandes áreas de práctica emergentes, esto es lo que probablemente cubrirá la evaluación de la conformidad.
- Eventos de operación (entradas, salidas, decisiones)
- Monitoreo automatizado de eventos (deriva, anomalías)
- Intervenciones de supervisión humana (aprobaciones, anulaciones)
Señales técnicas que convergen en las orientaciones de auditoría
Si bien no son obligatorios explícitamente, estos patrones técnicos abordan la pregunta práctica que harán los auditores: ¿cómo se prueba que estos registros no han sido modificados?
Encadenamiento criptográfico
Cada entrada del registro incluye un hash de la entrada anterior, lo que crea secuencias a prueba de manipulaciones.
Cadenas de hash SHA-256 con acumulaciones de árboles Merkle
Almacenamiento WORM
El almacenamiento Write-Once-Read-Many evita la modificación de registros históricos
immudb, bloqueo de objetos de Amazon S3, blobs inmutables de Azure
Anclaje de marca de tiempo
Las marcas de tiempo de terceros independientes prueban que los registros existieron en un momento específico
OpenTimestamps, RFC 3161 TSA, anclaje blockchain
Arquitectura de solo agregar
Las correcciones se convierten en nuevas versiones vinculadas en lugar de sobrescrituras.
Event sourcing, libros de contabilidad de solo anexado, bases de datos nativas de seguimiento de auditoría
Cadena de evidencia: desde las operaciones hasta la prueba lista para auditoría
Cada paso produce evidencia que un revisor puede verificar de forma independiente y sin conexión.
Los auditores quieren prueba de que su QMS funciona (registros) y de que los registros son confiables (pruebas de integridad).
Dónde se equivocan los equipos
- Esperar a normas armonizadas antes de implementar controles de integridad
- Tratar la retención de 6 meses como suficiente cuando las normas del sector exigen más tiempo
- El registro existe pero la integridad no es verificable (sin hash, sin encadenamiento)
- Faltan registros de acceso al conjunto de datos o se modifican fácilmente
- Sin prueba independiente de marca de tiempo de que los registros existían cuando se afirma
Incorpore pruebas con evidencia de manipulación en sus operaciones de IA
KLA proporciona registros de auditoría anclados criptográficamente desde el primer día.
- Ledger respaldado por immudb: almacenamiento de evidencia solo-anexar; cada exportación se ancla al ledger y el registro de anclaje viaja en el bundle
- Anclaje OpenTimestamps: anclado por lotes a Bitcoin cada hora; el bundle incluye el recibo OTS para que la marca de tiempo pueda confirmarse frente a la cadena de Bitcoin cuando lo decidas
- S3 Object Lock: almacenamiento WORM en modo compliance para retención de payload sin procesar
- Exportaciones de Evidence Room: paquetes firmados con hashes por artefacto e instrucciones de verificación
No espere a las normas armonizadas. Construya la arquitectura de evidencia que exigirán los auditores.
Verifique la integridad de la evidencia con la CLI:
# Verify evidence bundle integrity kla evidence verify --bundle ./evidence-export.zip # Export with full hash chain kla export evidence \ --tenant $KLA_TENANT_ID \ --days 30 \ --include-timestamps \ --format pdf
Qué demuestra el verificador
La exportación de Evidence Room incluye un verificador independiente que revisa un bundle sin acceso a la red y sin infraestructura de KLA. Offline demuestra que el bundle es internamente consistente: cada entrada (datos, pruebas y claves públicas) proviene del propio bundle.
Firma del manifiesto
El manifiesto se canonicaliza (RFC 8785 / JCS) y su digest se recomputa. El JWS separado lleva firmas ES256 SEK y TEK válidas sobre ese digest, verificadas contra las claves públicas que el bundle incrusta en keys/jwks.json.
Inclusión Merkle
Cada artefacto se vuelve a hashear (SHA-256) al digest que declara el manifiesto, la prueba de inclusión de cada artefacto alcanza la raíz sellada, y la raíz Merkle recomputada coincide con el valor del manifiesto.
Firmas de recibos
Cada cadena de recibos de gobernanza se verifica: la firma ed25519 de cada recibo se valida contra una clave embebida en el bundle, y el prevReceiptHash de cada paso enlaza con el paso anterior, de génesis al último.
Cadena de hash del ledger
Cada registro de ledger exportado se vuelve a hashear a su hash declarado, y los registros consecutivos se enlazan mediante previousHash de extremo a extremo.
Anclaje OpenTimestamps
timestamp.ots se analiza bajo las reglas estrictas de OpenTimestamps y se compromete con el digest del manifiesto recomputado. Cuando el recibo está atestado en Bitcoin, el verificador informa su altura de bloque; un recibo de calendario pendiente se acepta como confirmación de Bitcoin pendiente.
Lo que la verificación sin conexión no demuestra
- La autenticidad necesita una comprobación de claves fuera de banda. Las firmas SEK, TEK y de recibos se validan todas contra las claves que el bundle incrusta en keys/jwks.json, así que offline el bundle solo demuestra que es internamente consistente. Para demostrar que proviene de KLA, fije esas claves contra un JWKS publicado por KLA o una huella de clave.
- El anclaje de Bitcoin de OpenTimestamps se confía sin conexión. Confirmar su altura de bloque compara la prueba con la cadena de Bitcoin en vivo, y un recibo de calendario pendiente sigue pendiente hasta una actualización de calendario.
- La prueba del anclaje del ledger immudb está presente y se analiza sin conexión. Confirmar su inclusión contra el estado firmado del ledger necesita una comprobación en red.
Preguntas frecuentes
¿Article 12 requiere explícitamente integridad criptográfica?
No, pero el patrón de MiFID II, SOX, GDPR y MDR es inequívoco: el texto basado en principios se convierte en una práctica prescriptiva en un plazo de 2 a 4 años. Los auditores y los organismos notificados interpretarán que "grabación automática" significa un registro a prueba de manipulaciones.
¿Qué períodos de retención se aplican a los registros de IA?
Article 12 especifica un mínimo de 6 meses para los registros automatizados, pero los requisitos específicos del sector a menudo anulan esto. Las instituciones financieras deberían esperar entre 5 y 7 años. La documentación técnica debe conservarse durante 10 años después de la introducción del sistema en el mercado.
¿Cuándo se publicarán las normas armonizadas?
prEN ISO/IEC 24970 (estándar de registro) está en la boleta de votación del Borrador de Estándar Internacional. prEN 18286 (estándar QMS) entró en investigación pública en octubre de 2025. Se esperan estándares finales para el cuarto trimestre de 2026, pero las expectativas de los auditores se están formando ahora.
¿Qué acceso tendrán los organismos notificados?
Según el Anexo VII, los organismos notificados pueden exigir acceso completo a API a conjuntos de datos de entrenamiento, validación y prueba. Pueden realizar pruebas directas si no están satisfechos con la evidencia del proveedor. Los registros de acceso a los conjuntos de datos se convertirán en sí mismos en objetivos de auditoría.
¿Cómo debemos manejar la auditabilidad del modelo ML?
Los umbrales para un registro extenso aún no están claros, pero los auditores probablemente esperarán: seguimiento de la versión del modelo, cambios de hiperparámetros, metadatos de ejecución de entrenamiento y trazabilidad de decisiones para resultados de alto riesgo.
Recursos relacionados
Continúe su viaje cumplimiento del EU AI Act.
El marco de auditoría empresarial integra las pruebas de integridad en el método de auditoría completo; la evaluación de preparación identifica brechas de evidencia y la página del software de auditoría de agentes de IA cubre la evaluación de la plataforma.
Plantilla de Article 17 QMS
Plantilla del sistema de gestión de calidad para IA de alto riesgo con mapeo prEN 18286.
Hub del EU AI Act
Guía completa de los requisitos de EU AI Act y los cronogramas de cumplimiento normativo.
Descripción general de seguridad
Arquitectura técnica para la integridad de la evidencia y protección de datos.
Demostración de exportación de evidencia
Vea cómo se generan paquetes de pruebas verificables sin conexión.
No espere a que los estándares se pongan al día
La brecha entre el texto de Article 12 y las expectativas prácticas de auditoría se cerrará rápidamente. Las organizaciones que anticipen requisitos más estrictos tendrán importantes ventajas competitivas cuando comiencen las evaluaciones de conformidad.