Qué es ISO/IEC 27090:2026
ISO/IEC 27090:2026 es una norma internacional de ISO e IEC, cuya primera edición se publicó el 14 de octubre de 2026. Está publicada: ya no es un borrador. Su ficha oficial describe orientación sobre amenazas específicas de los sistemas de IA durante su ciclo de vida, incluida la protección de datos de entrenamiento y modelos.
Puede resultar útil tanto a organizaciones que desarrollan IA como a las que la utilizan. Es una norma de orientación, no una certificación independiente. Este artículo se apoya en información pública oficial; no reproduce el texto completo ni atribuye cláusulas o controles no consultados. Las medidas y ejemplos siguientes son propuestas prácticas de Céntrika, no una transcripción del estándar.
Por qué la IA necesita medidas de ciberseguridad específicas
Una aplicación puede tener servidores protegidos y, aun así, producir resultados manipulados. El análisis de seguridad debe considerar qué aprende el modelo, qué recibe durante su uso y qué acciones puede ejecutar. La protección convencional sigue siendo necesaria: identidades, accesos, copias de seguridad y gestión de vulnerabilidades continúan siendo fundamentales.
Para analizar un sistema concreto, conviene separar sus activos: datos de entrenamiento, pesos y configuración del modelo, proceso de inferencia, entradas, salidas e integraciones. También importan las actualizaciones y los proveedores. Un asistente con acceso de lectura a documentos presenta una exposición diferente de otro que puede enviar correos o modificar expedientes. La finalidad y los permisos reales determinan qué protección tiene sentido.
Principales amenazas de ciberseguridad en IA
La ficha de ISO describe amenazas específicas de IA. Su guía explicativa, basada en el borrador final, menciona también inferencia de pertenencia, inversión y manipulación directa del modelo, así como ataques mediante entradas y salidas. NIST AI 100-2 E2025 aporta contexto sobre ataques y mitigaciones de aprendizaje automático adversario.
La tabla constituye una síntesis divulgativa de Céntrika, no una reproducción literal ni una clasificación oficial de ISO/IEC 27090. Las posibles protecciones son recomendaciones prácticas de Céntrika que deben adaptarse y probarse en cada sistema; no se presentan como controles obligatorios de la norma.
| Amenaza | Qué puede ocurrir | Consecuencia | Posible protección |
|---|---|---|---|
| Envenenamiento de datos | Se incorporan datos manipulados al entrenamiento | Comportamiento dirigido o degradado | Revisar procedencia, integridad y muestras |
| Robo o extracción del modelo | Se obtiene por acceso directo o se intenta reconstruir su funcionamiento mediante consultas | Pérdida de propiedad intelectual | Restringir acceso y detectar consultas anómalas |
| Ataques de evasión o entradas adversarias | Una entrada preparada altera la predicción durante el uso | Decisiones incorrectas | Pruebas específicas y validación contextual |
| Inyección de instrucciones (prompt injection) | Contenido no fiable intenta dirigir al asistente | Acciones o respuestas no autorizadas | Separar datos e instrucciones y limitar herramientas |
| Exposición de información sensible | Una salida revela contenido reservado | Daño a personas o negocio | Permisos por usuario y revisión de salidas |
| Inferencia de pertenencia (membership inference) | Se intenta averiguar si los datos de una persona o un registro se usaron en el entrenamiento | Exposición de la pertenencia de un registro al conjunto de entrenamiento | Limitar información observable, evaluar la exposición del modelo y realizar pruebas de privacidad |
| Inversión del modelo (model inversion) | Se intenta reconstruir información a partir de las respuestas o características del modelo | Posible revelación de información sensible | Evaluar salidas, limitar información innecesaria y aplicar medidas de protección de datos |
| Manipulación directa del modelo (direct model poisoning) | Se alteran directamente parámetros, pesos u otros componentes del modelo | Modificación no autorizada de su comportamiento | Controlar accesos, verificar integridad y mantener trazabilidad de versiones |
| Ataques mediante salidas maliciosas | Una salida contiene instrucciones o contenido malicioso que otros componentes procesan | Acciones no previstas o compromiso de sistemas conectados | Tratar las salidas como contenido no confiable, validar su uso y limitar permisos de las integraciones |
Otros puntos de exposición: reentrenamiento y proveedores
Reentrenamiento comprometido. Los datos recogidos durante la operación pueden introducir amenazas si se reutilizan para entrenar nuevas versiones. Esto puede prolongar un ataque más allá de la versión inicial. Conviene validar los conjuntos de datos y aprobar las versiones antes de utilizarlas.
Compromiso de terceros. Los componentes, modelos y servicios externos también pueden convertirse en vías de compromiso. Conviene evaluar su origen, sus cambios y las condiciones del proveedor. El reentrenamiento y los proveedores son puntos de exposición en los que pueden materializarse ataques como los anteriores, más que categorías independientes de ataque.
Los controles reducen exposición, pero necesitan pruebas: un filtro de instrucciones aislado no garantiza protección. Diferenciar ataque intencionado, error de calidad y cambio legítimo ayuda a investigar sin sacar conclusiones prematuras.
La seguridad durante el ciclo de vida de la IA
La siguiente secuencia propone puntos de revisión; no pretende reproducir las fases oficiales de la norma. Cada transición debería permitir saber qué cambió, quién lo autorizó y qué comprobaciones se realizaron.
- Diseño: delimitar finalidad, permisos, amenazas y consecuencias de un fallo.
- Recopilación de datos: comprobar origen, condiciones de uso e integridad.
- Entrenamiento: controlar acceso a datos, código, parámetros y artefactos.
- Validación: probar ataques relevantes y documentar limitaciones.
- Despliegue: separar entornos, gestionar secretos y configurar privilegios mínimos.
- Operación: vigilar accesos, consultas y acciones fuera de patrón.
- Monitorización: relacionar alertas con riesgos y responsables.
- Actualización o reentrenamiento: validar datos nuevos, comparar versiones y prever reversión.
- Retirada: revocar permisos, cerrar integraciones y gestionar conservación y eliminación.
La monitorización de sistemas de IA convierte estas revisiones en seguimiento continuado. Un cambio de modelo o proveedor merece revisar las hipótesis de seguridad, aunque la interfaz visible siga siendo idéntica.
ISO/IEC 27090 e ISO/IEC 27001: diferencias y complementariedad
ISO/IEC 27001:2022 establece requisitos para un sistema de gestión de seguridad de la información. ISO/IEC 27090 se centra en orientación sobre amenazas de IA y complementa las prácticas de seguridad existentes, incluidas ISO/IEC 27001 e ISO/IEC 27002.
| Aspecto | ISO/IEC 27001 | ISO/IEC 27090 |
|---|---|---|
| Finalidad | Gestionar seguridad de la información | Abordar amenazas específicas de IA |
| Alcance | Información y procesos dentro del SGSI | Sistemas de IA y su ciclo de vida |
| Enfoque | Requisitos de un sistema de gestión | Orientación especializada |
| Aplicación a IA | Incluye activos de IA dentro del alcance definido | Profundiza en su exposición particular |
| Controles | Selección y tratamiento según riesgos | Apoyo para comprender amenazas y protección |
| Papel organizativo | Marco de gestión y mejora | Complemento técnico al análisis de seguridad |
No hace falta crear dos circuitos de aprobación paralelos. Como propuesta organizativa, la empresa puede ampliar su registro de riesgos y su gestión de cambios con escenarios de IA, manteniendo responsables y evidencias conectados.
ISO/IEC 27090 e ISO/IEC 42001
ISO/IEC 42001 establece un sistema de gestión de IA. Permite organizar políticas, responsabilidades, riesgos y mejora. La ciberseguridad específica puede incorporarse a ese marco según el alcance y la exposición de cada organización. La relación con ISO/IEC 27090 aquí descrita es una propuesta de integración, no un requisito adicional atribuido a ambas normas.
Por ejemplo, un departamento comercial solicita un asistente documental. Negocio define la finalidad; seguridad revisa accesos y amenazas; el equipo técnico prueba restricciones; la persona responsable decide sobre el riesgo residual. La implantación de ISO/IEC 42001 puede conectar esas decisiones sin convertir cada equipo en un proceso independiente.
En una auditoría del sistema de gestión, será relevante poder demostrar que los procesos establecidos se ejecutan. Una presentación de controles previstos aporta menos información que una prueba fechada, un resultado y una decisión sobre las limitaciones detectadas.
ISO/IEC 27090 y la gestión de riesgos de IA
ISO/IEC 23894:2023 ofrece orientación sobre gestión de riesgos de IA. Para conectar seguridad y negocio, conviene describir escenarios concretos: qué activo puede verse afectado, por qué vía y con qué consecuencias. El nombre de una amenaza por sí solo no permite priorizar inversión.
La gestión de riesgos de IA puede seguir esta secuencia práctica de Céntrika: Identificación → Riesgo → Control → Responsable → Evidencia → Seguimiento. Probabilidad e impacto deben valorarse con criterios adecuados al contexto, incluyendo personas afectadas y dependencias externas.
| Activo | Amenaza | Impacto potencial | Control | Evidencia |
|---|---|---|---|---|
| Documentos internos | Inyección indirecta | Acceso o divulgación indebida | Autorización por documento y usuario | Prueba de permisos y resultado |
| Datos de entrenamiento | Manipulación | Predicciones alteradas | Procedencia y validación del conjunto | Versión y revisión aprobada |
| Modelo | Extracción | Pérdida de conocimiento propio | Acceso limitado y alertas | Registros de acceso revisados |
| Herramientas conectadas | Acción inducida | Modificación de expedientes | Aprobación humana y límites de acción | Registro de autorización |
La tabla es ilustrativa. Cada fila necesita una persona responsable, una fecha de revisión y una decisión sobre el riesgo restante; instalar un control sin verificar su funcionamiento deja el análisis incompleto.
Qué relación tiene ISO/IEC 27090 con el AI Act
El artículo 15 del Reglamento (UE) 2024/1689 aborda precisión, solidez y ciberseguridad de sistemas de alto riesgo. La seguridad técnica puede aportar evidencias para evaluar obligaciones aplicables, pero una norma voluntaria y una obligación legal tienen funciones distintas. Hay que determinar primero el papel de la organización, la clasificación y el calendario del sistema.
El artículo 15.5, consultable en el portal oficial de la Comisión, exige medidas adecuadas al contexto y los riesgos frente a intentos de manipulación de datos, componentes preentrenados y entradas, ataques a la confidencialidad o fallos del modelo. El Reglamento (UE) 2026/1744 modificó el artículo 113: las secciones 1 a 3 del capítulo III, salvo el artículo 6.5, se aplican el 2 de diciembre de 2027 a los sistemas del artículo 6.2 y anexo III, y el 2 de agosto de 2028 a los del artículo 6.1 y anexo I. Deben comprobarse además las exclusiones y disposiciones transitorias del caso concreto.
Aplicar ISO/IEC 27090 no garantiza el cumplimiento del AI Act ni genera automáticamente presunción de conformidad. Esta última exige comprobar las condiciones jurídicas aplicables, incluidas las referencias pertinentes en el Diario Oficial. Tampoco sustituye la evaluación de conformidad. El recurso ISO 42001 vs AI Act ayuda a distinguir gestión voluntaria y cumplimiento.
Qué deberían hacer las empresas
Una propuesta proporcionada comienza por sistemas concretos y decisiones que puedan mantenerse. No todas las empresas necesitan las mismas pruebas ni el mismo nivel de formalización.
- Inventariar: registrar finalidad, uso, proveedor y propietario en el inventario de IA.
- Identificar activos: datos, modelos, integraciones, credenciales y acciones permitidas.
- Analizar amenazas: revisar puntos de entrada y capacidades del posible atacante.
- Valorar riesgo: considerar probabilidad, impacto y exposición real.
- Tratar: seleccionar medidas viables y decidir sobre el riesgo residual.
- Asignar: definir quién aprueba, implementa, supervisa y responde.
- Documentar: vincular decisiones con controles y pruebas.
- Revisar: establecer seguimiento y disparadores de reevaluación.
La gestión de proveedores de IA debe aclarar qué puede comprobar la empresa y qué depende del tercero. Pedir evidencia concreta sobre permisos, versiones y notificación de cambios suele ser más útil que aceptar una declaración genérica de seguridad.
Qué evidencias conviene conservar
El expediente puede incluir inventarios, evaluaciones de riesgos, registros de amenazas, decisiones de tratamiento, pruebas de seguridad y aprobaciones. También control de versiones, cambios, incidentes, acciones correctivas, revisiones de proveedores y seguimiento. Esta relación es una recomendación práctica, no un listado universalmente obligatorio por ISO/IEC 27090.
Las evidencias de IA deben permitir reconstruir una decisión: qué se probó, sobre qué versión, con qué resultado y quién aceptó las limitaciones. Los logs y la trazabilidad ayudan, pero hay que limitar acceso y conservación, proteger datos personales y evitar guardar secretos innecesarios. Acumular registros sin propósito ni revisión no demuestra control efectivo.
Ejemplo empresarial: proteger un asistente de IA
Una empresa conecta un asistente a documentos internos. Un archivo externo incluye instrucciones que intentan inducir la divulgación de información reservada. Es un ejemplo ilustrativo de inyección indirecta de instrucciones, no un caso oficial de la norma. El riesgo depende de los permisos del usuario, del contenido recuperado y de las herramientas disponibles.
El equipo detecta una respuesta inesperada y conserva, con acceso restringido, la consulta, el documento implicado, la versión y los registros necesarios. Seguridad y el responsable del sistema delimitan la exposición; el propietario de los datos identifica información afectada. Si procede, intervienen Legal, protección de datos y el proveedor. La gestión de incidentes de IA coordina investigación, respuesta y comunicaciones pertinentes.
Como tratamiento, se revisa la autorización en la recuperación documental, se separa contenido externo de instrucciones y se restringen herramientas. Las acciones sensibles requieren aprobación. Antes de reactivar funciones, se repite la prueba original y se añaden variantes, consultas legítimas y usuarios con permisos distintos. Se conservan resultados y limitaciones: corregir una demostración aislada no prueba que todos los ataques hayan desaparecido.
Integrar la ciberseguridad en el gobierno de IA
La protección gana continuidad cuando políticas, inventario, responsables, riesgos, proveedores, incidentes y auditorías comparten referencias. Un sistema debe poder localizarse en el inventario y relacionarse con sus controles, cambios y decisiones. Así, negocio y seguridad pueden hablar de la misma exposición sin depender de documentos dispersos.
El gobierno de IA conecta esas piezas con la mejora continua. El enfoque de Céntrika consiste en traducir necesidades de gestión en controles verificables y evidencias útiles. Para revisar las obligaciones europeas con una perspectiva más amplia, puede consultarse también AI Act para empresas.
Conclusión
Proteger IA exige examinar datos, modelos y comportamiento, además de infraestructura. ISO/IEC 27090 puede complementar los enfoques de seguridad y gobierno existentes. El paso práctico es identificar una exposición concreta, decidir medidas proporcionadas y comprobar que funcionan, con una persona responsable y evidencia de seguimiento.
Referencias y alcance editorial
Fuentes consultadas el 16 de octubre de 2026: ISO/IEC 27090:2026, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 42001:2023, ISO/IEC 23894:2023 y NIST AI 100-2 E2025. Referencias jurídicas: artículo 15 en el portal oficial de la Comisión, Reglamento (UE) 2026/1744 y Reglamento (UE) 2024/1689 en EUR-Lex. Los ejemplos y controles son recomendaciones de Céntrika, sin atribución de cláusulas no verificadas.
¿Conoces los riesgos de seguridad de los sistemas de IA de tu organización?
Identificar los sistemas de IA, evaluar sus riesgos y definir controles es el primer paso para construir una gobernanza más segura y responsable.