ISO/IEC 27090: Detectar, evaluar y controlar las amenazas de seguridad para sistemas de IA

Del inicio del proyecto en 2022 a la publicación en 2026

El proyecto se aprobó el 15/09/2022, la consulta sobre el Committee Draft comenzó en enero de 2024 y la votación del DIS el 16/04/2025. El Final Draft se sometió a votación del 23/06 al 19/08/2026 y pasó el mismo día del cierre de la votación al estado «under publication»; el 14/10/2026 siguió la publicación con el código de etapa 60.60. El resultado de la votación no es público, pero la transición sin devolución al comité acredita la aprobación. Por el camino cambió el título: de «Guidance for addressing security threats and failures» pasó a «Addressing security threats and compromises to AI systems», los fallos se convirtieron en compromisos y la extensión creció de 46 a 56 páginas con 115 entradas bibliográficas.

Organismo editor y comités

La norma ha sido elaborada por ISO/IEC JTC 1/SC 27 «Information security, cybersecurity and privacy protection», con secretaría en el DIN (Chair Dr. Andreas Wolf); el grupo de trabajo responsable fue el WG 4 «Security controls and services», bajo el Convenor Faud Khan, del SCC canadiense; ninguna fuente pública nombra a los editores del proyecto. El SC 27 Journal de septiembre de 2026 describe 27090 como la primera norma del subcomité dedicada específicamente a la seguridad de los sistemas de IA. En Alemania, el grupo de trabajo NA 043-04-27-04 «IT-Sicherheitsmaßnahmen und Dienste» es el espejo del WG 4; a 22/10/2026 su lista de proyectos no contiene ni un proyecto de adopción ni una posición sobre 27090.

Adquisición, idioma y versiones nacionales

La norma se publica exclusivamente en inglés. ISO cobra 204 CHF; DIN Media distribuye el original ISO como ISO/IEC 27090:2026-10 por 218,32 euros netos, y en la IEC Webstore figura como publicación 117332. No existe una versión alemana: DIN Media y SNV distribuyen solo el original ISO en inglés, no se conoce una adopción como ÖNORM y la adopción británica BS ISO/IEC 27090:2026 está anunciada para el 31 de octubre de 2026. Pueden consultarse gratuitamente vistas previas con el índice, la Introduction, las cláusulas 1 a 4, 5.1 a 5.3 y la bibliografía; las cláusulas 5.4 a 7, la Table 1 y los anexos solo están disponibles en la versión completa, y las afirmaciones de esta página al respecto se apoyan en el índice y en evaluaciones del FDIS, y están señaladas como tales.

Norma de orientación, no norma de sistema de gestión

ISO/IEC 27090 es un International Standard con carácter de orientación. El propio explainer de ISO habla de directrices de seguridad, no de requisitos para un sistema de gestión de IA; para ello, la cláusula 5.2 remite a ISO/IEC 42001. No existe un certificado «ISO 27090», ni una auditoría «según 27090», ni una presunción de conformidad con la Ley de IA o el Cyber Resilience Act. Sin embargo, la norma tampoco es una mera colección de recomendaciones: la cláusula 5.1 contiene dos frases con «shall» acreditadas, según las cuales los controles de seguridad de la información, por ejemplo de ISO/IEC 27002, deben implantarse con base en el riesgo y los compromisos específicos de la IA deben considerarse a lo largo de todo el ciclo de vida. Para la práctica: no hay requisitos certificables, pero sí una expectativa clara de tratar las amenazas de la cláusula 6 en el propio sistema de gestión de riesgos.

Scope: desarrollar o utilizar

La cláusula 1 describe el objeto así: amenazas y compromisos relevantes para la seguridad que son específicos de los sistemas de IA, sus consecuencias, y su detección y mitigación a lo largo de todo el ciclo de vida — aplicable a empresas, administraciones públicas y organizaciones sin ánimo de lucro que desarrollan o utilizan sistemas de IA. La Introduction habla de desarrollar o desplegar, la cláusula 5.1 de actores a lo largo de la cadena de suministro. La cláusula 3 no define los roles de proveedor y responsable del despliegue de la Ley de IA ni los roles de partes interesadas de ISO/IEC 22989; por tanto, toda asignación de medidas a roles es interpretación. El ámbito no se limita a la IA generativa.

Referencias normativas e informativas

La norma cita de forma normativa exactamente dos documentos: ISO/IEC 22989 sin fecha, es decir, incluidas las modificaciones futuras como la enmienda en curso sobre IA generativa, e ISO/IEC 23053:2022. ISO/IEC 27001, 27002, 42001, 23894, 5338 y 38507 figuran solo en la bibliografía, pero en 5.1 y 5.2 se nombran expresamente como base de trabajo. La cláusula 3 toma los objetivos de protección de la nueva ISO/IEC 27000:2026, y amenaza, ataque y vulnerabilidad de ISO/IEC 27002:2022.

Qué no es objeto de la norma

• Requisitos para un sistema de gestión de IA: la cláusula 5.2 remite a ISO/IEC 42001.
• Riesgos para la protección de datos de los sistemas de IA: objeto de la norma hermana ISO/IEC 27091.
• La IA como herramienta de defensa, así como amenazas que solo emplean IA, por ejemplo deepfakes o phishing asistido por IA.
• Ataques de IA contra IA, así como la seguridad funcional (safety), para la que es pertinente ISO/IEC TR 5469.
• Una presunción de conformidad con la Ley de IA o el Cyber Resilience Act: 27090 no es una norma armonizada y no existe un mapeo oficial a prEN 18282 o ETSI TS 104 223.

27090 y 27091: seguridad y protección de datos como pareja

ISO/IEC 27091 «Cybersecurity and Privacy — Artificial Intelligence — Privacy protection» aún no está publicada; a 22/10/2026 la votación del FDIS no había comenzado. Según resúmenes basados en el DIS, trata el análisis de protección de datos, la privacidad de los modelos de IA y la ingeniería de la privacidad en el ciclo de vida. El solapamiento es visible: Membership Inference y Model Inversion figuran en ambas normas, en 27090 como amenaza de seguridad contra la confidencialidad de los datos de entrenamiento, en 27091 como riesgo para la protección de datos. Una publicación a principios de 2027 es plausible, pero no es una fecha objetivo de ISO.

Cláusula 5: 5.1 como marco, seis prácticas

La cláusula 5.1 establece el marco: los sistemas de IA son componentes de software integrados a los que se aplican, con base en el riesgo, los controles de ISO/IEC 27002, y los compromisos específicos de la IA, incluidos los enumerados en la Table 1, deben considerarse a lo largo del ciclo de vida según ISO/IEC 22989 y 5338. Como punto de partida eficiente, la norma nombra el endurecimiento de la pila de software frente al robo directo de modelos, y como ejemplos ETSI EN 304 223 y el NIST Secure Software Development Framework. La cláusula 5.2 describe un programa de gobernanza con inventario, análisis de riesgos y tratamiento de riesgos; la 5.5 estructura la gestión de la cadena de suministro en cinco subapartados, desde las amenazas generales y las específicas de la IA hasta las estrategias de contramedida. La cláusula 5.3 adopta los seis principios de Zero Trust de ISO/IEC 27002 8.27, los ilustra con cinco ejemplos que llegan hasta la verificación de acciones de agentes y anuncia que se incorporan a todas las secciones de mitigación de la cláusula 6.

Cláusula 6: nueve tipos en una estructura uniforme

La Table 1 se referencia en 5.1, pero no figura allí; según nuestra lectura se ubica en 6.1 y, de acuerdo con la evaluación del FDIS, enumera doce tipos de ataque: nueve de la cláusula 6 y tres del Anexo B.

Cláusula 7 y los anexos

La cláusula 7 es breve, con cuatro páginas, pero según nuestra valoración es el punto de la norma más importante para las decisiones sobre medidas. La cláusula 7.2 trata las interacciones contradictorias; la evaluación del FDIS cita como ejemplo un adversarial training que aumentó la susceptibilidad a ataques de parche y recomienda probar todas las medidas conjuntamente antes del despliegue. La cláusula 7.3 trata la continuidad de las medidas a lo largo del ciclo de vida; la 7.4 describe el deterioro del modelo y de las medidas, con monitorización, reentrenamiento cuando sea necesario y revalidación antes de devolverlo a operación; la 7.7 distingue las entradas fuera de distribución, que no son necesariamente ataques, de las entradas adversarias. El Anexo A asigna los ataques al ciclo de vida y a los activos, el Anexo B describe variantes de IA de ataques convencionales y el Anexo C el aprendizaje federado.

Términos, abreviaturas, bibliografía

La cláusula 3 define 30 términos, entre ellos la división tripartita del conocimiento del atacante en ataques de zero knowledge, partial knowledge y perfect knowledge en lugar de la metáfora de caja negra, gris y blanca. Los tipos de ataque figuran en 3.13 a 3.24, con Prompt Injection definida de forma tan amplia que los contenidos que actúan como instrucción de entrada o dentro de ella cubren también la variante indirecta. No se definen agente de IA, compromiso ni IA predictiva. La cláusula 4 enumera 15 abreviaturas, desde AI, pasando por DP, JIT, OOD y RAG, hasta RT; falta MCP, lo que, conforme a las Directivas ISO/IEC, es un fuerte indicio de que el Model Context Protocol no aparece en el texto de la norma. No se citan NIST AI RMF, NIST AI 100-2, el OWASP Top 10 for LLM Applications, el OWASP Agentic Top 10 ni el Model Context Protocol — precisamente los documentos con los que esta página complementa la norma.

Tesis central de la Introduction

La Introduction formula cuatro ideas que sostienen el resto de la norma. Primera: la práctica según ISO/IEC 27001 y 27002 sigue siendo la recomendada, porque los sistemas de IA son software y comparten todas las vulnerabilidades conocidas. Segunda: con aprendizaje continuo, los datos operativos pueden convertirse en datos de entrenamiento, con lo que la operación se convierte en vector de poisoning. Tercera: la exfiltración de un modelo se logra mediante consultas legítimas aunque todos los controles estándar estén intactos; el rate limiting ayuda. Cuarta: la detección es difícil pero imprescindible, por lo que la norma establece la defensa en profundidad como principio rector y dedica a cada tipo de ataque su propia sección de detección.

Activos y objetivos del atacante

Según la evaluación de la Table 1 basada en el FDIS, la norma ordena sus doce tipos de ataque por el activo afectado en primer lugar: modelo, datos de entrenamiento, datos de prueba, salida y servicio. A ello se suman, desde 5.1, la pila de software en la que está integrado el sistema de IA y, desde 5.5, la cadena de suministro, que según la evaluación del FDIS abarca modelos preentrenados, conjuntos de datos adquiridos, plataformas de notebooks y herramientas de MLOps. Por ello, un inventario de IA según 5.2 debería registrar, por cada sistema, el artefacto del modelo, los datos, las fuentes de recuperación, los system prompts, las interfaces, los permisos de herramientas y el pipeline. Según nuestra lectura, detrás de los nueve tipos hay seis objetivos del atacante.

Conocimiento del atacante y fases

La cláusula 3 distingue en 3.10 a 3.12 ataques sin conocimiento, con conocimiento parcial y con conocimiento completo del modelo, en todos los casos sin credenciales de acceso. Esto revela el foco de la primera edición: el atacante típico es un externo que actúa de forma dirigida. Gary Hinson ha criticado que las amenazas accidentales, los actores internos y las consecuencias más allá de la propia organización estén infrarrepresentados; al menos, según la evaluación del FDIS, la Table 1 marca cada tipo como escenario de atacante o de accidente. Los actores internos con permisos legítimos y las configuraciones erróneas deberá añadirlos usted mismo al registro de riesgos. En el plano temporal, 5.1 ordena los ataques según si actúan durante el desarrollo y el entrenamiento, durante la inferencia y la operación, o en ambas fases.

La norma menciona en 5.1 el ciclo de vida según ISO/IEC 22989 y 5338, de la idea a la retirada del servicio, y en el Anexo A asigna los ataques al ciclo de vida y a los activos; las columnas de ese anexo no son visibles en las vistas previas. Las seis fases de esta página, más los ejes transversales de cadena de suministro y gobernanza, son un modelo de trabajo de VamiSec que se orienta por esas dos normas, pero no reproduce ninguna denominación de etapas de la 27090.

1. 1
   Fase 01 · Desarrollo/EntrenamientoDatos y adquisición

   Data Poisoning (6.2) y los tipos del Anexo B Direct Training Data Leak y Model Input Leak; según 5.5, los conjuntos de datos adquiridos forman parte de la cadena de suministro. Anclajes: procedencia (6.11.4), limitación de datos (6.11.2).

2. 2
   Fase 02 · Desarrollo/EntrenamientoDesarrollo y entrenamiento

   Direct Model Poisoning (6.7) y las backdoors (3.24) apuntan al artefacto del modelo y a la pipeline. Anclajes: entorno de desarrollo (7.6), ingeniería de software (5.4), Zero Trust para los datos de entrenamiento (5.3).

3. 3
   Fase 03 · TransiciónVerificación y validación

   Aquí la susceptibilidad a Evasion, Membership Inference y Model Inversion se vuelve medible antes de que los atacantes la exploten. Anclajes: red teaming (5.7), threat modelling (5.6), prueba conjunta de todas las medidas (7.2).

4. 4
   Fase 04 · Inferencia/OperaciónDespliegue e integración

   Con la conexión a aplicaciones, fuentes de recuperación y herramientas surgen las superficies de ataque para Prompt Injection (6.9) y la salida con ataques de inyección (6.10). Anclajes: límites de la aplicación y acceso al modelo, incluido RAG (5.3), filtrado de entradas (7.7), limitación de tasa (7.8).

5. 5
   Fase 05 · Inferencia/OperaciónOperación y supervisión

   Evasion (6.3), Membership Inference (6.4), Model Exfiltration (6.5), Model Inversion (6.6) y Sensitive Model Output (6.8) se ejecutan mediante consultas legítimas. Anclajes: registro y monitorización (7.5), apartados de detección 6.x.3, comportamiento no deseado del modelo en operación (6.11.3).

6. 6
   Fase 06 · Ambas capasReevaluación y retirada del servicio

   El modelo y las medidas se degradan con el tiempo (7.4): monitorización, reentrenamiento cuando sea necesario, revalidación antes de la reincorporación. El reentrenamiento con datos operativos reabre el vector de poisoning de 6.2. Sobre la retirada del servicio, la versión de acceso libre guarda silencio; ETSI EN 304 223 dedica a ello un principio propio.

Aprendizaje continuo: la operación se convierte en fase de entrenamiento

La Introducción y la página del catálogo de ISO subrayan el mismo punto: el reentrenamiento y las actualizaciones requieren atención de seguridad, porque las entradas operativas pueden convertirse en datos de entrenamiento. El apartado 6.7 contempla el Model Poisoning directo en desarrollo u operación, 7.3 trata la continuidad de las medidas, 7.4 describe la degradación del modelo y de las medidas, y 5.3 extiende Zero Trust desde la gestión de los datos de entrenamiento hasta la operación de agentes. Para los CISO esto significa que toda realimentación de datos de usuario hacia un modelo, también a través de funciones de feedback, almacenes de memoria o índices RAG, es una transición a la fase de entrenamiento y requiere las mismas aprobaciones que la adquisición de datos original.

6.2 Data Poisoning: integridad de los datos de entrenamiento

Data Poisoning manipula los datos de los que aprende un modelo y actúa en el desarrollo y el entrenamiento, y en el aprendizaje continuo también en la operación. Las variantes dirigidas falsean la integridad de los datos de entrenamiento y de la salida; las no dirigidas afectan a la disponibilidad. La norma trata los ataques de backdoor como término genérico, no como tipo de compromiso propio. La evaluación del FDIS describe el apartado de detección como un reconocimiento: los procedimientos automatizados no separan de forma fiable los datos envenenados de los valores atípicos. Por eso la mitigación se desplaza hacia delante, a la procedencia, a las comprobaciones de integridad a lo largo de la pipeline y a la limitación de los datos que llegan siquiera a un modelo (6.11.4, 6.11.2). El envenenamiento de una base de recuperación no lo trata la norma como tipo propio; OWASP recoge para ello LLM05, LLM09 y ASI06, MITRE ATLAS la técnica AML.T0080, y la guía orientativa de la BaFin menciona expresamente el envenenamiento del conocimiento de una base RAG. Recomendación VamiSec: aprobar los índices RAG, los almacenes de memoria y los datos de feedback como si fueran datos de entrenamiento.

6.7 Direct Model Poisoning: manipulación del propio modelo

El Model Poisoning directo según 3.18 no actúa sobre los datos, sino directamente sobre el modelo, en el desarrollo o en la operación; se ve afectada la integridad del modelo. Según nuestra lectura, la familia de medidas comprende la protección del entorno de desarrollo según 7.6, firmas y sumas de comprobación para los artefactos del modelo y la ejecución en un Trusted Execution Environment, que la cláusula 3 toma de ISO/IEC 27071. Dos casos muestran el mecanismo: PoisonGPT, de julio de 2023, un GPT-J-6B manipulado mediante edición del modelo bajo el typosquat «EleuterAI» en Hugging Face, y nullifAI, de febrero de 2025, dos modelos con archivos pickle corruptos y reverse shell. Ambos son, en lo esencial, pruebas de concepto. La frontera con la cadena de suministro es difusa, por lo que el capítulo 13 de esta página trata por separado el aprovisionamiento de modelos.

6.8 y Anexo B: datos que el modelo revela

Sensitive Model Output según 6.8 significa que un modelo revela a través de su salida datos de entrenamiento confidenciales o, según 3.22, también entradas anteriores, durante la inferencia; según nuestra lectura, la mitigación consiste en filtros de salida y en la limitación de datos según 6.11.2. El Anexo B añade las vías convencionales hacia el mismo resultado: el robo directo de datos de entrenamiento y la fuga de entradas del modelo, definidos en 3.20 y 3.21. El ejemplo más destacado de 6.8 es EchoLeak, una vulnerabilidad zero-click en Microsoft 365 Copilot a través de la cual podían exfiltrarse datos internos por la salida (CVE-2025-32711, corregida en mayo de 2025). Membership Inference y Model Inversion se tratan en el capítulo 7 de esta página.

Evasion: engañar en lugar de manipular

Evasion es el ataque clásico contra los modelos predictivos: una imagen, una transacción o un texto se alteran mínimamente y la clasificación cambia. La norma sitúa la detección en 7.7, que separa las entradas fuera de distribución de las entradas adversarias. La mitigación incluye el adversarial training; las abreviaturas EOT, RT e IDBT de la cláusula 4 apuntan a transformaciones de entrada como técnica adicional, aunque su asignación a 6.3.4 es nuestra lectura. Decisiva es la indicación de 7.2: según la evaluación del FDIS, la norma cita un adversarial training que aumentó la susceptibilidad a ataques de parche y recomienda por ello probar todas las medidas de forma conjunta antes de que un modelo entre en operación. Hasta ahora no se ha hecho público ningún incidente de evasión verificado en producción.

Model Exfiltration: robo mediante consultas

La Introducción cita Model Exfiltration como ejemplo paradigmático de que todos los controles estándar pueden estar intactos y el modelo perderse igualmente, porque cada consulta individual es legítima. La detección y la defensa se apoyan en el registro y la monitorización según 7.5, para lo que la norma cita expresamente ISO/IEC 27002 8.15 y 8.16, en la limitación de tasa del uso del modelo según 7.8 y en la optimización del tamaño del modelo según 7.9. El Anexo B sitúa junto a ello el robo directo del modelo según 3.19, que 5.1 menciona como motivo para endurecer primero la pila de software. El caso más conocido es una acusación: a partir del 28/01/2025, OpenAI manifestó que DeepSeek podría haber destilado sus modelos de forma indebida; no se publicaron pruebas.

Membership Inference y Model Inversion: confidencialidad de los datos de entrenamiento

Ambos ataques explotan que los modelos memorizan parcialmente sus datos de entrenamiento y los revelan a través de probabilidades, valores de confianza o formulaciones. Según nuestra lectura, la mitigación actúa en tres puntos: differential privacy en el entrenamiento, cuya abreviatura DP recoge la cláusula 4, limitación de las salidas a lo necesario y limitación de datos según 6.11.2. Para 2024 a 2026 no hay constancia pública de ningún incidente en producción; la bibliografía remite, con el trabajo de Carlini sobre la extracción de datos de entrenamiento de modelos de lenguaje, a la base de investigación. La Ley de IA agrupa estos ataques bajo Confidentiality Attacks, la guía orientativa de la BaFin bajo el término colectivo Inference Attacks, y recomienda la privacidad diferencial frente a las inferencias derivadas de consultas múltiples.

Lo que dice la norma sobre la IA generativa

La cláusula 3 define foundation model, LLM e IA generativa (3.27 a 3.29) y formula Prompt Injection en 3.23 de modo que quedan cubiertos los contenidos que actúan como instrucción de entrada o dentro de ella, con lo que se incluye la inyección indirecta a través de documentos, páginas web o correos electrónicos. El apartado 6.9 asigna el ataque a la inferencia; se ven afectadas la integridad de la salida y la confidencialidad de información interna del sistema, como los system prompts. Según nuestra lectura, la mitigación comprende el filtrado de entradas de 7.7, la separación entre instrucción y datos, y la aprobación humana para acciones con consecuencias. El apartado 6.10 trata el caso de que la propia salida del modelo transporte ataques de inyección contra sistemas posteriores; según nuestra lectura, la defensa reside en la codificación de salida y en listas de permitidos del lado del receptor. RAG aparece en la cláusula 4 y dos veces en 5.3, donde cada consulta de documentos debe autenticarse y autorizarse individualmente.

Lo que dice la norma sobre los agentes y lo que no

La palabra agente aparece tres veces en las partes de acceso libre, exclusivamente en 5.3: en el ejemplo de verificación de acciones de agentes, en el que cada acción se verifica y autoriza individualmente, el acceso se concede just-in-time con alcance limitado y los derechos caducan al finalizar la tarea, y en la fórmula del ciclo de vida hasta la operación de agentes. La palabra tool no figura en las partes de acceso libre, MCP falta en la lista de abreviaturas y en la bibliografía, agente de IA no está definido, y no se citan ni OWASP Top 10 for LLM Applications, ni la Agentic Top 10, ni NIST AI 100-2. Heise resume que la primera edición solo trata de forma marginal los sistemas agénticos con acceso a herramientas. Es consecuencia del ritmo de normalización: el Committee Draft data de enero de 2024 y la oleada de incidentes agénticos comenzó en 2025.

Casos reales 2025 a 2026: Prompt Injection es operativa

La lista de casos para 6.9 y 6.10 es larga y en su mayoría real: EchoLeak en Microsoft 365 Copilot (zero-click, corregida en mayo de 2025), ForcedLeak en Salesforce Agentforce, en el que datos de CRM fluyeron como solicitud de imagen hacia un dominio caducado de la lista de permitidos (CVSS 9.4), ShareLeak en Copilot Studio (CVE-2026-21520), la demostración de investigación Comment and Control de abril de 2026, en la que una inyección en el título de un pull request llevó a un agente de programación a publicar su propia clave de API, y la vulnerabilidad en la GitHub Action de Claude Code (corregida el 05/05/2026). Unit 42 contabilizó en marzo de 2026 doce casos de prompt injection indirecta en entornos reales con 22 técnicas de payload. Para 6.10 es instructivo Amazon Q Developer 1.84.0: el código introducido debía iniciar un agente sin confirmación con todos los permisos de herramientas y borrar datos, pero fracasó por un error de sintaxis (CVE-2025-8217).

Las dos frases vinculantes de 5.1 y qué significan

En las partes de libre acceso de la norma, según nuestra revisión, hay dos frases formuladas con carácter vinculante en el texto técnico, ambas en 5.1 —sin contar el texto estándar formal del prólogo (Foreword)—: los controles de seguridad de la información, tal como los describe ISO/IEC 27002, deben implantarse con un enfoque basado en riesgos, y los compromisos específicos de la IA, incluidos los enumerados en la Tabla 1, deben tenerse en cuenta a lo largo de todo el ciclo de vida. Todo lo demás en las partes accesibles es orientación; no es posible indicar una cifra total para el documento completo, porque las páginas 8 a 50 solo están disponibles en la versión completa. La norma no contiene en ningún caso requisitos certificables. El mensaje es claro: primero el SGSI, después la extensión específica para IA. 5.1 trata los sistemas de IA como componentes de software integrados y señala el endurecimiento de la pila de software contra el robo directo de modelos como punto de partida eficiente.

5.2 Programa de gobernanza: inventario, análisis de riesgos, tratamiento

El apartado 5.2 describe tres componentes: un inventario de los sistemas de IA, un análisis de riesgos y el tratamiento de los riesgos identificados. Para la gobernanza, la norma remite a ISO/IEC 38507; para la implantación como sistema de gestión, a ISO/IEC 42001. Lo que no hace: la cláusula 3 no define ni los roles de proveedor (provider) y responsable del despliegue (deployer) de la Ley de IA ni los roles de las partes interesadas de ISO/IEC 22989. Quien asigne responsabilidades lo hace como interpretación propia y debería señalarlo así en el documento de gobernanza.

Qué debe incluir el inventario de IA

• Origen y versión del modelo: entrenado internamente, modelo de código abierto de un repositorio, modelo fundacional en el propio tenant o API externa; la variante de obtención determina la superficie de ataque.
• Fuentes de datos de entrenamiento, fine-tuning y recuperación (retrieval) con procedencia, aprobación y propietario; 6.11.4 trata la procedencia del sistema y de los datos como tema propio.
• Acceso de consulta y API: quién puede consultar el modelo y con qué límites, base contra la extracción (6.5) y los ataques de inferencia (6.4, 6.6).
• Herramientas, acciones y permisos de los componentes agénticos; el análisis jurídico en arXiv 2604.04604 cita un inventario completo de acciones externas y flujos de datos como primera obligación.
• Propietario, criticidad y clasificación regulatoria: alto riesgo según la Ley de IA, función crítica o importante según DORA, producto con elementos digitales según el CRA.

El punto ciego se llama Shadow AI: en la encuesta de CSA/Token Security del 21/04/2026, el 82 % de 418 encuestados informó de agentes de IA desconocidos, y según el informe de IBM del 30/07/2025, en el 97 % de las brechas de seguridad relacionadas con IA faltaban controles de acceso a la IA. Los estudios están patrocinados por proveedores, pero la dirección es inequívoca: sin inventario, el análisis de riesgos según 5.2 queda incompleto, y cada medida solo alcanza a los sistemas que se conocen.

Nota para citas: la Tabla 1 se referencia en 5.1, pero no figura allí; su ubicación y contenido solo pueden consultarse en la versión completa. Esta página cuenta los nueve tipos de 6.2 a 6.10.

Ingeniería de software para IA (5.4): sin vía especial

El apartado 5.4 traslada prácticas consolidadas del desarrollo de software a los sistemas de IA; la norma remite al NIST Secure Software Development Framework (SP 800-218), y la bibliografía incluye además las directrices del NCSC para el desarrollo seguro de IA. La postura es pragmática: un sistema de IA es ante todo software, y quien no endurece su pila pierde el modelo por vías convencionales; el Anexo B recoge el robo directo de modelos como variante específica de IA de un ataque clásico. En ISO/IEC 42001, la correspondencia según nuestra lectura está en A.6.2.3, la documentación de diseño y desarrollo, que 27090 cita en 5.1.

Defensa centrada en los datos: procedencia, integridad, limitación

Detección: una cuestión de investigación abierta

En la detección del Data Poisoning (6.2.3) la norma es llamativamente cauta: según la evaluación basada en el FDIS, describe el tema como cuestión de investigación abierta, porque los procedimientos automatizados no separan de forma fiable los datos envenenados de los valores atípicos. De ello se deriva una ponderación que compartimos: la prevención mediante procedencia, aprobación y acceso pesa más que la detección a posteriori, y la monitorización de la degradación del modelo en 7.4 se convierte en la segunda línea de defensa. La introducción nombra el mecanismo que traslada el tema a la operación: con el aprendizaje continuo, los datos operativos se convierten en datos de entrenamiento, y cada ronda de reentrenamiento es un nuevo vector de poisoning.

Para la Retrieval Augmented Generation rige el mismo principio en el lado del conocimiento: 5.3 describe, en el ejemplo sobre límites de la aplicación, que cada consulta de documentos se autentica y autoriza individualmente, y la guía orientativa de la BaFin habla de envenenamiento del conocimiento de la base RAG (p. 29). Quien carga documentos corporativos sin verificar en un índice vectorial construye por sí mismo el vector de poisoning.

Qué dice la norma sobre las pruebas

La cláusula 5 sitúa el Threat Modelling en 5.6 y el Red Teaming en 5.7 junto a la gobernanza y la cadena de suministro como prácticas básicas; cada tipo de compromiso de la cláusula 6 incluye un subapartado sobre detección. La cláusula 7 justifica por qué no basta con probar una sola vez: 7.2 describe interacciones entre medidas y cita como ejemplo que el entrenamiento adversarial aumentó la vulnerabilidad frente a ataques de parche; la norma recomienda probar todas las medidas conjuntamente antes del despliegue. 7.4 añade la degradación con el tiempo, con monitorización, reentrenamiento cuando sea necesario y revalidación antes de volver a la operación.

Cuándo probar: desencadenantes en lugar de calendario

• Antes del despliegue: probar todas las mitigaciones conjuntamente, porque pueden debilitarse entre sí (7.2).
• Tras cambios en el modelo, el system prompt o la fuente de recuperación: los tres desencadenantes que Kertos cita para repetir el Red Teaming.
• Tras cada ronda de reentrenamiento: revalidación antes de volver a la operación (7.4).
• Tras actualizaciones de modelo de un proveedor: por eso los anuncios de actualización deben formar parte de los requisitos para proveedores; Kertos los cita como punto contractual, y la guía orientativa de la BaFin menciona para modelos adquiridos la due diligence y los SLA como práctica (cap. IV.2).
• De forma recurrente para medidas cuya eficacia disminuye: los filtros de entrada y los umbrales de anomalías envejecen con el panorama de amenazas.
• En sistemas agénticos, tras cada cambio en herramientas, permisos o integraciones (recomendación VamiSec más allá de 5.3).

La conexión regulatoria es estrecha: para la IA de alto riesgo, la Ley de IA exige en el art. 9, apartados 6 a 8, pruebas dentro de la gestión de riesgos; DORA exige en los art. 24 y 25 un programa de pruebas con pruebas de penetración y revisiones del código fuente, y la BaFin describe como práctica, según la criticidad, adversarial testing, pruebas de penetración adversariales con el proveedor de nube y pruebas de estrés. ISO/IEC 27090 aporta los conceptos de ataque y la lógica de las pruebas, no la obligación.

En ISO/IEC 27090, el Red Teaming no es una prueba obligatoria ni de certificación. El alcance y la periodicidad los determinan el análisis de riesgos, la criticidad y, cuando proceda, la Ley de IA, DORA o el CRA.

5.3 Zero Trust: cinco ejemplos que se integran en todas las mitigaciones

• Protección de los datos de entrenamiento: la norma la sitúa al inicio de la lista de ejemplos.
• Controles de acceso al modelo, incluido el acceso a través de RAG.
• Límites de la aplicación: cada consulta de documentos se autentica y autoriza individualmente; ninguna relación de confianza generalizada entre el modelo y la fuente de datos.
• Verificación de las acciones de agentes: autorización individual por cada acción del agente, permisos solo durante la duración de la tarea.
• Monitorización continua desde el entrenamiento, pasando por el despliegue, hasta la operación de los agentes.

Esta línea coincide con los documentos de las autoridades desde 2025: el BSI y la ANSSI describen en sus Design Principles para sistemas basados en LLM del 11/08/2025 seis principios, desde autenticación y autorización, pasando por sandboxing y monitorización, hasta concienciación, y dejan constancia de que un LLM nunca debe autenticar por sí mismo; la NSA constata en su análisis de seguridad de MCP de mayo de 2026 que la autorización es opcional en el protocolo. Según nuestra valoración, ISO/IEC 27090 no es la formulación más detallada de este consenso, pero sí la que mejor se integra con el SGSI y el SGIA.

Medidas operativas por tipo de compromiso

Detección e incidentes: qué dice la norma y qué debe aportar el SGSI

La introducción formula el núcleo: la detección es difícil pero esencial, y la exfiltración de modelos se logra mediante consultas legítimas pese a controles estándar intactos; el rate limiting ayuda. Por eso cada tipo de compromiso tiene un apartado de detección, y 7.5 agrupa logging y monitorización. La estructura de la norma no tiene un apartado propio sobre gestión de incidentes; a nuestro juicio, la gestión de incidentes del SGSI necesita tres complementos: etiquetado de IA para los incidentes, vías de notificación a los proveedores de modelos y reglas de detección para patrones de consulta, llamadas a herramientas y anomalías en las salidas.

Los casos reales de la operación muestran que la ruta de salida es superficie de ataque: EchoLeak (CVE-2025-32711, CVSS del CNA 9.3) permitió, mediante una inyección zero-click, la fuga de datos internos de M365 a través de la salida de Copilot; corregido en mayo de 2025, sin explotación conocida; ForcedLeak aprovechó en Salesforce Agentforce un dominio caducado de la allowlist para la fuga de datos de CRM; la Claude Code GitHub Action leyó, tras una inyección en textos de issues, variables de entorno fuera del sandbox. En los tres casos, según nuestra valoración, los filtros de salida, las allowlists y el logging de llamadas a herramientas de 6.8.4, 6.10.4 y 7.5 habrían dificultado o hecho visible la fuga. En el sector financiero se añade el plan de acción que la supervisión bancaria del BCE espera de las entidades significativas hasta el 31/10/2026, que incluye logging y verificación continua de API y cuentas de servicio, aunque con la mirada puesta en la IA como herramienta de ataque, no en las amenazas de 27090.

El logging según ISO/IEC 27002 8.15 y el art. 12 RTS RMF sirve a la seguridad; las obligaciones de registro según los art. 12 y 26 de la Ley de IA son un régimen propio; documente ambos requisitos por separado.

Según el análisis basado en el FDIS, el apartado 5.5 cita como elementos de la cadena de suministro los modelos preentrenados, los conjuntos de datos adquiridos, las herramientas MLOps y las plataformas de notebooks. Para los actores a lo largo de la cadena, el apartado 5.1 remite a los controles A.6.2.3 y A.6.2.6 de ISO/IEC 42001, y el anexo B, según la presentación basada en el DIS, incluye también los ataques a la cadena de suministro como variante específica de IA de los ataques convencionales. La norma describe así la cadena desde la fuente de datos, pasando por el modelo, hasta el entorno de herramientas, sin privilegiar ninguna modalidad de aprovisionamiento.

Tres variantes de aprovisionamiento, tres perfiles de riesgo

AI-BOM: qué debería contener la lista de materiales

• Modelos con fuente, versión, hash o firma y licencia, incluidos los modelos base detrás de los fine-tunings.
• Conjuntos de datos con procedencia, aprobación y finalidad de uso (entrenamiento, fine-tuning, recuperación, prueba).
• Paquetes y bibliotecas con fijación de versiones (pinning), verificación de hash y contraste con los avisos de seguridad (advisories).
• Herramientas, conectores y servidores MCP de los sistemas agénticos con sus permisos.
• System prompts, plantillas de prompts y fuentes de recuperación: cada cambio es un desencadenante de pruebas.
• Compromisos del proveedor conforme a ISO/IEC 27002 5.19/5.20: uso de las entradas para el entrenamiento, verificación de componentes preentrenados, anuncio de actualizaciones, pruebas frente a evasión e inyección.

La Cybersecurity Information Sheet conjunta sobre riesgos de la cadena de suministro de IA/ML, publicada en la lista de la NSA el 13/03/2026, recomienda la AI-BOM como complemento de la SBOM. La guía orientativa de la BaFin cita como práctica para las entidades financieras la diligencia debida, los SLA y una salida con exportación de modelos, datos de entrenamiento y metadatos (cap. IV.2); la EIOPA espera de las aseguradoras, en su Opinion de 06/08/2025, información y garantías de los proveedores terceros. ISO/IEC 27090 aporta los conceptos de ataque con los que estas exigencias pueden formularse de forma concreta frente al proveedor.

Casos reales 2024–2026: la cadena de suministro como vía preferente

Dos lecciones: en primer lugar, la infraestructura reacciona — PyPI rechaza desde el 22/07/2026 nuevos archivos para releases con más de 14 días de antigüedad. En segundo lugar, eso no basta: el incidente de octubre se produjo con un tag de Git limpio y Trusted Publishing activado. Para los operadores esto significa fijación de versiones con verificación de hash, un espejo interno con retardo de aprobación, secretos de corta duración con alcance limitado — y la constatación de que las propias credenciales de las herramientas de IA se han convertido en objetivo.

Tres normas, tres roles — y la norma hermana 27091

Mecánica de la SoA: 27090 como fuente de controles

ISO/IEC 27001 permite en 6.1.3 determinar medidas de cualquier fuente; el anexo A es lista de comprobación, no límite. Justo ahí 27090 resulta conectable: las mitigaciones de 6.x.4 y de la cláusula 7 pueden citarse como fuente en la declaración de aplicabilidad — por ejemplo 6.8.4 para filtros de salida o 6.9.4 contra prompt injection — sin un segundo sistema de gestión. Para su identificación sirven los atributos de control conforme a ISO/IEC 27002 4.2. No está registrada ninguna enmienda de IA a 27002:2022, ni tampoco una revisión de 42001:2023; lo único nuevo es ISO/IEC AWI 42003 como guía de implementación de 42001.

1. 1
   ISO/IEC 27002 5.9 · 42001 A.4.3Inventariar los sistemas de IA como activos

   Registrar por sistema la fuente del modelo, los datos de entrenamiento y de fine-tuning, las fuentes de recuperación, el acceso de consulta y los permisos agénticos.

2. 2
   ISO/IEC 27001 6.1.2 · 27090 cláusula 6Incorporar los nueve tipos a la evaluación de riesgos

   Evaluar por sistema qué tipos de compromiso y variantes del anexo B son realistas — en relación con la variante de aprovisionamiento y la fase del ciclo de vida.

3. 3
   ISO/IEC 27001 6.1.3Seleccionar medidas y citar 27090 en la SoA

   Documentar las mitigaciones seleccionadas con el número de apartado, justificar las excluidas, anotar las interacciones conforme a 7.2.

4. 4
   ISO/IEC 27002 5.19/5.20 · 42001 A.10.3Ampliar la evaluación de proveedores a los proveedores de modelos

   Aplicar el cuestionario del capítulo 13 de esta página, archivar las respuestas en la AI-BOM, fijar contractualmente los compromisos sobre actualizaciones y pruebas.

5. 5
   ISO/IEC 27090 5.7 · 42001 A.6.2.4Probar y repetir ante cada cambio

   Red Teaming antes de la puesta en servicio y tras cada cambio de modelo, system prompt o fuente de recuperación; devolver los informes al registro de riesgos y a la SoA.

Qué preguntarán los auditores en el futuro

Sobre el panorama de certificación: la base de acreditación para los certificadores de 42001 es ISO/IEC 42006:2025. En la base de datos de la DAkkS no figuraba a 22/10/2026 ningún organismo de certificación acreditado para ISO/IEC 42001, mientras que para ISO/IEC 27001 hay 37 organismos listados; a nivel internacional, entre otros, BSI Group (ANAB, UKAS, RvA) y DQS (ANAB) obtuvieron acreditaciones en marzo de 2026. Quien aspire a un certificado 42001 debería comprobar individualmente el acreditador del organismo elegido.

Formulaciones como «certificación ISO 27090», «conforme a 27090» o «auditoría según 27090» son objetivamente incorrectas; lo correcto es: medidas conforme a ISO/IEC 27090 implementadas en el SGSI según 27001 o en el AIMS según 42001.

Art. 15, apartado 5, Ley de IA: conceptos que 27090 desarrolla

La vía de presunción a través del art. 42 merece una mirada atenta: el apartado 2 remite a certificados bajo un esquema del Cybersecurity Act, pero ENISA no dispone hasta hoy de ningún esquema candidato para IA. Lo prácticamente utilizable es el apartado 3, introducido por el Reglamento Omnibus — la IA de alto riesgo dentro del ámbito de aplicación del CRA se considera conforme con el art. 15 cuando se cumplen los requisitos del art. 12, apartado 1, del CRA y se acreditan en la declaración UE de conformidad. La implementación del CRA sostiene así la vertiente de ciberseguridad de la Ley de IA; 27090 es, según nuestra valoración, la herramienta con la que pueden concretarse los requisitos del anexo I del CRA para el componente de IA.

Un segundo punto afecta a los roles: conforme al art. 25 de la Ley de IA, un responsable del despliegue se convierte en proveedor cuando comercializa un sistema de alto riesgo bajo su propio nombre, lo modifica sustancialmente o cambia su finalidad; el fine-tuning de modelos ajenos puede superar ese umbral y, dado que 27090 no define los roles, la asignación de las medidas al propio rol debe hacerse de forma explícita en el documento de gobernanza. Sobre el estado en la región DACH: no existe una versión alemana, DIN Media y SNV distribuyen el original en inglés, no se conoce una adopción como ÖNORM y el BSI no menciona la norma en ninguna publicación; la adopción británica BS ISO/IEC 27090:2026 está anunciada para el 31/10/2026. TÜV Rheinland aconsejó en mayo de 2026 no esperar a las normas armonizadas — tras la Enquiry rechazada de prEN 18282, eso vale aún más.

ISO/IEC 27090 no genera presunción de conformidad conforme a la Ley de IA ni al Cyber Resilience Act; para ello está prevista prEN 18282 de CEN/CENELEC JTC 21, todavía en borrador. El mandato de normalización M/613 sustituye a M/593; si lo deroga o modifica formalmente no está documentado públicamente.

1. 1
   Días 1–14 · 27090 5.2 · 27001 6.1Aclarar mandato, alcance y nivel objetivo

   La dirección confirma la iniciativa y designa responsables; el alcance comprende todos los sistemas de IA, incluido el uso de API; derivar el nivel objetivo por sistema a partir de la clasificación de alto riesgo, la criticidad y la variante de aprovisionamiento.

2. 2
   Días 15–45 · 27002 5.9 · 27090 5.6Inventario y modelo de amenazas

   Construir el inventario de IA con AI-BOM; por sistema, un modelo de amenazas según los nueve tipos y el anexo B; registrar por separado los agentes con sus herramientas y permisos.

3. 3
   Días 46–90 · 27001 6.1.2/6.1.3 · 27090 cláusula 6Evaluación de riesgos y SoA

   Evaluar los riesgos, seleccionar mitigaciones de 6.x.4 y de la cláusula 7, citar 27090 en la SoA; medidas inmediatas: presupuestos de consultas, registro de entradas, salidas y llamadas a herramientas, fijación de versiones con verificación de hash.

4. 4
   Meses 4–6 · 27090 5.3, 5.5, 7.5–7.8Endurecer: Zero Trust, cadena de suministro, operación

   Reestructurar el acceso a modelos y datos conforme a 5.3, permisos de agentes just-in-time con alcance y caducidad; ampliar la evaluación de proveedores a los proveedores de modelos; poner en operación filtros de entrada y salida, throttling y detección de anomalías.

5. 5
   Meses 7–9 · 27090 5.7, 7.2, 7.4Probar: Red Teaming e interacciones

   Red Teaming de los sistemas priorizados, probar conjuntamente las mitigaciones, medir también el rendimiento del modelo; anclar en la gestión de cambios los desencadenantes de pruebas para cambios de modelo, prompt y recuperación.

6. 6
   Meses 10–12 · 42001 A.6.2.6 · 27001 revisión por la direcciónDemostrar la eficacia y cerrar el ciclo

   Analizar los informes de monitorización y de deriva, devolver los resultados de las pruebas al registro de riesgos y a la SoA, informar de los indicadores a la dirección, derivar de la autoevaluación la hoja de ruta del año siguiente.

Indicadores que el consejo de administración entiende

Objeciones — y lo que respondemos

Como comprobación de plausibilidad sirve el modelo de madurez de tres niveles de Abilene Academy: un mínimo a los 30 días con inventario, modelos de amenazas y registro de las llamadas de inferencia y a herramientas; un estado consolidado a los 90 días con evidencias de procedencia, pruebas de Red Team, requisitos a proveedores y respuesta a incidentes de IA; y un estado avanzado con monitorización continua, revisión de los cambios de modelo y verificación de los permisos de los agentes. El principio allí formulado de tratar cada artefacto de modelo, cada conjunto de datos, cada plantilla de prompt y cada permiso de herramienta como superficie de ataque coincide con nuestra lectura de la norma.

ISO/IEC 27090 es una norma de orientación sin requisitos certificables. Vinculantes son las obligaciones derivadas del propio SGSI o AIMS, así como de la Ley de IA, el CRA, NIS2 y DORA. La hoja de ruta es una recomendación de VamiSec y no constituye asesoramiento jurídico.