ISO 27001 e ISO 27090 implantadas en conjunto — seguridad de la IA en un SGSI

ISO/IEC 27001 es una norma de requisitos: establece lo que debe lograr un sistema de gestión de la seguridad de la información y, por eso, es certificable. ISO/IEC 27090 es una norma de orientación: describe qué amenazas afectan específicamente a los sistemas de IA, cómo se detectan y cómo se combaten. No exige un sistema de gestión propio, sino que se apoya en la práctica consolidada de ISO/IEC 27001 y 27002: dos frases formuladas de forma vinculante en su apartado de principios exigen implantar los controles de seguridad de la información con un enfoque basado en riesgos y tener en cuenta los compromisos específicos de la IA a lo largo de todo el ciclo de vida.

Dos puntos de anclaje sostienen todo el modelo

En primer lugar, la evaluación de riesgos: los nueve tipos de compromiso se evalúan para cada sistema de IA dentro del alcance, en el mismo registro y con la misma metodología que todos los demás riesgos de seguridad de la información. En segundo lugar, la declaración de aplicabilidad: ISO/IEC 27001 admite controles de cualquier fuente y exige compararlos con el anexo A. Así, las indicaciones de defensa de ISO/IEC 27090 se convierten en controles del SGSI que se implantan, se someten a seguimiento, se auditan y se verifican también en la auditoría de certificación.

• Ni un segundo sistema de gestión, ni una segunda metodología de riesgos, ni un segundo control documental
• Cada medida una sola vez, con varias correspondencias: con el anexo A, con ISO/IEC 27090 y, si procede, con ISO/IEC 42001 o la Ley de IA
• La auditoría interna, la revisión por la dirección y la auditoría de certificación verifican también las medidas de IA
• Quien aún no tenga un SGSI implanta el SGSI y el perfil de IA en un solo proyecto

Los análisis separados duplican las entrevistas y producen resultados contradictorios. Por eso verificamos una sola vez cada requisito de los capítulos 4 a 10 y cada control relevante del anexo A, y evaluamos al mismo tiempo si la extensión de IA también está cubierta. A ello se suma el análisis de los contenidos específicos de IA de ISO/IEC 27090 que no tienen correspondencia directa en ISO/IEC 27001: los nueve tipos de compromiso, Zero Trust para modelos y agentes, red teaming, las interacciones entre medidas y la pérdida de eficacia con el tiempo.

1. 1
   Alcance y contexto

   Reunión de lanzamiento con la dirección y el equipo del SGSI: objetivos de la iniciativa, como el certificado, los requisitos de clientes o la Ley de IA; alcance provisional; partes interesadas con requisitos de IA.

2. 2
   Inventario de IA

   Registrar todos los sistemas de IA —de desarrollo propio, operados en el tenant propio, utilizados como API o SaaS o integrados en software estándar—; la comparación con compras, licencias, repositorios de código y datos de red saca a la luz la IA en la sombra.

3. 3
   Revisión documental

   Política, metodología de riesgos, registro de riesgos, declaración de aplicabilidad, descripciones de procesos, evaluaciones de proveedores y políticas de IA existentes.

4. 4
   Entrevistas y muestras

   CISO y equipo del SGSI, operaciones de TI, ingeniería de ML y ciencia de datos, desarrollo de software, compras, protección de datos y áreas de negocio; muestras técnicas sobre derechos de acceso a modelos y datos, registro de eventos y filtros de entrada y salida.

5. 5
   Valoración por niveles de madurez

   Cada requisito en cuatro niveles, de «inexistente» a «eficaz y verificado», con doble valoración: para el requisito del SGSI y para su extensión de IA.

6. 6
   Registro de brechas y resumen ejecutivo

   Brechas con riesgo, esfuerzo, responsables y prioridad; mapa de calor por capítulo de la norma y por sistema de IA; las diez brechas más importantes para la dirección.

Qué aporta el análisis de brechas

• Primera versión del inventario de IA con propietarios y criticidad
• Registro de brechas ISO/IEC 27001 × ISO/IEC 27090 con niveles de madurez
• Valoración de la relevancia de los nueve tipos de compromiso por sistema de IA
• Mapa de calor y resumen ejecutivo con prioridades y estimación aproximada del esfuerzo
• Recomendación sobre el alcance y la vía de certificación

La base es la evaluación de riesgos: para cada sistema de IA dentro del alcance se evalúan los tipos de compromiso relevantes según su probabilidad y sus consecuencias. El tratamiento de riesgos selecciona entonces las medidas —del anexo A, de ISO/IEC 27090 o de elaboración propia— y las compara con el anexo A para que no falte ningún control necesario. Así surge una declaración de aplicabilidad ampliada que indica para cada medida su fuente, su justificación y su estado de implantación.

Dos vías hacia la declaración de aplicabilidad

Priorizar en lugar de hacerlo todo a la vez

• Primero, las medidas sin arrepentimiento (no-regret): inventario de IA, propietarios, protección de accesos, registro de eventos, normas de uso de la IA generativa
• Después, según el riesgo: los sistemas de IA más críticos y los tipos de compromiso con valoración alta
• Tener en cuenta los plazos: auditorías de clientes, próxima auditoría de seguimiento, obligaciones de la Ley de IA para la IA de alto riesgo a partir de diciembre de 2027
• Que los riesgos residuales los acepten formalmente los propietarios del riesgo, no el equipo del proyecto

ISO/IEC 27001 exige que los cambios en el SGSI se realicen de forma planificada, y la ampliación de IA es uno de esos cambios; la buena práctica es definir de antemano la finalidad, las posibles consecuencias, los recursos y las responsabilidades. Esto protege un certificado existente, porque el SGSI sigue siendo operativo durante la transformación, y da una estructura clara a una implantación desde cero. El concepto abarca la organización del proyecto, los paquetes de trabajo, las dependencias, el presupuesto, la comunicación y los indicadores.

Hoja de ruta por oleadas

1. 1
   Oleada 0 · semanas 1–4Mandato y medidas inmediatas

   Confirmar el alcance, completar el inventario de IA, designar propietarios, publicar las normas de uso de la IA generativa, depurar los accesos a modelos y datos y activar el registro de eventos en los sistemas más críticos.

2. 2
   Oleada 1 · meses 2–4Gobierno y metodología

   Aprobar la política de seguridad de la información y la política específica de seguridad de la IA, poner en marcha el plan de tratamiento de riesgos de la fase 2 y definir los requisitos para los proveedores.

3. 3
   Oleada 2 · meses 3–8Medidas técnicas

   Zero Trust para datos, modelos y agentes, controles de entrada y salida, protección del entorno de desarrollo, monitorización y limitación de uso, red teaming de los sistemas más críticos.

4. 4
   Oleada 3 · meses 6–10Migración y formación

   Migrar procesos y datos, impartir formación por grupo destinatario, medir indicadores y recopilar evidencias.

5. 5
   Oleada 4 · meses 9–12Verificar y decidir

   Auditoría interna, acciones correctivas, revisión por la dirección y decisión sobre la auditoría de certificación.

Los plazos son valores orientativos de proyectos para una implantación conjunta desde cero con un número manejable de sistemas de IA. Con un SGSI ya existente y certificado, gran parte de las oleadas 1 y 4 deja de ser necesaria: en ese caso, la ampliación de IA a menudo puede incorporarse antes de la próxima auditoría de seguimiento.

Indicadores para la gestión

• Porcentaje de sistemas de IA con propietario, evaluación de riesgos y entrada en la declaración de aplicabilidad
• Porcentaje de sistemas de IA críticos con registro de eventos de la inferencia y monitorización
• Hallazgos abiertos de red teaming y auditoría, por antigüedad y gravedad
• Tasa de formación por grupo destinatario
• Cumplimiento de plazos de los paquetes de trabajo respecto a la hoja de ruta

En el plano organizativo, la implantación empieza por las normas que afectan a todos: la política ampliada con la IA, las normas de uso de la IA generativa, la clasificación de los datos de entrenamiento, de prompts y de salida, y un procedimiento de cambios que trate los cambios de modelo, el reentrenamiento y las modificaciones de los prompts de sistema o de las fuentes de recuperación como cambios de software. En el plano técnico, la implantación sigue los tipos de compromiso que obtuvieron una valoración alta en la evaluación de riesgos.

Zero Trust como hilo conductor

ISO/IEC 27090 traslada a la IA los principios de Zero Trust que ISO/IEC 27002 describe para las arquitecturas de sistemas seguras: cada acceso a datos de entrenamiento, modelos y fuentes de recuperación se autentica y autoriza de forma individual, las aplicaciones de IA tienen límites claros, cada acción de los agentes de IA se verifica por separado, los permisos se conceden solo para la tarea y por tiempo limitado, y el comportamiento de los sistemas se monitoriza de forma continua. Estos principios están presentes en todas las indicaciones de defensa de la norma.

Evidencias que conviene recopilar ya

• Políticas y normas de uso aprobadas, con su versión
• Configuraciones y conceptos de permisos para modelos, datos y agentes
• Evidencias de registro de eventos y monitorización, con análisis de ejemplo
• Informes de red teaming y de pruebas de aceptación, con el tratamiento de los hallazgos
• Tickets de cambio para cambios de modelo y reentrenamientos, con revalidación

La migración tiene dos niveles. En el plano de los procesos, los procesos existentes del SGSI asumen los casos de IA, en lugar de que surja junto al SGSI un universo propio de procesos de IA. En el plano de los datos, los registros, las medidas y las evidencias se trasladan desde hojas de cálculo, wikis y herramientas heredadas a un modelo de datos consolidado en el que cada medida existe una sola vez y remite a varios marcos de referencia.

Migración de datos en cinco pasos

1. 1
   Inventario inicial

   ¿Qué registros, listas de medidas, evidencias y hallazgos de auditoría existen, dónde están y con qué calidad?

2. 2
   Modelo de datos objetivo

   Un modelo para activos, riesgos, controles, evidencias y proveedores, con correspondencias múltiples con ISO/IEC 27001, ISO/IEC 27090 y, si procede, ISO/IEC 42001, la Ley de IA, NIS2 o DORA.

3. 3
   Depuración

   Fusionar duplicados, completar propietarios y vigencias, aclarar las medidas huérfanas: no todo lo heredado merece migrarse.

4. 4
   Prueba piloto y aceptación

   Migración de prueba con muestras, aceptación por parte de los responsables funcionales y conciliación de los recuentos.

5. 5
   Transición y archivo

   Fecha de corte, breve funcionamiento en paralelo, archivo de los datos heredados respetando las obligaciones de conservación: el historial de evidencias debe conservarse para la próxima auditoría.

Los contenidos se derivan de los tipos de compromiso y de las medidas definidas en la fase 2; por eso difieren claramente según el rol. Una formación única para todos no sirve ni a la alta dirección, que debe evaluar riesgos y aprobar recursos, ni a la ingeniería de ML, que debe impedir ataques concretos contra datos y modelos.

Demostrar la eficacia

• Perfil de competencia por rol, con nivel objetivo y nivel actual
• Evidencias de asistencia y breves pruebas de conocimientos
• Evidencias prácticas, como escenarios de ejercicio superados
• Indicadores en la revisión por la dirección: tasa de formación por grupo destinatario, notificaciones de anomalías

ISO/IEC 27001 exige auditorías internas a intervalos planificados, un programa de auditoría con frecuencia, métodos, responsabilidades y comunicación de resultados, así como auditores objetivos e imparciales. Sirven de orientación ISO 19011 para las auditorías de sistemas de gestión e ISO/IEC 27007 para las auditorías del SGSI. Los criterios de auditoría son ISO/IEC 27001 y los requisitos propios; para las medidas de IA, por tanto, la declaración de aplicabilidad. ISO/IEC 27090 no es un criterio de auditoría; actúa a través de las medidas que usted ha adoptado de ella.

Preguntas de verificación típicas relacionadas con la IA

• ¿Están todos los sistemas de IA en producción en el inventario? ¿Y coincide el inventario con los datos de compras y de red?
• ¿Existe para cada sistema de IA dentro del alcance una evaluación de riesgos actualizada con los tipos de compromiso relevantes?
• ¿Se ajustan los derechos de acceso a modelos, datos de entrenamiento y fuentes de recuperación al concepto de permisos? Muestra de las autorizaciones.
• ¿Se registran y analizan las entradas y salidas, la versión del modelo y las llamadas a herramientas? Muestra de los registros.
• ¿Se probó y revalidó antes del último cambio de modelo? Muestra de los tickets de cambio.
• ¿Se han tratado los hallazgos del red teaming y se les hace seguimiento?
• ¿Se ha evaluado a los proveedores de modelos y se les ha obligado contractualmente?

ISO/IEC 27001 establece lo que la dirección debe revisar a intervalos planificados: el estado de las acciones de revisiones por la dirección anteriores, los cambios en las cuestiones internas y externas y en las necesidades de las partes interesadas, la información sobre el desempeño de la seguridad de la información (no conformidades, resultados de seguimiento, medición y auditoría y cumplimiento de los objetivos), la retroalimentación de las partes interesadas, los resultados de la evaluación de riesgos y el estado del tratamiento de riesgos, así como las oportunidades de mejora. El resultado son decisiones documentadas.

Decisiones que deberían figurar en el acta

• Apetito de riesgo para la IA y aceptación de los riesgos residuales de los sistemas más críticos
• Recursos para las próximas oleadas de la hoja de ruta
• Ajustes del alcance ante nuevos sistemas de IA
• Decisión go/no-go sobre la auditoría de certificación
• Objetivos e indicadores para el siguiente ciclo

1. 1
   Selección del organismo de certificación

   Elegir un organismo acreditado (en Alemania, acreditado por la DAkkS) y acordar el alcance, los emplazamientos y la duración de la auditoría. Los requisitos para los organismos los regulan ISO/IEC 17021-1 e ISO/IEC 27006-1.

2. 2
   Auditoría de etapa 1

   Revisión de la documentación y de la preparación para la certificación: alcance con los sistemas de IA, evaluación de riesgos, declaración de aplicabilidad, planificación y realización de la auditoría interna y de la revisión por la dirección.

3. 3
   Auditoría de etapa 2

   Verificación de la eficacia in situ: entrevistas, inspecciones y muestras; en los sistemas de IA, por ejemplo, conceptos de permisos, registros, informes de pruebas y evidencias de cambios.

4. 4
   Acciones correctivas y decisión

   Las no conformidades se corrigen dentro de los plazos del organismo de certificación; después, el organismo decide sobre la certificación.

5. 5
   Certificado y ciclo

   El certificado es válido durante tres años; en los años siguientes se realizan auditorías de seguimiento y, después, la recertificación. Los nuevos sistemas de IA se incorporan a través del alcance y de la declaración de aplicabilidad.

Qué dice el certificado y qué no

El certificado confirma un SGSI conforme a ISO/IEC 27001 para un alcance descrito. Si este incluye los sistemas de IA, su seguridad forma parte del sistema de gestión certificado. El certificado no contiene ninguna afirmación del tipo «certificado según ISO/IEC 27090», y tampoco debe darse a entender en la comunicación. Lo correcto es: «SGSI certificado según ISO/IEC 27001; las medidas para nuestros sistemas de IA se orientan por ISO/IEC 27090».

Opcional: auditoría combinada con ISO/IEC 42001

Quien quiera demostrar además la gestión de la IA en su conjunto —evaluación de impacto, responsabilidades, ciclo de vida, calidad de los datos— puede integrar un sistema de gestión de la IA conforme a ISO/IEC 42001. Ambas normas siguen la misma estructura de alto nivel y es posible realizar auditorías combinadas. A tener en cuenta: a 22/10/2026, en Alemania no figuraba ningún organismo de certificación acreditado por la DAkkS para ISO/IEC 42001; las ofertas con acreditación de otros organismos de acreditación deberían examinarse una por una.

Siete errores que vemos con frecuencia

• Un segundo registro o un sistema de gestión de la IA separado junto al SGSI: doble mantenimiento, evaluaciones contradictorias
• ISO/IEC 27090 tratada como lista de comprobación en lugar de priorizada mediante la evaluación de riesgos
• IA en la sombra pasada por alto en software estándar y SaaS
• Protección solo mediante reglas en el prompt en lugar de permisos, aprobaciones y aislamiento
• Sin registro de eventos de la inferencia: los incidentes pasan desapercibidos y las auditorías carecen de evidencias
• Migración poco antes de la auditoría: se pierde el historial de evidencias
• Publicidad con «certificado ISO 27090»: engañosa y expuesta a reclamaciones por competencia desleal

Factores de éxito

• Mandato visible de la dirección con apetito de riesgo para la IA
• Propietario de cada sistema de IA en el área de negocio, no solo en TI
• Un único modelo de datos con correspondencias múltiples
• Medidas sin arrepentimiento tempranas para un efecto rápido
• Red teaming como evidencia de eficacia
• Formación por grupo destinatario en lugar de un curso único