RHETRA / Guías / EU AI Act

Cumplimiento del EU AI Act, en la práctica

El EU AI Act (Ley de IA de la UE) obliga a las organizaciones que operan IA de alto riesgo a mantener un sistema de gestión de riesgos, gobernanza de datos, registro automático, transparencia, supervisión humana y ciberseguridad — de forma continua y con evidencia (Art. 9–15). Las multas por incumplir las obligaciones de alto riesgo alcanzan los 15 M€ o el 3 % de la facturación global. La pregunta práctica no es «¿qué documentos necesitamos?», sino «¿podemos producir evidencia verificable de lo que nuestra IA hizo realmente?». Esta guía cubre el calendario, las obligaciones y la vía basada en evidencia para cumplirlas.

1 · El calendario que importa

• 1 de agosto de 2024 — el Reglamento entró en vigor.
• 2 de febrero de 2025 — se aplican las prácticas prohibidas (puntuación social, extracción no selectiva de imágenes faciales, entre otras).
• 2 de agosto de 2025 — se aplican las obligaciones para los modelos de IA de uso general.
• 2 de agosto de 2026 — se aplica el grueso de las obligaciones de alto riesgo (sistemas del Anexo III: puntuación crediticia, empleo, infraestructuras críticas, aplicación de la ley y más).
• 2 de agosto de 2027 — termina la transición ampliada para la IA de alto riesgo integrada en productos ya regulados (productos sanitarios, maquinaria).

Si su organización es un banco, una aseguradora, un operador hospitalario o una autoridad pública que usa IA en decisiones sobre personas, la fecha de agosto de 2026 es la que tiene sobre la mesa. Construir la infraestructura de registro y supervisión lleva trimestres, no semanas — por eso los supervisores esperan verla en funcionamiento, no en planificación.

2 · A qué le obliga realmente el alto riesgo

Siete deberes operativos, todos continuos:

• Art. 9 — Gestión de riesgos: un proceso iterativo y documentado a lo largo de todo el ciclo de vida, no una evaluación puntual.
• Art. 10 — Gobernanza de datos: los datos de entrenamiento/validación/prueba deben ser pertinentes, representativos y examinados en busca de sesgos.
• Art. 11 — Documentación técnica: actualizada, completa y a disposición de las autoridades.
• Art. 12 — Registro: el sistema debe registrar eventos automáticamente durante toda su vida útil — aquí es donde la mayoría de las arquitecturas fallan en silencio, porque unos logs que se pueden editar son apuntes, no evidencia.
• Art. 13 — Transparencia: los responsables del despliegue deben poder entender y usar correctamente la salida del sistema.
• Art. 14 — Supervisión humana: capacidad de intervención efectiva e integrada en el diseño — no un sello al final.
• Art. 15 — Precisión, robustez, ciberseguridad: resiliencia frente a errores y frente a ataques, incluido el envenenamiento de datos y de modelos.

3 · Los tramos reales de las multas

El Art. 99 define tres tramos — se citan mal a menudo, así que con precisión:

• Hasta 35 M€ o el 7 % de la facturación anual global — solo para las prácticas prohibidas (Art. 5).
• Hasta 15 M€ o el 3 % — por infringir las demás obligaciones, incluidos todos los deberes de alto riesgo anteriores.
• Hasta 7,5 M€ o el 1 % — por facilitar información incorrecta o engañosa a las autoridades.

4 · Documentos frente a evidencia: la trampa del cumplimiento

La respuesta corporativa por defecto a la regulación son documentos: políticas, registros, PDF. Los deberes de alto riesgo del EU AI Act son en gran medida operativos — atañen a lo que el sistema hace en tiempo de ejecución. Un PDF de política no puede demostrar que una llamada de IA concreta, en una fecha concreta, fue verificada, enmascarada, permitida o bloqueada. Unos logs editables no pueden probar que nadie los limpió después.

La evidencia tiene dos propiedades de las que los documentos carecen: la genera el propio sistema que aplica la política y es a prueba de manipulación. Eso es alcanzable hoy: una pasarela de aplicación de políticas delante de cada llamada de IA, más firmas criptográficas sobre cada decisión. Las firmas post-cuánticas (p. ej. Dilithium5 / ML-DSA, estandarizadas por el NIST) mantienen esa evidencia duradera incluso frente a futuros ataques cuánticos — relevante, porque los registros de auditoría deben seguir siendo verificables durante años.

5 · El ciclo: definir → aplicar → probar → exportar

• Definir la política de forma legible por máquina: qué clases de datos pueden llegar a qué modelos, qué se enmascara, quién aprueba las excepciones.
• Aplicarla en cada llamada: una pasarela (compatible con OpenAI, para que las aplicaciones no cambien) clasifica cada llamada y aplica BLOCK / SANITIZE / ALLOW — esto es el registro del Art. 12 y la supervisión del Art. 14, producidos como efecto secundario de la operación.
• Probar cada decisión: firmarla y atestiguar el propio entorno de ejecución (la atestación de hardware, explicada aquí).
• Exportar la evidencia: entregar al auditor registros verificables en lugar de capturas de pantalla.

Esta es la arquitectura que RHETRA entrega: la pasarela KRONOS y la Governance Platform implementan el ciclo de extremo a extremo — on-premise o SaaS. El contexto más amplio — por qué la verificabilidad es el núcleo de la soberanía — está en nuestra guía pilar: ¿Qué es la IA soberana?

Esta guía es información general sobre el Reglamento (UE) 2024/1689, no asesoramiento jurídico.