La brecha de evidencia del EU AI Act: lo que realmente exigirán los auditores
Article 12 requiere "registro automático de eventos" pero casi no proporciona ninguna especificidad. Esta brecha se cerrará rápidamente una vez que comience la aplicación. El precedente de MiFID II, SOX, GDPR y MDR muestra que los requisitos basados en principios evolucionan consistentemente hacia expectativas de auditoría altamente específicas dentro de 2 a 4 años.
Las organizaciones que se preparan ahora deberían implementar sistemas de registro anclados criptográficamente y a prueba de manipulaciones. No porque Article 12 lo exija, sino porque eso es precisamente lo que 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 está movilizando antes de 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 inmutables, bases de datos nativas de seguimiento de auditoría
Cadena de evidencia: desde las operaciones hasta la prueba lista para auditoría
El objetivo no es solo registrar. Es demostrar que los registros son confiables.
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 a prueba de manipulaciones en sus operaciones de IA
KLA Digital proporciona registros de auditoría anclados criptográficamente desde el primer día.
- Ledger respaldado por immudb: Almacenamiento de evidencia solo-anexar con verificación criptográfica incorporada
- Anclaje OpenTimestamps: anclado por lotes a Bitcoin cada hora, proporcionando prueba independiente de que los registros existían cuando se afirma
- 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
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.
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 a prueba de manipulaciones.
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.