Conformity Standard for Industrial AI Software
Verifiable requirements that an artificial intelligence product intended to operate on an industrial process shall meet. Where IRIS-SEC 27001 certifies how an organisation is managed, IRIS 14001 certifies how the software behaves.
Complete normative text, published openly and free to read.
A Product Standard, Not a Management System Standard
Almost every well-known standard certifies organisations: how they are run, who decides, what is documented. IRIS 14001 does not. It certifies a thing: a specific piece of software, in a specific version, subjected to specific tests. It is the difference between auditing a brake factory and braking at 100 km/h.
Certifies that the organisation has processes, owners and evidence. It says nothing about how the product it makes behaves.
ISO 9001 · ISO/IEC 27001 · IRIS-SEC 27001 · IRIS-CORP 30000
Certifies that a specific artefact meets measurable requirements, verified with test methods declared in advance.
IRIS 14001 · IRIS-PHARMA 40001 · 14010–14090 vertical family
Three Conformity Levels
They do not measure algorithm quality. They measure how much has been verified and how much is made public. Moving up a level does not require a better model: it requires submitting it to more scrutiny.
The mandatory baseline. Bench verification, documentation and configuration inspection.
26 mandatory requirements · no on-site test required
Adds verification against the real process: the auditor goes to the plant and induces the failures.
+11 requirements · on-site test and fault injection mandatory
Adds measurement of the real impact on people's work, and its publication.
+3 requirements · employment outcome measured and published
IRIS 14001:2026 Normative Text
The complete body, in the open. A supplier can self-assess against the 40 requirements before deciding whether certification pays off — and a factory can use them as a procurement specification even if the supplier is not certified.
Contents
- Scope
- Normative references
- Terms and definitions
- Requirements D1 — Security and control architecture
- Requirements D2 — Data, models and traceability
- Requirements D3 — Human-in-the-loop and usability
- Requirements D4 — Employment impact
- Requirements D5 — Regulatory compliance
- Annex A — Test methods
- Annex B — Distribution by level
- Annex C — Family 14010–14090
1 · 2 · 3 — Scope, References and Definitions
1 Scope
This standard specifies the product conformity requirements applicable to software that uses artificial intelligence techniques to predict, classify, optimise or decide on an industrial process.
1.1 Object of certification
The certifiable object is a software product identified by name and major version, with a declared validity domain. The organisation that develops it, its internal quality processes and its management systems are not covered by this standard; they are certified separately through IRIS-CORP 30000 and IRIS-SEC 27001.
1.2 Field of application
It applies to software intended for industrial environments, regardless of deployment model: on premises, at the edge, in a private cloud or as a managed service. It applies whether the software recommends or acts, and whether the model is proprietary or integrates third-party models.
1.3 Exclusions
This standard does not establish machinery functional safety requirements (IEC 61508, ISO 13849) nor replace the conformity assessment required by Regulation (EU) 2024/1689 for high-risk systems. Nor does it assess the model's predictive accuracy: it assesses that the system behaves safely, traceably and honestly including when it is wrong.
1.4 Conformity
The 26 level N1 requirements are mandatory and cannot be excluded. Level N2 and N3 requirements apply only when those levels are sought. A requirement not applicable due to the nature of the product shall be technically justified before the audit team, which rules on its relevance.
2 Normative references
The following documents are referred to in whole or in part and are indispensable for the application of this standard. Where no edition is stated, the latest in force applies.
- ISO/IEC 25000 — Software product quality (SQuaRE).
- ISO/IEC 22989 — Artificial intelligence concepts and terminology.
- ISO/IEC 23894 — Artificial intelligence risk management.
- IEC 62443-4-1 and 62443-4-2 — Development and component requirements for industrial control systems.
- ISO 9241-210 — Human-centred design.
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- IRIS-SEC 27001 — Information security in industrial AI.
- IRIS 14090 — Industrial Safety AI.
3 Terms and definitions
For the purposes of this standard the following terms apply. Terms not defined here are taken from ISO/IEC 22989.
3.1 industrial AI product
Software identified by name and version that applies inference to industrial process data to produce predictions, classifications, recommendations or setpoints.
3.2 validity domain
Declared set of process conditions, materials, ranges and installations for which product behaviour has been validated by its manufacturer.
3.3 test method
Declared procedure by which the audit team verifies compliance with a requirement. The seven admissible methods are defined in Annex A.
3.4 safe degradation
Predefined operational state to which the process transitions when the product ceases to be reliable or available, without compromising the safety of people or the integrity of the manufactured product.
3.5 override
Action by which a person nullifies the product's actuation or recommendation, with immediate effect and without requiring hierarchical authorisation.
3.6 conformity level
Degree of scrutiny to which the product has been subjected: N1 Conformant, N2 Advanced, N3 Exemplary. It does not express predictive quality.
3.7 disagreement
Situation in which the responsible person takes a decision different from the one recommended by the product.
Requirements (normative) — The 40 Verifiable Points
Each requirement carries its assigned test method and the level from which it becomes mandatory. Level N1 requirements are mandatory for any certification, whichever level is sought.
| Code | Requirement | Method | Level |
|---|---|---|---|
| R.1.1 | Separation of inference and controlThe inference layer shall be separated from the process control logic, so that a failure of the former does not prevent safe operation of the latter. | M-04 | N1 |
| R.1.2 | Declared actuation limitsThe software shall declare the maximum range of variation it can induce on each process variable, and enforce it at runtime. | M-03 | N1 |
| R.1.3 | Safe degradation stateA defined state shall exist to which the system transitions when it ceases to be reliable, and entering that state shall not depend on external connectivity. | M-04 | N1 |
| R.1.4 | Watchdog and availability signalThe system shall expose a liveness signal verifiable by the control system, with a declared period. | M-03 | N1 |
| R.1.5 | Startup in a known stateAfter a power loss or restart, the system shall boot into a documented state and shall not resume automatic actuation without confirmation. | M-04 | N1 |
| R.1.6 | Isolation of the safety pathNo machine or process safety function shall depend on a model output. | M-01 | N1 |
| R.1.7 | Continuity test without AIIt shall be demonstrated on site that the process remains safe and productive with the system disconnected. | M-05 | N2 |
| R.1.8 | Critical signal redundancyVariables on which automatic actuation depends shall come from a redundant or cross-checked source. | M-02 | N2 |
| Code | Requirement | Method | Level |
|---|---|---|---|
| R.2.1 | Reconstructable decision recordFor any past decision it shall be possible to reconstruct which model version produced it, with which inputs and at what confidence. | M-06 | N1 |
| R.2.2 | Identifiable model versioningEvery deployed model shall carry a unique identifier visible from the operating interface. | M-02 | N1 |
| R.2.3 | Training set documentationThe origin, period and process conditions of the data used to train the model shall be documented. | M-01 | N1 |
| R.2.4 | Declared validity domainThe supplier shall state the process conditions outside which the model is not validated. | M-01 | N1 |
| R.2.5 | Out-of-domain detectionThe system shall detect and flag when it is operating outside its declared validity domain. | M-03 | N1 |
| R.2.6 | Evidence retentionDecision records shall be retained for the period required by the sector and be exportable in an open format. | M-06 | N1 |
| R.2.7 | Drift measurementThe system shall continuously measure divergence between operational and training data, and expose the result. | M-06 | N2 |
| R.2.8 | Inference reproducibilityGiven the same inputs and model version, the output shall be reproducible or its variability bounded and declared. | M-03 | N2 |
| Code | Requirement | Method | Level |
|---|---|---|---|
| R.3.1 | Always-available overrideThe operator shall be able to override the system at any time, without special credentials or menu navigation. | M-05 | N1 |
| R.3.2 | Bounded override timeThe time between the override command and its effect on the process shall be measured and declared. | M-03 | N1 |
| R.3.3 | Operator-level explanationEvery recommendation shall carry a reason understandable by the person who will act on it, not merely a score. | M-07 | N1 |
| R.3.4 | Honest uncertainty expressionThe system shall visually distinguish a reliable output from a doubtful one, rather than presenting all with equal authority. | M-05 | N1 |
| R.3.5 | Use with protective equipmentThe interface shall be operable with gloves, under ambient noise and in the real lighting conditions of the workstation. | M-05 | N1 |
| R.3.6 | Disagreement loggingWhen the operator contradicts the system, the fact and reason shall be recorded, and that record shall feed model improvement. | M-06 | N2 |
| R.3.7 | No automated pressureThe system shall not use countdowns, escalating alarms or penalties that push the operator to accept its recommendation without evaluating it. | M-07 | N2 |
| R.3.8 | Periodic override verificationOverride capability shall be tested under real conditions at a declared frequency, not reviewed on paper. | M-05 | N3 |
| Code | Requirement | Method | Level |
|---|---|---|---|
| R.4.1 | Declared job impactThe supplier shall state which tasks of the role the system absorbs and which it does not. | M-01 | N1 |
| R.4.2 | Training plan includedThe supply shall include training for affected personnel, sized and with defined content. | M-01 | N1 |
| R.4.3 | No covert individual monitoringThe system shall not produce individual performance metrics unless expressly declared and legally grounded. | M-02 | N1 |
| R.4.4 | Knowledge transfer to the teamDocumentation shall enable in-house personnel to understand why decisions are made, not only how to use the system. | M-01 | N1 |
| R.4.5 | Information to worker representativesThere shall be evidence that legal worker representation has been informed of the deployment and its scope. | M-01 | N2 |
| R.4.6 | Measurement of real job changeThe change in the work content of affected people shall be measured before and after. | M-07 | N2 |
| R.4.7 | Verified reskillingIt shall be evidenced that personnel displaced from a task have received and passed training for the new one. | M-01 | N3 |
| R.4.8 | Publication of employment outcomeThe aggregate employment outcome shall be published or made available to the IRIS Observatory. | M-01 | N3 |
| Code | Requirement | Method | Level |
|---|---|---|---|
| R.5.1 | AI Act classificationThe supplier shall declare whether the system is high-risk under Regulation (EU) 2024/1689 and substantiate the classification. | M-01 | N1 |
| R.5.2 | Available technical documentationSufficient technical documentation for an inspection shall exist, kept current with deployed versions. | M-01 | N1 |
| R.5.3 | Legal basis for personal dataWhere personal data is processed, the legal basis shall be identified and minimisation applied. | M-01 | N1 |
| R.5.4 | Identified sectoral requirementsThe requirements of the target sector shall be identified and how the system meets them documented. | M-01 | N1 |
| R.5.5 | Serious incident notificationA procedure shall exist by which the supplier notifies the customer of incidents affecting system reliability. | M-01 | N1 |
| R.5.6 | Post-market monitoringThe supplier shall systematically collect the system's behaviour at customer installations. | M-06 | N2 |
| R.5.7 | Documented interoperabilityInterfaces with existing industrial systems shall be documented and based on open protocols where an option exists. | M-02 | N2 |
| R.5.8 | Supply reversibilityThe customer shall be able to recover their data and history in a usable format when the contractual relationship ends. | M-01 | N2 |
Annex A (normative) — Test Methods
The seven methods used to verify each requirement. The method is declared before the audit and cannot be swapped for a weaker one without technical justification accepted by the certification body.
| Code | Test method | What it involves |
|---|---|---|
| M-01 | Documentary review | Examination of the technical, contractual and process documentation supplied by the provider. |
| M-02 | Configuration inspection | Direct verification on the installation of parameters, permissions, interfaces and versions. |
| M-03 | Functional bench test | Testing system behaviour in a controlled environment, with inputs defined by the audit team. |
| M-04 | Fault injection | Deliberate induction of network loss, service outage, corrupted data or out-of-range inputs. |
| M-05 | On-site test with the real process | Observing the system operating on the line, with the personnel who use it daily. |
| M-06 | Historical log analysis | Analysis of decision and operation records over a representative period. |
| M-07 | Structured operator interview | Guided conversation with those who use the system, without their line managers present. |
A standard without declared test methods becomes a list of good intentions: every auditor checks whatever seems reasonable, and two certificates stop meaning the same thing.
Annex B (informative) — Distribution by Level
How many requirements each dimension contributes at each level. No dimension may fall below its minimum: a shortfall in safety is not offset by excellence in traceability.
| Dimension | N1 Conformant | N2 Advanced | N3 Exemplary | Total |
|---|---|---|---|---|
| D1 Security and Control Architecture | 6 | 2 | 0 | 8 |
| D2 Data, Models and Traceability | 6 | 2 | 0 | 8 |
| D3 Human-in-the-Loop and Industrial Usability | 5 | 2 | 1 | 8 |
| D4 Employment and Organisational Impact | 4 | 2 | 2 | 8 |
| D5 Regulatory and Sectoral Compliance | 5 | 3 | 0 | 8 |
| Total | 26 | 11 | 3 | 40 |
Cumulative requirement: N1 = 26 requirements · N2 = 37 requirements · N3 = all 40.
Annex C (informative) — IRIS 14010–14090 Family
Vertical modules audited as a scope extension over a valid IRIS 14001 certificate. They are not separately certifiable.
| Code | Designation | Scope |
|---|---|---|
| IRIS 14010 | Industrial Machine Vision | Visual inspection systems, image-based quality control, defect detection |
| IRIS 14020 | Predictive Maintenance | Failure prediction, degradation analysis, maintenance optimisation |
| IRIS 14030 | Process Optimisation | Scheduling, production planning, parameter optimisation |
| IRIS 14040 | Digital Twins | Plant simulation, virtual replicas, scenario testing |
| IRIS 14050 | Intelligent Robotics | AI for industrial robots, cobots, AGVs and autonomous systems |
| IRIS 14060 | AI Quality Control | Intelligent SPC systems, nonconformity prediction |
| IRIS 14070 | Supply Chain AI | Demand forecasting, logistics optimisation, inventory management |
| IRIS 14080 | AI Energy Efficiency | Consumption optimisation, intelligent energy management |
| IRIS 14090 | Industrial Safety AI | AI-based safety systems, risk prediction |
Certification Process
Product assessment in four phases. Unlike a management system, here the software is tested: the audit team defines the inputs, induces the failures and observes the response.
Which version, which validity domain and which level is sought are defined. Without a closed scope there is no testing.
Documentary review, configuration inspection, functional testing and fault injection in a controlled environment.
Observation on the real process, operator interviews and historical log analysis at a live installation.
Certificate tied to a major version, with annual review and retesting on model architecture change.
Scheme conditions
- The certificate names the version. 'The product' is not certified; the product in the audited major version is.
- Model architecture change: requires notification and may trigger full retesting.
- Extension of the validity domain: requires retesting of dimension D2.
- Reference installation: for N2 and N3 the supplier shall provide a real installation for testing, with the end customer's permission.
- Vertical modules: codes 14010 to 14090 are audited as an extension over a valid 14001 certificate.
Nature of the Scheme and Terms of Use
Transparency about what IRIS 14001 is and is not
What it is
IRIS 14001 is a product certification scheme owned by European Initiative Industry 4.0, openly published, whose fulfilment is assessed through testing and an independent third-party audit.
What it is not
It is not an ISO, IEC, CEN or UNE standard. It is not accredited by ENAC or any national accreditation body. It implies no endorsement or relationship with ISO or IEC. It complements ISO 25000 where that standard does not reach for industrial AI, but neither replaces nor derives from it.
Obtaining IRIS 14001 certification does not exempt an organisation from any legal obligation, including the conformity assessment required by Regulation (EU) 2024/1689 for high-risk AI systems.
Terms of use of the normative text
The text is published openly and free of charge for reading, citation and internal use by any organisation, including use as a technical procurement specification. Partial reproduction is permitted with attribution. Use of the mark and of the designation 'IRIS 14001 certified' is reserved to products that have passed testing and hold a valid certificate.
Want to Certify Your Software to IRIS 14001?
The usual first step is a self-assessment against the 40 requirements. Tell us what the product is and which level you are aiming for, and we will show you your real starting position.
Frequently Asked Questions about IRIS 14001
Does IRIS 14001 certify my company or my software?
Your software. IRIS 14001 is a product standard: a specific system is audited, in a specific version, with a declared scope of use. The organisation is certified by IRIS-CORP 30000, and the management of its security by IRIS-SEC 27001. One supplier may hold all three, and they are independent of each other.
What is the difference between levels N1, N2 and N3?
N1 'Conformant' requires the 26 mandatory requirements and is verified mainly on the bench and through documentation. N2 'Advanced' adds 11 requirements and, above all, requires on-site testing with the real process. N3 'Exemplary' adds 3 requirements centred on measured employment impact and publication of the outcome. It is not a scale of algorithm quality; it is a scale of how much has been verified and how much is made public.
Can a vertical module be certified without holding IRIS 14001?
No. Codes 14010 to 14090 are scope extensions over a valid IRIS 14001 certificate. First the product is shown to meet the common baseline, then the specificity of machine vision, predictive maintenance, robotics or whichever applies is audited.
What is a 'test method' and why does it matter?
It is how each requirement is verified, declared in advance. Each of the 40 requirements is assigned one of 7 methods: documentary review, configuration inspection, bench test, fault injection, on-site test, log analysis or operator interview. It matters because a standard without test methods becomes a list of good intentions: every auditor checks whatever they like, and two certificates no longer mean the same thing.
My software is general AI, not industrial. Can I certify it?
Only for its industrial application. If the product is used on the shop floor, that scope is certified and stated on the certificate. If it is exclusively for retail, financial services or other sectors, IRIS 14001 is not the right standard.
Is it an ISO standard, or accredited?
No. IRIS 14001 is a certification scheme owned by European Initiative Industry 4.0, independent of ISO, IEC, CEN, AENOR and ENAC, without accreditation or endorsement from those bodies. It complements ISO 25000 where that standard does not reach for industrial AI, but neither replaces nor derives from it.
How long does it take and how often must it be renewed?
Three to six months depending on product complexity and the level sought. The certificate is issued for a specific major version and is valid for two years, with annual review. A change of model architecture or an extension of the declared validity domain requires notification and may trigger retesting.