El Plan de Acción de la UE sobre IA y Ciberseguridad: Cuando la regulación deja de ladrar y empieza a morder

La transición del papel a la trinchera operativa

Estamos a mediados de julio de 2026 y, si algo hemos aprendido en los últimos dos años, es que la Comisión Europea tiene una capacidad inagotable para generar acrónimos. Sin embargo, el nuevo Plan de Acción sobre Ciberseguridad e Inteligencia Artificial, presentado formalmente el pasado 7 de julio, marca un punto de inflexión. Ya no estamos ante una declaración de intenciones ética o un Libro Blanco sobre la bondad de los algoritmos. Lo que tenemos sobre la mesa es el manual de instrucciones para que la IA no se convierta en el talón de Aquiles de la infraestructura crítica europea.

Este plan no nace en el vacío. Surge en un momento en el que el Reglamento de Inteligencia Artificial (AI Act) ya ha superado su fase de gracia y las entidades financieras están sudando tinta para cumplir con los últimos hitos de DORA (Digital Operational Resilience Act). La ironía de la situación es deliciosa: mientras los departamentos de innovación de los bancos corren para integrar modelos de lenguaje de gran escala (LLM) que automaticen el servicio al cliente, los departamentos de riesgos y ciberseguridad están descubriendo que han metido un caballo de Troya en sus sistemas de información. El Plan de Acción de la Comisión es, en esencia, el intento de Bruselas de poner orden antes de que el primer incidente sistémico provocado por una IA mal asegurada obligue a cerrar el mercado de capitales un lunes por la mañana.

Tesis editorial: El fin de la soberanía del 'sandbox'

Durante años, la respuesta regulatoria a cualquier tecnología emergente ha sido el 'sandbox': un entorno controlado donde jugar sin romper nada. Mi tesis es que este Plan de Acción liquida esa era de experimentación ingenua. La Comisión ha entendido que la IA es, simultáneamente, el pirómano y el bombero. El plan desplaza el foco desde la gobernanza teórica hacia la resiliencia operativa real.

Lo que el regulador nos está diciendo ahora es que, si vas a usar IA en un sector crítico, la carga de la prueba sobre su seguridad recae íntegramente en ti, y que las herramientas de evaluación tradicionales (como los simples tests de penetración) son papel mojado ante ataques de adversarial machine learning o envenenamiento de datos (data poisoning). La creación de la Plataforma de Pruebas Seguras junto a ENISA no es una invitación, es el preludio de un estándar de certificación que pronto será obligatorio para cualquier proveedor de servicios TIC bajo el Artículo 28 de DORA.

El impacto regulatorio cruzado: DORA, NIS2 y el AI Act

Para entender la profundidad de este Plan de Acción, hay que dejar de mirar las normativas como silos estancos. En 2026, la interoperabilidad regulatoria es la única forma de supervivencia para un CISO o un Director de Compliance. El Plan de Acción actúa como el tejido conectivo entre tres grandes pilares:

1. DORA y la gestión de terceros (Art. 28 y 30)

Bajo DORA, las entidades financieras tienen la obligación de gestionar el riesgo de terceros ICT. Pero, ¿qué ocurre cuando el tercero es un modelo de IA de caja negra? El Plan de Acción refuerza la capacidad de evaluación de modelos antes de su comercialización. Esto significa que los bancos ya no podrán escudarse en que "el proveedor es un gigante tecnológico de EE.UU." para justificar la falta de transparencia. El plan exige que los modelos de IA de propósito general (GPAI) con riesgo sistémico pasen por el tamiz de la Oficina de IA de la UE, proporcionando a las entidades financieras una base de evidencias técnicas que antes simplemente no existía.

2. NIS2 y la gestión de vulnerabilidades (Art. 21)

La Directiva NIS2 obliga a las entidades esenciales e importantes a adoptar medidas de gestión de riesgos de ciberseguridad. El Plan de Acción introduce aquí el uso de la IA para la detección automatizada de vulnerabilidades. Es un arma de doble filo: el plan fomenta el uso de modelos open-source para que las empresas detecten sus propios fallos antes que los atacantes. Sin embargo, también reconoce que los actores maliciosos están usando esas mismas herramientas para automatizar el descubrimiento de zero-days a una escala que el ojo humano no puede procesar. El Artículo 21 de NIS2 ahora debe leerse bajo el prisma de la "velocidad algorítmica".

3. El Cyber Resilience Act (CRA) y el software con IA

El Plan de Acción se apoya en el CRA para asegurar que cualquier producto con elementos digitales que incorpore IA tenga un ciclo de vida de seguridad garantizado. Esto afecta directamente a la cadena de suministro de software (SBOM), donde la procedencia de los datos de entrenamiento de la IA se convierte en un requisito de cumplimiento tan crítico como el propio código fuente.

La paradoja de la IA soberana y el 'Grand Challenge'

Uno de los puntos más ambiciosos del plan es el lanzamiento del EU Grand Challenge on AI for Cybersecurity. Bruselas quiere que Europa deje de ser un mero consumidor de seguridad estadounidense o israelí. La inversión en AI Factories y futuras Gigafactories no es solo política industrial; es una estrategia de defensa nacional.

Sin embargo, aquí es donde entra mi escepticismo profesional. La soberanía tecnológica no se decreta, se construye con capital y talento. Mientras la Comisión anuncia desafíos y plataformas de pruebas, el sector privado europeo sigue lidiando con una fragmentación que dificulta la creación de modelos de IA defensivos que puedan competir con los de OpenAI o Anthropic. El éxito de este Plan de Acción no se medirá por cuántas empresas participen en el desafío, sino por si logramos que un CISO de un banco del IBEX 35 confíe más en una herramienta de detección de anomalías nacida en una AI Factory de Lyon que en una solución de Palo Alto.

Implicaciones para entidades financieras españolas

Para la banca y los seguros en España, este plan aterriza en un terreno ya abonado por la supervisión estricta del Banco de España y la CNMV. Las implicaciones operativas son inmediatas:

• Revisión de contratos de outsourcing: Las entidades deben empezar a incluir cláusulas específicas sobre la transparencia de los datos de entrenamiento y la protección contra ataques adversarios, alineándose con el futuro "European Blueprint" mencionado en el plan.
• Pruebas de resiliencia (TLPT): Bajo el marco de DORA, los ejercicios de Threat-Led Penetration Testing deberán evolucionar para incluir escenarios donde la IA de la propia entidad sea el vector de ataque o el objetivo de la manipulación.
• Gobernanza de la IA: Ya no basta con un comité de ética. Se requiere una integración técnica entre el equipo de Ciencia de Datos y el SOC (Security Operations Center).

Checklist de evidencias para auditoría en la era de la IA

Si usted es un responsable de cumplimiento, su próxima auditoría no preguntará si tiene una política de IA, sino qué evidencias técnicas puede mostrar. Basándonos en el Plan de Acción y las normativas cruzadas, estas son las pruebas que debería estar preparando:

• Registro de Algoritmos: Inventario detallado de todos los sistemas de IA en uso, clasificados por nivel de riesgo según el AI Act y criticidad según DORA.
• Informes de Red Teaming específicos para IA: Resultados de pruebas de estrés diseñadas para engañar a los modelos de detección de fraude o de scoring crediticio.
• Certificaciones de Proveedores: Evidencia de que sus proveedores de IA cumplen con el Cyber Resilience Act y han pasado por las evaluaciones de la Oficina de IA de la UE.
• Protocolo de Respuesta a Incidentes IA: Una actualización de su plan de continuidad de negocio que contemple qué hacer si su IA empieza a tomar decisiones alucinatorias o sesgadas masivamente debido a un ataque externo.

Conclusión: La seguridad no es un anexo, es el producto

El Plan de Acción de la Comisión Europea para 2026 nos deja una lección clara: la Inteligencia Artificial sin ciberseguridad no es innovación, es negligencia. Para los que llevamos años cubriendo la regulación financiera, este movimiento es la confirmación de que el regulador ha perdido el miedo a la tecnología y ha empezado a entender sus tripas.

No se deje engañar por el lenguaje diplomático del documento. Detrás de cada mención a la "colaboración" y el "apoyo", hay una exigencia implícita de transparencia y control. En el mundo post-DORA y post-AI Act, la capacidad de una entidad para demostrar que su IA es resiliente será su mayor ventaja competitiva. O, al menos, la única forma de evitar que el regulador le apague los servidores.

El laberinto de las competencias cruzadas: DORA frente al AI Act

La gran ficción de 2025 fue creer que el cumplimiento de la IA y la ciberseguridad financiera corrían por carriles separados. En este julio de 2026, la realidad es más cruda: el solapamiento regulatorio es una trampa para los incautos. El vínculo crítico reside en el DORA art. 6, que obliga a las entidades a mantener un marco de gestión de riesgos TIC de hierro. Si tu entidad utiliza modelos de IA para el scoring de crédito o la detección de fraude, esos sistemas ya no son solo 'proyectos de innovación'; son activos TIC críticos.

Aquí es donde el AI Act art. 15 entra a morder. Este artículo exige que los sistemas de IA de alto riesgo demuestren una resiliencia adecuada contra intentos de terceros de alterar su uso o rendimiento mediante la explotación de vulnerabilidades. No basta con un firewall. El regulador exige ahora pruebas de resistencia específicas contra el adversarial machine learning. Si el modelo de IA de un banco es engañado para autorizar transferencias fraudulentas, la sanción no vendrá solo por el fallo de seguridad, sino por la incapacidad de demostrar que se cumplió con los requisitos de robustez y precisión que el AI Act impone a los sistemas de alto riesgo. La interoperabilidad de sanciones entre la autoridad financiera y la oficina de IA es, desde enero de este año, una realidad operativa.

Impacto sectorial: El fin de la complacencia en infraestructuras críticas

El impacto de este Plan de Acción no es uniforme, y el sector de la energía y el transporte está descubriendo que NIS2 art. 21 es mucho más que una lista de deseos. Mientras que en 2024 muchos veían la ciberseguridad como un coste operativo, en 2026 se ha convertido en una condición de licencia. Las entidades financieras, bajo el paraguas de DORA, ya han pasado por el aro, pero las fintech de mediano tamaño están sufriendo para mapear sus dependencias de terceros según el DORA art. 28.

Para las aseguradoras, el desafío es el 'cyber silencioso' potenciado por IA. El Plan de Acción de la UE obliga ahora a una transparencia que choca frontalmente con el secreto comercial. Bajo la CSRD art. 1 (en sus disposiciones sobre reporte de riesgos digitales), las empresas deben desglosar cómo su dependencia de la IA afecta a su resiliencia a largo plazo. Esto ha provocado un ajuste en las primas de seguros de ciberriesgo de hasta un 30% para aquellas empresas que no pueden certificar que sus modelos de IA han sido auditados bajo el marco del Cybersecurity Act art. 46, que define los esquemas europeos de certificación de ciberseguridad. El mercado ya no se cree las promesas; exige el sello de ENISA.

Escenario operativo: Respuesta ante un envenenamiento de datos

¿Cómo responde un equipo de compliance hoy, 15 de julio de 2026, ante la sospecha de un ataque de data poisoning en su modelo de detección de blanqueo de capitales? El procedimiento ya no es discrecional. Primero, se activa el protocolo de notificación de incidentes graves bajo DORA art. 19, cumpliendo con los plazos de 24 horas para el informe inicial. La novedad este año es que, si el incidente afecta a los datos de entrenamiento, también se dispara automáticamente la obligación del GDPR art. 33 si existe riesgo para los derechos de los interesados.

Pasos críticos en la trinchera:

• Aislamiento y Triage: Desconexión del modelo afectado y activación del sistema de respaldo no basado en IA (si existe) o retorno a reglas heurísticas tradicionales, según el plan de continuidad de negocio exigido por NIST CSF 2.0 GV.RM.
• Auditoría de Linaje: Rastreo del origen de los datos contaminados. Aquí, el registro de logs exigido por el AI Act art. 12 es la única prueba válida ante el regulador para demostrar que no hubo negligencia en la custodia de la cadena de suministro de datos.
• Recertificación: Antes de volver a producción, el modelo debe pasar un test de estrés que valide que el sesgo introducido por el ataque ha sido erradicado, documentando cada paso para la futura inspección de la autoridad nacional competente.

La cadena de suministro: El martillo del Cyber Resilience Act

El Plan de Acción ha puesto el foco en lo que yo llamo 'la zona oscura': los proveedores de software de IA que operan desde fuera de la UE. El Cyber Resilience Act (CRA) art. 13 ha dejado de ser una amenaza lejana para convertirse en un muro infranqueable. Desde principios de 2026, cualquier producto con elementos digitales —incluyendo modelos de IA pre-entrenados— debe llevar el marcado CE de ciberseguridad si quiere venderse en el mercado único.

Esto ha forzado a los CISO a realizar un inventario brutal. Ya no basta con saber qué software usas; necesitas la Software Bill of Materials (SBOM) completa. Si tu proveedor de IA no puede certificar que cumple con el CRA art. 10 (obligaciones de diligencia debida en la gestión de vulnerabilidades), tu entidad está asumiendo un riesgo legal directo bajo DORA. Además, con la plena entrada en vigor de eIDAS 2.0 art. 1, la identidad digital de los agentes que interactúan con estos sistemas debe ser verificable. Ya no hay excusas para el anonimato en la gestión de infraestructuras críticas: o el sistema es trazable y seguro por diseño, o es ilegal. La era de 'moverse rápido y romper cosas' ha sido sustituida por la era de 'moverse con cautela y documentar hasta el último bit'.