Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 15.5 del AI Act obliga a los sistemas de alto riesgo a tener, teniendo en cuenta su finalidad prevista, niveles adecuados de precisión, solidez y ciberseguridad frente a intentos de terceros no autorizados que puedan modificar su uso o rendimiento. La ciberseguridad de los sistemas de IA es un ámbito específico que va más allá de la ciberseguridad del software convencional, porque los sistemas de IA tienen vulnerabilidades propias que los sistemas de software tradicionales no presentan.
La Guía 11 analiza en sus 42 páginas las amenazas específicas de los sistemas de IA, las medidas técnicas que el art. 15.5 exige, y la relación de estas obligaciones con el marco de ciberseguridad sectorial — fundamentalmente la Directiva NIS2 para infraestructuras críticas y el Reglamento DORA para el sector financiero. El objetivo es proporcionar a los responsables de seguridad y a los juristas un marco integrado que evite duplicidades y garantice que las medidas adoptadas cumplen simultáneamente con los tres marcos normativos aplicables.
La guía parte de un reconocimiento que es relevante para la estrategia de cumplimiento: la ciberseguridad de un sistema de IA tiene dos capas que deben protegerse por separado. La primera capa es la seguridad de la infraestructura que aloja el sistema — los servidores, la red, las bases de datos, las APIs. Esta capa se protege con las medidas de ciberseguridad convencionales que los frameworks como ISO 27001 o NIS2 establecen. La segunda capa es la seguridad del propio sistema de IA — los datos de entrenamiento, el modelo, y el proceso de inferencia. Esta segunda capa requiere medidas específicas que la ciberseguridad convencional no cubre.
El data poisoning o envenenamiento de datos es el ataque más peligroso a largo plazo contra un sistema de IA. Consiste en introducir datos maliciosos en el conjunto de entrenamiento del sistema con el objetivo de que el modelo aprenda un comportamiento incorrecto en situaciones específicamente diseñadas por el atacante. Un ataque de data poisoning exitoso puede hacer que el sistema cometa errores sistemáticos en situaciones que el atacante controla, sin que esos errores sean detectables en las evaluaciones de rendimiento general del sistema.
El model stealing o extracción del modelo es el ataque mediante el que un adversario reconstruye el modelo de IA a partir de sus inputs y outputs, sin acceder al código o los pesos del modelo. Realizando un número suficientemente grande de consultas al sistema y observando los outputs, el adversario puede aproximar el comportamiento del modelo con suficiente fidelidad para usarlo de forma no autorizada o para diseñar ataques adversariales más efectivos. Para sistemas de IA con valor comercial significativo o que procesan información sensible, el model stealing es una amenaza real.
La inversión del modelo o model inversion es el ataque mediante el que un adversario reconstruye datos del conjunto de entrenamiento a partir de las respuestas del modelo. Si el modelo ha memorizado datos personales individuales de los datos de entrenamiento — lo que puede ocurrir especialmente cuando los datos de entrenamiento son pequeños o cuando el modelo ha sido entrenado con overfitting — los ataques de inversión pueden revelar esos datos personales. Esto representa una brecha de datos personales bajo el RGPD con independencia de que el modelo no exponga directamente los datos.
Los ataques de evasión son los más conocidos en el ámbito académico: modificaciones minimas y calculadas de un input real para que el sistema lo clasifique de forma diferente a la que sería correcta. Los ejemplos más conocidos son las imágenes adversariales — imágenes que para el ojo humano son claramente un perro pero que el sistema de reconocimiento de imagen clasifica como un avión — pero los ataques de evasión existen también para sistemas de análisis de texto, de audio y de datos tabulares.
La guía establece un catálogo de medidas técnicas para proteger los sistemas de IA de alto riesgo frente a los ataques descritos. Para la protección frente al data poisoning, las medidas incluyen el control de acceso estricto a los sistemas de almacenamiento de datos de entrenamiento, la verificación criptográfica de la integridad de los datos, el uso de técnicas de detección de anomalías en los datos de entrenamiento para identificar posibles intentos de envenenamiento, y la limitación del número de fuentes de datos de entrenamiento a fuentes verificadas y de confianza.
Para la protección frente al model stealing, las medidas incluyen la limitación del número de consultas que un único usuario puede realizar en un período de tiempo, la introducción de ruido calibrado en los outputs del modelo para dificultar la reconstrucción del modelo sin degradar significativamente su utilidad, el monitoreo de patrones de uso que indiquen posibles intentos de extracción, y la protección de los endpoints de la API con autenticación robusta y registros detallados de uso.
Para la protección frente a la inversión del modelo, las medidas incluyen el uso de técnicas de privacidad diferencial durante el entrenamiento, que añaden ruido matemáticamente controlado para que el modelo no memorice datos individuales, y la evaluación periódica del riesgo de inversión mediante técnicas de auditoría de privacidad del modelo.
Para la protección frente a ataques de evasión, las medidas incluyen el entrenamiento adversarial — incluir ejemplos adversariales en los datos de entrenamiento para que el modelo aprenda a clasificarlos correctamente — y la implementación de sistemas de detección de inputs adversariales que alerten cuando un input presenta las características estadísticas típicas de un ataque de evasión.
La Directiva NIS2 (Directiva 2022/2555) establece obligaciones de ciberseguridad para entidades esenciales e importantes en diez sectores críticos: energía, transporte, banca, infraestructuras de mercado financiero, sanidad, agua potable, aguas residuales, infraestructuras digitales, gestión de servicios TIC y administración pública. Las empresas de estos sectores que usan sistemas de IA de alto riesgo deben cumplir simultáneamente con el art. 15 del AI Act y con las obligaciones de gestión de riesgos del art. 21 NIS2.
El art. 21 NIS2 exige que las entidades sujetas implementen medidas técnicas y organizativas para gestionar los riesgos que plantean para la seguridad de las redes y sistemas de información. Estas medidas incluyen la gestión de incidentes, la continuidad de negocio, la cadena de suministro, la seguridad en la adquisición, desarrollo y mantenimiento de sistemas, la gestión de vulnerabilidades, la formación en ciberseguridad, y las políticas de evaluación de la eficacia de las medidas.
La guía establece que las medidas de ciberseguridad del art. 15 AI Act y las del art. 21 NIS2 son en gran medida compatibles y complementarias. La diferencia principal es que el art. 15 AI Act añade requisitos específicos para las vulnerabilidades propias de los sistemas de IA (data poisoning, model stealing, evasión) que NIS2 no menciona explícitamente porque es una directiva de ciberseguridad general no específica de IA.
El Reglamento DORA (Reglamento 2022/2554 sobre la resiliencia operativa digital del sector financiero) establece requisitos específicos de ciberseguridad y resiliencia para entidades financieras. Las entidades financieras que usan sistemas de IA de alto riesgo — bancos, aseguradoras, gestoras de fondos, plataformas de negociación — están sujetas a tres marcos normativos simultáneos: el AI Act, NIS2 y DORA.
La guía mapea las principales áreas de solapamiento entre los tres marcos. La gestión de riesgos TIC del art. 6 DORA y el sistema de gestión de riesgos del art. 9 AI Act cubren parcialmente el mismo territorio: ambos exigen identificar, evaluar y mitigar los riesgos de los sistemas tecnológicos. La diferencia es que DORA se centra en los riesgos para la continuidad operativa y la estabilidad financiera, mientras que el art. 9 AI Act se centra en los riesgos para la salud, la seguridad y los derechos fundamentales de las personas. En la práctica, las entidades financieras deben integrar ambos procesos en un único sistema de gestión de riesgos que cubra los requisitos de ambas normas.
La guía recomienda que el plan de respuesta a incidentes de ciberseguridad de la organización incluya procedimientos específicos para los incidentes que afecten a sistemas de IA de alto riesgo. Estos procedimientos deben contemplar la evaluación de si el incidente de ciberseguridad ha comprometido la integridad del modelo o de los datos de entrenamiento, la determinación de si el incidente constituye un "incidente grave" en el sentido del art. 73 AI Act que deba notificarse a la AESIA, la coordinación con el DPO para determinar si el incidente también constituye una brecha de datos personales que deba notificarse a la AEPD en 72 horas, y el proceso de evaluación del sistema tras el incidente para determinar si puede continuar operando o debe suspenderse temporalmente.
En los modelos de despliegue en la nube — que son los más frecuentes para sistemas de IA de alto riesgo — la responsabilidad de ciberseguridad se distribuye entre el proveedor del sistema de IA, el proveedor de la plataforma cloud y el desplegador. Esta distribución de responsabilidad, conocida como el "modelo de responsabilidad compartida", requiere una definición contractual precisa de qué medidas de ciberseguridad corresponden a cada parte.
La guía establece que el proveedor del sistema de IA es responsable de la ciberseguridad del sistema en sí — el modelo, los datos de entrenamiento, las APIs del sistema. El proveedor de la plataforma cloud es responsable de la seguridad de la infraestructura en la que el sistema opera. El desplegador es responsable de la seguridad de su propio entorno de uso del sistema — sus credenciales de acceso, su configuración de seguridad, y el acceso de sus empleados al sistema.
En la práctica, los acuerdos de nivel de servicio (SLA) con proveedores de plataformas cloud y de sistemas de IA deben incluir cláusulas específicas sobre ciberseguridad que definan con precisión las responsabilidades de cada parte, los estándares de seguridad que cada parte debe cumplir, los procedimientos de notificación de incidentes de seguridad, y los mecanismos de auditoría que permitan al desplegador verificar el cumplimiento de las obligaciones de ciberseguridad del proveedor.
Las Administraciones Públicas españolas que desarrollen o usen sistemas de IA de alto riesgo tienen una capa adicional de requisitos de ciberseguridad: el Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022). El ENS establece una política de seguridad de la información para el sector público español con cuatro categorías de sistema — esencial, alta, media y básica — cada una con un conjunto de controles de seguridad obligatorios.
Los sistemas de IA de alto riesgo usados por las AAPP deben clasificarse en el ENS según el impacto que un incidente de seguridad tendría en la prestación del servicio público. Los sistemas de IA que afectan a derechos fundamentales — decisiones sobre prestaciones sociales, sobre acceso a servicios públicos, sobre procesamiento de datos de salud — deberían clasificarse en categoría alta o esencial, lo que implica los controles de seguridad más exigentes del ENS.
La coordinación entre el art. 15 del AI Act y el ENS es un área que el Centro Criptológico Nacional (CCN) está trabajando activamente, desarrollando guías específicas sobre cómo los controles del ENS se mapean sobre los requisitos del AI Act para sistemas de alto riesgo en el sector público. La Guía CCN-STIC que cubrirá este ámbito estaba en proceso de elaboración a la fecha de publicación de la Guía 11 de la AESIA.
El ciclo de vida de un sistema de IA de alto riesgo debe incluir auditorías periódicas de ciberseguridad que verifiquen que las medidas de protección implementadas son efectivas y están actualizadas. La guía recomienda una auditoría completa de ciberseguridad al menos cada 18 meses para sistemas de alto riesgo, con auditorías más frecuentes cuando el sistema procesa datos especialmente sensibles o cuando opera en sectores de alto impacto.
Las auditorías de ciberseguridad de sistemas de IA tienen elementos específicos que no están cubiertos por las auditorías de ciberseguridad de software tradicional: la evaluación de la resistencia del sistema a ataques adversariales específicos de IA, la verificación de la integridad del proceso de entrenamiento y de los datos de entrenamiento, y la evaluación de los riesgos de inversión del modelo y de extracción del modelo. Estas evaluaciones requieren auditores con competencias específicas en IA y en ciberseguridad — una combinación que aún es escasa en el mercado español.
En los modelos de despliegue en la nube — que son los más frecuentes para sistemas de IA de alto riesgo — la responsabilidad de ciberseguridad se distribuye entre el proveedor del sistema de IA, el proveedor de la plataforma cloud y el desplegador. Esta distribución de responsabilidad, conocida como el "modelo de responsabilidad compartida", requiere una definición contractual precisa de qué medidas de ciberseguridad corresponden a cada parte.
La guía establece que el proveedor del sistema de IA es responsable de la ciberseguridad del sistema en sí — el modelo, los datos de entrenamiento, las APIs del sistema. El proveedor de la plataforma cloud es responsable de la seguridad de la infraestructura en la que el sistema opera. El desplegador es responsable de la seguridad de su propio entorno de uso del sistema — sus credenciales de acceso, su configuración de seguridad, y el acceso de sus empleados al sistema.
En la práctica, los acuerdos de nivel de servicio (SLA) con proveedores de plataformas cloud y de sistemas de IA deben incluir cláusulas específicas sobre ciberseguridad que definan con precisión las responsabilidades de cada parte, los estándares de seguridad que cada parte debe cumplir, los procedimientos de notificación de incidentes de seguridad, y los mecanismos de auditoría que permitan al desplegador verificar el cumplimiento de las obligaciones de ciberseguridad del proveedor.
Las Administraciones Públicas españolas que desarrollen o usen sistemas de IA de alto riesgo tienen una capa adicional de requisitos de ciberseguridad: el Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022). El ENS establece una política de seguridad de la información para el sector público español con cuatro categorías de sistema — esencial, alta, media y básica — cada una con un conjunto de controles de seguridad obligatorios.
Los sistemas de IA de alto riesgo usados por las AAPP deben clasificarse en el ENS según el impacto que un incidente de seguridad tendría en la prestación del servicio público. Los sistemas de IA que afectan a derechos fundamentales — decisiones sobre prestaciones sociales, sobre acceso a servicios públicos, sobre procesamiento de datos de salud — deberían clasificarse en categoría alta o esencial, lo que implica los controles de seguridad más exigentes del ENS.
La coordinación entre el art. 15 del AI Act y el ENS es un área que el Centro Criptológico Nacional (CCN) está trabajando activamente, desarrollando guías específicas sobre cómo los controles del ENS se mapean sobre los requisitos del AI Act para sistemas de alto riesgo en el sector público. La Guía CCN-STIC que cubrirá este ámbito estaba en proceso de elaboración a la fecha de publicación de la Guía 11 de la AESIA.
El ciclo de vida de un sistema de IA de alto riesgo debe incluir auditorías periódicas de ciberseguridad que verifiquen que las medidas de protección implementadas son efectivas y están actualizadas. La guía recomienda una auditoría completa de ciberseguridad al menos cada 18 meses para sistemas de alto riesgo, con auditorías más frecuentes cuando el sistema procesa datos especialmente sensibles o cuando opera en sectores de alto impacto.
Las auditorías de ciberseguridad de sistemas de IA tienen elementos específicos que no están cubiertos por las auditorías de ciberseguridad de software tradicional: la evaluación de la resistencia del sistema a ataques adversariales específicos de IA, la verificación de la integridad del proceso de entrenamiento y de los datos de entrenamiento, y la evaluación de los riesgos de inversión del modelo y de extracción del modelo. Estas evaluaciones requieren auditores con competencias específicas en IA y en ciberseguridad — una combinación que aún es escasa en el mercado español.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español