Process and engineering environments already have a mature discipline for deciding how much a safety-critical function can be trusted. Under IEC 61508 and its process-sector counterpart IEC 61511, a safety function is assigned a Safety Integrity Level — SIL 1 through 4 — and that rating carries real consequences for how it is designed, proof-tested, documented and maintained.
When an AI component appears near that architecture — an anomaly-detection model feeding an interlock, a predictive-maintenance model informing a shutdown decision, an alarm-rationalisation layer — the natural question is what SIL it should carry.
That question is worth taking seriously and it is worth answering carefully, because the honest answer has two halves that point in opposite directions.
What transfers well
Most of what makes functional safety work is not the number. It is the surrounding discipline, and that discipline applies to AI components with very little modification.
Hazard and operability review. A HAZOP asks systematically what happens when each part of a system deviates from intent. That method extends naturally to an AI component: what happens when the model drifts, when input distribution shifts, when it is confidently wrong rather than obviously broken. The technique does not care whether the deviating element is a valve or a classifier.
Failure mode analysis. FMEA applied to a model rather than a component is unfamiliar but not conceptually hard. Models have failure modes. They are simply less enumerable than a valve's, which makes the exercise more valuable, not less.
Protection layer accounting. LOPA forces an explicit question: is this AI system being credited as an independent protection layer, and what would have to be true for that claim to hold? The most common answer we would expect is no, and it should not be — but the value is in the question being asked and answered explicitly rather than assumed.
Management of change. This is where the analogy earns its keep. Process industries have rigorous MOC discipline: a physical modification goes through review, approval and documentation. A retrained model is a modification. It very often does not go through anything. An organisation that already runs MOC properly has the machinery to govern model updates and frequently has not thought to point it there.
Competency and responsible charge. Someone named, qualified and accountable signs off. This is the closest existing analogue to what we certify.
What does not transfer
Now the other half, and it is the part that matters most.
SIL is quantitative, and the quantity cannot currently be produced for AI. A SIL rating rests on a demonstrable probability of failure on demand — a number derived from failure-rate data, architecture and proof-test intervals, and auditable by a third party. Most machine-learning components cannot produce a defensible equivalent. This is a recognised assurance gap in current guidance, not something we or anyone else has solved.
Anyone offering an "AI-SIL" with a number attached should be asked precisely how that number was derived and what data supports it. We would expect the answer to be unsatisfying.
AI failures are systematic, not random. Functional safety mathematics is built substantially on random hardware failure, which is statistically tractable. A model failing on an input class it was never trained to handle is not random — it will fail that way every time, deterministically, until something changes. Redundancy helps far less than it does with hardware. Two models trained on the same data share the same blind spots, so a 2oo3 arrangement can produce agreement without producing correctness.
Failures are not conspicuous. A failed transmitter usually announces itself — out of range, flatlined, obviously wrong. A drifting model returns a plausible number. It stays inside the range operators expect and moves in the direction they expect. It is exactly the kind of failure a control room is least equipped to notice, because everything looks normal.
Common-cause failure enters through the supply chain. Two independent-looking AI systems may share a foundation model, a training corpus, or a vendor. That is a common-cause dependency that a conventional independence analysis is not looking for and will not find.
The environment is non-stationary. IEC 61508 assumes a function whose behaviour is stable unless modified. A model's effective behaviour changes as the world it observes changes, without anyone touching it. A proof test confirms the function worked at the moment of testing, which is a weaker statement than it is for a pressure transmitter.
Where the standards actually are
The formal landscape is genuinely immature, and it is worth being direct about that rather than implying more coverage than exists.
ISO/IEC TR 5469:2024 addresses functional safety and AI, and is a technical report — informative, not certifiable against. ISO/IEC TS 22440 is in progress. ISO/IEC 23894:2023 covers AI risk management at an organisational level rather than functional safety. Within the ASME VVUQ series, verification and validation for machine learning does not yet have a published standard.
So there is no equivalent of IEC 61508 for AI to certify against, and claims to the contrary should be treated with suspicion.
How we approach it
We map AI-assisted decisioning against the discipline an organisation already runs, using its own SIL-rated architecture as the reference frame rather than inventing a parallel one. What we assess is whether that discipline has genuinely been extended to the AI component: whether a named competent person is accountable for its role, whether its failure modes have been analysed, whether model changes go through change control, whether drift is monitored, and whether its protection-layer status is explicit rather than assumed.
What we do not do is issue a number implying the AI component has been reduced to a SIL. That number does not exist yet. Saying so is more useful than manufacturing one — particularly to engineers, who will recognise a fabricated reliability figure faster than most.
The full mapping is published under Frameworks, including the limits above.