ISO/IEC 27090 es la norma internacional que se ocupa de proteger a los sistemas de inteligencia artificial. Su título lo dice sin rodeos: atender las amenazas y los compromisos de seguridad propios de la IA. ISO e IEC la publicaron en octubre de 2026, y llega para cubrir lo que la seguridad de siempre no alcanza a ver en un modelo: los datos con los que aprende, las consultas con las que se le puede robar y las instrucciones con las que se le puede manipular.
No sustituye a nada que su organización ya tenga. Se apoya en ISO 27001 e ISO 27002 para la seguridad de la información y convive con ISO 42001, que gobierna el uso de la IA en toda la organización. Lo que agrega es el detalle técnico: qué activos de la IA hay que proteger, cómo se comprometen, cómo se detecta el ataque y cómo se mitiga durante todo el ciclo de vida del sistema.
Esta guía explica qué es la norma, por qué importa hoy, las amenazas que atiende, sus tres áreas de guía, cómo encaja con 27001 y 42001, nuestro cruce contra MITRE ATLAS, MITRE ATT&CK, OWASP y NIST AI RMF, y por dónde empezar.
Qué es ISO/IEC 27090:2026
ISO/IEC 27090:2026, «Cybersecurity · Artificial intelligence (AI) · Addressing security threats and compromises to AI systems», es una guía de 56 páginas elaborada por el subcomité ISO/IEC JTC 1/SC 27, el mismo que mantiene ISO 27001. Se publicó en octubre de 2026 como primera edición.
Su objetivo es ayudar a las organizaciones a entender, detectar y mitigar las amenazas de seguridad propias de los sistemas de IA a lo largo de todo su ciclo de vida, desde los datos de entrenamiento hasta el modelo en operación y sus actualizaciones. Explica cómo se pueden explotar las debilidades de un sistema de IA, qué consecuencias tiene y qué medidas ayudan a contenerlo.
Tres precisiones evitan confusiones frecuentes:
- Es una guía, no un sistema de gestión. No fija requisitos auditables ni se certifica. Lo certificable en IA sigue siendo ISO 42001, y en seguridad de la información, ISO 27001.
- Trata de proteger a la IA, no de usar IA para defender otros sistemas.
- No se limita a la IA generativa ni a los chatbots. Aplica a cualquier sistema de IA, propio o de terceros, en organizaciones de cualquier tamaño, públicas o privadas.
Para sus conceptos se apoya en ISO/IEC 22989 (terminología de IA) e ISO/IEC 23053 (marco para describir sistemas de IA que usan aprendizaje automático).
Por qué la seguridad de la IA importa hoy
Un sistema de IA sigue expuesto a todo lo que amenaza al software y a la infraestructura. Pero además tiene superficies de ataque que un firewall, un antivirus o un control de acceso no ven. Estas son las razones por las que la norma llega en buen momento:
- La IA ya opera en producción. Ya no vive solo en el navegador: está en las aplicaciones de oficina, en el editor de código y en agentes que corren solos en servidores. Lo explicamos en La IA ya salió del navegador.
- Los datos son superficie de ataque. Si alguien mete datos maliciosos en el entrenamiento, o en los datos que se juntan en operación y luego sirven para reentrenar, el daño queda dentro del modelo.
- Un acceso legítimo puede servir para robar. Con suficientes consultas que parecen normales se puede reconstruir un modelo. Controlar quién entra no basta si nadie vigila cómo se usa.
- El catálogo de ataques ya lo reconoce. En octubre de 2026, MITRE ATT&CK v20 incorporó la inyección de instrucciones y la exfiltración por agentes de IA, y dejó claro que varias todavía no tienen estrategia de detección. Lo analizamos en MITRE ATT&CK v20.
- Las consecuencias van más allá de la información. Cuando la IA influye en decisiones o en procesos físicos, un modelo comprometido puede dañar a personas.
- Los clientes van a preguntar. Igual que hoy piden ISO 27001 a sus proveedores, empezarán a preguntar cómo se protege la IA que se les entrega o que procesa sus datos. ISO 27090 les da el vocabulario para hacerlo.
Las amenazas que atiende ISO 27090
La norma agrupa los compromisos de un sistema de IA en familias. Esta es nuestra lectura, en lenguaje llano, de las que la propia ISO destaca:
| Amenaza | Qué pasa | Dónde aparece |
|---|---|---|
| Envenenamiento de datos | Datos maliciosos en el entrenamiento tuercen el comportamiento del modelo. | Datos, entrenamiento y reentrenamiento |
| Exfiltración del modelo | El modelo sale de la organización, robado o reconstruido con consultas que parecen legítimas. | Operación |
| Evasión | Entradas diseñadas para que el modelo se equivoque, por ejemplo para que deje pasar lo que debía detener. | Operación |
| Inferencia de pertenencia | Se deduce si un registro concreto formó parte del entrenamiento. Es un riesgo de privacidad. | Operación |
| Inversión del modelo | Se reconstruye información sensible del entrenamiento a partir de las respuestas. | Operación |
| Envenenamiento directo del modelo | Se altera el modelo mismo, o llega comprometido desde un tercero. | Desarrollo y cadena de suministro |
| Inyección de instrucciones | El modelo obedece instrucciones maliciosas, escritas directo o escondidas en documentos, correos o páginas que procesa. | Operación |
| Salida sensible del modelo | La respuesta revela datos confidenciales, configuración o información de otros usuarios. | Operación |
| Salidas con ataques de inyección | La respuesta trae código o comandos que otro sistema ejecuta sin validar. | Operación e integración |
La lección de fondo es la defensa en profundidad: varias capas de protección, sabiendo que algunas de estas amenazas siguen siendo difíciles de detectar. Ninguna medida aislada basta, y ninguna garantiza inmunidad.
Las tres áreas de guía de la norma
ISO 27090 organiza su guía en tres áreas conectadas:
Aplicar la seguridad de la información a la IA
Gobierno de IA, principios de confianza cero, ingeniería de software segura, seguridad de la cadena de suministro, modelado de amenazas y red teaming. Es llevar lo que ya funciona en seguridad al terreno de los modelos y sus datos.
Entender las amenazas propias de la IA
Los tipos de compromiso, sus consecuencias, cómo se detectan y cómo se mitigan. Incluye saber de dónde vienen los sistemas y los datos, y cómo limitar los efectos de un comportamiento no deseado del modelo en operación.
Mantener la protección en el tiempo
Las mitigaciones se diseñan juntas, porque una puede debilitar a otra. Bitácoras y monitoreo, protección de los entornos de desarrollo, detección de entradas maliciosas, límites al uso del modelo y revisión del deterioro de modelos y protecciones.
Lo que conviene hacer antes de todo
Inventariar los sistemas de IA propios y de terceros, saber de dónde vienen sus datos y modelos, sentar en la misma mesa a seguridad, desarrollo, datos y compras, y decidir quién detecta y quién responde.
ISO 27001, ISO 42001 e ISO 27090: cómo encajan
Las tres normas no compiten. Cada una contesta una pregunta distinta y se usan juntas:
| Norma | Pregunta que responde | Tipo | ¿Se certifica? |
|---|---|---|---|
| ISO/IEC 27001 | ¿Cómo gestiono la seguridad de la información? | Sistema de gestión (SGSI) | Sí |
| ISO/IEC 42001 | ¿Cómo gobierno la IA en toda la organización? | Sistema de gestión (SGIA) | Sí |
| ISO/IEC 27090 | ¿Cómo protejo mis sistemas de IA de las amenazas que les son propias? | Guía técnica de seguridad | No |
| ISO/IEC 27002 | ¿Cómo implemento los controles de seguridad? | Guía de controles | No |
En la práctica, ISO 42001 pide gestionar los riesgos de la IA, e ISO 27090 explica con detalle cuáles son los de seguridad y cómo atenderlos. La seguridad es parte del gobierno responsable de la IA, pero no es todo: sesgo, transparencia y supervisión humana se quedan en 42001. Y quien ya tiene ISO 27001 tiene la base, porque 27090 parte de sus prácticas y señala dónde hace falta protección adicional para datos, modelos y flujos de IA.
Cruce de ISO 27090 con ISO 27001, NIST AI RMF y MITRE
Para que la norma se pueda operar, la cruzamos contra los marcos que su equipo ya usa. Es criterio de QMA, no de ISO: ayuda a ubicar cada amenaza en un control de ISO 27001, en el NIST AI RMF y en el catálogo de técnicas de ataque que usan los equipos de detección y de Red Team.
| Amenaza | ISO 27001 (Anexo A) | NIST AI RMF | MITRE ATLAS | OWASP LLM 2025 |
|---|---|---|---|---|
| Envenenamiento de datos | A.5.21 · A.8.25 · A.8.32 · A.8.16 | MEASURE 2.7 · MANAGE 3.2 | AML.T0020 · AML.T0070 | LLM04 |
| Exfiltración del modelo | A.5.15 · A.8.12 · A.8.16 · A.8.20 | MEASURE 2.7 | AML.T0024.002 | LLM10 |
| Evasión | A.8.29 · A.8.16 | MEASURE 2.7 · MEASURE 2.4 | AML.T0015 · AML.T0043 | No aplica |
| Inferencia de pertenencia | A.5.34 · A.8.11 | MEASURE 2.10 | AML.T0024.000 | LLM02 |
| Inversión del modelo | A.5.34 · A.8.11 | MEASURE 2.10 | AML.T0024.001 | LLM02 |
| Envenenamiento directo del modelo | A.5.21 · A.8.32 · A.5.23 | MANAGE 3.2 · MAP 4.2 | AML.T0018.000 · AML.T0058 | LLM03 · LLM04 |
| Inyección de instrucciones | A.8.26 · A.8.28 · A.8.29 | MEASURE 2.7 | AML.T0051 · AML.T0054 | LLM01 |
| Salida sensible del modelo | A.8.12 · A.5.34 · A.5.12 | MEASURE 2.10 | AML.T0057 · AML.T0056 | LLM02 · LLM07 |
| Salidas con ataques de inyección | A.8.26 · A.8.28 | MEASURE 2.7 | AML.T0077 | LLM05 |
Dos lecturas que salen del cruce. La primera: ISO 27001 cubre bien la base (proveedores, desarrollo seguro, monitoreo, prevención de fuga de datos), pero ningún control del Anexo A nombra la inyección de instrucciones ni la extracción de un modelo. Esas pruebas hay que diseñarlas. La segunda: en MITRE ATT&CK v20, la inyección directa e indirecta de instrucciones (T1698 y T1699) y la exfiltración habilitada por IA (T1700) ya tienen técnica, pero solo la exfiltración trae estrategia de detección. Ahí es donde la guía de ISO 27090 y un ejercicio de Red Team valen más.
En nuestro cruce entre NIST AI RMF e ISO 27001, la cobertura directa de 27001 llega a más de la mitad en las funciones de gobierno y respuesta, y cae a 36 % en medición y a 28 % en mapeo. Quien ya tiene SGSI sabe gobernar y responder; casi nada de cómo medir y probar un sistema de IA. Ese es el hueco que llena ISO 27090.
Cómo se prueba la seguridad de un sistema de IA
La norma pide modelado de amenazas y red teaming: atacar el sistema antes de que lo ataque alguien más. En un ejercicio de Red Team aplicado a IA, estas son las pruebas que tienen más valor:
- Inyección de instrucciones directa e indirecta contra asistentes y agentes internos, incluidas las que viajan dentro de documentos y correos.
- Abuso de agentes: qué datos puede leer el agente, a qué destinos puede enviar y si se le puede convencer de usar sus herramientas para sacar información.
- Extracción y fuga: consultas masivas para reconstruir el modelo o para hacerle revelar su configuración o datos de entrenamiento.
- Evasión: entradas diseñadas para que un clasificador o un filtro deje pasar lo que debía detener.
- Cadena de suministro: origen e integridad de los modelos, datos y bibliotecas de terceros.
Y del lado de la detección, el monitoreo: registrar consultas, respuestas y acciones de agentes para detectar el abuso y reconstruir un incidente. Es la parte que opera un servicio de detección y respuesta gestionada.
QMA Certeza · seguridad de IA dentro del mismo programa
ISO 27090 rinde más cuando no se trabaja como un documento aparte. En QMA Certeza la llevamos al mismo programa de cumplimiento donde ya viven ISO 27001, ISO 42001 y NIST AI RMF: el inventario de sistemas de IA, las amenazas de cada uno, los controles que las atienden y la evidencia de que operan, con el mapeo cruzado entre marcos para no documentar dos veces lo mismo.
Mientras la norma llega a las bibliotecas de marcos de cumplimiento, la trabajamos como marco propio dentro de la plataforma, con la estructura de amenazas, áreas y cruces que se ve en esta página.
Cómo empezamos
- Diagnóstico de seguridad de IA (60 a 90 minutos). Qué sistemas de IA opera la organización, propios y de terceros, con qué datos, quién los usa y qué ya cubre su ISO 27001 o su programa de seguridad.
- Mapa de amenazas y ruta. Las amenazas de ISO 27090 que aplican a cada sistema, priorizadas por impacto, con los controles y las pruebas que hacen falta.
- Prueba y operación. Red Team contra los sistemas de IA prioritarios, monitoreo de su uso y evidencia en QMA Certeza, integrada con ISO 27001 e ISO 42001 si ya están en marcha.
Preguntas frecuentes
¿Qué es ISO/IEC 27090?
Es la norma de ISO e IEC que da guía para entender, detectar y mitigar las amenazas de seguridad propias de los sistemas de inteligencia artificial durante todo su ciclo de vida: envenenamiento de datos, robo del modelo, evasión, inferencia de pertenencia, inversión del modelo, inyección de instrucciones y salidas sensibles.
¿Cuándo se publicó ISO 27090?
En octubre de 2026, como primera edición (ISO/IEC 27090:2026), con 56 páginas. La elaboró el subcomité ISO/IEC JTC 1/SC 27, el mismo de ISO 27001.
¿ISO 27090 es certificable?
No. Es una guía, no un sistema de gestión con requisitos auditables. Una organización puede demostrar que la aplica, pero el certificado en IA se obtiene con ISO 42001 y el de seguridad de la información con ISO 27001.
¿Cuál es la diferencia entre ISO 27090 e ISO 42001?
ISO 42001 gestiona la IA en toda la organización: políticas, roles, evaluación de impacto, transparencia y supervisión humana. ISO 27090 se concentra en la seguridad de los sistemas de IA: qué amenazas los afectan y cómo detectarlas y mitigarlas. Se usan juntas.
¿Necesito ISO 27001 para aplicar ISO 27090?
No es requisito, pero es la base natural. ISO 27090 parte de las prácticas de ISO 27001 e ISO 27002 y agrega lo que la IA necesita además. Quien ya tiene un SGSI avanza mucho más rápido.
¿ISO 27090 solo aplica a la IA generativa?
No. Aplica a cualquier sistema de IA, desde un clasificador de fraude hasta un agente que usa herramientas, y a organizaciones de cualquier tamaño que desarrollen o usen IA, incluida la de terceros.
¿Cómo se relaciona ISO 27090 con MITRE ATLAS y OWASP?
MITRE ATLAS cataloga técnicas de ataque contra sistemas de IA y el OWASP Top 10 para LLM lista los riesgos más comunes de las aplicaciones con modelos de lenguaje. ISO 27090 da el marco de gestión de esas amenazas. En esta página está nuestro cruce entre los tres.
¿Por dónde empiezo con ISO 27090?
Por el inventario: qué sistemas de IA tiene la organización, propios y de terceros, de dónde vienen sus datos y modelos y quién los opera. Después, las amenazas que aplican a cada uno, las pruebas que hacen falta y quién detecta y responde.
Fuentes: ISO, ficha de ISO/IEC 27090:2026 y ISO/IEC 27090 explained. MITRE ATLAS 5.6.0, MITRE ATT&CK v20, OWASP Top 10 for LLM Applications 2025 y NIST AI RMF 1.0. Los cruces son criterio de QMA. Esta página no reproduce el texto de la norma; para su contenido completo, consulte la edición publicada por ISO. Última actualización: octubre de 2026.