AI Act: Regulación Europea de IA y sus Implicaciones en Ciberseguridad

La primera ley integral de IA del mundo

El 12 de julio de 2024, la Unión Europea publicó el Reglamento (UE) 2024/1689, conocido como AI Act o Ley de Inteligencia Artificial. No es una directiva que cada Estado miembro transpone a su manera (como NIS2). Es un reglamento de aplicación directa en los 27 Estados miembros, con el mismo texto legal vinculante desde Lisboa hasta Helsinki.

La motivación es clara: la IA se ha desplegado masivamente en sectores críticos (salud, justicia, infraestructuras, seguridad) sin un marco regulatorio específico. El RGPD cubre datos personales, NIS2 cubre ciberseguridad de redes y sistemas, pero ninguno abordaba los riesgos específicos de los sistemas autónomos de toma de decisiones. El AI Act llena ese vacío.

Para los profesionales de ciberseguridad, esta regulación tiene implicaciones directas. Los sistemas de detección de amenazas basados en ML, los SOC automatizados, los escáneres de vulnerabilidades con IA y las herramientas de análisis de malware operan en un terreno que ahora tiene reglas explícitas.

Timeline del AI Act

Fecha	Hito
Abril 2021	La Comisión Europea presenta la propuesta original
Diciembre 2023	Acuerdo político trilateral (Parlamento, Consejo, Comisión)
13 marzo 2024	Aprobación por el Parlamento Europeo (523 votos a favor)
21 mayo 2024	Aprobación formal por el Consejo de la UE
12 julio 2024	Publicación en el Diario Oficial de la UE
1 agosto 2024	Entrada en vigor
2 febrero 2025	Aplicación de prohibiciones (prácticas inaceptables)
2 agosto 2025	Obligaciones para modelos GPAI y designación de autoridades
2 agosto 2026	Aplicación completa: sistemas de alto riesgo (Anexo III)
2 agosto 2027	Aplicación para sistemas de alto riesgo en productos regulados (Anexo I)

La aplicación escalonada no es casual. Las prohibiciones de prácticas inaceptables (social scoring, manipulación subliminal) se aplican primero porque el consenso político sobre ellas era más sólido. Las obligaciones más complejas, como las de alto riesgo, tienen un plazo mayor para permitir la adaptación del mercado.

Clasificación por niveles de riesgo

El AI Act adopta un enfoque basado en riesgo con cuatro niveles. Cada nivel implica obligaciones proporcionalmente mayores.

Nivel de riesgo	Tratamiento	Ejemplos
Inaceptable	Prohibido	Social scoring gubernamental, manipulación subliminal que cause daño, explotación de vulnerabilidades de grupos específicos, scraping masivo no selectivo de imágenes faciales, reconocimiento de emociones en trabajo y educación, categorización biométrica por raza/orientación
Alto	Permitido con requisitos estrictos	IA en infraestructuras críticas (energía, agua, transporte), dispositivos médicos con componente IA, sistemas de selección de personal, evaluación crediticia, IA en migración y control de fronteras, IA en administración de justicia
Limitado	Obligaciones de transparencia	Chatbots (deben revelar que son IA), sistemas de generación de deepfakes (deben etiquetar el contenido), sistemas de reconocimiento de emociones (deben informar al usuario)
Mínimo	Sin obligaciones específicas	Filtros de spam, IA en videojuegos, sistemas de recomendación de contenido, optimización de inventario

Prácticas prohibidas relevantes para seguridad

Algunas prohibiciones del Artículo 5 tienen conexión directa con el ámbito de la ciberseguridad:

• Vigilancia biométrica remota en tiempo real en espacios públicos, salvo excepciones tasadas (búsqueda de víctimas, prevención de amenazas terroristas específicas e inminentes, localización de sospechosos de delitos graves). Cada excepción requiere autorización judicial previa.
• Categorización biométrica que infiera raza, opinión política, afiliación sindical, creencias religiosas u orientación sexual.
• Puntuación social (social scoring) por parte de autoridades públicas que evalúe o clasifique a personas basándose en su comportamiento social.
• Policía predictiva basada exclusivamente en perfilado o evaluación de características personales, sin indicios objetivos de actividad delictiva.

Para equipos de seguridad que trabajan con herramientas de behavioral analytics o user entity behavior analytics (UEBA), la línea entre detección legítima de amenazas internas y vigilancia prohibida merece atención cuidadosa.

Sistemas de IA de alto riesgo: requisitos

Los sistemas clasificados como alto riesgo (Anexo III del Reglamento) deben cumplir seis bloques de requisitos definidos en los Artículos 8 a 15.

1. Sistema de gestión de riesgos (Art. 9)

Un proceso iterativo que abarca todo el ciclo de vida del sistema:

• Identificación y análisis de riesgos conocidos y previsibles.
• Estimación y evaluación de riesgos que surjan del uso previsto y del uso razonablemente previsible.
• Adopción de medidas de mitigación adecuadas.
• Pruebas para verificar que las medidas funcionan.

2. Gobernanza de datos (Art. 10)

Los datasets de entrenamiento, validación y prueba deben:

• Ser relevantes, representativos, libres de errores y completos.
• Tener en cuenta las características específicas del contexto de uso.
• Cumplir requisitos estadísticos apropiados.
• Documentar las decisiones de diseño del dataset, los procesos de recogida y las operaciones de preprocesamiento.

3. Documentación técnica (Art. 11)

Documentación exhaustiva que permita evaluar el cumplimiento, incluyendo:

• Descripción general del sistema y su finalidad.
• Elementos del sistema y su proceso de desarrollo.
• Información detallada sobre los datos de entrenamiento.
• Métricas de rendimiento, robustez y ciberseguridad.
• Descripción del sistema de gestión de riesgos.

4. Registro de actividad y trazabilidad (Art. 12)

Los sistemas de alto riesgo deben generar registros automáticos (logs) que permitan:

• Rastrear el funcionamiento durante toda la vida útil.
• Identificar situaciones de riesgo.
• Facilitar la supervisión posterior al despliegue.
• Los logs deben conservarse durante un período adecuado a la finalidad.

5. Transparencia e información al usuario (Art. 13)

El proveedor debe proporcionar instrucciones de uso claras y completas que incluyan:

• Identidad del proveedor y datos de contacto.
• Características, capacidades y limitaciones del sistema.
• Nivel de precisión, robustez y ciberseguridad.
• Circunstancias conocidas que puedan generar riesgos.
• Especificaciones de los datos de entrada.
• Medidas de supervisión humana.

6. Supervisión humana (Art. 14)

El sistema debe diseñarse para permitir la supervisión efectiva por personas físicas:

• El operador humano debe poder comprender las capacidades y limitaciones del sistema.
• Debe poder interpretar correctamente los resultados.
• Debe poder decidir no usar el sistema o ignorar, anular o revertir sus resultados.
• Debe poder detener el sistema mediante un botón de parada o procedimiento similar.

7. Precisión, robustez y ciberseguridad (Art. 15)

Los sistemas de alto riesgo deben alcanzar niveles apropiados de:

• Precisión: métricas declaradas en la documentación técnica.
• Robustez: resiliencia frente a errores, fallos e inconsistencias en el entorno.
• Ciberseguridad: resistencia frente a intentos de manipulación por terceros no autorizados, incluyendo ataques adversariales (data poisoning, model evasion, model inversion).

Este último punto es especialmente relevante. El AI Act reconoce explícitamente que los sistemas de IA son superficies de ataque y exige protección contra ataques adversariales como requisito legal.

IA en el contexto de ciberseguridad

Herramientas de ciberseguridad con IA

La industria de ciberseguridad ha adoptado masivamente modelos de ML e IA en sus productos. Estas son las categorías principales afectadas:

Categoría	Ejemplos de uso	Clasificación probable AI Act
Detección de amenazas (NDR/EDR)	Modelos ML para detectar tráfico malicioso, comportamiento anómalo	Mínimo o limitado (depende del sector)
SOC automation / SOAR	Triaje automático de alertas, respuesta automatizada	Mínimo, salvo en infraestructuras críticas
Análisis de malware	Clasificación de samples, extracción de features, sandboxing inteligente	Mínimo
Escáneres de vulnerabilidades	Priorización automática de CVEs, predicción de explotabilidad (EPSS)	Mínimo
UEBA / behavioral analytics	Detección de amenazas internas, perfilado de usuarios	Potencialmente alto si incluye biometría
Autenticación biométrica	Reconocimiento facial, voz, huella para acceso	Alto si es remoto y en tiempo real
IA en infraestructuras críticas	IDS/IPS para redes energéticas, sanitarias, transporte	Alto (componente de seguridad de producto regulado)

La clave no es el tipo de herramienta, sino el contexto de despliegue. Un mismo motor de detección de anomalías puede ser "riesgo mínimo" en un e-commerce y "alto riesgo" cuando protege una red hospitalaria o una central eléctrica.

Ataques adversariales como riesgo regulado

El Artículo 15 del AI Act exige que los sistemas de alto riesgo sean resistentes a ataques adversariales. Esto convierte en requisito legal la protección contra:

• Data poisoning: contaminación de datos de entrenamiento para alterar el comportamiento del modelo.
• Model evasion: inputs diseñados para que el modelo clasifique incorrectamente (por ejemplo, malware que evade detección ML).
• Model inversion: extracción de información sensible del modelo entrenado.
• Model extraction: replicación del modelo propietario mediante consultas repetidas.

Para los equipos de seguridad ofensiva (red team), esto significa que las pruebas de robustez adversarial de sistemas de IA se convertirán en un servicio de auditoría con demanda creciente.

Obligaciones por rol en la cadena de valor

El AI Act define obligaciones diferenciadas según el rol del actor en la cadena de suministro del sistema de IA.

Proveedor (Art. 16-23)

El proveedor (quien desarrolla o encarga el sistema y lo pone en el mercado con su nombre) tiene las obligaciones más extensas:

• Implementar el sistema de gestión de riesgos.
• Garantizar la gobernanza de datos.
• Elaborar la documentación técnica.
• Implementar el registro de actividad.
• Realizar la evaluación de conformidad antes de la puesta en el mercado.
• Registrar el sistema en la base de datos de la UE.
• Aplicar el marcado CE.
• Establecer un sistema de vigilancia poscomercialización.
• Notificar incidentes graves a las autoridades.

Implementador / deployer (Art. 26)

Quien despliega el sistema de IA de alto riesgo en su organización debe:

• Usar el sistema conforme a las instrucciones del proveedor.
• Asignar la supervisión humana a personas competentes.
• Garantizar que los datos de entrada sean relevantes y representativos.
• Supervisar el funcionamiento del sistema.
• Conservar los registros generados automáticamente (mínimo 6 meses).
• Informar al proveedor o distribuidor de incidentes graves.
• Realizar una evaluación de impacto en derechos fundamentales (para ciertos usos).

Importador y distribuidor (Art. 24-25)

Obligaciones de verificación: confirmar que el proveedor ha cumplido sus obligaciones, que el sistema tiene marcado CE y que viene acompañado de la documentación requerida.

Evaluación de conformidad

Los sistemas de alto riesgo deben someterse a una evaluación de conformidad antes de su puesta en el mercado. Existen dos vías:

1. Autoevaluación (control interno): El proveedor verifica por sí mismo que cumple los requisitos. Aplicable a la mayoría de sistemas de alto riesgo del Anexo III.
2. Evaluación por organismo notificado: Obligatoria para sistemas de identificación biométrica remota. Un tercero independiente verifica el cumplimiento.

El proveedor debe emitir una declaración UE de conformidad y aplicar el marcado CE antes de comercializar el sistema.

Régimen sancionador

El AI Act establece un marco de sanciones con tres niveles, diseñado para ser disuasorio incluso para las grandes tecnológicas.

Infracción	Sanción máxima	Alternativa porcentual
Prácticas prohibidas (Art. 5)	35 millones EUR	7% facturación global anual
Incumplimiento de obligaciones de alto riesgo	15 millones EUR	3% facturación global anual
Información incorrecta a autoridades	7,5 millones EUR	1,5% facturación global anual

Para PYMEs y startups, las sanciones se calculan sobre el umbral inferior (el que resulte más bajo entre el importe fijo y el porcentaje). Esto evita que una multa sea desproporcionada para empresas más pequeñas, aunque no las exime de cumplir las obligaciones sustantivas.

Cada Estado miembro designa una o varias autoridades nacionales de supervisión del mercado. En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA), creada en 2023, asume este rol.

Intersección AI Act y NIS2

El AI Act y NIS2 operan en planos complementarios, pero sus ámbitos se solapan cuando un sistema de IA se despliega en entidades cubiertas por NIS2.

Aspecto	NIS2	AI Act
Objeto	Ciberseguridad de redes y sistemas de información	Seguridad y derechos fundamentales de sistemas de IA
Tipo de norma	Directiva (transposición nacional)	Reglamento (aplicación directa)
Ámbito	18 sectores, entidades esenciales e importantes	Cualquier sector donde se despliegue IA de alto riesgo
Requisitos de ciberseguridad	Medidas técnicas y organizativas apropiadas	Art. 15: precisión, robustez, ciberseguridad del sistema IA
Notificación de incidentes	24h alerta + 72h notificación + 1 mes informe	Incidentes graves que afecten derechos fundamentales
Supervisión humana	No específico	Requisito explícito (Art. 14)
Sanciones	10M EUR / 2% (esenciales)	35M EUR / 7% (prohibiciones)

Para una organización que opera un SOC automatizado con IA en el sector energético (cubierto por NIS2), las obligaciones se acumulan: debe cumplir NIS2 para la ciberseguridad general de su red y AI Act para el sistema de IA que automatiza la detección y respuesta.

El AI Act establece en su Artículo 2(7) que, cuando un sistema de IA se utilice como componente de seguridad de un producto cubierto por legislación sectorial de la UE, se aplican ambos marcos simultáneamente.

Modelos de IA de propósito general (GPAI)

El AI Act introduce una categoría específica para los modelos de propósito general (General-Purpose AI, GPAI), como GPT-4, Claude, Gemini, Llama o Mistral. Estos modelos no tienen una finalidad específica predeterminada, lo que los sitúa fuera de la clasificación de riesgo estándar.

Obligaciones para todos los proveedores GPAI

• Elaborar y mantener actualizada la documentación técnica del modelo.
• Proporcionar información y documentación a los proveedores de sistemas de IA que integren el modelo.
• Establecer una política de cumplimiento de derechos de autor.
• Publicar un resumen detallado del contenido utilizado para el entrenamiento.

Obligaciones adicionales para GPAI con riesgo sistémico

Un modelo GPAI se considera de riesgo sistémico cuando su capacidad de cómputo acumulada de entrenamiento supera los 10^25 FLOPS, o cuando la Comisión lo designa así por sus capacidades de alto impacto. Las obligaciones adicionales incluyen:

• Realizar evaluaciones del modelo, incluyendo pruebas adversariales.
• Evaluar y mitigar posibles riesgos sistémicos.
• Documentar e informar de incidentes graves a la AI Office.
• Garantizar un nivel adecuado de ciberseguridad del modelo.

Para la comunidad de ciberseguridad, esto tiene una implicación directa: los proveedores de modelos foundation deben demostrar que sus modelos son resistentes a jailbreaks, prompt injection y otros ataques que permitan generar contenido peligroso (instrucciones para crear malware, exploits funcionales, etc.).

Implicaciones para vendors de ciberseguridad

Los fabricantes de productos de ciberseguridad que integran IA deben prepararse para varios escenarios:

Productos que incorporan ML/IA para detección

Si el producto se despliega en infraestructuras críticas cubiertas por el Anexo I (energía, transporte, salud, agua), el componente de IA se clasifica como alto riesgo. Esto implica documentación técnica completa, evaluación de conformidad y marcado CE para el componente IA.

MSSPs y SOC-as-a-Service

Los proveedores de servicios gestionados de seguridad que utilizan IA para triaje automático de alertas o respuesta automatizada deben evaluar si sus clientes operan en sectores de alto riesgo. Si un MSSP sirve a una empresa energética, el sistema de IA que gestiona sus alertas podría clasificarse como alto riesgo por extensión.

Herramientas de threat intelligence con IA

Los productos de CTI que utilizan IA para correlación automática, atribución de campañas o predicción de amenazas generalmente caen en riesgo mínimo o limitado. Sin embargo, si esas predicciones alimentan directamente sistemas de decisión automatizada en infraestructuras críticas, el contexto de despliegue puede elevar la clasificación.

Recomendaciones prácticas para vendors

1. Auditar la cartera de productos para identificar cuáles incorporan componentes de IA/ML.
2. Mapear los sectores de despliegue de cada producto para determinar si algún cliente opera en alto riesgo.
3. Documentar datasets de entrenamiento, métricas de rendimiento y procesos de validación.
4. Implementar pruebas adversariales como parte del ciclo de desarrollo.
5. Preparar la documentación técnica conforme al Anexo IV del Reglamento.
6. Designar un responsable de cumplimiento del AI Act dentro de la organización.

Recursos y referencias

Fuentes oficiales

• Reglamento (UE) 2024/1689 (texto completo): Diario Oficial de la UE, 12 de julio de 2024.
• AI Act Explorer: navegador interactivo del texto legal con búsqueda por artículo.
• European AI Office: oficina de la Comisión encargada de la implementación.
• AESIA: Agencia Española de Supervisión de la Inteligencia Artificial.

Guías de implementación

• NIST AI Risk Management Framework: marco complementario de gestión de riesgos IA.
• ENISA AI Cybersecurity: informes de ENISA sobre riesgos de ciberseguridad en IA.
• ISO/IEC 42001:2023: sistema de gestión de IA (complementario al AI Act).

Relación con otros marcos regulatorios

• RGPD (2016/679): Protección de datos personales. El AI Act lo complementa, no lo sustituye. Si un sistema de IA procesa datos personales, ambos se aplican.
• NIS2 (2022/2555): Ciberseguridad de redes y sistemas. Obligaciones acumulativas cuando la IA opera en sectores cubiertos.
• DORA (2022/2554): Resiliencia operativa digital del sector financiero. Los sistemas de IA en banca y seguros deben cumplir ambos.
• Directiva de Responsabilidad por IA (propuesta): Establece reglas civiles de responsabilidad por daños causados por IA. Pendiente de aprobación final.