AI in process safety management: what changes in each element

What does AI change in each element of process safety management?

• Process safety information. A model trained on historian data becomes process knowledge. Its training data, valid range and version belong in the record, next to the safe upper and lower limits OSHA requires under paragraph (d).
• Hazard identification and risk analysis. AI is a node to study where its output feeds a decision, and a tool that drafts or checks the study. Both need rules. See AI in HAZOP.
• Operating procedures. An AI assistant’s sources fall under document control. Procedures need steps for when the model is unavailable or wrong.
• Operating limits. Optimisation pushes towards the edge of the envelope. The limits, and the consequences of deviation that OSHA paragraph (f) requires procedures to state, have to bind the model. See AI and operating limits.
• Process control and alarms. An advisory or closed-loop model in the control system changes what the operator sees and what the plant does. AI alarm ranking falls under the alarm philosophy and IEC 62682. See AI in process control and DCS.
• Safety instrumented systems. IEC 61508 and IEC 61511 contain no AI-specific guidance. ISO/IEC TR 5469:2024 gives guidance for AI inside or around safety functions. See AI and safety instrumented systems.
• Management of change. Retraining, a vendor update or a new data source changes process technology. Many MOC procedures do not yet catch it. See AI management of change.
• Mechanical integrity. A predictive maintenance model that supports a deferral or a longer interval becomes part of the inspection and maintenance basis. Its blind spots belong in the deferral risk assessment, as the Corlinda case shows.
• Control of work. AI that drafts permits, checks isolations or flags clashes between jobs sits inside a barrier the permit issuer signs for. See AI in control of work.
• Training and competence. People need to question the model as well as use it. They also need to run the plant when it is down, and competence assessment has to test that.
• Incident investigation. Investigators need the model version, its inputs and its outputs at the time of the event, so those records have to be kept.
• Emergency response. Where a camera system or an AI alert starts the response, the plan states who acts on it and what happens when it fails.
• Audit. Audits test whether the elements above cover the AI the site actually uses, including tools staff adopted without approval.

Examples by asset type are in AI by asset.

Do insurers exclude AI-related losses, and what will JV partners and buyers ask?

Insurers. The AI exclusions most often quoted are narrower than they sound. Verisk filed “optional multistate exclusion endorsements for Generative Artificial Intelligence for use with the ISO General Liability program” (Verisk). These are US general liability forms, effective January 2026 (Independent Agent). Each carrier decides whether to attach them. They are written for generative AI. On my reading they are not aimed at AI used in process control, but the test is your own policy wording, which you should read with your broker. Expect a risk engineer to ask what AI acts on the process and how it went through management of change.

JV partners. A non-operating partner relies on the operator’s safety management system. Where the operator brings AI into control, alarm handling or maintenance decisions, the partner can ask for the AI use inventory, the MOC records and the assurance plan, in the same way it asks about any other change to major accident risk.

Due diligence. A buyer of an operating asset needs to know which decisions AI now informs or takes, who owns each model, whether the vendor contracts survive the sale, and whether the site can still run without it. The answers belong in the operational and process safety review, next to integrity and competence. See the AI audit specialist for how I join a review team.

If you own the AI Act file and not the safety management system

Where the AI compliance role sits in legal, data or IT, the safety management system usually stays with operations and HSE. On a high-hazard site the two files describe the same systems, and the SMS owner needs four things from the AI Act owner.

First, the register. The SMS owner needs every AI system that reaches a decision about the hazardous process, with its provider, version and intended purpose, so each one can be matched to an MOC record and a risk assessment.

Second, the classification and its date. Whether a system is high-risk under Annex III, under Annex I or not at all decides when the deployer duties in Article 26 apply. See the dates for operators.

Third, the provider’s documents. The instructions for use, the stated limits and the provider’s post-market monitoring belong in process safety information, operating procedures and operator training.

Fourth, one route for changes and incidents. A vendor update or a retraining is both an AI Act matter and a management of change. A serious incident is reportable under the AI Act and investigated under the SMS. Agreeing one route avoids two parallel records of the same event.

In return, the SMS owner can give the AI Act owner the evidence that human oversight works in practice, from competence records, drills and barrier assessments.

Which AI rules sit alongside process safety law?

In the EU, an AI system intended as a safety component in the supply of gas, heating or electricity is high-risk under Annex III of the EU AI Act. The NIST AI Risk Management Framework gives general guidance.

To see what AI changes in your own elements, start with an autonomous operations briefing.