ISO/IEC 27090 y el artículo 15.5: qué pide sobre ISO 27001 y qué no da

ISO/IEC 27090 se publicó el 14 de octubre de 2026 y llega con una coincidencia que invita a un atajo. Su catálogo de amenazas se parece mucho a la lista que el artículo 15.5 del Reglamento (UE) 2024/1689 manda atender en los sistemas de alto riesgo: envenenamiento de datos y de modelos, ejemplos adversarios, ataques a la confidencialidad. El atajo es concluir que aplicar la norma cumple el artículo. No lo cumple por sí sola, y la razón no está en el contenido sino en el mecanismo: la norma es una guía internacional y la presunción de conformidad en el reglamento tiene tres puertas concretas, ninguna de las cuales es esta.

Lo que sí hace, y no es poco, es dar a quien ya tiene un sistema de gestión de seguridad de la información con ISO 27001 el mapa de lo que ese sistema no ve cuando el activo es un modelo. Las dos cosas a la vez son la lectura útil.

Qué es ISO/IEC 27090, en una frase y en su estructura

Es una norma de ISO/IEC JTC 1/SC 27, el subcomité de seguridad de la información, de 56 páginas y primera edición. Su objeto es ayudar a entender las consecuencias de las amenazas específicas de los sistemas de IA a lo largo de su ciclo de vida, y describir cómo detectarlas y mitigarlas. Se aplica a cualquier organización que desarrolle o use sistemas de IA, y ese «o use» importa más adelante.

La estructura dice para qué sirve mejor que cualquier resumen:

• La cláusula 5 aplica la seguridad de la información a la IA: programa de gobierno de IA, principios de confianza cero, prácticas de ingeniería de software, cadena de suministro (con un apartado propio para los vectores de ataque específicos de IA), modelado de amenazas y red teaming.
• La cláusula 6 es el núcleo: nueve tipos de compromiso (envenenamiento de datos, evasión, inferencia de pertenencia, exfiltración del modelo, inversión del modelo, envenenamiento directo del modelo, salida sensible, inyección de instrucciones e inyección en la salida), cada uno con la misma plantilla de cuatro partes: descripción, fallos que provoca, cómo se detecta y cómo se mitiga.
• La cláusula 7 trata las mitigaciones como lo que son en la práctica: medidas que pueden entrar en conflicto entre sí, que tienen que mantenerse a lo largo del ciclo de vida y que se deterioran con el tiempo, igual que el modelo.
• Tres anexos informativos: el cruce de ataques con fases del ciclo de vida y con activos, las versiones específicas de IA de ataques convencionales y el aprendizaje federado.

Y una premisa que la norma deja escrita desde la introducción: los sistemas de IA sufren todas las amenazas de la ciberseguridad clásica y además las suyas, y las nuevas no desplazan a las viejas. Por eso no es un sistema de gestión alternativo, sino una capa sobre ISO/IEC 27001 y 27002.

La lista del artículo 15.5, cruzada con la norma

El artículo 15 es el de precisión, solidez y ciberseguridad, y su apartado 5 tiene tres párrafos. El primero exige que el sistema sea resistente a los intentos de terceros no autorizados de alterar su uso, sus resultados de salida o su funcionamiento aprovechando sus vulnerabilidades. El segundo, que las soluciones técnicas sean adecuadas a las circunstancias y los riesgos. El tercero enumera las vulnerabilidades específicas de la IA que esas soluciones deben atender, según corresponda, con medidas para

prevenir, detectar, combatir, resolver y controlar los ataques que traten de manipular el conjunto de datos de entrenamiento («envenenamiento de datos»), o los componentes entrenados previamente utilizados en el entrenamiento («envenenamiento de modelos»), la información de entrada diseñada para hacer que el modelo de IA cometa un error («ejemplos adversarios» o «evasión de modelos»), los ataques a la confidencialidad o los defectos en el modelo.

Puestos uno al lado del otro:

Lo que nombra el artículo 15.5	Dónde lo trata ISO/IEC 27090	Lectura
Envenenamiento de datos	6.2	Correspondencia directa
Envenenamiento de modelos (componentes preentrenados)	6.7 y la cadena de suministro de 5.5	El reglamento piensa en el componente que llega de fuera; la norma lo reparte entre el ataque al modelo y la cadena de suministro
Ejemplos adversarios o evasión	6.3	Correspondencia directa
Ataques a la confidencialidad	6.4, 6.5, 6.6 y 6.8	La norma los desglosa en cuatro: pertenencia, exfiltración, inversión y salida sensible
Defectos en el modelo	Sin apartado propio; lo más cercano es 6.11 y el deterioro de 7.4	Aquí la norma ayuda menos, porque un defecto no necesita atacante
(El primer párrafo: alterar el uso aprovechando vulnerabilidades)	6.9 y 6.10	La inyección de instrucciones y la inyección en la salida no aparecen con nombre en el artículo, y caben de lleno en su primer párrafo

Dos diferencias de fondo que la tabla no enseña. La primera está en los verbos: el artículo pide prevenir, detectar, combatir, resolver y controlar, y la plantilla de la norma llega hasta detectar y mitigar. Resolver un ataque en curso y controlar sus efectos es respuesta a incidentes, y eso hay que traerlo de otro sitio. La segunda está en quién pregunta: el artículo es una obligación de resultado sobre un sistema concreto, y la norma es una guía sobre amenazas en general. El paso de una a otra, decidir qué amenazas aplican a este sistema y con qué medida, sigue siendo trabajo propio.

Las tres puertas de la presunción, y por qué 27090 no es ninguna

Para la ciberseguridad del artículo 15 el reglamento abre tres vías de presunción de conformidad.

La norma armonizada (artículo 40). Presume la conformidad con los requisitos de la Sección 2, donde está el artículo 15, a quien aplique normas armonizadas citadas en el Diario Oficial y en la medida en que las cubran. La norma en preparación para la ciberseguridad del artículo 15 es prEN 18282, Cybersecurity specifications for AI systems, de CEN-CENELEC/JTC 21. No está publicada ni, por tanto, citada en el Diario Oficial. ISO/IEC 27090 no es armonizada ni lo pretende: no tiene Anexo ZA y no responde a ninguna petición de normalización de la Comisión. Lo que he explicado para EN 18286 y el artículo 17 vale aquí al revés: allí había una norma citada cuyo alcance había que leer fila a fila; aquí, para la ciberseguridad, todavía no hay ninguna.

El certificado de ciberseguridad (artículo 42.2). Presume que cumplen los requisitos de ciberseguridad del artículo 15 los sistemas con certificado o declaración de conformidad de un esquema europeo creado con el Reglamento (UE) 2019/881, el de la Ley de Ciberseguridad, en la medida en que el certificado los contemple. Esa última condición es la que pesa. Hoy el único esquema europeo adoptado es el EUCC (Reglamento de Ejecución (UE) 2024/482), que certifica productos TIC con Criterios Comunes; el de servicios en la nube y el de redes 5G siguen en desarrollo. Es un esquema general: lo que cubra del artículo 15 dependerá de lo que se haya evaluado, y las vulnerabilidades propias de la IA del tercer párrafo no son su objeto. Un certificado así puede sostener parte del primer párrafo y dejar intacto el tercero.

El Reglamento de Ciberresiliencia (artículo 42.3). Es la novedad. El Reglamento (UE) 2026/1744 añadió al artículo 42 un tercer apartado que trae al propio texto lo que ya decía el artículo 12 del Reglamento (UE) 2024/2847: un sistema de alto riesgo que entre en el ámbito de ese reglamento se considera conforme con los requisitos de ciberseguridad del artículo 15 si cumple los requisitos esenciales de ciberseguridad de su anexo I (del producto y de los procesos del fabricante) y su declaración UE de conformidad demuestra el nivel de protección que exige el artículo 15. Dos límites: solo alcanza a productos con elementos digitales dentro del ámbito de la ciberresiliencia, y sus obligaciones principales se aplican desde el 11 de diciembre de 2027, nueve días después de que empiecen a aplicarse las del alto riesgo del anexo III, el 2 de diciembre de 2027.

Los textos de los artículos 15.5, 17.1.e, 42.2 y 42.3 y del artículo 12 del Reglamento (UE) 2024/2847 están verificados a 23 de octubre de 2026 en el Diario Oficial: el texto original de cada reglamento y la modificación del Reglamento (UE) 2026/1744, que no toca los artículos 15 ni 17.1.e.

Dónde entra 27090 sin presumir nada

Si no presume, ¿para qué la quiere quien fabrica un sistema de alto riesgo? Para rellenar los dos huecos que el reglamento deja expresamente abiertos a la espera de la armonizada.

El primero es el artículo 17.1.e. El sistema de gestión de la calidad del proveedor debe recoger las especificaciones técnicas, incluidas las normas, que se aplicarán y, cuando las normas armonizadas no se apliquen en su totalidad o no cubran todos los requisitos de la Sección 2, los medios con los que se asegura el cumplimiento. Hoy, para la ciberseguridad específica de la IA, ese «no cubran» es la situación de todo el mundo. Una guía internacional publicada, aplicada amenaza por amenaza y con la decisión de cada una documentada, es un medio que se puede defender ante una autoridad de vigilancia. Defender no es presumir: si la autoridad pregunta, la carga de demostrar que las soluciones son adecuadas a las circunstancias y los riesgos sigue siendo de quien las eligió.

El segundo es la documentación técnica. El anexo IV pide, entre la descripción detallada de los elementos del sistema, las medidas de ciberseguridad adoptadas. La plantilla de la cláusula 6 (descripción, fallos, detección, mitigación) es casi la forma que esa entrada necesita para que diga algo más que «se aplican los controles de seguridad corporativos».

Para quien usa el sistema bajo su autoridad (el responsable del despliegue, deployer), la entrada es otra. El artículo 15 no le obliga a él, pero las instrucciones de uso tienen que decirle con qué nivel de ciberseguridad se probó y validó el sistema y qué circunstancias previsibles pueden afectarlo (artículo 13.3.b.ii), y tiene que usarlo conforme a esas instrucciones y vigilar su funcionamiento (artículo 26). Que la norma esté escrita también para organizaciones que usan IA le da dos cosas: el vocabulario para preguntar al proveedor qué amenazas consideró, y el mapa de lo que la propia organización añade alrededor del sistema y nadie más protege, como los documentos con los que alimenta un asistente, que son la puerta de una inyección de instrucciones.

Qué le pide a quien ya tiene ISO 27001

Aquí está el valor práctico para la mayoría de organizaciones, tengan o no un sistema de alto riesgo. La norma no reabre el sistema de gestión: da por supuestos los controles de ISO/IEC 27002 y dice que se apliquen según las necesidades de la organización y los riesgos que salgan de su evaluación. Lo que hace es enseñar dónde esa evaluación se queda ciega cuando el activo es un modelo.

El inventario de activos se queda corto. Un sistema de IA trae activos que el inventario de seguridad no suele tener: los datos de entrenamiento y su procedencia, los parámetros del modelo, las entradas en operación y las salidas. La inversión del modelo y la inferencia de pertenencia existen porque un dato de entrenamiento sigue siendo recuperable a través del modelo, así que proteger el almacén donde vivía ya no basta.

Hay amenazas que no se saltan ningún control. La exfiltración del modelo se construye con consultas legítimas: el atacante pregunta y observa. La introducción de la norma lo dice sin rodeos, el modelo puede robarse aunque las medidas convencionales funcionen. Una evaluación de riesgos que solo busca accesos no autorizados no la encuentra.

La cadena de suministro cambia de forma. Un modelo preentrenado o un conjunto de datos de terceros no es una dependencia de software al uso: no se audita leyendo su código. Es exactamente el «componente entrenado previamente» del artículo 15.5, y la norma le dedica un apartado propio.

Las mitigaciones caducan. Es la idea de la cláusula 7 que más cuesta encajar en un sistema de gestión: una medida que funcionaba puede debilitar otra, o dejar de funcionar porque el modelo ha cambiado o porque el atacante ha aprendido. La revisión anual del tratamiento de riesgos se queda lenta si el modelo se reentrena cada trimestre.

Nada de esto exige un sistema de gestión nuevo. Exige que la evaluación de riesgos del sistema que ya existe, y el de ISO/IEC 42001 si también está, incorporen esta lista y la revisen cuando cambia el modelo, no cuando toca el calendario.

Lo que decide la organización

Con la norma publicada y la armonizada todavía sin fecha, hay tres decisiones que no conviene dejar a la inercia.

Quién firma la entrada de ciberseguridad del artículo 15. La tentación es dársela entera a seguridad de la información. Pero la mitad de la lista (envenenamiento, evasión, defectos del modelo) se decide en el equipo que entrena y valida, y la evidencia de que una mitigación sigue funcionando sale de la vigilancia del sistema en producción. Si nadie tiene escrita esa frontera, la entrada de ciberseguridad de la documentación técnica queda a medio camino entre dos equipos que creen que es del otro.

Esperar a prEN 18282 o documentar ya. Esperar parece prudente y no lo es. El artículo 17.1.e ya obliga a documentar los medios mientras no haya armonizada, y cuando llegue la norma se podrá contrastar con ella lo hecho; lo que no se podrá es reconstruir decisiones que no se tomaron. Lo razonable es usar ISO/IEC 27090 como medio declarado hoy y dejar escrito el disparador para revisarlo el día que se cite prEN 18282.

Qué dispara la revisión. Cada cambio de modelo, de datos de entrenamiento o de proveedor de un componente preentrenado cambia el mapa de amenazas. Si el disparador es solo la auditoría anual, la cláusula 7 de la norma ya avisa de lo que pasa: las mitigaciones envejecen más deprisa que el calendario.

La norma no resuelve ninguna de las tres. Las vuelve imposibles de ignorar, que en gobierno de IA es a menudo lo más útil que puede hacer un documento.