Norma de Conformidad para Software de IA Industrial
Requisitos verificables que debe cumplir un producto de inteligencia artificial destinado a operar sobre un proceso industrial. Donde IRIS-SEC 27001 certifica cómo se gestiona una organización, IRIS 14001 certifica cómo se comporta el software.
Texto normativo íntegro, publicado en abierto y sin coste de acceso.
Una Norma de Producto, No de Sistema de Gestión
Casi todas las normas conocidas certifican organizaciones: cómo se gestionan, quién decide, qué se documenta. IRIS 14001 no. Certifica una cosa: un software concreto, en una versión concreta, sometido a ensayos concretos. Es la diferencia entre auditar una fábrica de frenos y frenar con el coche a 100 km/h.
Certifica que la organización tiene procesos, responsables y evidencias. No dice nada sobre cómo se comporta el producto que fabrica.
ISO 9001 · ISO/IEC 27001 · IRIS-SEC 27001 · IRIS-CORP 30000
Certifica que un artefacto concreto cumple requisitos medibles, comprobados con métodos de ensayo declarados de antemano.
IRIS 14001 · IRIS-PHARMA 40001 · familia vertical 14010–14090
Tres Niveles de Conformidad
No miden la calidad del algoritmo. Miden cuánto se ha comprobado y cuánto se hace público. Subir de nivel no exige un modelo mejor: exige someterlo a más escrutinio.
La base obligatoria. Verificación en banco, documentación e inspección de configuración.
26 requisitos obligatorios · no exige ensayo en planta
Añade la comprobación sobre proceso real: el auditor va a la planta y provoca los fallos.
+11 requisitos · ensayo en planta e inyección de fallos obligatorios
Añade la medición del impacto real sobre el trabajo de las personas, y su publicación.
+3 requisitos · resultado de empleo medido y publicado
Texto Normativo IRIS 14001:2026
El cuerpo completo, en abierto. Un proveedor puede autoevaluarse contra los 40 requisitos antes de decidir si le compensa certificarse — y una fábrica puede usarlos como pliego de compra aunque el proveedor no esté certificado.
Índice de la norma
- Alcance
- Referencias normativas
- Términos y definiciones
- Requisitos D1 — Arquitectura de seguridad y control
- Requisitos D2 — Datos, modelos y trazabilidad
- Requisitos D3 — Human-in-the-loop y usabilidad
- Requisitos D4 — Impacto en el empleo
- Requisitos D5 — Cumplimiento normativo
- Anexo A — Métodos de ensayo
- Anexo B — Distribución por nivel
- Anexo C — Familia 14010–14090
1 · 2 · 3 — Alcance, Referencias y Definiciones
1 Alcance
Esta norma especifica los requisitos de conformidad de producto aplicables al software que emplea técnicas de inteligencia artificial para predecir, clasificar, optimizar o decidir sobre un proceso industrial.
1.1 Objeto de la certificación
El objeto certificable es un producto de software identificado por nombre y versión mayor, con un dominio de validez declarado. No son objeto de esta norma la organización que lo desarrolla, sus procesos internos de calidad ni sus sistemas de gestión, que se certifican por separado mediante IRIS-CORP 30000 e IRIS-SEC 27001.
1.2 Ámbito de aplicación
Aplica a software destinado a entornos industriales, con independencia de su modelo de despliegue: en planta, en el borde, en nube privada o como servicio gestionado. Aplica tanto si el software recomienda como si actúa, y tanto si el modelo es propio como si integra modelos de terceros.
1.3 Exclusiones
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 a los sistemas de alto riesgo. Tampoco evalúa la exactitud predictiva del modelo: evalúa que el sistema se comporte de forma segura, trazable y honesta también cuando se equivoca.
1.4 Conformidad
Los 26 requisitos de nivel N1 son de obligado cumplimiento y no admiten exclusión. Los de nivel N2 y N3 son exigibles únicamente cuando se opta a esos niveles. Un requisito no aplicable por la naturaleza del producto debe justificarse técnicamente ante el equipo auditor, que decide sobre su procedencia.
2 Referencias normativas
Los siguientes documentos se citan de forma total o parcial y son indispensables para la aplicación de esta norma. Cuando no se indica edición, aplica la última vigente.
- ISO/IEC 25000 — Calidad del producto software (SQuaRE).
- ISO/IEC 22989 — Conceptos y terminología de inteligencia artificial.
- ISO/IEC 23894 — Gestión del riesgo en inteligencia artificial.
- IEC 62443-4-1 y 62443-4-2 — Requisitos de desarrollo y de componente para sistemas de control industrial.
- ISO 9241-210 — Diseño centrado en el operador humano.
- Reglamento (UE) 2024/1689 — Reglamento de Inteligencia Artificial.
- IRIS-SEC 27001 — Seguridad de la información en IA industrial.
- IRIS 14090 — Safety AI Industrial.
3 Términos y definiciones
A efectos de esta norma se aplican los términos siguientes. Los no definidos aquí se toman de ISO/IEC 22989.
3.1 producto de IA industrial
Software identificado por nombre y versión que aplica inferencia sobre datos de un proceso industrial para producir predicciones, clasificaciones, recomendaciones o consignas.
3.2 dominio de validez
Conjunto declarado de condiciones de proceso, materiales, rangos e instalaciones para los que el comportamiento del producto ha sido validado por su fabricante.
3.3 método de ensayo
Procedimiento declarado con el que el equipo auditor comprueba el cumplimiento de un requisito. Los siete métodos admitidos se definen en el Anexo A.
3.4 degradación segura
Estado operativo predefinido al que transita el proceso cuando el producto deja de ser fiable o disponible, sin comprometer la seguridad de las personas ni la integridad del producto fabricado.
3.5 anulación
Acción por la que una persona deja sin efecto la actuación o la recomendación del producto, con efecto inmediato y sin requerir autorización jerárquica.
3.6 nivel de conformidad
Grado de escrutinio al que se ha sometido el producto: N1 Conforme, N2 Avanzado, N3 Ejemplar. No expresa calidad predictiva.
3.7 discrepancia
Situación en la que la persona responsable adopta una decisión distinta de la recomendada por el producto.
Requisitos (normativo) — Los 40 Puntos Verificables
Cada requisito lleva asignado su método de ensayo y el nivel a partir del cual es exigible. Los de nivel N1 son obligatorios para cualquier certificación, sea cual sea el nivel al que se opte.
| Código | Requisito | Método | Nivel |
|---|---|---|---|
| R.1.1 | Separación entre inferencia y controlLa capa de inferencia debe estar separada de la lógica de control del proceso, de modo que un fallo de la primera no impida el funcionamiento seguro de la segunda. | M-04 | N1 |
| R.1.2 | Límites de actuación declaradosEl software debe declarar el rango máximo de variación que puede inducir sobre cada variable de proceso, y hacerlo cumplir en tiempo de ejecución. | M-03 | N1 |
| R.1.3 | Estado de degradación seguraDebe existir un estado definido al que el sistema transita cuando deja de ser fiable, y el paso a ese estado no debe depender de conectividad externa. | M-04 | N1 |
| R.1.4 | Watchdog e indicación de disponibilidadEl sistema debe exponer una señal de vida verificable por el sistema de control, con periodo declarado. | M-03 | N1 |
| R.1.5 | Arranque en estado conocidoTras un corte de alimentación o un reinicio, el sistema debe arrancar en un estado documentado y no reanudar actuación automática sin confirmación. | M-04 | N1 |
| R.1.6 | Aislamiento de la ruta de seguridadNinguna función de seguridad de máquina o de proceso debe depender de una salida del modelo. | M-01 | N1 |
| R.1.7 | Prueba de continuidad sin IADebe demostrarse en planta que el proceso se mantiene en condiciones seguras y productivas con el sistema desconectado. | M-05 | N2 |
| R.1.8 | Redundancia de la señal críticaLas variables de las que dependa una actuación automática deben proceder de una fuente redundante o contrastada. | M-02 | N2 |
| Código | Requisito | Método | Nivel |
|---|---|---|---|
| R.2.1 | Registro de decisión reconstruibleDebe poder reconstruirse, para cualquier decisión pasada, qué versión del modelo la produjo, con qué entradas y con qué confianza. | M-06 | N1 |
| R.2.2 | Versionado de modelo identificableCada modelo desplegado debe tener un identificador único visible desde la interfaz de operación. | M-02 | N1 |
| R.2.3 | Documentación del conjunto de entrenamientoDebe documentarse el origen, el periodo y las condiciones de proceso de los datos con los que se entrenó el modelo. | M-01 | N1 |
| R.2.4 | Declaración del dominio de validezEl proveedor debe declarar las condiciones de proceso fuera de las cuales el modelo no está validado. | M-01 | N1 |
| R.2.5 | Detección de operación fuera de dominioEl sistema debe detectar y señalar cuándo está operando fuera de su dominio de validez declarado. | M-03 | N1 |
| R.2.6 | Retención de evidenciaLos registros de decisión deben conservarse durante el periodo exigido por el sector, y ser exportables en formato abierto. | M-06 | N1 |
| R.2.7 | Medición de derivaEl sistema debe medir de forma continua la divergencia entre los datos de operación y los de entrenamiento, y exponer el resultado. | M-06 | N2 |
| R.2.8 | Reproducibilidad de la inferenciaDadas las mismas entradas y la misma versión de modelo, la salida debe ser reproducible o su variabilidad debe estar acotada y declarada. | M-03 | N2 |
| Código | Requisito | Método | Nivel |
|---|---|---|---|
| R.3.1 | Anulación siempre disponibleEl operario debe poder anular la actuación del sistema en todo momento, sin credenciales especiales ni navegación por menús. | M-05 | N1 |
| R.3.2 | Tiempo de anulación acotadoEl tiempo entre la orden de anulación y su efecto sobre el proceso debe estar medido y declarado. | M-03 | N1 |
| R.3.3 | Explicación al nivel del operarioCada recomendación debe ir acompañada de una razón comprensible para quien la va a ejecutar, no solo de una puntuación. | M-07 | N1 |
| R.3.4 | Expresión honesta de la incertidumbreEl sistema debe distinguir visualmente entre una salida fiable y una dudosa, sin presentar todas con la misma autoridad. | M-05 | N1 |
| R.3.5 | Uso con equipo de protecciónLa interfaz debe ser operable con guantes, con ruido ambiente y en las condiciones de iluminación reales del puesto. | M-05 | N1 |
| R.3.6 | Registro de la discrepanciaCuando el operario contradice al sistema, debe registrarse el hecho y el motivo, y ese registro debe alimentar la mejora del modelo. | M-06 | N2 |
| R.3.7 | Ausencia de presión automatizadaEl sistema no debe emplear cuentas atrás, alarmas escalonadas ni penalizaciones que induzcan a aceptar su recomendación sin evaluarla. | M-07 | N2 |
| R.3.8 | Verificación periódica de la anulaciónLa capacidad de anulación debe probarse en condiciones reales con periodicidad declarada, no revisarse documentalmente. | M-05 | N3 |
| Código | Requisito | Método | Nivel |
|---|---|---|---|
| R.4.1 | Declaración de impacto en puestosEl proveedor debe declarar qué tareas del puesto absorbe el sistema y cuáles no. | M-01 | N1 |
| R.4.2 | Plan de formación incluidoEl suministro debe incluir formación para el personal afectado, dimensionada y con contenidos definidos. | M-01 | N1 |
| R.4.3 | Ausencia de vigilancia individual encubiertaEl sistema no debe producir métricas de desempeño individual salvo declaración expresa y base legal. | M-02 | N1 |
| R.4.4 | Transferencia de conocimiento al equipoLa documentación debe permitir que el personal propio entienda el porqué de las decisiones, no solo su uso. | M-01 | N1 |
| R.4.5 | Información a la representación de los trabajadoresDebe existir constancia de que la representación legal ha sido informada del despliegue y su alcance. | M-01 | N2 |
| R.4.6 | Medición del cambio real en el puestoDebe medirse, antes y después, cómo cambia el contenido del trabajo de las personas afectadas. | M-07 | N2 |
| R.4.7 | Recualificación verificadaDebe acreditarse que el personal desplazado de una tarea ha recibido y superado formación para la nueva. | M-01 | N3 |
| R.4.8 | Publicación del resultado de empleoEl resultado agregado sobre el empleo debe publicarse o ponerse a disposición del Observatorio IRIS. | M-01 | N3 |
| Código | Requisito | Método | Nivel |
|---|---|---|---|
| R.5.1 | Clasificación frente al Reglamento de IAEl proveedor debe declarar si el sistema es de alto riesgo conforme al Reglamento (UE) 2024/1689 y sostener la clasificación. | M-01 | N1 |
| R.5.2 | Documentación técnica disponibleDebe existir documentación técnica suficiente para una inspección, mantenida al día con las versiones desplegadas. | M-01 | N1 |
| R.5.3 | Base de tratamiento de datos personalesCuando se traten datos de personas, debe identificarse la base jurídica y aplicarse minimización. | M-01 | N1 |
| R.5.4 | Requisitos sectoriales identificadosDeben identificarse las exigencias del sector de destino y documentarse cómo las cumple el sistema. | M-01 | N1 |
| R.5.5 | Notificación de incidente graveDebe existir un procedimiento por el que el proveedor notifica al cliente los incidentes que afecten a la fiabilidad del sistema. | M-01 | N1 |
| R.5.6 | Vigilancia poscomercializaciónEl proveedor debe recoger de forma sistemática el comportamiento del sistema en las instalaciones de sus clientes. | M-06 | N2 |
| R.5.7 | Interoperabilidad documentadaLas interfaces con sistemas industriales existentes deben estar documentadas y basarse en protocolos abiertos cuando exista opción. | M-02 | N2 |
| R.5.8 | Reversibilidad del suministroEl cliente debe poder recuperar sus datos e históricos en formato utilizable al terminar la relación contractual. | M-01 | N2 |
Anexo A (normativo) — Métodos de Ensayo
Los siete métodos con los que se comprueba cada requisito. El método se declara antes de la auditoría y no puede sustituirse por otro más débil sin justificación técnica aceptada por el organismo certificador.
| Código | Método de ensayo | En qué consiste |
|---|---|---|
| M-01 | Revisión documental | Examen de la documentación técnica, contractual y de proceso aportada por el proveedor. |
| M-02 | Inspección de configuración | Verificación directa sobre la instalación de parámetros, permisos, interfaces y versiones. |
| M-03 | Ensayo funcional en banco | Prueba del comportamiento del sistema sobre un entorno controlado, con entradas definidas por el equipo auditor. |
| M-04 | Inyección de fallos | Provocación deliberada de pérdida de red, caída de servicio, datos corruptos o entradas fuera de rango. |
| M-05 | Ensayo en planta con proceso real | Observación del sistema operando sobre la línea, con el personal que lo usa a diario. |
| M-06 | Análisis de registros históricos | Explotación de los registros de decisión y de operación de un periodo representativo. |
| M-07 | Entrevista estructurada con operarios | Conversación guiada con quienes usan el sistema, sin la presencia de sus responsables jerárquicos. |
Una norma sin métodos de ensayo declarados se convierte en una lista de buenas intenciones: cada auditor comprueba lo que le parece, y dos certificados dejan de significar lo mismo.
Anexo B (informativo) — Distribución por Nivel
Cuántos requisitos aporta cada dimensión en cada nivel. Ninguna dimensión puede quedar por debajo de su mínimo: no se compensa una carencia en seguridad con excelencia en trazabilidad.
| Dimensión | N1 Conforme | N2 Avanzado | N3 Ejemplar | Total |
|---|---|---|---|---|
| D1 Arquitectura de Seguridad y Control | 6 | 2 | 0 | 8 |
| D2 Datos, Modelos y Trazabilidad | 6 | 2 | 0 | 8 |
| D3 Human-in-the-Loop y Usabilidad Industrial | 5 | 2 | 1 | 8 |
| D4 Impacto en el Empleo y la Organización | 4 | 2 | 2 | 8 |
| D5 Cumplimiento Normativo y Sectorial | 5 | 3 | 0 | 8 |
| Total | 26 | 11 | 3 | 40 |
Acumulado exigible: N1 = 26 requisitos · N2 = 37 requisitos · N3 = los 40.
Anexo C (informativo) — Familia IRIS 14010–14090
Módulos verticales que se auditan como ampliación de alcance sobre un certificado IRIS 14001 vigente. No son certificables por separado.
| Código | Denominación | Ámbito |
|---|---|---|
| IRIS 14010 | Visión Artificial Industrial | Sistemas de inspección visual, control de calidad por imagen, detección de defectos |
| IRIS 14020 | Mantenimiento Predictivo | Predicción de fallos, análisis de degradación, optimización de mantenimiento |
| IRIS 14030 | Optimización de Procesos | Scheduling, planificación de producción, optimización de parámetros |
| IRIS 14040 | Gemelos Digitales | Simulación de planta, réplicas virtuales, testing de escenarios |
| IRIS 14050 | Robotización Inteligente | IA para robots industriales, cobots, AGVs y sistemas autónomos |
| IRIS 14060 | Control de Calidad con IA | Sistemas SPC inteligentes, predicción de no conformidades |
| IRIS 14070 | IA para Supply Chain | Previsión de demanda, optimización logística, gestión de inventarios |
| IRIS 14080 | Eficiencia Energética con IA | Optimización de consumo, gestión inteligente de energía |
| IRIS 14090 | Safety AI Industrial | Sistemas de seguridad basados en IA, predicción de riesgos |
Proceso de Certificación
Evaluación de producto en cuatro fases. A diferencia de un sistema de gestión, aquí se ensaya el software: el equipo auditor define las entradas, provoca los fallos y observa la respuesta.
Se define qué versión, qué dominio de validez y a qué nivel se opta. Sin alcance cerrado no se ensaya.
Revisión documental, inspección de configuración, pruebas funcionales e inyección de fallos sobre entorno controlado.
Observación sobre proceso real, entrevistas con operarios y análisis de registros históricos de una instalación viva.
Certificado ligado a una versión mayor, con revisión anual y reensayo ante cambio de arquitectura del modelo.
Condiciones del esquema
- El certificado nombra la versión. No se certifica «el producto», se certifica el producto en la versión mayor auditada.
- Cambio de arquitectura del modelo: obliga a notificación y puede requerir reensayo completo.
- Ampliación del dominio de validez: exige reensayo de la dimensión D2.
- Instalación de referencia: para N2 y N3 el proveedor debe facilitar una instalación real donde ensayar, con permiso del cliente final.
- Módulos verticales: los códigos 14010 a 14090 se auditan como ampliación sobre un certificado 14001 vigente.
Naturaleza del Esquema y Condiciones de Uso
Transparencia sobre qué es y qué no es IRIS 14001
Qué es
IRIS 14001 es un esquema de certificación de producto propio de la Iniciativa Europea Industria 4.0, publicado en abierto, cuyo cumplimiento se evalúa mediante ensayo y 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 ni relación alguna con ISO o IEC. Complementa a ISO 25000 en lo que esta no alcanza para IA industrial, pero no la sustituye ni deriva de ella.
Obtener la certificación IRIS 14001 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 se publica de forma abierta y gratuita para su lectura, cita y uso interno por cualquier organización, incluido su uso como pliego técnico de compra. Se permite la reproducción parcial citando la fuente. El uso del sello y de la denominación «certificado IRIS 14001» queda reservado a los productos que hayan superado el ensayo y mantengan su certificado vigente.
¿Quiere Certificar su Software en IRIS 14001?
El primer paso habitual es una autoevaluación contra los 40 requisitos. Díganos qué producto es y a qué nivel aspira, y le indicamos su punto de partida real.
Preguntas Frecuentes sobre IRIS 14001
¿IRIS 14001 certifica mi empresa o mi software?
Tu software. IRIS 14001 es una norma de producto: se audita un sistema concreto, en una versión concreta, con un alcance de uso declarado. Quien certifica la organización es IRIS-CORP 30000, y quien certifica la gestión de su seguridad es IRIS-SEC 27001. Un mismo proveedor puede tener las tres, y son independientes entre sí.
¿Qué diferencia hay entre los niveles N1, N2 y N3?
N1 «Conforme» exige los 26 requisitos obligatorios y se verifica sobre todo en banco y documentación. N2 «Avanzado» añade 11 requisitos y, sobre todo, exige ensayo en planta con proceso real. N3 «Ejemplar» añade 3 requisitos centrados en el impacto laboral medido y en la publicación del resultado. No es una escala de calidad del algoritmo, es una escala de cuánto se ha comprobado y de cuánto se hace público.
¿Se puede certificar un módulo vertical sin tener IRIS 14001?
No. Los códigos 14010 a 14090 son ampliaciones de alcance sobre un certificado IRIS 14001 vigente. Primero se demuestra que el producto cumple la base común, y después se audita la especificidad de visión artificial, mantenimiento predictivo, robótica o la que corresponda.
¿Qué es un «método de ensayo» y por qué importa?
Es cómo se comprueba cada requisito, declarado de antemano. Cada uno de los 40 requisitos lleva asignado uno de los 7 métodos: revisión documental, inspección de configuración, ensayo en banco, inyección de fallos, ensayo en planta, análisis de registros o entrevista con operarios. Importa porque una norma sin método de ensayo se convierte en una lista de buenas intenciones: cada auditor comprueba lo que quiere y dos certificados no significan lo mismo.
Mi software es de IA general, no industrial. ¿Puedo certificarlo?
Solo para su aplicación industrial. Si el producto tiene uso en planta, se certifica ese alcance y así queda declarado en el certificado. Si es exclusivamente para retail, servicios financieros u otros sectores, IRIS 14001 no es la norma adecuada.
¿Es una norma ISO o está acreditada?
No. IRIS 14001 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. Complementa a ISO 25000 en lo que esta no cubre para IA industrial, pero no la sustituye ni deriva de ella.
¿Cuánto tarda y cada cuánto hay que renovarlo?
De 3 a 6 meses según la complejidad del producto y el nivel al que se opte. El certificado se emite para una versión mayor concreta y tiene validez de dos años, con revisión anual. Un cambio de arquitectura del modelo o una ampliación del dominio de validez declarado obligan a notificación y pueden requerir reensayo.