Seguridad de la Información para Sistemas de IA Industrial
Requisitos para establecer, implantar, mantener y mejorar de forma continua un Sistema de Gestión de Seguridad de la IA Industrial (SGSIA). Donde ISO/IEC 27001 protege la información de la organización, IRIS-SEC 27001 protege el modelo, el dato de proceso y la decisión automatizada.
Texto normativo íntegro, publicado en abierto y sin coste de acceso.
El Hueco que Ninguna Norma Cubre Hoy
Una fábrica que despliega inteligencia artificial sobre su proceso productivo se encuentra con tres normas maduras que rodean su problema sin resolverlo. Ninguna de las tres fue escrita para un modelo que toma decisiones sobre una línea de producción en marcha.
Sistema de gestión de seguridad de la información. Excelente para activos de información corporativa: servidores, aplicaciones, personas, procesos.
No cubre: el modelo como activo, el envenenamiento de datos de entrenamiento, los ataques adversarios, ni la decisión automatizada como evidencia.
Sistema de gestión de la inteligencia artificial. Aporta gobernanza, gestión de riesgos e impacto de la IA con enfoque generalista.
No cubre: la profundidad técnica de ciberseguridad, ni la especificidad del entorno industrial y de la capa de control.
Seguridad de los sistemas de automatización y control industrial. La referencia real en OT: zonas, conductos, niveles de seguridad.
No cubre: es anterior a la IA industrial. No contempla modelos, entrenamiento, deriva ni autonomía de decisión.
La intersección de las tres. Seguridad de la información aplicada específicamente a sistemas de IA que operan sobre procesos industriales reales.
Aporta: 54 controles sobre modelo, dato de proceso, convergencia IT/OT, cadena de suministro de IA y supervisión humana efectiva.
La Familia IRIS-SEC 27000
Seguridad de la Información en IA Industrial
IRIS-SEC 27001 es la norma certificable de la familia: define el sistema de gestión y los controles. Las certificaciones 27010 a 27090 son módulos especializados que se auditan sobre la base de 27001 cuando el alcance de la organización lo requiere.
Catálogo de Certificaciones de Seguridad
| Código IRIS | Denominación | Ámbito | Ref. ISO/IEC · Regulación |
|---|---|---|---|
| IRIS-SEC 27001 | SGSIA — Norma Base Certificable | Sistema de gestión de seguridad de la IA industrial: cláusulas 4–10 y Anexo A completo | Equiv. ISO/IEC 27001 + 42001 + IEC 62443 |
| IRIS-SEC 27010 | Seguridad del Modelo | Envenenamiento de datos, ejemplos adversarios, extracción e inversión de modelo, puertas traseras | Sin equivalente ISO específico |
| IRIS-SEC 27020 | Integridad del Dato Industrial | Sensores, telemetría, historiadores de proceso, linaje y procedencia del dato | Complementa ISO 8000 · ALCOA+ |
| IRIS-SEC 27030 | Convergencia IT/OT con IA | Zonas y conductos, separación IA/control, canales de escritura sobre el proceso | Complementa IEC 62443-3-3 |
| IRIS-SEC 27040 | Cadena de Suministro de IA | AIBOM, modelos preentrenados de terceros, procedencia de datasets, proveedores | Complementa ISO/IEC 27036 |
| IRIS-SEC 27050 | Soberanía y Localización del Dato | Jurisdicción del dato y del cómputo, reversibilidad, dependencia extracomunitaria | Complementa ISO/IEC 27018 · RGPD · Data Act |
| IRIS-SEC 27060 | Copilotos y LLM Industriales | Inyección de instrucciones, fuga de know-how, asistentes conversacionales en planta | Sin equivalente ISO específico |
| IRIS-SEC 27070 | Continuidad y Degradación Segura | Fallback ante caída del modelo o del proveedor, operación sin IA, resiliencia | Complementa ISO 22301 |
| IRIS-SEC 27080 | Respuesta a Incidentes de IA | Forense de decisiones automatizadas, notificación a autoridades, lecciones aprendidas | Complementa ISO/IEC 27035 · NIS2 |
| IRIS-SEC 27090 | Cumplimiento del Reglamento de IA | Sistemas de alto riesgo, gestión de riesgos, documentación técnica y vigilancia poscomercialización | Complementa ISO/IEC 42001 · AI Act UE |
Nomenclatura: la familia IRIS-SEC replica la numeración de ISO/IEC 27001 con el mismo criterio ya aplicado en IRIS-EDU 21001 respecto a ISO 21001. El número señala equivalencia de ámbito; el prefijo IRIS-SEC identifica inequívocamente al emisor del esquema.
Texto Normativo IRIS-SEC 27001:2026
El cuerpo completo de la norma, en abierto. ISO cobra por sus normas; nosotros creemos que un estándar que aspira a proteger la industria europea debe poder leerse antes de comprarse.
Índice de la norma
1 · 2 · 3 — Alcance, Referencias y Definiciones
1 Alcance
Esta norma especifica los requisitos para establecer, implantar, mantener y mejorar de forma continua un Sistema de Gestión de Seguridad de la IA Industrial (SGSIA) en el contexto de una organización que diseña, integra, opera o suministra sistemas de inteligencia artificial que influyen sobre procesos industriales.
1.1 Aplicabilidad
La norma es aplicable a toda organización, con independencia de su tamaño, sector o naturaleza jurídica, que se encuentre en al menos uno de los siguientes perfiles:
- Desarrolladora — diseña o entrena modelos destinados a entornos industriales.
- Integradora — despliega, adapta o conecta sistemas de IA a la infraestructura de producción de un tercero.
- Operadora — explota sistemas de IA sobre su propio proceso productivo, sean propios o de terceros.
- Proveedora de servicio — presta capacidad de cómputo, datos, modelos o mantenimiento a cualquiera de las anteriores.
1.2 Ámbito material
El SGSIA cubre el ciclo de vida completo del sistema de IA industrial: origen y adquisición del dato, entrenamiento, validación, despliegue, operación, supervisión, actualización y retirada. Comprende tanto la capa de tecnología de la información (IT) como los puntos de contacto con la capa de tecnología de operación (OT) en los que la IA lee del proceso o escribe sobre él.
1.3 Exclusiones del alcance
Esta norma no establece requisitos de seguridad funcional de maquinaria (IEC 61508, ISO 13849), ni sustituye la evaluación de conformidad exigida por el Reglamento (UE) 2024/1689 de Inteligencia Artificial para sistemas de alto riesgo. Tampoco constituye una certificación acreditada por ISO, IEC, CEN, AENOR ni ENAC.
1.4 Conformidad
Todos los requisitos de las cláusulas 4 a 10 son de obligado cumplimiento y no admiten exclusión. Los controles del Anexo A son de aplicación por defecto: cualquier exclusión debe justificarse formalmente en la Declaración de Aplicabilidad conforme a la cláusula 6.1.3.
2 Referencias normativas
Los siguientes documentos se citan de forma total o parcial y son indispensables para la aplicación de esta norma. Cuando se indica edición, aplica únicamente esa edición; en caso contrario, aplica la última edición vigente.
- ISO/IEC 27001 — Sistemas de gestión de la seguridad de la información. Requisitos.
- ISO/IEC 27002 — Controles de seguridad de la información.
- ISO/IEC 42001 — Sistemas de gestión de la inteligencia artificial.
- ISO/IEC 23894 — Gestión del riesgo en inteligencia artificial.
- IEC 62443-2-1, 62443-3-2, 62443-3-3, 62443-4-1 — Seguridad de sistemas de automatización y control industrial.
- ISO 22301 — Continuidad de negocio.
- Reglamento (UE) 2024/1689 — Reglamento de Inteligencia Artificial.
- Directiva (UE) 2022/2555 — NIS2.
- Reglamento (UE) 2016/679 — RGPD.
- IRIS 14001 — Certificación base de software de IA industrial.
- IRIS 14090 — Safety AI Industrial.
3 Términos y definiciones
A efectos de esta norma se aplican los términos siguientes. Los términos no definidos aquí se toman de ISO/IEC 27000 e ISO/IEC 22989.
3.1 sistema de IA industrial
Sistema que aplica técnicas de aprendizaje automático o inferencia sobre datos procedentes de un proceso industrial, con el fin de predecir, clasificar, optimizar o decidir sobre dicho proceso.
3.2 SGSIA
Sistema de Gestión de Seguridad de la IA Industrial. Conjunto de elementos de una organización, interrelacionados, para establecer políticas y objetivos y alcanzarlos en materia de seguridad de sus sistemas de IA industrial.
3.3 activo de modelo
Conjunto formado por la arquitectura, los pesos entrenados, los hiperparámetros, el código de inferencia y la documentación asociada de un modelo. Se considera activo de información a todos los efectos de esta norma.
3.4 nivel de autonomía
Grado en el que un sistema de IA actúa sobre el proceso sin confirmación humana previa. Se clasifica en: N0 informativo, N1 recomendación con aprobación explícita, N2 actuación con supervisión y capacidad de anulación, N3 actuación autónoma con revisión posterior.
3.5 envenenamiento de datos
Manipulación deliberada de los datos de entrenamiento, ajuste o realimentación con el objeto de alterar el comportamiento del modelo resultante.
3.6 ejemplo adversario
Entrada construida deliberadamente para inducir en el modelo una salida errónea que un observador humano no consideraría ambigua.
3.7 deriva
Degradación del desempeño de un modelo causada por la divergencia entre la distribución de los datos de operación y la de los datos de entrenamiento.
3.8 degradación segura
Estado operativo predefinido al que transita el proceso cuando el sistema de IA deja de ser fiable, disponible o confiable, sin comprometer la seguridad de las personas ni la integridad del producto.
3.9 AIBOM
Inventario estructurado de todos los componentes de un sistema de IA: modelos base, conjuntos de datos, bibliotecas, pesos preentrenados, servicios de inferencia y sus respectivas procedencias y licencias.
3.10 supervisión humana efectiva
Condición en la que la persona responsable dispone simultáneamente de información suficiente, tiempo suficiente y autoridad suficiente para anular una decisión del sistema de IA antes de que produzca efectos irreversibles.
4 a 10 — Requisitos del Sistema de Gestión
Estas siete cláusulas siguen la estructura armonizada de alto nivel (Anexo SL) común a ISO/IEC 27001, ISO/IEC 42001, ISO 9001 e ISO 22301. La numeración es deliberadamente idéntica para que una organización con un sistema de gestión certificado pueda absorber IRIS-SEC 27001 ampliando sus procedimientos existentes en lugar de duplicarlos.
4 Contexto de la organización
4.1 Comprensión de la organización y de su contexto
La organización debe determinar las cuestiones internas y externas pertinentes para su SGSIA, incluyendo de forma expresa: el sector industrial y su criticidad, el panorama de amenazas aplicable a la IA industrial, la dependencia tecnológica de proveedores extracomunitarios y el marco regulatorio de cada jurisdicción en la que opera.
4.2 Comprensión de las necesidades y expectativas de las partes interesadas
Deben identificarse las partes interesadas del SGSIA y sus requisitos. Como mínimo: clientes industriales, personas trabajadoras y su representación legal, proveedores de modelos y datos, aseguradoras, autoridades de supervisión de mercado y autoridades competentes en materia de ciberseguridad.
4.3 Determinación del alcance del SGSIA
El alcance debe expresarse por escrito e identificar: los sistemas de IA incluidos, las plantas o instalaciones afectadas, los procesos productivos implicados y las interfaces con sistemas de terceros. Las exclusiones deben justificarse y no pueden dejar fuera ningún sistema de IA con nivel de autonomía N2 o N3.
4.4 Sistema de gestión de seguridad de la IA industrial
La organización debe establecer, implantar, mantener y mejorar de forma continua el SGSIA, incluidos los procesos necesarios y sus interacciones, de acuerdo con los requisitos de esta norma.
5 Liderazgo
5.1 Liderazgo y compromiso
La alta dirección debe demostrar liderazgo y compromiso respecto al SGSIA asegurando la disponibilidad de recursos, la integración de los requisitos en los procesos de negocio y la comunicación de la importancia de una gestión eficaz de la seguridad de la IA industrial.
5.2 Política
Debe establecerse una política de seguridad de la IA industrial, apropiada al propósito de la organización, que incluya el compromiso de cumplir los requisitos aplicables y de mejorar continuamente el SGSIA. La política debe estar documentada, comunicada dentro de la organización y disponible para las partes interesadas pertinentes.
5.3 Roles, responsabilidades y autoridades
La alta dirección debe asignar la responsabilidad y autoridad para el SGSIA. Debe designarse de forma nominal:
- Un responsable del SGSIA, con autoridad para detener el despliegue de un sistema de IA.
- Un propietario para cada activo de modelo en producción.
- Un responsable de supervisión humana por cada sistema con nivel de autonomía N2 o N3.
La función de propietario de modelo no puede recaer en la misma persona que aprueba su paso a producción.
6 Planificación
6.1 Acciones para tratar riesgos y oportunidades
6.1.1 Generalidades. Al planificar el SGSIA, la organización debe considerar las cuestiones de la cláusula 4.1 y los requisitos de la 4.2, y determinar los riesgos y oportunidades que es necesario tratar.
6.1.2 Apreciación del riesgo de seguridad de la IA industrial. La organización debe definir y aplicar un proceso de apreciación del riesgo que, además de los criterios habituales de confidencialidad, integridad y disponibilidad, evalúe expresamente:
- La consecuencia física de una decisión errónea del modelo sobre el proceso, el producto y las personas.
- La superficie de ataque específica de la IA: datos de entrenamiento, canal de realimentación, interfaz de inferencia, artefactos del modelo.
- La capacidad real de detección de una manipulación silenciosa del comportamiento del modelo.
- La ventana de reversibilidad: tiempo disponible entre la decisión automatizada y su efecto irreversible.
6.1.3 Tratamiento del riesgo. La organización debe definir y aplicar un proceso de tratamiento del riesgo que seleccione las opciones apropiadas y determine los controles necesarios. Debe compararse el conjunto de controles determinado con el Anexo A y elaborar una Declaración de Aplicabilidad que contenga los controles necesarios, su justificación, el estado de implantación y la justificación de la exclusión de cualquier control del Anexo A.
6.2 Objetivos de seguridad de la IA industrial
Deben establecerse objetivos medibles, coherentes con la política, comunicados y actualizados. Ejemplos de indicadores admisibles: cobertura de modelos con firma criptográfica verificada, tiempo medio de detección de deriva, porcentaje de decisiones N2/N3 con traza forense completa, tiempo de transición a degradación segura.
6.3 Planificación de los cambios
Cuando la organización determine la necesidad de cambios en el SGSIA, estos deben llevarse a cabo de manera planificada. Todo cambio en un modelo en producción se considera un cambio del SGSIA.
7 Soporte
7.1 Recursos
La organización debe determinar y proporcionar los recursos necesarios para el establecimiento, implantación, mantenimiento y mejora continua del SGSIA, incluida la capacidad técnica para auditar de forma independiente el comportamiento de sus propios modelos.
7.2 Competencia
Debe determinarse la competencia necesaria de las personas que afectan al desempeño de la seguridad de la IA industrial, y asegurarse mediante formación, experiencia o certificación. Se admite como evidencia de competencia la certificación IRIS-PRO en el nivel correspondiente al rol.
7.3 Toma de conciencia
Las personas que realicen trabajos bajo el control de la organización deben tomar conciencia de la política, de su contribución a la eficacia del SGSIA y de las implicaciones de no cumplir los requisitos. En particular, el personal de planta debe conocer los límites de fiabilidad del sistema de IA con el que trabaja.
7.4 Comunicación
Deben determinarse las comunicaciones internas y externas pertinentes, incluyendo qué comunicar, cuándo, a quién y por qué medios. Debe existir un canal definido para que cualquier persona de planta notifique un comportamiento anómalo del sistema de IA.
7.5 Información documentada
El SGSIA debe incluir la información documentada requerida por esta norma y la que la organización determine necesaria. Como mínimo debe conservarse: el alcance, la política, la metodología y los resultados de la apreciación del riesgo, el plan de tratamiento, la Declaración de Aplicabilidad, el inventario de sistemas de IA, los registros de auditoría interna y las actas de revisión por la dirección.
8 Operación
8.1 Planificación y control operacional
La organización debe planificar, implantar y controlar los procesos necesarios para cumplir los requisitos y ejecutar las acciones determinadas en la cláusula 6. Debe mantenerse información documentada suficiente para confiar en que los procesos se han ejecutado según lo planificado.
8.2 Apreciación del riesgo de seguridad de la IA industrial
La organización debe llevar a cabo apreciaciones del riesgo a intervalos planificados y cuando se propongan o produzcan cambios significativos, conservando información documentada de los resultados.
8.3 Tratamiento del riesgo de seguridad de la IA industrial
Debe implantarse el plan de tratamiento del riesgo y conservarse información documentada de los resultados.
8.4 Operación segura de los sistemas de IA
Requisito específico de esta norma, sin equivalente en ISO/IEC 27001. Durante toda la vida operativa de cada sistema de IA en el alcance, la organización debe mantener de forma continua:
- Un registro de operación que permita reconstruir a posteriori qué versión del modelo tomó cada decisión, con qué entradas y con qué grado de confianza.
- Un umbral de degradación definido y monitorizado, cuya superación active automáticamente la transición al estado de degradación segura.
- Una verificación periódica de la capacidad de anulación humana, ejecutada como prueba real y no como revisión documental.
- Un procedimiento de retirada que garantice que un modelo desactivado no puede reactivarse sin pasar de nuevo por validación.
9 Evaluación del desempeño
9.1 Seguimiento, medición, análisis y evaluación
La organización debe determinar qué necesita seguimiento y medición, los métodos aplicables, cuándo se realiza y cuándo se analizan y evalúan los resultados. Los métodos seleccionados deben producir resultados comparables y reproducibles.
9.2 Auditoría interna
Deben realizarse auditorías internas a intervalos planificados. El programa de auditoría debe incluir, al menos una vez por ciclo, una prueba práctica de degradación segura sobre un sistema en producción o sobre su gemelo de preproducción, no limitada a la revisión documental.
9.3 Revisión por la dirección
La alta dirección debe revisar el SGSIA a intervalos planificados. La revisión debe incluir el estado de las acciones previas, los cambios en el contexto y en el panorama de amenazas, la retroalimentación sobre el desempeño, los resultados de las apreciaciones de riesgo, el estado del plan de tratamiento, los incidentes de IA registrados y las oportunidades de mejora.
10 Mejora
10.1 Mejora continua
La organización debe mejorar de forma continua la idoneidad, adecuación y eficacia del SGSIA.
10.2 No conformidad y acción correctiva
Ante una no conformidad, la organización debe reaccionar para controlarla y corregirla, hacer frente a sus consecuencias, evaluar la necesidad de eliminar sus causas, implantar las acciones necesarias y revisar su eficacia.
Anexo A (normativo) — Controles de Seguridad de la IA Industrial
54 controles agrupados en 7 dominios. Todos son de aplicación por defecto. La exclusión de cualquiera de ellos exige justificación documentada en la Declaración de Aplicabilidad y es objeto de revisión específica durante la auditoría de certificación.
| A.1.1 | Política de seguridad de la IA industrialDebe definirse, aprobarse por la dirección, publicarse y revisarse una política específica para la seguridad de los sistemas de IA industrial. |
| A.1.2 | Propiedad de modelos y conjuntos de datosTodo activo de modelo y todo conjunto de datos de entrenamiento debe tener un propietario nominal responsable de su seguridad durante todo su ciclo de vida. |
| A.1.3 | Inventario de sistemas de IADebe mantenerse actualizado un inventario de todos los sistemas de IA en producción, incluidos los desplegados por unidades de negocio fuera del control del departamento de tecnología. |
| A.1.4 | Clasificación por criticidad y autonomíaCada sistema de IA debe clasificarse según su nivel de autonomía (N0–N3) y la criticidad del proceso sobre el que actúa, determinando el rigor de los controles aplicables. |
| A.1.5 | Modelado de amenazas específico de IADebe realizarse un modelado de amenazas que contemple los vectores propios de la IA y no únicamente los de la infraestructura que la soporta. |
| A.1.6 | Interfaz con el SGSI existenteCuando la organización disponga de un SGSI conforme a ISO/IEC 27001, debe documentarse la interfaz entre ambos sistemas evitando duplicidades y zonas sin cobertura. |
| A.1.7 | Identificación de requisitos legales y regulatoriosDeben identificarse y mantenerse actualizados los requisitos aplicables derivados del Reglamento de IA, NIS2, RGPD, Data Act y normativa sectorial. |
| A.1.8 | Segregación de funciones en el despliegueLas funciones de desarrollo del modelo, validación independiente y autorización de paso a producción deben recaer en personas distintas. |
| A.2.1 | Seguridad en el diseño del modeloLos requisitos de seguridad deben incorporarse desde la fase de diseño del modelo y no añadirse tras su validación funcional. |
| A.2.2 | Control de acceso a datos de entrenamientoEl acceso a los conjuntos de entrenamiento, ajuste y validación debe restringirse, registrarse y revisarse periódicamente. |
| A.2.3 | Protección frente a envenenamiento de datosDeben aplicarse medidas de detección de anomalías, validación estadística y control de procedencia sobre todo dato que alimente un entrenamiento o reentrenamiento. |
| A.2.4 | Robustez frente a ejemplos adversariosLos modelos que operen sobre señales manipulables desde el exterior deben someterse a pruebas de robustez adversaria proporcionadas a su nivel de autonomía. |
| A.2.5 | Protección frente a extracción e inversiónDeben limitarse la exposición de la interfaz de inferencia, el volumen de consultas y el detalle de las respuestas para impedir la reconstrucción del modelo o de sus datos de entrenamiento. |
| A.2.6 | Versionado y firma de artefactosTodo artefacto de modelo desplegado debe estar versionado y firmado criptográficamente, verificándose su integridad en cada carga. |
| A.2.7 | Segregación del entorno de entrenamientoLos entornos de entrenamiento y experimentación deben estar segregados de los entornos de producción y de la red de control. |
| A.2.8 | Validación de seguridad previa al despliegueNingún modelo debe pasar a producción sin superar una validación de seguridad documentada e independiente del equipo que lo desarrolló. |
| A.2.9 | Retirada y desmantelamiento segurosLa retirada de un modelo debe incluir la revocación de sus credenciales, la conservación de su traza histórica y la imposibilidad de reactivación sin nueva validación. |
| A.3.1 | Autenticación de fuentes de telemetríaDebe verificarse la autenticidad de sensores, pasarelas y fuentes de telemetría que alimentan al sistema de IA, impidiendo la inyección de datos por fuentes no autorizadas. |
| A.3.2 | Integridad del dato en tránsito OT a IAEl flujo de datos desde la capa de control hasta la plataforma de inferencia debe protegerse frente a modificación no detectada. |
| A.3.3 | Linaje y procedencia del datoDebe poder reconstruirse el origen, las transformaciones y los responsables de cualquier dato que haya influido en el entrenamiento o en una decisión. |
| A.3.4 | Detección de deriva y de anomalías de entradaDebe monitorizarse de forma continua la distribución de los datos de entrada para detectar deriva, degradación o manipulación. |
| A.3.5 | Protección del historiador de procesoLos sistemas historiadores que constituyan fuente de verdad para el entrenamiento deben protegerse con controles de integridad equivalentes a los de un registro de evidencia. |
| A.3.6 | Retención de los datos de decisiónDeben conservarse las entradas, salidas y metadatos de las decisiones automatizadas durante un periodo suficiente para permitir la investigación posterior y el cumplimiento regulatorio. |
| A.3.7 | Minimización de datos de personas trabajadorasLos datos que permitan identificar o evaluar individualmente a personas trabajadoras deben minimizarse, seudonimizarse y someterse a control de acceso reforzado. |
| A.3.8 | Protección del conocimiento industrial embebidoDeben aplicarse medidas que impidan la extracción del know-how de proceso contenido en los datos y en los modelos, especialmente cuando el cómputo se externaliza. |
| A.4.1 | Segmentación en zonas y conductosLos sistemas de IA deben ubicarse en zonas de seguridad definidas, con conductos controlados hacia la red de control, conforme al modelo de IEC 62443-3-2. |
| A.4.2 | Separación entre capa de IA y capa de controlLa lógica de seguridad del proceso no debe depender de la disponibilidad ni de la corrección del sistema de IA. |
| A.4.3 | Control de los canales de escrituraTodo canal por el que la IA emita consignas hacia el proceso debe estar explícitamente autorizado, limitado en rango y registrado. |
| A.4.4 | Seguridad del cómputo en el bordeLos dispositivos de inferencia desplegados en planta deben protegerse frente a acceso físico, extracción de modelos y sustitución de firmware. |
| A.4.5 | Endurecimiento de plataformas de inferenciaLas plataformas que ejecutan modelos deben someterse a configuración segura, reducción de superficie de ataque y gestión de parches documentada. |
| A.4.6 | Gestión de credenciales y secretos de IALas claves de acceso a servicios de inferencia, repositorios de modelos y fuentes de datos deben custodiarse, rotarse y auditarse. |
| A.4.7 | Registro inmutable de acciones sobre el procesoLas acciones de la IA sobre el proceso deben registrarse en un soporte que impida su modificación o borrado por parte de los operadores del propio sistema. |
| A.4.8 | Sincronización temporal fiableTodos los elementos que generen registros deben compartir una fuente de tiempo fiable y protegida, condición necesaria para la trazabilidad forense. |
| A.5.1 | Inventario de componentes de IA (AIBOM)Debe mantenerse un inventario de todos los componentes del sistema de IA, con su procedencia, versión y licencia. |
| A.5.2 | Evaluación de modelos preentrenados de tercerosTodo modelo base o pesos preentrenados de origen externo debe someterse a evaluación de seguridad antes de su incorporación. |
| A.5.3 | Verificación de procedencia de conjuntos de datosDebe verificarse el origen, la licencia y la integridad de todo conjunto de datos externo empleado en entrenamiento o validación. |
| A.5.4 | Requisitos contractuales de seguridadLos contratos con proveedores de modelos, datos o cómputo deben incluir requisitos de seguridad, derecho de auditoría y obligaciones de notificación de incidentes. |
| A.5.5 | Localización y jurisdicción del dato y del cómputoDebe conocerse y documentarse en qué jurisdicción residen los datos y se ejecuta la inferencia, evaluando el riesgo de acceso por autoridades extranjeras. |
| A.5.6 | Reversibilidad y estrategia de salidaDebe existir un plan documentado y probado para sustituir a un proveedor de IA sin pérdida de capacidad operativa ni de datos históricos. |
| A.5.7 | Gestión de vulnerabilidades en dependencias de IADebe existir un proceso de vigilancia y remediación de vulnerabilidades en marcos, bibliotecas y servicios de la pila de IA. |
| A.6.1 | Monitorización continua del comportamiento del modeloEl desempeño y el patrón de decisión del modelo en producción deben monitorizarse de forma continua frente a una línea base establecida. |
| A.6.2 | Detección de uso indebido y sondeoDeben detectarse patrones de consulta compatibles con intentos de extracción, sondeo o evasión del modelo. |
| A.6.3 | Umbrales de degradación y activación de fallbackDeben definirse umbrales cuantitativos cuya superación active de forma automática la reducción del nivel de autonomía o el paso a degradación segura. |
| A.6.4 | Operación degradada sin IAEl proceso debe poder mantenerse en condiciones seguras sin el sistema de IA, y esta capacidad debe verificarse mediante prueba real periódica. |
| A.6.5 | Plan de respuesta a incidentes de IADebe existir un plan específico que contemple los escenarios propios de la IA: modelo comprometido, deriva súbita, envenenamiento detectado, caída del proveedor. |
| A.6.6 | Análisis forense de decisiones automatizadasDebe conservarse la evidencia necesaria para reconstruir cualquier decisión automatizada con posterioridad a un incidente. |
| A.6.7 | Notificación de incidentes a autoridadesDebe existir un procedimiento que asegure la notificación en plazo a las autoridades competentes conforme a NIS2, al Reglamento de IA y a la normativa sectorial. |
| A.6.8 | Continuidad ante caída del proveedor de IALa indisponibilidad prolongada de un proveedor externo de modelos o inferencia debe estar contemplada en el plan de continuidad de negocio. |
| A.7.1 | Competencia del personal de plantaLas personas que operan junto a sistemas de IA deben acreditar competencia sobre sus límites, sus modos de fallo y los procedimientos de anulación. |
| A.7.2 | Concienciación sobre ingeniería social asistida por IAEl personal debe estar formado frente a suplantación de voz, vídeo e identidad generada por IA en contextos de autorización industrial. |
| A.7.3 | Supervisión humana efectivaDebe garantizarse que la persona supervisora dispone de información, tiempo y autoridad suficientes para intervenir antes de que la decisión sea irreversible. |
| A.7.4 | Verificación periódica de la anulaciónLa capacidad de anulación humana debe probarse en condiciones reales con periodicidad definida, documentando el tiempo de respuesta obtenido. |
| A.7.5 | Canal de alerta interna protegidoDebe existir un canal que permita a cualquier persona de la organización alertar sobre riesgos del sistema de IA sin temor a represalias. |
| A.7.6 | Seguridad de copilotos y asistentes LLMLos asistentes conversacionales desplegados en entorno industrial deben protegerse frente a inyección de instrucciones y frente a la revelación de información restringida. |
Resumen del Anexo A
- A.1 Gobierno — 8 controles · política, propiedad, inventario, clasificación
- A.2 Ciclo de vida del modelo — 9 controles · envenenamiento, adversarios, firma, retirada
- A.3 Dato industrial — 8 controles · telemetría, linaje, deriva, know-how
- A.4 Arquitectura IT/OT — 8 controles · zonas, escritura sobre proceso, borde, registro
- A.5 Cadena de suministro — 7 controles · AIBOM, terceros, jurisdicción, reversibilidad
- A.6 Operación y respuesta — 8 controles · monitorización, fallback, forense, NIS2
- A.7 Factor humano — 6 controles · competencia, supervisión, anulación, copilotos
Total: 54 controles. Ninguno es opcional por defecto.
Anexo B (informativo) — Declaración de Aplicabilidad
La Declaración de Aplicabilidad (DdA) es el documento que conecta el riesgo con el control. Es la pieza que el equipo auditor lee primero y la que determina, en la práctica, si una certificación es sólida o es papel. Su elaboración es un requisito de la cláusula 6.1.3.
B.1 Estructura mínima exigida
La DdA debe contener una fila por cada uno de los 54 controles del Anexo A, con las siguientes columnas:
| Columna | Contenido | Obligatoria |
|---|---|---|
| Control | Código y denominación según el Anexo A | Sí |
| Aplicable | Sí / No | Sí |
| Justificación | Motivo de la inclusión o de la exclusión, referido al riesgo identificado en 6.1.2 | Sí |
| Riesgo asociado | Identificador del riesgo del registro que este control trata | Sí, si aplicable |
| Estado | No iniciado / En implantación / Implantado / Verificado | Sí, si aplicable |
| Evidencia | Referencia al documento, registro o prueba que acredita la implantación | Sí, si implantado |
| Responsable | Rol nominal responsable del control | Sí, si aplicable |
| Última revisión | Fecha de la última verificación de eficacia | Sí, si verificado |
B.2 Ejemplo de cumplimentación
Extracto ilustrativo correspondiente a una planta de fabricación que opera visión artificial de terceros con nivel de autonomía N2.
| Control | Aplicable | Justificación | Estado | Evidencia |
|---|---|---|---|---|
| A.2.3 Envenenamiento de datos |
Sí | El modelo se reentrena mensualmente con imágenes etiquetadas por operarios de línea; existe riesgo R-014 de etiquetado malicioso o negligente. | Implantado | PRO-IA-07 §4 Registro de validación estadística mensual |
| A.2.4 Ejemplos adversarios |
Sí | La cámara es accesible desde zona de tránsito; riesgo R-021 de manipulación física de la escena. | En implantación | Plan PT-2026-03, pruebas previstas Q4 |
| A.2.7 Segregación de entrenamiento |
No | Exclusión justificada: la organización no entrena modelos. El reentrenamiento lo ejecuta el proveedor en su propia infraestructura. El riesgo se traslada mediante A.5.4 y se verifica en la auditoría anual al proveedor. | — | Contrato PRV-2025-11 cláusula 9 Informe auditoría proveedor 2026 |
| A.4.3 Canales de escritura |
Sí | El sistema emite señal de rechazo hacia el desviador de línea; riesgo R-008 de rechazo masivo indebido. | Verificado | Prueba PT-2026-01 Límite de tasa configurado en PLC, acta de verificación 12/03/2026 |
| A.6.4 Operación degradada sin IA |
Sí | Riesgo R-003: indisponibilidad del servicio de inferencia en nube. | Verificado | Simulacro 22/05/2026 Transición a inspección manual en 4 min 10 s |
B.3 Errores frecuentes que invalidan una DdA
- Justificar por conveniencia y no por riesgo — «no aplica porque no disponemos de recursos» no es una justificación admisible.
- Excluir A.6.4 o A.7.3 — la operación degradada y la supervisión humana efectiva no admiten exclusión en sistemas con autonomía N2 o N3.
- Declarar implantado sin evidencia verificable — un procedimiento redactado no es evidencia de implantación; lo es su registro de ejecución.
- Trasladar el riesgo al proveedor sin verificarlo — la exclusión por traslado exige evidencia de la verificación efectiva sobre el tercero.
- DdA desalineada del registro de riesgos — todo control aplicable debe poder rastrearse hasta al menos un riesgo identificado.
Anexo C (informativo) — Correspondencias con Otras Normas
Tabla de equivalencias por dominio. Una organización ya certificada puede reutilizar buena parte de su evidencia existente: la columna «aporta IRIS-SEC» indica lo que ninguna de las otras normas exige.
| Dominio IRIS-SEC | ISO/IEC 27001 | ISO/IEC 42001 | IEC 62443 | Aporta IRIS-SEC |
|---|---|---|---|---|
| A.1 Gobierno | Cobertura alta | Cobertura alta | Cobertura media | Clasificación por nivel de autonomía N0–N3 y segregación en la autorización de despliegue |
| A.2 Ciclo de vida del modelo | Sin cobertura | Cobertura baja | Sin cobertura | Dominio completo: envenenamiento, adversarios, extracción, firma de artefactos |
| A.3 Dato industrial | Cobertura media | Cobertura baja | Cobertura media | Linaje del dato de proceso, deriva y protección del know-how embebido |
| A.4 Arquitectura IT/OT | Cobertura baja | Sin cobertura | Cobertura alta | Separación IA/control y gobierno de los canales de escritura de la IA sobre el proceso |
| A.5 Cadena de suministro | Cobertura media | Cobertura media | Cobertura media | AIBOM, procedencia de pesos y datasets, jurisdicción del cómputo y reversibilidad |
| A.6 Operación y respuesta | Cobertura media | Cobertura baja | Cobertura media | Umbrales de degradación, fallback probado y forense de decisiones automatizadas |
| A.7 Factor humano | Cobertura baja | Cobertura media | Cobertura baja | Verificación práctica de la anulación y seguridad de copilotos industriales |
Esta tabla es orientativa y no sustituye al análisis de brecha formal. Una organización certificada en ISO/IEC 27001 cubre habitualmente entre el 30 % y el 45 % de los controles de IRIS-SEC 27001 con su evidencia existente.
Proceso de Certificación
Evaluación de conformidad de tercera parte en dos fases, con ciclo de tres años y vigilancia anual. La auditoría de fase 2 se realiza en planta: no se certifica IA industrial desde una sala de reuniones.
Evaluación previa del estado de partida frente a los 54 controles. Recomendado para organizaciones sin SGSI previo.
Revisión del alcance, la política, la metodología de riesgo, el plan de tratamiento y la Declaración de Aplicabilidad. Determina la preparación para la fase 2.
Verificación de la implantación y eficacia de los controles sobre sistemas reales, incluida prueba práctica de degradación segura y de anulación humana.
Certificado válido tres años, con auditoría de seguimiento anual y recertificación completa al término del ciclo.
Condiciones del esquema
- Duración total típica: de 5 a 10 meses desde el inicio hasta la emisión, según el estado de partida y el número de sistemas en el alcance.
- Reentrenamiento significativo: obliga a notificación al organismo certificador y puede requerir auditoría extraordinaria.
- Incidente grave de IA: obliga a notificación en 72 horas y a revisión del certificado.
- Alcance modular: los módulos 27010 a 27090 se auditan como ampliación de alcance sobre un certificado 27001 vigente.
- Reconocimiento cruzado: la evidencia de un SGSI certificado en ISO/IEC 27001 se acepta para los controles con correspondencia directa según el Anexo C.
Naturaleza del Esquema y Condiciones de Uso
Transparencia sobre qué es y qué no es IRIS-SEC 27001
Qué es
IRIS-SEC 27001 es un esquema de certificación sectorial propio de la Iniciativa Europea Industria 4.0, publicado en abierto, cuyo cumplimiento se evalúa mediante auditoría de tercera parte independiente.
Qué no es
No es una norma ISO, IEC, CEN ni UNE. No está acreditada por ENAC ni por ningún organismo nacional de acreditación. No implica respaldo, aprobación ni relación alguna con la Organización Internacional de Normalización (ISO) ni con la Comisión Electrotécnica Internacional (IEC). La coincidencia numérica con ISO/IEC 27001 indica equivalencia de ámbito material, no equivalencia de origen ni de reconocimiento oficial.
Obtener la certificación IRIS-SEC 27001 no exime del cumplimiento de ninguna obligación legal, incluida la evaluación de conformidad exigida por el Reglamento (UE) 2024/1689 a los sistemas de IA de alto riesgo.
Condiciones de uso del texto normativo
El texto de esta norma se publica de forma abierta y gratuita para su lectura, cita y uso interno por parte de cualquier organización. Se permite su reproducción parcial citando la fuente. El uso del sello y de la denominación «certificado IRIS-SEC 27001» queda reservado a las organizaciones que hayan superado la auditoría de certificación y mantengan su certificado vigente.
¿Quiere Certificar su Organización en IRIS-SEC 27001?
El primer paso habitual es un análisis de brecha frente a los 54 controles del Anexo A. Cuéntenos su alcance y le indicamos su punto de partida real.
Preguntas Frecuentes sobre IRIS-SEC 27001
¿IRIS-SEC 27001 sustituye a ISO/IEC 27001?
No. IRIS-SEC 27001 se construye sobre la estructura armonizada de ISO (Anexo SL), las mismas cláusulas 4 a 10, precisamente para integrarse en un SGSI existente sin duplicar el sistema de gestión. ISO/IEC 27001 protege la información de la organización; IRIS-SEC 27001 protege el modelo, el dato industrial y la decisión automatizada, que son activos que el Anexo A de ISO/IEC 27002 no contempla. Lo ideal es tener ambas.
¿Qué relación tiene con ISO/IEC 42001 y con IEC 62443?
IRIS-SEC 27001 ocupa la intersección de las tres normas. ISO/IEC 42001 gestiona la IA de forma genérica y sin profundidad de ciberseguridad; IEC 62443 asegura el entorno OT pero es anterior a la IA industrial y no contempla modelos, entrenamiento ni deriva; ISO/IEC 27001 es IT-céntrica. Una planta que despliega IA sobre su proceso queda entre las tres. El Anexo C de la norma detalla la correspondencia dominio por dominio.
¿La norma es de pago?
No. El texto normativo completo — alcance, cláusulas 4 a 10, Anexo A con los 54 controles y la guía de Declaración de Aplicabilidad — se publica en abierto en esta página. Solo tiene coste la auditoría de certificación por tercera parte independiente. Puede autoevaluarse antes de decidir si le interesa certificarse.
¿Puede certificarse una organización que no desarrolla IA, solo la usa?
Sí. La cláusula 1.1 distingue cuatro perfiles: desarrolladora, integradora, operadora y proveedora de servicio. Una planta que opera IA de terceros certifica los controles que le aplican y traslada el resto a su cadena de suministro mediante el dominio A.5, justificando las exclusiones en la Declaración de Aplicabilidad. El ejemplo del Anexo B corresponde exactamente a ese caso.
¿Cuántos controles tiene el Anexo A y cuáles no admiten exclusión?
54 controles en 7 dominios. Todos son de aplicación por defecto y cualquier exclusión exige justificación documentada referida a un riesgo identificado. En sistemas con nivel de autonomía N2 o N3 no se admite la exclusión de A.6.4 (operación degradada sin IA) ni de A.7.3 (supervisión humana efectiva).
¿Está acreditada por ISO o por ENAC?
No, y lo declaramos expresamente. IRIS-SEC 27001 es un esquema de certificación propio de la Iniciativa Europea Industria 4.0, independiente de ISO, IEC, CEN, AENOR y ENAC, sin acreditación ni respaldo de esos organismos. La coincidencia numérica con ISO/IEC 27001 señala equivalencia de ámbito, igual que IRIS-EDU 21001 respecto a ISO 21001, no equivalencia de origen.
Ya tenemos ISO/IEC 27001. ¿Cuánto trabajo adicional supone?
Una organización con un SGSI maduro cubre habitualmente entre el 30 % y el 45 % de los controles de IRIS-SEC 27001 con evidencia ya existente, sobre todo en los dominios A.1 y A.5. El esfuerzo real se concentra en A.2 (ciclo de vida del modelo) y A.6 (operación y respuesta), que son los dominios sin cobertura en ISO/IEC 27002. El análisis de brecha previo cuantifica esa distancia antes de comprometer presupuesto.
¿Cuánto tarda la certificación?
Entre 5 y 10 meses desde el inicio hasta la emisión, según el estado de partida y el número de sistemas incluidos en el alcance. El certificado tiene validez de tres años, con auditoría de seguimiento anual. Un reentrenamiento significativo de un modelo en el alcance obliga a notificación y puede requerir auditoría extraordinaria.