Can AI be used in a SIL-rated function?
IEC 61511 sets requirements for the specification, design, installation, operation and maintenance of a SIS “so that it can be confidently entrusted to achieve or maintain a safe state of the process” (IEC 61511-1). That confidence rests on a specified function, a design verified against its specification, a calculated probability of failure on demand and proof tests at a set interval. The UK HSE describes protection against systematic failures through a properly managed safety lifecycle, and notes that the probability of failure on demand “is critically dependent upon the frequency of proof testing” (HSE, Control systems).
A learned model fits this poorly. Its behaviour across the full input range cannot be specified in advance or covered by test. It can change when retrained. A proof test says little about inputs the model has never seen. The current reference is ISO/IEC TR 5469:2024, a technical report that gives guidance, not requirements. It covers AI inside a safety-related function, conventional safety functions protecting AI-controlled equipment, and AI used to design safety functions.
Where is AI arriving around the SIS?
I audited safety instrumented systems at bp and trained in SIL and LOPA earlier at INEOS. These uses sit outside the safety function, yet each feeds the evidence the SIS relies on.
- Proof-test interval optimisation. A model that proposes longer intervals from failure history changes an input to the PFD calculation. Its data, including which failures were recorded and what each test covered, becomes part of the SIL verification basis.
- Demand-rate and spurious-trip analytics. A measured demand rate above the one assumed in the LOPA is a finding for the hazard and risk assessment. A spurious-trip fix that alters voting, setpoints or time delays is a SIS modification.
- Bypass and override monitoring. HSE expects override management to cover authorisation, security, recording, monitoring and review. Once a model that flags long or repeated overrides becomes the monitoring, its coverage and failure modes belong in the procedure.
- Predictive diagnostics of final elements. Valve signature or partial-stroke analytics credited for diagnostic coverage, or used to defer a full test, change the assumptions in the SRS. The Corlinda case shows how a deferral supported by a model can go wrong.
- AI used to draft the SRS or the SIL determination. A generated draft looks complete. The reviewer needs the competence to find what is missing, and the functional safety assessment stays independent of the tool. The study side is covered in AI and HAZOP.
What changes in the functional safety management plan?
For each use, the plan names the tool, its owner and the lifecycle phase it supports. Any value it supplies that the SRS or the PFD calculation credits must be traceable to validated data. A retrained model or a new vendor version is a change to the SIS basis and needs a trigger in AI management of change. Competence requirements extend to the people who accept its outputs. Functional safety assessments and audits include it in scope.
Is AI around the SIS high-risk under the EU AI Act?
Annex III point 2 classes as high-risk AI systems intended as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. Whether a given use around a SIS is such a safety component is a legal question. Settle it for each use before deployment, because the answer changes the obligations.
The wider picture is on the AI process safety management page. To test one SIS use against your own system, start with an autonomous operations briefing.