# Deploying AI under OT and safety constraints
An AI model watches a torque-fastening station and flags a pattern: bolts on a certain engine bracket are trending toward the low end of spec. It recommends bumping target torque by a small amount. That recommendation does not go straight to the tool. It stops. Before a single fastener changes, the change must pass through the machine's PLC logic, a functional-safety review, and a human sign-off.
That gap between "the model recommends" and "the line actually changes" is the entire subject of this lesson. In manufacturing, AI does not get to touch the physical process just because it is confident.
First, define the terrain.
IT (Information Technology) is your email, ERP, databases, and cloud. Its priority is confidentiality and data integrity. If IT goes down for an hour, that is painful but recoverable.
OT (Operational Technology) is the equipment that runs the physical plant: PLCs, drives, sensors, robots, safety relays. A PLC (Programmable Logic Controller) is the rugged industrial computer that executes the deterministic control logic on a machine. OT's priority is availability and safety. If a stamping press behaves unexpectedly, people can be hurt.
AI lives naturally in the IT and cloud world: lots of data, fast iteration, retraining on the fly. OT is the opposite: change is slow, validated, and deeply conservative. Deploying AI in manufacturing means bridging these two cultures without letting IT's "move fast" habits contaminate a safety-critical machine.
To place AI correctly, engineers use ISA-95, an international standard that describes manufacturing systems as a stack of levels.
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.
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.View full definition → 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.View full definition →, 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.
You get most of the payoff from AI in read-only or advisory roles. Concrete examples:
Notice the pattern. AI shortens the distance to a good decision. A qualified human and the existing control system still make the change.
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" 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:
Below is a simplified illustration of the boundary in code. The model outputs an object that cannot execute anything; it only requests review.
recommendation = {
"asset": "torque_station_07",
"parameter": "target_torque_nm",
"current": 42.0,
"suggested": 43.5,
"confidence": 0.88,
"safety_relevant": True, # forces functional-safety review
"status": "PENDING_HUMAN_REVIEW"
}
# No write to the PLC here. The object is queued for an engineer.
send_to_review_queue(recommendation)The point of the snippet: the AI's job ends at a request. There is no code path from the model to the actuator.
Knowledge check
1. Why must an AI-generated torque recommendation pass through PLC logic, a functional-safety review, and human sign-off before changing the physical process?
2. What best captures the fundamental cultural difference between IT and OT that complicates AI deployment in manufacturing?
3. According to ISA-95, where would a PLC executing deterministic control logic on a machine be located?
4. Select ALL correct answers about why OT environments are treated more conservatively than IT environments.
Select all the correct answers.
5. Select ALL correct answers about where AI naturally fits versus where it must be constrained in a manufacturing stack.
Select all the correct answers.
When a plant asks "can we deploy this model?", walk the layers:
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.