La Comisión Europea publicó el 7 de julio de 2026 el Plan de Acción sobre Ciberseguridad e Inteligencia Artificial, identificado como COM(2026) 577 final. La noticia se ha resumido casi siempre como un programa europeo para "usar IA contra los ciberataques". La descripción no es falsa, pero se queda en la superficie. El documento hace algo bastante más concreto: define cómo pretende Europa reorganizar la evaluación de modelos avanzados, el acceso a capacidades de IA con potencial ofensivo, las pruebas en entornos controlados, la gestión de vulnerabilidades, la seguridad del software de código abierto y la formación de los profesionales que tendrán que operar todo eso.
Conviene aclarar desde el principio qué no es. El plan no es una ley, ni un reglamento, ni una directiva. Es una Comunicación de la Comisión: un instrumento de política pública que fija prioridades, responsables y actuaciones. Ninguna empresa española va a ser sancionada por "incumplir el plan". Las obligaciones vinculantes siguen viniendo del Reglamento de Inteligencia Artificial, de NIS2, de DORA, del Cyber Resilience Act, del RGPD y de la normativa sectorial que corresponda.
Su importancia está en otro sitio. El plan expone cómo la Comisión, la Oficina Europea de IA, ENISA, el Joint Research Centre y el European Cybersecurity Competence Centre quieren aplicar ese marco ante una hipótesis operativa muy concreta: que los modelos más avanzados acaben comprimiendo el ciclo completo de ataque —reconocimiento, descubrimiento de la vulnerabilidad, explotación, movimiento lateral y exfiltración— hasta un ritmo que las estructuras de decisión actuales no pueden seguir.
Si hay que quedarse con una idea, es esta: el plan no obliga a comprar herramientas de IA, obliga a replantear el modelo operativo. La prioridad se desplaza de detectar más hallazgos a verificar, decidir y remediar más deprisa; de probar modelos en producción a evaluarlos en entornos controlados; y de confiar en un proveedor de IA a exigirle que demuestre capacidades, límites, continuidad, trazabilidad y control humano.
Qué naturaleza jurídica tiene el plan y por qué conviene distinguirla
En la Unión Europea conviven instrumentos con efectos muy distintos. Un reglamento, como el AI Act o DORA, es directamente aplicable. Una directiva, como NIS2, obliga a los Estados miembros a alcanzar determinados resultados mediante su transposición nacional. Una Comunicación de la Comisión expresa una estrategia, interpreta prioridades y anuncia actuaciones, pero no impone por sí misma obligaciones equivalentes a las de un reglamento. El Plan de Acción pertenece a esta tercera categoría.
La distinción evita dos errores opuestos, y ambos se están cometiendo estas semanas. El primero es presentarlo como una norma nueva y generar una urgencia de cumplimiento que no existe. El segundo, más caro a medio plazo, es tratarlo como un documento sin consecuencias: el plan determina dónde se van a concentrar capacidades, guías, evaluaciones, financiación y coordinación europea, y revela qué prácticas considera la Comisión necesarias para aplicar correctamente obligaciones que sí son vinculantes.
La lectura razonable es que se trata de política de ejecución alrededor de un núcleo normativo ya vigente. Funciona como puente entre el AI Act y la operación diaria de ciberseguridad. Merece la pena tener presente el reparto de piezas:
- Plan de Acción COM(2026) 577. Política y coordinación. Aporta nueve actuaciones europeas con responsables y, en la mayoría de los casos, plazos.
- AI Act, Reglamento (UE) 2024/1689. Obligación legal directa. Requisitos para sistemas de IA y para modelos de propósito general, incluido el régimen de riesgo sistémico.
- NIS2, Directiva (UE) 2022/2555. Obligación mediante transposición. Gestión de riesgos, incidentes, vulnerabilidades y cadena de suministro en entidades esenciales e importantes.
- DORA, Reglamento (UE) 2022/2554. Obligación legal directa en el sector financiero. Resiliencia operativa, pruebas, incidentes y terceros proveedores de servicios TIC.
- Cyber Resilience Act, Reglamento (UE) 2024/2847. Obligación legal directa para productos con elementos digitales. Seguridad desde el diseño y gestión de vulnerabilidades durante toda la vida del producto.
- Cyber Solidarity Act. Capacidad operativa europea de preparación, detección y apoyo ante incidentes significativos o a gran escala.
El plan debe leerse junto al texto oficial de la Comisión, no como sustituto de esas normas.
«Frontier AI» no es lo mismo que sistema de alto riesgo ni que GPAI con riesgo sistémico
Otro punto que exige precisión es el vocabulario, porque se está usando de forma intercambiable en la cobertura y no lo es. El plan emplea la expresión frontier AI para describir los modelos más avanzados disponibles o en desarrollo, capaces de ejecutar una variedad amplia de tareas y de acercarse, alcanzar o superar el estado del arte. Toma esa definición de trabajo de la propuesta del Cloud and AI Development Act.
No es una categoría jurídica autónoma del AI Act. El Reglamento maneja otras tres:
- Sistema de IA de alto riesgo. Clasificación ligada al uso y al contexto: determinados sistemas en biometría, empleo, educación, infraestructuras críticas o productos regulados.
- Modelo de IA de propósito general (GPAI). Modelo capaz de realizar de forma competente una amplia variedad de tareas y de integrarse en numerosos sistemas.
- GPAI con riesgo sistémico. Modelo de propósito general con capacidades de alto impacto, o designado por la Comisión atendiendo a sus capacidades y efectos previsibles.
La diferencia tiene consecuencias prácticas. Un modelo puede ser técnicamente de frontera sin que esa etiqueta determine por sí sola su régimen jurídico. Y, al revés, una aplicación empresarial puede ser de alto riesgo por su finalidad aunque funcione sobre un modelo que no esté en la frontera tecnológica.
Las directrices de la Comisión utilizan un umbral indicativo de 10²³ operaciones de coma flotante de entrenamiento para identificar determinados modelos de propósito general que generan lenguaje, imagen o vídeo. El AI Act presume riesgo sistémico cuando el entrenamiento supera 10²⁵ operaciones, si bien ese umbral está sujeto a revisión y la Comisión puede designar un modelo por sus capacidades aunque no lo alcance, según su propia documentación sobre obligaciones de GPAI.
Para los proveedores de GPAI con riesgo sistémico, el artículo 55 del AI Act exige, entre otras medidas, evaluar el modelo mediante protocolos y herramientas normalizados —incluidas pruebas adversarias—, identificar y mitigar riesgos sistémicos, registrar y comunicar incidentes graves, garantizar un nivel adecuado de ciberseguridad para el modelo y su infraestructura, y mantener evidencias que permitan la supervisión de la Oficina Europea de IA.
Las obligaciones de GPAI empezaron a aplicarse el 2 de agosto de 2025. Desde el 2 de agosto de 2026 la Comisión anuncia aplicación plena y disponibilidad de sus poderes de ejecución, con multas para proveedores de GPAI de hasta el 3 % de la facturación mundial anual. Los modelos puestos en el mercado antes del 2 de agosto de 2025 disponen, con carácter general, hasta el 2 de agosto de 2027 para adaptarse, según el marco de gobernanza publicado por la Comisión.
Determinar si una organización actúa como proveedor, integrador o simple desplegador no se resuelve mirando el contrato del modelo. Importa quién lo desarrolla, quién lo modifica de forma sustancial, bajo qué nombre se comercializa y cómo llega al mercado. Un ajuste menor no convierte automáticamente a una empresa en proveedora de GPAI, pero una modificación sustancial o una comercialización bajo marca propia sí pueden cambiar el análisis.
Por qué la Comisión considera que el modelo defensivo actual se queda corto
El plan parte de una asimetría concreta: la IA puede acelerar el descubrimiento y la explotación de vulnerabilidades más deprisa de lo que una organización tarda en verificar, aprobar y desplegar la corrección. No es una intuición, es una observación sobre el ritmo de mejora de las capacidades.
El AI Security Institute británico estimó en febrero de 2026 que el horizonte de tareas cibernéticas que los modelos podían completar con un 80 % de fiabilidad se había duplicado aproximadamente cada 4,7 meses desde la aparición de los modelos de razonamiento a finales de 2024. El dato relevante no es solo la cifra, sino su deriva: la estimación anterior del propio instituto, de noviembre de 2025, situaba ese periodo en unos 8 meses. La medición se aceleró entre una revisión y la siguiente, y modelos posteriores han superado incluso esa tendencia, según el análisis publicado por el instituto. El propio AISI subraya que la métrica es imperfecta y no constituye una predicción lineal. Aun así, explica bien por qué la Comisión no quiere esperar a que esas capacidades se generalicen.
ENISA publicó el mismo 7 de julio su informe Cybersecurity in the Frontier AI Era. Su análisis es bastante más incómodo que el mensaje institucional resumido, y merece leerse entero. Identifica siete problemas estructurales.
La asimetría de velocidad y el «authority gap»
La barrera ya no es únicamente técnica. Incluso cuando una organización identifica correctamente un riesgo, sus comités de cambio, responsables de servicio y ventanas de mantenimiento pueden necesitar días para autorizar una intervención. Un atacante automatizado no está sujeto a ese proceso.
ENISA llama authority gap a esa incapacidad de aprobar una acción defensiva dentro del tiempo disponible: no falta capacidad técnica, falta autoridad ejecutable a tiempo. La organización tendrá que decidir cuándo una corrección automatizada supone menos riesgo que mantener una exposición con alta probabilidad de explotación. Eso no equivale a activar el parcheo automático indiscriminado, sino a definir de antemano qué activos, cambios y condiciones admiten una decisión automatizada, cuáles exigen validación humana y cómo se revierte una intervención defectuosa.
La devaluación económica del descubrimiento
Encontrar vulnerabilidades va a ser más barato. El valor escaso se desplaza hacia la validación, la priorización y la remediación.
ENISA recoge un caso compartido por la industria: una organización pasó de unas 80 CVE en el primer trimestre de 2025 a cerca de 500 en el mismo trimestre de 2026 y, al incorporar herramientas de frontier AI, llegó a recibir en torno a 500 hallazgos diarios. No significa que todos fueran explotables, ni que cualquier organización vaya a ver ese volumen. Lo que demuestra es que un proceso diseñado para cientos de informes al año colapsa cuando el coste marginal de producir un hallazgo tiende a cero. El CERT-EU ha desarrollado esta misma idea al analizar cómo cambia la economía del descubrimiento de vulnerabilidades.
La deuda técnica como riesgo de primer orden
La IA facilita analizar código antiguo, reconstruir lógica y localizar combinaciones de debilidades. Los sistemas heredados y fuera de soporte acumulan así una exposición creciente frente a un análisis que antes era caro y ahora no lo es.
La respuesta no puede reducirse a parchear más rápido cuando el fabricante ya no publica parches. Segmentación, bastionado, aislamiento, monitorización reforzada, controles compensatorios y retirada planificada pasan a formar parte de la misma estrategia.
El cuello de botella de la verificación
Un parche generado por IA no es una corrección fiable por definición. Debe compilar, superar pruebas, preservar la funcionalidad, no introducir vulnerabilidades nuevas y funcionar en configuraciones reales.
La paradoja es que la misma IA que acelera el descubrimiento puede trasladar el cuello de botella a la validación humana. También obliga a revisar una práctica muy extendida: descartar sistemáticamente las vulnerabilidades de baja severidad. Varias debilidades menores pueden encadenarse y formar una ruta de explotación crítica que ningún análisis aislado detecta.
La conversión en arma de las vulnerabilidades N-day
La publicación de un parche informa al defensor, pero también entrega al atacante el material necesario para comparar versiones, analizar diferencias y reconstruir la vulnerabilidad corregida.
De ahí una consecuencia que conviene interiorizar: la ventana de exposición no termina cuando el fabricante publica la actualización. Termina cuando la organización ha desplegado la corrección o un control compensatorio eficaz en todos los activos afectados y ha verificado el cierre.
La saturación de los canales de divulgación
Los mantenedores de proyectos de código abierto y las plataformas de divulgación ya están recibiendo grandes volúmenes de informes generados o asistidos por IA. El problema no es solo el ruido: si la calidad de los hallazgos mejora, el volumen de vulnerabilidades reales puede superar igualmente la capacidad de revisión.
La política de divulgación coordinada tendrá que incorporar requisitos de reproducibilidad, evidencia, deduplicación, priorización y límites de envío. Sin ellos, un canal diseñado para mejorar la seguridad puede acabar funcionando como una denegación de servicio contra el mantenedor.
Los ataques desde dentro del perímetro de confianza
Un componente de código abierto comprometido, una actualización firmada pero maliciosa o una herramienta de seguridad alterada pueden introducir al atacante dentro del perímetro de confianza sin atravesar ninguna frontera vigilada.
El modelo defensivo debe asumir que una dependencia legítima puede ser el vector inicial. Eso refuerza la necesidad de telemetría interna, segmentación, mínimos privilegios, inventario de dependencias y detección basada en comportamiento, no solo en firmas o indicadores conocidos.
Las nueve actuaciones: qué va a hacer realmente Europa y cuándo
El plan no se queda en principios. Asigna nueve actuaciones con organismos responsables y, en la mayoría de los casos, plazos. Agrupadas por pilar, quedan así.
Uso seguro de la IA avanzada
- Capacidad europea de evaluación de modelos, a cargo de la Comisión y la Oficina Europea de IA, prevista para 2027. Evaluación independiente de capacidades y mitigaciones, con foco en ciberseguridad.
- Blueprint de acceso estructurado a IA avanzada, Comisión y ENISA, cuarto trimestre de 2026. Criterios para que organizaciones europeas autorizadas accedan a capacidades cibernéticas avanzadas.
- Plataforma segura de pruebas, ENISA y Joint Research Centre, cuarto trimestre de 2026. Pruebas de IA en cyber ranges y entornos simulados sin exponer infraestructura real.
- Guías sobre amenazas y uso seguro de IA, ENISA y organismos europeos, desde el tercer trimestre de 2026.
Resiliencia cibernética europea
- Gestión de vulnerabilidades adaptada a la era de la IA, Comisión, Estados miembros, ENISA e industria, desde el tercer trimestre de 2026. Evolución de la base de datos europea de vulnerabilidades, de la divulgación coordinada y de las herramientas de priorización.
- Campaña de resiliencia del código abierto crítico, ENISA, Comisión, comunidades e industria, con piloto en el cuarto trimestre de 2026.
Capacidad industrial y talento
- Grand Challenge de remediación asistida por IA, Comisión, European Cybersecurity Competence Centre y ENISA, cuarto trimestre de 2026.
- Acceso a capacidad de las AI Factories, Comisión y Estados miembros, sin fecha cerrada.
- Formación de profesionales de ciberseguridad, Comisión, Estados miembros e industria, cuarto trimestre de 2026.
La Comisión ha identificado además unos 200 millones de euros ya previstos en Horizonte Europa y Europa Digital para tecnologías avanzadas de IA aplicada a ciberseguridad antes del final del actual marco financiero plurianual, según el anuncio oficial del plan. Es una cifra que conviene tener presente para calibrar expectativas: es financiación relevante para investigación y capacidades europeas, no un fondo al que las empresas vayan a acceder para comprar herramientas.
Evaluar, acceder y probar no son la misma actividad
El primer pilar separa tres funciones que muchas organizaciones tratan como si fueran una sola, con consecuencias previsibles cuando llega una auditoría.
La evaluación del modelo responde a qué capacidades y riesgos sistémicos tiene y si sus mitigaciones funcionan. La realizan el proveedor, evaluadores independientes y la Oficina Europea de IA, y produce un informe de capacidades, riesgo y mitigación.
La prueba operativa responde a si ese modelo sirve para un caso concreto de detección, triaje, inteligencia de amenazas o respuesta sin crear riesgos inaceptables. La realizan el usuario y, en el marco europeo, ENISA, el JRC y el operador del cyber range. Produce evidencia de idoneidad y de límites en un entorno realista.
La evaluación de conformidad responde a si un sistema de alto riesgo cumple los requisitos jurídicos aplicables antes de comercializarse o ponerse en servicio. La realizan el proveedor y, cuando procede, un organismo notificado, y produce una declaración o certificación.
La futura capacidad europea de evaluación anunciada para 2027 no será un organismo de evaluación de conformidad. Su función será apoyar la evaluación independiente de modelos avanzados, producir señales tempranas de riesgo y aportar capacidad técnica a la Oficina Europea de IA. Confundir ambas funciones lleva a dos errores caros: usar un informe de seguridad como si fuera una conformidad legal, o tratar un marcado regulatorio como si garantizase resistencia operativa frente a ataques.
El Blueprint europeo de acceso estructurado
Los proveedores más avanzados pueden limitar el acceso a capacidades cibernéticas sensibles mediante programas privados. El plan reconoce que esa decisión puede estar justificada por seguridad, pero también que los criterios suelen ser poco transparentes y dependen de empresas no europeas.
El Blueprint previsto para el cuarto trimestre de 2026 deberá definir qué tipos de organizaciones pueden solicitar acceso —autoridades, infraestructuras críticas, proveedores de ciberseguridad e investigadores—, cómo se verifica la identidad y legitimidad del solicitante, qué condiciones de seguridad reducen el riesgo de abuso, cómo se comparte conocimiento entre organizaciones autorizadas, cómo se informa de programas de acceso planificados y qué medidas de contingencia se aplican si el proveedor o un tercer país restringe o retira el acceso.
No impondrá obligaciones nuevas a los proveedores: será una referencia voluntaria y una base para la cooperación internacional. Pero introduce una cuestión de continuidad que conviene llevar a los contratos ya: qué ocurre con la capacidad defensiva si el modelo deja de estar disponible. Una herramienta integrada en el SOC o en el proceso de remediación no puede tener como único plan de continuidad esperar a que vuelva la interfaz de programación.
La plataforma de pruebas de ENISA y el JRC
La plataforma prevista para finales de 2026 permitirá probar modelos en casos de uso como análisis de vulnerabilidades, remediación y respuesta a incidentes. El diseño descrito por la Comisión incluye limitaciones que definen bien su alcance: los participantes usarán sus propias credenciales de acceso al modelo y asumirán sus costes, las pruebas se regirán por reglas compartidas de seguridad y confidencialidad, cada participante conservará la responsabilidad sobre sus métodos, ENISA y el JRC gobernarán el acceso y agregarán resultados, y se reutilizarán cyber ranges existentes en lugar de construir capacidad nueva donde ya la hay.
No se pretende certificar modelos ni comprobar su conformidad con el AI Act. Se pretende saber si una capacidad funciona de forma segura en condiciones realistas.
Para una empresa, el equivalente mínimo es disponer de un entorno donde poder medir tasa de detección y falsos positivos, acciones incorrectas o fuera de alcance, resistencia a inyección de prompt, envenenamiento de datos y manipulación de herramientas, fuentes utilizadas y nivel de confianza, trazabilidad de cada recomendación, capacidad de reversión, comportamiento ante datos incompletos, dependencia del proveedor y degradación segura, y consumo, latencia y coste por incidente.
Si un agente puede aislar equipos, revocar credenciales o modificar reglas, el listado anterior se queda corto. Una auditoría de seguridad de agentes de IA y MCP debe revisar además identidad, autorización por herramienta, límites transaccionales, secretos, memoria, registro y separación entre instrucciones confiables y contenido no confiable.
La gestión de vulnerabilidades deja de ser un proceso y pasa a ser un sistema de decisión
El segundo pilar es el más relevante para la mayoría de empresas. La Comisión no dice que falten escáneres. Dice que el problema es convertir un volumen creciente de hallazgos en correcciones efectivamente desplegadas.
El cambio se entiende mejor fase por fase, comparando el modelo tradicional con el que exige este escenario.
- Descubrimiento. De escaneos periódicos a cobertura continua de activos y dependencias. La evidencia mínima es un inventario con SBOM y una medida real de cobertura.
- Validación. De la revisión manual por orden de llegada a la deduplicación, reproducción y validación asistida. La evidencia es técnica y con estado de validación explícito.
- Priorización. Del CVSS aislado a la combinación de exposición real, catálogo de vulnerabilidades explotadas, probabilidad de explotación, información VEX, criticidad del activo y controles existentes. Cada prioridad debe tener motivo y propietario.
- Decisión. Del comité de cambio genérico a una autoridad predefinida por nivel de riesgo y tipo de activo, con matriz de autorización y de excepción.
- Remediación. De la ventana de parche estándar a un abanico que incluye parche, mitigación, aislamiento o retirada, siempre con cambio aprobado y trazable.
- Verificación. Del ticket cerrado al desplegar al reescaneo, la prueba y la monitorización, con evidencia de cierre efectivo.
- Aprendizaje. Del informe trimestral a métricas que ajusten reglas, con tendencias, fallos y acciones derivadas.
Bases de datos, divulgación coordinada y la plataforma del CRA
El plan pide adaptar la base de datos europea de vulnerabilidades y la futura plataforma única de notificación del Cyber Resilience Act a un volumen mayor de descubrimientos asistidos por IA. También propone revisar las políticas nacionales de divulgación coordinada y comprobar si los estándares ISO/IEC que las sustentan siguen siendo adecuados.
No es una cuestión administrativa. Si distintas bases describen el mismo defecto con datos incompatibles, la automatización multiplica los errores en lugar de reducirlos. Para priorizar a velocidad de máquina hacen falta identificadores estables, relaciones entre productos y versiones, explotabilidad, mitigaciones y estados de parcheo procesables por máquina.
VEX adquiere aquí un papel que a menudo se subestima. Un SBOM indica que un componente está presente; VEX permite expresar si una vulnerabilidad concreta afecta realmente al producto en ese contexto. Sin esa capa, un inventario completo genera una cantidad inmanejable de falsos positivos, y el equipo acaba ignorando la herramienta que acaba de implantar.
La campaña europea sobre código abierto crítico
La Comisión y ENISA quieren mapear los componentes de código abierto críticos para infraestructuras esenciales y lanzar una primera campaña de resiliencia a finales de 2026. El modelo propuesto no se limita a financiar auditorías: prevé identificar componentes cuya criticidad justifique una intervención, emparejar proyectos con patrocinadores públicos o privados, aportar especialistas, herramientas o modelos a los mantenedores, recurrir a proveedores de confianza de la Reserva Europea de Ciberseguridad, crear un catálogo de servicios de IA para análisis, parcheo y remediación, y trasladar los resultados al futuro instrumento europeo de mantenimiento de código abierto.
La idea responde a un fallo económico conocido: un componente mantenido por dos o tres personas en su tiempo libre puede sostener servicios de enorme valor sin que quienes dependen de él financien proporcionalmente su seguridad.
Ninguna empresa debería esperar a que Europa publique ese mapa. Se puede empezar con cuatro preguntas: qué componentes de código abierto ejecutan funciones críticas, qué versiones están fuera de soporte o dependen de un único mantenedor, cuánto se tarda en saber si una CVE nueva afecta a producción, y si existe capacidad de sustituir, aislar o mantener internamente el componente. Un programa de gestión de vulnerabilidades debería responderlas con activos, responsables y evidencias, no con un cuadro de mando de severidades.
Soberanía tecnológica, capacidad industrial y talento
El tercer pilar es el más estratégico y el menos inmediato. La Comisión reconoce que las capacidades de IA con mayor potencial cibernético se concentran en proveedores no europeos y que el acceso puede depender de decisiones privadas o de terceros países.
El Grand Challenge sobre remediación asistida
La Comisión, con el European Cybersecurity Competence Centre y ENISA, lanzará a finales de 2026 un desafío para desarrollar una solución que apoye todo el ciclo de remediación, no solo el descubrimiento.
El énfasis es deliberado y acertado. Europa no necesita otra demostración de que un modelo encuentra fallos: eso ya está resuelto. Necesita sistemas capaces de validar la vulnerabilidad, entender el contexto del activo, proponer una corrección o mitigación, generar pruebas, estimar el impacto operativo, facilitar el despliegue y verificar que el riesgo se ha reducido de verdad.
AI Factories y cómputo soberano
El plan propone facilitar el acceso a las AI Factories para probar, entrenar y desplegar modelos aplicados a la ciberresiliencia. Soberanía no significa que cada empresa deba entrenar su propio modelo; significa evitar que capacidades críticas dependan en exclusiva de infraestructura, datos y condiciones de acceso fuera de control europeo.
Para una empresa concreta la cuestión es menos geopolítica y más contractual: proveedor, región, portabilidad, continuidad, claves, registros, subencargados y capacidad real de sustitución.
Formación y competencias nuevas
La Comisión utilizará la Cybersecurity Skills Academy para crear módulos sobre IA aplicada a ciberseguridad, y ENISA actualizará el marco europeo de competencias en ciberseguridad.
No basta con enseñar a escribir prompts. Los perfiles tendrán que manejar evaluación de modelos y límites de los bancos de pruebas, seguridad de agentes y herramientas, datos, procedencia y envenenamiento, diseño de controles con validación humana obligatoria, modelado de amenazas de sistemas de IA, pruebas adversarias, evidencias regulatorias y continuidad ante dependencia de modelos.
El riesgo más serio no es que la IA sustituya al analista. Es que el analista acabe asumiendo responsabilidad sobre una acción que no puede explicar ni reconstruir.
Cómo encaja el plan con AI Act, NIS2, DORA y CRA
El plan no crea un quinto marco independiente. Intenta que los cuatro existentes produzcan una respuesta coherente en lugar de cuatro respuestas paralelas.
AI Act: seguridad del modelo y del sistema
Para GPAI con riesgo sistémico, el foco está en la evaluación de capacidades, el riesgo de uso malicioso, la comunicación de incidentes y la ciberseguridad del modelo y su infraestructura. Para los sistemas de alto riesgo, el marco incluye gestión de riesgos, gobernanza de datos, documentación técnica, registro de actividad, información al desplegador, supervisión humana, exactitud, robustez y ciberseguridad.
El calendario exige cuidado. El Consejo dio luz verde definitiva el 29 de junio de 2026 al Digital Omnibus de IA, que desplaza la aplicación de las reglas de alto riesgo al 2 de diciembre de 2027 para sistemas independientes del anexo III y al 2 de agosto de 2028 para sistemas integrados en productos regulados, según el comunicado del Consejo. Ese aplazamiento no elimina las obligaciones de GPAI ya aplicables, ni convierte la espera en una estrategia razonable: los plazos se han movido porque faltaban estándares técnicos armonizados y autoridades nacionales, no porque el riesgo haya disminuido.
NIS2: riesgo operativo y cadena de suministro
NIS2 exige medidas proporcionadas de gestión de riesgos para entidades esenciales e importantes: gestión de incidentes, continuidad, seguridad de la cadena de suministro, adquisición y desarrollo seguros, gestión y divulgación de vulnerabilidades, evaluación de eficacia, criptografía, control de acceso y autenticación.
La norma es tecnológicamente neutral, de modo que una amenaza acelerada por IA sigue siendo simplemente un riesgo que debe gestionarse. Lo que cambia es la evidencia de proporcionalidad: un acuerdo de nivel de servicio de parcheo que era defendible hace dos años puede dejar de serlo si la explotación se produce en horas.
La directiva impone además un modelo de notificación escalonada, con alerta temprana en 24 horas y notificación en 72 horas para incidentes significativos. ENISA señala que los flujos de respuesta deberán conservar revisión humana pero operar lo bastante rápido para cumplir esos plazos incluso cuando el volumen aumente.
DORA: resiliencia y terceros TIC en el sector financiero
DORA exige gobernar el riesgo TIC, clasificar funciones críticas, gestionar incidentes, probar resiliencia y controlar proveedores. Si una entidad financiera introduce un modelo en detección de fraude, SOC, desarrollo o atención al cliente, debe analizar a la vez la criticidad del servicio, los datos y secretos accesibles, la concentración y subcontratación, la continuidad ante retirada o caída del modelo, la localización y el tratamiento de la información, la capacidad de auditoría, las pruebas y la reversibilidad, y el impacto sobre el registro de terceros proveedores TIC.
Contratar una herramienta de IA no transfiere la responsabilidad de resiliencia al proveedor. Esa es probablemente la frase que más veces habrá que repetir en los próximos dos años.
Cyber Resilience Act: seguridad durante toda la vida del producto
El CRA será plenamente aplicable desde el 11 de diciembre de 2027 y obliga a los fabricantes de productos con elementos digitales a gestionar vulnerabilidades y seguridad durante toda la vida del producto.
El plan conecta el CRA con la nueva economía del descubrimiento: un fabricante deberá absorber más hallazgos, determinar su afectación, corregir, distribuir actualizaciones y comunicar activamente las vulnerabilidades explotadas y los incidentes graves. SBOM, VEX, seguridad desde el diseño y procesos de divulgación coordinada dejan de ser accesorios.
Una sola evidencia para varios marcos
La respuesta eficiente no es crear cuatro carpetas de cumplimiento, sino diseñar evidencias reutilizables. Hay ocho que sirven, con matices, a los cuatro marcos: el inventario de modelos, sistemas y finalidad; el registro de activos y dependencias; la evaluación de riesgos y amenazas; los registros y la trazabilidad de decisiones; las pruebas y sus resultados; la relación de proveedores, subproveedores y condiciones de salida; los incidentes y sus criterios de notificación; y la remediación con verificación de cierre.
La diferencia está en el propósito, el alcance y la autoridad que revisará cada una. Reutilizar no significa copiar sin contexto: la misma evidencia técnica puede servir a un auditor de ISO 27001 y a un supervisor financiero, pero no con la misma narrativa ni con el mismo nivel de detalle.
Qué significa el plan según el papel que juegue tu empresa
Proveedor de un GPAI. Debe determinar si el modelo entra en la definición de propósito general, si existe riesgo sistémico, qué documentación entregar a integradores y autoridades, y cómo gestiona derechos de autor, incidentes, evaluación y ciberseguridad.
Desarrollador o integrador. Necesita información suficiente sobre capacidades, límites, datos y condiciones de integración del modelo base, y debe documentar su propia capa: instrucciones de sistema, recuperación de contexto, herramientas, permisos, memoria, filtros, monitorización y uso previsto. La documentación del modelo base no es la documentación de su sistema.
Empresa desplegadora. Aunque no sea proveedora del modelo, debe gobernar finalidad, datos, usuarios, supervisión, proveedores, incidentes y controles. Si el sistema afecta a personas o a decisiones relevantes, habrá que analizar además RGPD, derechos fundamentales y normativa laboral o sectorial.
Entidad sujeta a NIS2 o DORA. Debe incorporar tanto los ataques acelerados por IA como los fallos de sus propias herramientas de IA al marco de riesgo operativo, y disponer de manuales de respuesta que coordinen seguridad, continuidad, asesoría jurídica, comunicación y notificación.
Fabricante sujeto al CRA. Debe integrar seguridad y gestión de vulnerabilidades en la vida del producto, mantener las dependencias y preparar canales de divulgación capaces de absorber informes asistidos por IA.
MSSP o SOC. Debe demostrar dónde interviene la IA, qué datos procesa, cómo reduce falsos positivos, qué decisiones puede ejecutar por sí sola, qué revisión humana existe y cómo se recupera el servicio si el modelo falla. Un SOC gestionado no debería presentar la IA como una caja negra que prioriza alertas: debería poder enseñar casos de uso, métricas, límites, registros y criterios de escalado.
La arquitectura de control que debería exigir un CISO
Antes de autorizar IA en operaciones de seguridad conviene exigir una arquitectura mínima, articulada en siete planos. No es una lista de buenas intenciones: cada plano se puede auditar.
- Identidad. Cada usuario, agente, servicio y herramienta debe tener identidad propia. Nada de credenciales genéricas compartidas ni claves con permisos globales.
- Autorización. El modelo puede recomendar una acción, pero la autorización debe residir en una política externa a él. Las herramientas deben aplicar mínimos privilegios y límites por operación, entorno y activo.
- Datos. Hay que clasificar prompts, contexto, documentos recuperados, telemetría, secretos y salidas, y definir retención, uso para entrenamiento, residencia y acceso del proveedor.
- Ejecución. Las acciones deben ser deterministas cuando sea posible, transaccionales, reversibles y observables. Un agente no debería improvisar comandos privilegiados sin una interfaz restringida.
- Verificación. Las salidas relevantes deben contrastarse con fuentes, políticas y telemetría. Para parches, eso implica compilación, pruebas, análisis y despliegue progresivo.
- Auditoría. Debe poder reconstruirse qué información recibió el modelo, qué versión intervino, qué herramientas utilizó, qué decisión propuso, quién la aprobó y qué resultado produjo.
- Continuidad. La operación debe degradarse de forma segura si el modelo, la interfaz o el proveedor dejan de estar disponibles, y los datos y manuales críticos deben seguir siendo accesibles.
Las cuatro decisiones que hay que tomar antes de elegir herramienta
La tentación, ante un documento así, es abrir un proyecto y repartirlo en fases por calendario. Es un error frecuente: el calendario da sensación de avance mientras las decisiones difíciles se posponen. Hay cuatro que conviene cerrar antes de evaluar ningún producto, porque condicionan todo lo demás.
Primera: cuál es el perímetro real, no el declarado
Nadie puede gobernar lo que no ha inventariado. Hay que localizar modelos, copilotos, agentes, integraciones y usos no autorizados; asignar a cada uno propietario técnico y de negocio; y documentar finalidad, usuarios, datos, herramientas, permisos y proveedor. En paralelo, medir la exposición de partida: cobertura de activos, volumen pendiente, tiempo medio de detección y de respuesta, y tiempo real de parcheo, que casi nunca coincide con el comprometido.
El resultado es un registro de sistemas de IA aprobado conjuntamente por seguridad, sistemas, asesoría jurídica y negocio. Sin esa firma conjunta, el inventario envejece en tres meses.
Segunda: qué papel jurídico juega la organización en cada caso de uso
Proveedor, integrador, importador, distribuidor o desplegador. La respuesta puede ser distinta para cada sistema, y determina qué obligaciones aplican del AI Act, NIS2, DORA, CRA, RGPD y normativa sectorial. Aquí también se decide qué acciones quedan permitidas, cuáles prohibidas y cuáles sujetas a aprobación, y se revisan contratos, subproveedores, uso para entrenamiento, retención, portabilidad y salida.
Tercera: dónde está el límite de la autoridad automatizada
Esta es la decisión que casi nadie toma explícitamente y la que determina si la organización sobrevive a un incidente rápido. Hay que fijar qué puede decidir una máquina sin intervención, qué requiere aprobación humana y quién asume el riesgo de no intervenir. También qué evidencias permiten reconstruir la decisión después, qué ocurre si el modelo se equivoca y cómo se gestiona una emergencia fuera de la ventana de cambio.
Un diseño maduro combina tres velocidades: automática para acciones acotadas, reversibles y de bajo impacto; con validación humana para decisiones urgentes con evidencia suficiente y autoridad preasignada; y colegiada para cambios estructurales, aceptación de riesgo y decisiones con impacto de negocio. Ese diseño tiene que existir antes del incidente. Durante una intrusión a velocidad de máquina ya no hay tiempo para negociar quién puede aislar un activo crítico.
Cuarta: qué hay que probar antes de dar por bueno un caso de uso
Antes de producción, el caso de uso debe haberse enfrentado a inyección de prompt directa e indirecta, manipulación de documentos, datos y herramientas, falta de contexto y telemetría contradictoria. Hay que medir falsos positivos y negativos, ejecutar una reversión completa, simular la pérdida de acceso al modelo y comprobar que cada decisión puede reconstruirse a posteriori.
El entregable de esta fase no es una demostración que funciona, sino un informe de pruebas con limitaciones aceptadas por escrito y criterios explícitos de puesta en producción.
Las preguntas que un proveedor debería poder responder por escrito
Un proveedor solvente responde a esto en un documento, no en una demostración comercial. Las agrupo por bloques.
Sobre el modelo. Qué modelo y versión se utiliza; si puede cambiar sin aprobación ni aviso; qué evaluaciones de seguridad se han realizado; cómo se miden capacidades cibernéticas y riesgo de abuso; y qué límites conocidos tiene.
Sobre los datos. Si los prompts, archivos, telemetría o salidas se usan para entrenamiento; dónde se procesan y almacenan; qué retención se aplica; qué subproveedores participan; y cómo se eliminan y exportan los datos.
Sobre las acciones. Qué herramientas puede invocar el sistema; cómo se autentica cada agente; dónde se aplica la autorización; si existen límites por importe, volumen, activo o entorno; y cómo se revierte una acción ejecutada.
Sobre la seguridad. Cómo se mitigan la inyección de prompt, el envenenamiento de datos y la exfiltración; qué registros se entregan al cliente; cómo se notifican incidentes y vulnerabilidades; si existe SBOM o inventario de dependencias; y qué pruebas independientes se permiten.
Sobre continuidad y cumplimiento. Qué ocurre si se retira el acceso al modelo; si puede sustituirse sin rediseñar toda la integración; qué acuerdo de nivel de servicio cubre disponibilidad y respuesta a incidentes; qué documentación se aporta para AI Act, NIS2, DORA o CRA; y quién conserva la responsabilidad sobre la decisión automatizada.
Una respuesta vaga sobre autenticación de agentes, punto de aplicación de la autorización, registros entregados, notificación de incidentes o continuidad ante retirada del modelo es una señal de riesgo, por muy bueno que sea el rendimiento del producto.
Métricas que sí demuestran si la IA está mejorando la seguridad
Contar alertas procesadas o textos resumidos no demuestra reducción de riesgo. Las métricas útiles comparan el proceso antes y después, y casi todas son temporales.
- Tiempo desde la publicación o detección hasta la validación; desde la validación hasta la decisión; y desde la decisión hasta la mitigación efectiva.
- Porcentaje de vulnerabilidades explotadas conocidas que siguen abiertas fuera del plazo comprometido.
- Tasa de cierres revalidados y porcentaje de acciones de IA que hubo que revertir.
- Falsos positivos y falsos negativos por caso de uso, e intervenciones humanas por decisión de alto impacto.
- Cobertura de registros y trazabilidad, e incidentes causados o agravados por la propia automatización.
- Tiempo de recuperación ante pérdida del proveedor, y porcentaje de dependencias críticas con SBOM, VEX y responsable asignado.
ENISA propone orientar las operaciones hacia tiempos de detección y respuesta de minutos en escenarios acelerados. No debería convertirse en un objetivo universal desconectado del contexto, pero sí funciona como prueba de estrés: si un ataque encadena identidad, nube y exfiltración en menos de una hora, ¿qué parte del proceso defensivo sigue dependiendo de una reunión al día siguiente?
La lectura de Hard2bit: el cambio real es de autoridad y de evidencia
El plan europeo suele presentarse como una carrera de capacidades entre atacantes y defensores. Esa lectura es incompleta. El problema central no será disponer de un modelo potente —eso va a estar al alcance de todos, incluidos los atacantes— sino autorizar decisiones rápidas sin perder el control y poder demostrar después por qué fueron correctas.
Las empresas ya tienen automatización. Lo que muchas no tienen es un modelo explícito de autoridad. Y automatizar un proceso mal gobernado no elimina el retraso: lo desplaza y lo hace menos visible, que es peor, porque desaparece de los indicadores justo cuando más falta hace verlo.
La organización preparada para este escenario no será la que conceda más autonomía a sus agentes, sino la que pueda demostrar qué les permite hacer, bajo qué condiciones, con qué evidencia y cómo recupera el control cuando algo sale mal.
Conclusión
El Plan de Acción europeo no anuncia una solución tecnológica única. Reconoce que el equilibrio entre ataque y defensa está cambiando porque la IA reduce el coste del descubrimiento, acelera el encadenamiento de vulnerabilidades y deja obsoletos procesos de decisión diseñados para otro ritmo.
Europa responde con evaluación independiente de modelos, acceso estructurado a capacidades avanzadas, pruebas en entornos controlados, modernización de la gestión de vulnerabilidades, apoyo al código abierto, cómputo soberano y formación. Es una respuesta razonable, aunque su calendario —2027 para la capacidad de evaluación— va por detrás del ritmo que el propio documento describe.
Para las empresas el mensaje es más concreto y más inmediato: inventario, autoridad, verificación, trazabilidad y continuidad. Si necesitas convertir este marco en una evaluación técnica y regulatoria de tu organización, puedes revisar los servicios de cumplimiento del EU AI Act, NIS2, DORA y seguridad de la inteligencia artificial, o plantearnos el caso concreto a través del formulario de contacto.
Fuentes primarias y documentos analizados
- Comisión Europea. Action Plan on Cybersecurity and Artificial Intelligence, COM(2026) 577 final
- Comisión Europea. Anuncio del plan, 7 de julio de 2026
- ENISA. Cybersecurity in the Frontier AI Era, julio de 2026
- Comisión Europea. Obligaciones para modelos de IA de propósito general
- Comisión Europea. Gobernanza y aplicación del AI Act
- EUR-Lex. Reglamento (UE) 2024/1689, AI Act
- Consejo de la UE. Aprobación definitiva del Digital Omnibus de IA, 29 de junio de 2026
- CERT-EU. AI is changing the economics of vulnerability discovery
- AI Security Institute. How fast is autonomous AI cyber capability advancing?