I. El problema que nadie quería admitir
Durante tres años les dijimos a los directorios que “la IA es un activo más y se gestiona como cualquier otro”. Era verdad a medias. Los controles de la 27002 protegen el servidor donde corre el modelo, el bucket donde viven los datos y la API que lo expone; pero no describen qué pasa cuando el ataque va contra el comportamiento aprendido del modelo. Un atacante que envenena una fracción mínima del dataset de reentrenamiento, que reconstruye un modelo propietario a punta de consultas legítimas, o que esconde una instrucción en un PDF que el agente va a leer, no está explotando una CVE. Está explotando la estadística.
Hasta ahora, para hablar de eso había que recurrir a taxonomías de terceros: NIST, MITRE, OWASP, ETSI. Todas buenas, ninguna de la familia ISO 27000 dedicada a IA. Y cuando el auditor de 27001 preguntaba “¿dónde está esto en su SGSI?”, la respuesta solía ser un documento interno con cara de improvisado.
Eso cambió el 14 de octubre de 2026.
II. Qué se publicó exactamente
ISO/IEC 27090:2026 (“Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems”) es la edición 1, tiene 56 páginas, fue desarrollada por el ISO/IEC JTC 1/SC 27 y alcanzó la etapa 60.60 (norma internacional publicada) el 14 de octubre de 2026 (ISO/IEC, 2026). Su objetivo declarado es orientar en la comprensión, detección y mitigación de amenazas de seguridad específicas de sistemas de IA a lo largo de su ciclo de vida (ISO/IEC, 2026).
El camino no fue corto. El registro oficial de ISO sitúa el inicio de la votación del DIS el 16 de abril de 2025 y su cierre el 10 de julio de ese año. La aprobación para pasar a FDIS figura el 11 de marzo de 2026; la votación final comenzó el 23 de junio y terminó el 19 de agosto. La publicación llegó el 14 de octubre de 2026. Conviene distinguir el cierre de una votación de la fecha en que se registra formalmente la siguiente etapa.
Dato clave: ISO/IEC 27090 es una norma de orientación, no una norma de requisitos de sistema de gestión. No debe confundirse su aplicación con una certificación de un SGSI conforme a ISO/IEC 27001 o de un sistema de gestión de IA conforme a ISO/IEC 42001.
Datos bibliográficos contrastados con la ficha oficial de ISO.
III. Cómo está construida: tres capas y tres anexos
Leída como arquitecto de controles, la norma tiene tres capas conceptuales que conviene separar.
Capa 1 – La IA como activo de información (cláusula 5). Aquí la 27090 hace lo que un CISO esperaba: ancla la seguridad de IA al SGSI existente. Programa de gobierno de IA con inventario de sistemas y usos, evaluación de riesgos para seleccionar controles de la 27002, y principios Zero Trust llevados a terreno de IA: asumir compromiso, autenticar y autorizar cada solicitud, mínimo privilegio, cifrado extremo a extremo; aplicados al dato de entrenamiento, al acceso al modelo, a los pipelines RAG y a los agentes. Suma además prácticas de ingeniería que ya conocemos (threat modeling, revisión de código, pentest, control de versiones) y las que son propias de ML: procedencia y linaje de datos, trazabilidad del modelo, validación continua, pruebas de deriva conceptual y de obsolescencia. Red teaming aparece explícitamente como método para emular adversarios reales (ISO/IEC, 2026).
Capa 2 – El catálogo de compromisos (cláusula 6). Es el corazón técnico y lo que la distingue de todo lo anterior en la familia 27000. Organiza cada compromiso por activo afectado y propiedad de seguridad vulnerada (confidencialidad, integridad, disponibilidad), e indica si requiere un atacante activo y si aplica a IA predictiva, generativa o ambas. La lista, doce en total: envenenamiento de datos, evasión, inferencia de pertenencia, exfiltración de modelo, inversión de modelo, envenenamiento directo del modelo, robo directo de modelo, fuga directa de datos de entrenamiento, fuga de entradas del modelo, salidas sensibles, inyección de prompts y salidas que contienen inyecciones. Para cada uno: consecuencias, detección y mitigación. La subcláusula 6.11 agrega consideraciones operacionales (limitación de datos, supervisión, mínimo privilegio del modelo, transparencia, validación continua, explicabilidad, pruebas de sesgo no deseado) que reconocen algo que en la práctica ya sabíamos: muchas fallas de IA son a la vez de seguridad y de confianza (ISO/IEC, 2026).
Capa 3 – Las mitigaciones como sistema (cláusula 7). Esta es, a mi juicio, la parte más madura del texto. Dice algo que casi ningún framework de IA dice con claridad: las mitigaciones interactúan, pueden debilitar otras defensas y pierden efectividad con el tiempo. Registro y monitoreo, protección del entorno de desarrollo, detección y filtrado de entradas maliciosas, limitación de uso del modelo (throttling) y optimización del tamaño del modelo no son una checklist: son un sistema que hay que validar de forma continua, porque tanto el modelo como sus defensas se deterioran (ISO/IEC, 2026).
Los anexos cierran el círculo: A mapea ataques a ciclo de vida y activos de IA/ML; B reinterpreta ataques clásicos (DoS, cadena de suministro, backdoors) en clave de IA; C trata aprendizaje federado. Referencias normativas: ISO/IEC 22989 (vocabulario de IA) e ISO/IEC 23053 (marco para sistemas de IA basados en ML).
IV. Dónde se ubica frente a lo que ya usábamos
La pregunta práctica no es “¿reemplaza a NIST, MITRE u OWASP?”, sino “¿qué rol cumple cada pieza?”. Mi lectura:
- NIST AI 100-2e2025 es la taxonomía de referencia. Clasifica los ataques en cinco dimensiones (tipo de sistema, etapa del ciclo de vida, objetivo del atacante, capacidades y conocimiento) y, para IA generativa, incorpora cadena de suministro, inyección directa e indirecta de prompts, violaciones de uso y seguridad de agentes (Vassilev et al., 2025). Es la referencia cuando necesitas precisión conceptual.
- MITRE ATLAS es la base de conocimiento operacional: una base viva de tácticas y técnicas adversarias contra sistemas con IA, construida sobre observaciones de ataques reales y demostraciones de equipos de red team (MITRE, s. f.). Es la referencia para emular adversarios y clasificar incidentes.
- OWASP Top 10 for LLM Applications 2025 es la vista de aplicación. Mantiene la inyección de prompts en el puesto 1 e incorpora fuga del system prompt y debilidades de vectores y embeddings para sistemas RAG (OWASP GenAI Security Project, 2025). Es la referencia para el equipo de desarrollo.
- ETSI EN 304 223 es el baseline europeo de requisitos, anunciado por ETSI en enero de 2026 (versión V2.1.1 fechada en diciembre de 2025). Define 13 principios y requisitos en cinco fases (diseño, desarrollo, despliegue, mantenimiento y fin de vida seguros) y cubre sistemas con redes neuronales profundas, incluida la IA generativa (ETSI, 2026). A diferencia de la 27090, es una norma de requisitos.
La 27090 no compite con ninguna: es el puente que las conecta con el SGSI. Su valor no está en descubrir una amenaza nueva, sino en darle una ubicación ISO a las que ya conocíamos, en el mismo lenguaje (activo, propiedad, riesgo, control) que un auditor de 27001 entiende sin traducción.
| Referencia | Enfoque | Uso práctico |
|---|---|---|
| ISO/IEC 27090 | Orientación de seguridad específica de IA | Conectar amenazas, activos y mitigaciones con la gestión de riesgos. |
| NIST AI 100-2e2025 | Taxonomía de aprendizaje automático adversario | Describir escenarios y capacidades del atacante con precisión. |
| MITRE ATLAS | Tácticas y técnicas adversarias | Diseñar ejercicios de red team y clasificar incidentes. |
| OWASP LLM Top 10 2025 | Riesgos de aplicaciones con LLM | Priorizar revisiones del software, RAG y agentes. |
| ETSI EN 304 223 | Requisitos de seguridad de referencia | Definir una base de seguridad a lo largo del ciclo de vida. |
| ISO/IEC 27001 y 42001 | Requisitos de sistemas de gestión | Organizar responsabilidades, riesgos, evidencias y mejora continua. |
V. La trampa de la certificación
Como la 27090 ofrece orientación, la discusión sobre certificación se traslada al sistema de gestión. ISO/IEC 42006:2025 establece requisitos adicionales para los organismos que auditan y certifican sistemas de gestión de IA conforme a ISO/IEC 42001, complementando ISO/IEC 17021-1. ISO registra su publicación el 7 de julio de 2025. La existencia de un certificado no sustituye la revisión de su alcance, su vigencia y la acreditación del organismo emisor.
Antes de aceptar el certificado de un proveedor, comprueba qué organización y actividades cubre, quién lo emitió y qué organismo acredita a ese certificador para el alcance declarado. Desde la práctica, la 27090 aporta preguntas técnicas para revisar cómo se tratan las amenazas de IA dentro del sistema de gestión.
VI. Lo que cambia en la práctica, por rol
- Si eres CISO o responsable de GRC: la cláusula 6 te da doce compromisos con nombre y apellido. Mi recomendación es que cada uno tenga un dueño en el registro de riesgos o una justificación documentada de por qué no aplica. Si tu SGSI no tiene inventario de sistemas de IA (incluidos los de terceros y el “shadow AI” de los usuarios), empieza por ahí: sin inventario es difícil aplicar esa orientación.
- Si construyes o integras modelos: procedencia y linaje de datos, trazabilidad de versiones de modelo y validación continua dejan de ser “buenas prácticas de MLOps” y pasan a ser expectativas de seguridad citables. Documenta qué mitigaciones de la cláusula 7 activaste y mide su efecto combinado, porque la propia norma advierte que pueden debilitarse entre sí.
- Si auditas: tienes por primera vez un criterio ISO para evaluar seguridad de IA dentro de una auditoría de 27001 o 42001, sin tener que justificar por qué usas una taxonomía de NIST. La 27090 puede apoyar la evaluación de controles; no sustituye los criterios y requisitos del esquema de auditoría aplicable.
- Si operas infraestructura crítica: la introducción de la norma menciona explícitamente sectores donde una falla tiene impacto serio (salud, robótica, automotriz). Para quienes trabajamos en IT/OT/ICS, el mensaje es claro: un modelo de mantenimiento predictivo o de detección de anomalías en una red industrial es un activo cuyo comportamiento puede ser manipulado, y debe estar en el mismo análisis de riesgo que el PLC.
| Responsable | Primera acción | Evidencia esperada |
|---|---|---|
| CISO / GRC | Inventariar los sistemas de IA y sus responsables. | Registro de riesgos, alcance y decisiones de tratamiento. |
| Ingeniería / MLOps | Revisar datos, modelos, integraciones y permisos. | Linaje, versiones, pruebas y resultados de mitigación. |
| Auditoría | Acordar criterios y evaluar evidencias. | Trazabilidad entre riesgo, control, prueba y hallazgo. |
| Operación IT/OT | Incluir los modelos en escenarios de impacto operacional. | Límites operativos, monitoreo y respuesta ante fallos. |
VII. Mi lectura final
La 27090 llega tarde respecto de la velocidad de adopción de IA, pero llega bien: ancla la seguridad de IA al SGSI en lugar de inventar una disciplina paralela, reconoce que las defensas se degradan y que interactúan entre sí, y da un vocabulario común a desarrolladores, auditores y directorios. No va a decirte si tus controles son suficientes; eso sigue siendo trabajo de evaluación de riesgos y de red team. Lo que sí hace es sacar a la seguridad de IA del terreno de la opinión.
Mi impresión desde la práctica en la región es que la mayoría de las organizaciones latinoamericanas es deployer y no desarrolladora de modelos. Si eso es así, el foco está en la integración: acceso a datos, exposición de APIs, pipelines RAG, agentes con herramientas. Ahí es donde se materializan los compromisos de la cláusula 6, y ahí es donde la 27090 más ayuda.
Si ya tienes 27001, el camino es corto: inventario de IA, cláusula 6 contra el registro de riesgos, y una decisión informada sobre 42001. Si no tienes 27001, la 27090 es una buena razón para empezar.
Referencias y fuentes
- ISO/IEC. (2026). ISO/IEC 27090:2026 — Addressing security threats and compromises to AI systems.
- ISO/IEC. (2025). ISO/IEC 42006:2025 — Requirements for bodies providing audit and certification of AI management systems.
- ISO/IEC. (2023). ISO/IEC 42001:2023 — Artificial intelligence — Management system.
- Vassilev, A., et al. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025).
- MITRE. (s. f.). ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems.
- OWASP GenAI Security Project. (2025). OWASP Top 10 for LLM Applications 2025.
- ETSI. (2026, 14 de enero). ETSI releases world-leading standard for securing AI.
Consulta de fuentes públicas: 19 de octubre de 2026. Artículo de análisis de Sebastián Vargas Yáñez. Las tres capas, el mapa y las acciones por rol son una síntesis editorial. Las referencias a cláusulas proceden del análisis aportado por el autor; para aplicar la norma debe consultarse su edición oficial completa.