Deploying AI under OT and safety constraints

To place AI correctly, engineers use ISA-95, an international standard that describes manufacturing systems as a stack of levels.

• Level 0: the physical process (motors, valves, sensors).
• Level 1: sensing and actuation control (PLCs).
• Level 2: supervisory control (SCADA, HMI screens).
• Level 3: manufacturing operations (MES, scheduling, quality).
• Level 4: business systems (ERP).

Most manufacturing AI belongs at Levels 3 and 4, or in a cloud layer above them. It analyzes, predicts, and recommends. It should almost never write directly to Level 1. The torque model in our opening scene sits well above the PLC. It sends a suggestion upward to a human and to operations systems, not a command downward to the tool.

Keep this rule in mind: AI proposes at high levels; validated control logic disposes at low levels.

Securing the connection: IEC 62443

Connecting AI to plant data creates a new attack surface. The relevant framework is IEC 62443, the leading standard for industrial automation and control system security.

Two of its core ideas matter here:

Zones and conduits. You group assets into security "zones" (for example, the safety-critical cell, the general OT network, the IT network) and control every "conduit" (data path) between them. An AI system pulling sensor data should sit in its own zone and reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → OT only through a tightly controlled, monitored conduit, often a one-way data diode or a firewall with strict rules.

Defense in depth. No single control is trusted. SegmentationSegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète →, authentication, monitoring, and least-privilege access all layer together.

The practical takeaway: your AI should read from OT far more freely than it writes. Most robust deployments start read-only. The model observes vibration, temperature, cycle times, and defect images, and produces insight. Any write-back path is a separate, heavily governed project.

A free primer worth reading is the CISA guidance on securing operational technology, which explains OT threat patterns in plain language.

Where AI adds value without touching the line

You get most of the payoff from AI in read-only or advisory roles. Concrete examples:

• Predictive maintenance. A model on Level 3 ingests motor current and vibration and predicts a bearing failure days ahead. Output: a maintenance work order, not a shutdown command.
• Visual quality inspection. A vision model flags surface defects on a casting. Output: a reject-lane suggestion an operator confirms.
• Process optimization advisory. A model suggests oven temperature setpoints for better yield. Output: a recommendation an engineer reviews and, if approved, enters through the normal validated procedure.

Notice the pattern. AI shortens the distance to a good decision. A qualified human and the existing control system still make the change.

Functional safety: the hard boundary

Some functions exist purely to prevent harm: an emergency stop, a light curtain that halts a robot when someone enters its cell, an overpressure cutoff. These are functional safety systems, governed by standards like IEC 61508 (general) and ISO 13849 (machinery).

The rule here is blunt: AI does not sit inside the safety function. A safety relay that stops a press must be simple, deterministic, and certifiable. You cannot certify a neural network's behavior across every possible input the way you can certify a hardwired safety circuit. So the safety layer stays independent and dumb, in the good sense: predictable and testable.

AI can *inform* safety indirectly (for example, predicting when a light curtain sensor is degrading), but it must never *be* the thing that keeps a worker's hand out of the die.

This is why the torque recommendation triggers a functional-safety review. Even a small torque change can affect clamping force, fastener fatigue, and downstream assembly integrity. Someone qualified has to confirm the change does not create a hazard.

Human-in-the-loop governance

"Human-in-the-loop" means a person reviews and approves an AI output before it takes effect. For OT, design this explicitly.

A workable governance flow for our torque case:

1. Model detects the drift and generates a recommendation with its evidence (the data, the confidence, the trend).

2. Recommendation is logged and routed to a process engineer, not the machine.

3. Engineer evaluates against spec and triggers a functional-safety review if the change affects a safety-relevant parameter.

4. If approved, the change is implemented through the normal validated procedure: updated in the PLC or recipe by an authorized person, with change control and version records.

5. The outcome is fed back to the model's monitoring so you can see whether the change helped.

Three things make this real:

• Auditability. Every recommendation and decision is logged. If a regulator or customer audit asks why torque changed, you have a record.
• Reversibility. You can roll back to the previous validated state quickly.
• Clear ownership. A named human, not "the AI," is accountable for the change.

Below is a simplified illustration of the boundary in code. The model outputs an object that cannot execute anything; it only requests review.

The point of the snippet: the AI's job ends at a request. There is no code path from the model to the actuator.

Putting it together: a deployment checklist

When a plant asks "can we deploy this model?", walk the layers:

• Placement: Is the AI at ISA-95 Level 3 or 4, reading data rather than writing control? Start read-only.
• Security: Is it in its own IEC 62443 zone, with a monitored conduit and least-privilege access to OT data?
• Safety: Does any recommendation touch a safety-relevant parameter? If so, a functional-safety review is mandatory and non-negotiable.
• Human-in-the-loop: Is there a named approver, an audit log, and a reversible, validated change procedure?
• Feedback: Do you measure whether acted-on recommendations actually improved outcomes?

If any answer is unclear, the model stays advisory. That is not a failure. Advisory AI already captures most of the value with a fraction of the risk.

Key takeaways

• AI proposes; validated control disposes. Keep AI at ISA-95 Levels 3 and 4, reading data and recommending, not writing directly to PLCs.
• Start read-only. Predictive maintenance, visual inspection, and advisory optimization deliver value without any risky write-back path.
• Safety functions stay independent of AI. Emergency stops and interlocks must remain simple, deterministic, and certifiable under standards like IEC 61508 and ISO 13849.
• Secure the connection with IEC 62443 zones and conduits, and treat any OT write access as a separate, tightly governed project.
• Make governance concrete: named human approver, audit log, reversibility, and a validated change procedure for every AI recommendation that reaches the line.