A controls engineer at a mid-market plant builds something genuinely clever. He has a predictive-maintenance model that watches the historian for a particular pump on the main coolant loop, and it has gotten good at spotting the early signature of cavitation hours before the pump trips. So far, so safe. Then his plant manager, thrilled, asks the obvious next question: "If it can see the problem coming, why doesn't it just slow the pump down automatically before it gets bad?" The engineer wires it up. The model now writes a setpoint back through the SCADA (Supervisory Control and Data Acquisition, the system that monitors and commands the plant's process equipment) to the variable-frequency drive on the pump. For three weeks it works beautifully. Then on a hot Thursday the model misreads a sensor glitch, a single bad reading from a fouled transmitter, as the onset of cavitation, and it cuts the coolant pump to forty percent. Within ninety seconds the process temperature climbs past the alarm band on a different system, an interlock trips the whole line, and the plant takes a four-hour unplanned shutdown that costs about $11,000 in lost production and a half-day of investigation. The model was not malfunctioning. It did exactly what it was built to do, on bad data, with its hands on the controls. That last clause is the whole problem. The most important boundary in plant AI is not technical accuracy. It is the line between AI that advises a human and AI that touches something that moves, and this lesson is about keeping AI firmly on the advisory side of that line unless the rare exception is properly governed.

The OT/IT Boundary and Why AI Lands on the Wrong Side of It

To keep AI advisory, you first have to be fluent in the boundary it keeps crossing. OT (Operational Technology, the systems that directly monitor and control physical equipment: the PLCs, the SCADA, the drives, the safety interlocks) is a fundamentally different world from IT (Information Technology, the business systems: email, the ERP, the file servers, the AI tools running in the cloud). The two worlds have opposite priorities, and AI was born entirely on the IT side, which is why it arrives on the floor with the wrong instincts.

IT optimizes for confidentiality and flexibility. You patch constantly, you update software weekly, an outage is annoying but recoverable, and the worst case is usually data loss. OT optimizes for availability and safety. The PLC (Programmable Logic Controller, the ruggedized industrial computer that actually runs the machine logic) may not have been rebooted in three years on purpose, you patch it during a planned outage if at all, and the worst case is not data loss. The worst case is a press cycling on a hand, a vessel over-pressurizing, or a line of molten material going somewhere it should not. In OT, an unexpected change is not an inconvenience. It is a hazard.

AI tools are IT-native. They live in the cloud or on a server, they update themselves, they are probabilistic by design, and they are comfortable being wrong some percentage of the time because in their native habitat being wrong means a worse recommendation, not a worse physical outcome. The instant you let one of those tools write a value into the OT world, into a setpoint, a PLC register, a drive command, you have taken something built to be occasionally and recoverably wrong and given it the ability to be occasionally and physically wrong, on equipment that moves, in a plant where 78% of OT networks lack centralized monitoring (the Dragos figure that defines the brownfield reality). You have connected a probabilistic system to a deterministic world without even being able to see most of what is happening on that network.

AI was built to be recoverably wrong in a world of data. The OT network is a world of motion and heat where wrong is not recoverable. Keep the boundary between them, and keep AI on the advisory side.

This is why the boundary is not a preference or a maturity stage you graduate out of. It is a structural fact about what these two kinds of systems are for. The advisory rule is the practical expression of that fact: AI on the floor analyzes, predicts, drafts, and recommends, and a human or a properly governed deterministic control system decides and acts. The AI gets to say "the pump is heading toward cavitation, recommend reducing speed." It does not get to reduce the speed.

What Advisory Actually Means in Practice

Advisory is easy to say and easy to violate without noticing, because the violation often does not look like handing over the controls. It looks like a convenience that quietly removes the human from the loop. So it is worth being precise about what the line actually is.

Advisory means the AI output terminates in a human decision or a deterministic, validated control system, never directly in physical action. The predictive-maintenance model that writes a prioritized work order into the CMMS (Computerized Maintenance Management System, the software holding work orders and asset history) is advisory: a planner reads the work order, a tech schedules it, a human acts. The vision system that flags a suspected defect and lights a screen for the operator to confirm is advisory: the operator makes the disposition. The same vision system wired to a reject-arm that kicks parts off the line with no human in the loop has crossed into control, and now its false-reject rate is not a number on a report, it is parts physically discarded on the model's say-so.

The subtle cases are where good engineers go wrong. An AI that "automatically adjusts" a process parameter to optimize yield is in control of that parameter even if a human set the optimization goal. An AI that "automatically acknowledges and clears" certain alarms is acting on the OT environment. An AI that "automatically opens a work order and dispatches a robot" to perform a task has reached past advice into action. The test is simple and unforgiving: between the AI's output and any physical change, is there either a human who can say no or a deterministic interlock that does not depend on the AI's judgment? If the answer is no, the AI is in control, whatever the vendor's slide deck calls it.

Why insist on this so hard? Because of three properties AI has that deterministic control systems do not. First, AI is probabilistic: it produces a most-likely answer, not a guaranteed-correct one, and on the rare bad input it will produce a confident wrong action. Second, AI is opaque: when it acts wrongly, you often cannot quickly see why, which means you cannot quickly trust it again or rule out the next bad action. Third, AI drifts: the camera angle shifts, the lighting changes between shifts, the sensor fouls, the process moves, and a model that was right in validation degrades silently in production. A traditional PLC interlock does exactly the same thing every time forever, which is precisely what you want guarding something that can hurt a person. Hand the action to the AI and you have replaced a deterministic guardian with a probabilistic, opaque, drifting one, on the equipment where determinism matters most.

The Real Cost of Letting AI Cross the Line

The advisory rule can feel overly cautious until you put the dollars and the hazards next to it, so let us walk the cost both ways: the cost of crossing the line and the smaller, manageable cost of staying behind it.

The opening story is the cheap version of crossing: $11,000 and a four-hour outage because a model with control authority acted on a single bad sensor reading. No one was hurt. Now consider the same pattern on equipment with a safety dimension. A model controlling a robotic cell's speed based on a vision estimate of where a worker is standing; a model adjusting the clamp pressure on a press; a model managing the temperature of an exothermic reaction. In each, a confident wrong action is not an $11,000 outage. It is an EHS (Environment, Health, and Safety) incident, a recordable injury, an OSHA visit, and a plant whose safety culture just learned that the AI everyone was excited about put a person at risk. There is no yield improvement that pays for that.

There is also the audit cost, which lands even when nothing breaks. Your customer audits the plant, not the AI vendor. When an auditor for your IATF 16949 (the automotive quality management standard) or AS9100 (the aerospace equivalent) system finds that an AI model has unsupervised authority to change a process parameter that affects product characteristics, that is a finding, because you cannot demonstrate the deterministic control of a special characteristic that the standard requires. "The AI manages it and it usually gets it right" is the opposite of what a process-control audit wants to hear. Keeping AI advisory, with a human or a validated control plan owning every action, is what keeps the audit clean.

Now the cost of staying behind the line, which is the part that surprises people: it is small, and it barely touches the value. Go back to the coolant pump. The advisory version of that system does almost everything the control version did. It watches the historian, it detects the cavitation signature hours early, and it alerts the operator with a specific, prioritized recommendation: "Pump P-104 trending toward cavitation, confidence high, recommend reducing speed to 70 percent and inspecting the suction strainer this shift." The operator, who can glance at the suction pressure and confirm the transmitter is not fouled, makes the call. The plant still avoids the trip. It still logs the save. It still gets the predictive value. What it does not get is the failure mode where a sensor glitch cuts the pump automatically, because a human stood between the model and the drive and that human caught the glitch the model could not. The advisory design captured the upside and left the catastrophic downside on the table. That is the trade, and it is not close.

The Narrow Exception: When Governed Control Is Justified

Honesty requires acknowledging that "AI never touches control, ever" is too absolute to survive contact with reality, and the rule itself says "unless properly governed." There are narrow, mature cases where closed-loop AI control is justified, and naming the conditions is more useful than pretending they never exist. The point is that those conditions are demanding, and almost nothing on a brownfield floor meets all of them yet.

Governed control becomes defensible only when all of the following hold together, not just some of them.

The process is non-safety-critical. Nothing the AI can do should be able to injure a person or cause a major release, even on its worst possible misfire. Safety functions stay with hardwired, deterministic safety systems, certified and independent of the AI. This is non-negotiable: AI does not go into a safety-instrumented function, period.

A deterministic envelope bounds the AI. The AI may adjust a parameter only within hard limits enforced by something that is not the AI: a PLC clamp, a mechanical stop, a rate limiter that physically cannot let the AI move the parameter fast or far enough to cause harm. The AI optimizes inside a cage the AI cannot open. The coolant model, governed properly, could only nudge the pump within a band the drive enforces independently, and could never cut it to forty percent on one bad reading.

The action is reversible and observed. A wrong action must be promptly detectable and promptly undoable, with monitoring good enough to catch the misfire fast. On a network where 78% of plants cannot centrally see their OT, this condition alone disqualifies most environments, because you cannot govern what you cannot observe.

There is a tested fallback and a logged trail. A validated manual or deterministic fallback takes over instantly if the AI is disabled, every AI action is logged for the audit, and the whole arrangement has a documented risk assessment and human ownership. The control plan, the validation, and the accountability are written down before the AI ever closes the loop, not after the incident.

The honest read for a 2026 brownfield plant is that this bar is high on purpose, and the right default is to assume you are not there yet. Closed-loop AI control is a destination you may reach on a specific, low-risk, well-instrumented process after you have done the governance work, not a feature you switch on because the predictive model looked impressive for three weeks. Until every one of those conditions is genuinely met and documented, the answer is advisory, and the engineer who insists on that is not being timid. They are being the adult in the room.

Designing Workflows That Stay Advisory by Construction

The strongest way to keep AI advisory is not a policy that people remember to follow under pressure. It is an architecture where crossing the line is not even wired up. You make advisory the path of least resistance by building it into the data flow.

Put a data diode, or at least a one-way street, at the boundary

The cleanest pattern is to let AI read from the OT environment but architecturally prevent it from writing back. The historian, the SCADA, and the sensors feed data outward to the AI, which lives on the IT side, and there is no return path that lets the model push a value into the control network. A data diode (a hardware device that physically permits data to flow in only one direction) is the strongest form of this, common in higher-security OT environments. Even a well-configured firewall rule that forbids inbound writes from the AI zone accomplishes the core goal: the model can see everything and command nothing. When the write path does not exist, no amount of model overconfidence or sensor glitch can become a physical action, because there is nowhere for the action to go.

Terminate every AI output in a human-readable recommendation

Design the output as advice aimed at a person: a prioritized alert, a draft work order, a flagged screen, a ranked list of candidate causes. The deliverable is information a human acts on, not a command a machine executes. The predictive model produces a work order; the planner schedules it. The vision model produces a flag; the operator dispositions it. This is the same advisory pattern across quality, maintenance, and process, and it is what keeps the human accountable for the action, which is what the customer audit and the safety system both require.

Log the advice and the human decision separately

For the audit trail and for trust, record two things distinctly: what the AI recommended, and what the human decided. When they agree, you have a clean record. When the human overrides the AI, you have captured exactly the judgment that justifies keeping the human in the loop, and over time those overrides become training data about where the model is weak. This is also how you earn operator trust: a crew that has seen the system respect their authority to say no will actually use the green light, where a crew that has been overruled by an automated action will disable it the first chance they get.

Build it this way and the advisory rule stops depending on discipline under pressure. The architecture enforces it. The night-shift engineer at 2:40 on a Tuesday cannot accidentally hand the pump to the model, because the write path was never built, the output was always a recommendation, and the only way for anything to move is for a human to decide it should. That is what it means to keep AI advisory in the OT environment by construction rather than by good intentions, and on a floor where you cannot even see most of your OT network, construction is the only kind of governance you can actually trust.

Key Takeaways

• The most important boundary in plant AI is not accuracy; it is the line between AI that advises a human and AI that directly touches something that moves. Keep AI on the advisory side unless a narrow, fully governed exception is met, because a probabilistic, opaque, drifting system has no business holding the controls of a deterministic, physical, sometimes hazardous process.
• OT (PLCs, SCADA, drives, interlocks) optimizes for availability and safety where a wrong change is a hazard; IT (where AI was born) optimizes for flexibility and treats being wrong as recoverable. Letting an IT-native AI write into the OT world imports the wrong instincts onto equipment where 78% of plants cannot even centrally monitor the network.
• Advisory means every AI output terminates in a human decision or a validated deterministic control system, never directly in physical action. The unforgiving test: between the AI's output and any physical change, is there a human who can say no or an interlock independent of the AI's judgment? If not, the AI is in control whatever the vendor calls it.
• Crossing the line is expensive: the coolant-pump case cost $11,000 and a four-hour outage when a model acted on one bad sensor reading, and on safety-relevant equipment the cost becomes an EHS incident, not an outage. It also creates audit findings, because IATF 16949 and AS9100 require demonstrable deterministic control of product-affecting parameters.
• Staying advisory barely costs any value: the advisory coolant model still detects cavitation hours early, still alerts with a specific recommendation, still avoids the trip and logs the save, while leaving the catastrophic single-bad-reading failure mode off the table because a human stood between the model and the drive.
• Governed closed-loop control is defensible only when all conditions hold together: non-safety-critical process, a deterministic envelope the AI cannot exceed, reversible and observable actions, a tested fallback, full logging, a documented risk assessment, and human ownership. On a 2026 brownfield floor the right default is to assume you have not met that bar yet.
• Make advisory the architecture, not just the policy: use a data diode or one-way boundary so AI can read OT but cannot write to it, terminate every output in a human-readable recommendation (work order, flag, ranked causes), and log the AI recommendation and the human decision separately for the audit trail and for operator trust.
• An architecture where the write path does not exist enforces the boundary under pressure better than any procedure, because no model overconfidence or sensor glitch can become physical action when there is nowhere for the action to go. On a floor you cannot fully see, construction is the only governance you can truly trust.