Where AI decisioning meets functional-safety engineering
Process and engineering environments already run on a mature, decades-old discipline for rating how much a safety-critical function can be trusted: Safety Integrity Levels under IEC 61508 and its process-sector counterpart, IEC 61511. Where an AI system sits inside or alongside a Safety Instrumented System — an anomaly-detection model feeding an interlock, an AI-assisted alarm-management layer, a predictive-maintenance model informing a shutdown decision — the question isn't whether AI is a fifth SIL. It's whether the surrounding engineering discipline that makes SIL meaningful has actually been applied to the AI component too.
What AIC maps, and against what
AIC maps AI-assisted decisioning in process and engineering environments against the same hazard-and-risk discipline the industry already uses for physical safety functions, using the plant's own SIL-rated architecture as the reference frame rather than inventing a parallel one. This applies to AI used for anomaly detection, predictive maintenance, alarm rationalisation, and decision-support feeding into (but not replacing) an existing Safety Instrumented System.
The established concept, and its AI equivalent
| Established | AI equivalent | What it means here |
|---|---|---|
| HAZOP | AI-aware HAZOP | Hazard and operability review extended to cover how an AI component's failure modes and drift could propagate into the process. |
| LOPA / Independent Protection Layers | AI as a claimed layer, or not | Whether an AI system can be credited as an independent protection layer at all, and what has to be true for that claim to hold. |
| FMEA | AI-FMEA | Failure Mode and Effects Analysis applied to model failure modes — not just component failure modes. |
| Management of Change (MOC) | Model change control | The same change-control discipline applied to a retrained or re-tuned model as to a physical modification. |
| Permit-to-work / Responsible Charge | Named human accountability | A named, competent person accountable for the AI-assisted decision — the same principle underlying every AIC certification. |
The safety measures a subject demonstrates
Named accountable engineer
A specific, competent individual is accountable for the AI component's role in the safety architecture — not a team, not a vendor.
Documented failure-mode analysis
The AI component has been through a hazard and failure-mode review appropriate to its role, with findings on record.
Change control on the model
Retraining, re-tuning, or model updates go through the same management-of-change discipline as any other safety-relevant modification.
Drift and performance monitoring
Ongoing monitoring exists for the model's performance and data drift, not just a one-time validation at deployment.
Clear protection-layer status
Whether the AI system is, or is not, being credited as a protection layer is explicit and documented — never assumed.
Where this mapping has limits
This translation has real limits, and AIC states them rather than papering over them. SIL is built on demonstrable, quantified failure rates for hardware and well-understood software — a probability of failure on demand that can be calculated and audited. Most AI/ML components cannot currently produce an equivalent, traceable number: this is a recognised assurance gap in current guidance (see IET and BSI commentary on AI in safety-related systems), not something AIC or anyone else has solved. AI failure modes also tend to be systematic rather than random, harder to make "fail-safe" in the classical sense, and vulnerable to common-cause failure through shared training data or supply chains. Standards are still catching up — ISO/IEC TR 5469:2024 and ISO/IEC TS 22440 (in committee) are early steps, and no AI/ML-specific verification and validation standard exists yet in the ASME VVUQ series. Treat this mapping as a rigorous translation of engineering discipline, not a claim that AI has been reduced to a SIL number.
Reviewed 2026-09-01.