Search for AI for industrial process control and you get product pages. Each one promises throughput, yield or energy. None of them tells you the one thing that decides the risk you are buying: how much authority the model has over the plant. A model that predicts a quality variable and a model that moves a valve are both sold as "AI process control". The evidence you should demand from each is completely different.
This article separates them, states what has to be true before each level is allowed near a live process, and turns that into questions to put to any vendor or research partner. It ends with the figures we measured on our own control stack, because a method is only as credible as the numbers it was held to.
AI for industrial process control is four products, not one
Every credible deployment keeps the same foundation: field instruments, a safety instrumented system and regulatory PID loops underneath. The learned component sits somewhere above that foundation, and where it sits is its authority level:
- It predicts. The model estimates a variable nobody can measure in real time. A human or an existing controller decides what to do with it.
- It advises. The model proposes a move. An operator accepts or rejects it.
- It writes a setpoint. The model changes the target of an existing loop in closed loop, and PID still moves the actuator.
- It moves the actuator. The model is the controller.
The consequence of a wrong output rises at each step, and so should the bar. We walked through the published literature at each of these layers in our piece on AI in chemical plants, sorted by where in the control hierarchy the model sits. Here the question is commercial: what are you buying, and what must it prove?
Level 1: the model predicts
This is where most of the value, and most of the headline numbers, actually live. In a deployment with Aramco, hybrid models combining first-principles simulation with AI reached up to 98.5% yield and quality prediction accuracy in continuous catalyst regeneration and platformer units. That result sits in refinery planning. It is a strong prediction result, and it says nothing about closed-loop control performance.
The bar: accuracy on operating data the model never saw, across the feeds and seasons the plant actually runs. A model validated only on the regime it was trained in has not been validated.
Level 2: the model advises
Advisory mode puts a recommendation in front of an operator. The clearest description on the current results page comes from UptimeAI, whose optimisation agent presents the proposed move, the active constraint, expected benefit, confidence and supporting evidence for operator review. The same page is candid that not every plant should begin in closed loop, and that APC and an optimisation layer are not mutually exclusive.
The bar: historized data for manipulated variables, controlled variables, targets and constraints, plus lab or quality data wherever yield or quality is part of the objective. Without that record the recommendation cannot explain itself, and an operator has no reason to follow it.
Level 3: the model writes a setpoint
This is the level most "closed-loop AI" products actually operate at. A widely cited boiler control guide describes reinforcement learning that does not replace PLC safety logic but adjusts the setpoints of existing PID loops as a supervisory layer, trained on a digital twin and deployed for inference only.
The incumbents sit here too. AspenTech lists 2 to 5% throughput, 3% yield and 10% energy reduction for its AI-enabled multivariable controller. Read those as vendor-reported ranges: no site, baseline or measurement window is given. In cement, a published kiln expert system used symbolic AI to stabilise calciner temperature and oxygen levels while raising the share of alternative fuels. It is an older form of AI, doing the same supervisory job.
The bar: write-back governance. Someone owns the limits the model may move within, changes pass through Management of Change, and the setpoint range is narrow enough that the regulatory layer can always recover. If you are weighing a learned supervisor against the loops you already have, the trade-offs are specific to the regime; see reinforcement learning versus PID.
Level 4: the model moves the actuator
Documented cases are rare. The best known is Yokogawa and JSR, where a reinforcement learning controller ran a chemical plant distillation column for 35 consecutive days of autonomous control, handling conditions that previously needed manual valve operation. The literature explains why that is still news: a systematic review of reinforcement learning in the process industries found most implementations confined to simulated environments, with digital-twin approaches at 6.4% and no standardised procedure for sim-to-real.
The bar: everything in the next section, demonstrated rather than asserted. We set out the proof obligations for a learned policy in more depth separately.
What has to be true before any of it touches an actuator
Levels 3 and 4 share five conditions. A vendor who cannot show evidence for each is selling Level 2 at a Level 4 price.
The constraint is written in physical units
"Keep the process safe" is not a constraint. A temperature ceiling, a pressure band or a maximum rate of change on a valve is. If the limits live only in an operator's head, the model cannot respect them and nobody can audit whether it did.
The decision fits inside the control period
Latency is a hard requirement, not a performance nicety. On a benchmark chemical process at UCLA, a reinforcement learning controller computed actions in 0.644 ms on average and 67.5 ms in the worst case, against 15.247 ms mean for short-horizon linear MPC, both inside a one second sampling budget. Ask for the worst case, not the mean, and ask where the model runs at the plant, because that decides whether a network round trip sits inside the loop.
The safety layer sits outside the model
A neural network cannot be trusted to police itself. The pattern that holds up is a separate, deterministic layer that checks every action before it reaches the plant, which is what Imubit points at when it describes learning captured in a deterministic controller your engineers can certify. Our preferred form is a safety filter that sits outside the policy, which passes a safe action unchanged and corrects an unsafe one minimally.
The gap between simulation and plant is measured
Every learned controller is trained on a model of the plant before it meets the plant. The question is not whether that model is wrong, it is by how much and in which direction. Ask for the measured error on held-out plant data and how it was used, which is the whole discipline of sim-to-real transfer. If the answer is that they built a digital twin for process control, ask how the twin itself was validated.
There is a fallback when no safe action exists
Sensors fail, feeds drift outside anything seen in training, and a safety layer may find no action that satisfies every constraint. The design must say what happens then: hand back to the existing controller, hold the last safe setpoint, or trip to a defined safe state. "It will not happen" is not a fallback.
Questions to put to any vendor
Turn the conditions above into a short list you can send before a demo:
- Which authority level does the product operate at on a site like ours, and which level did your cited results come from?
- For each benefit figure: which site, which baseline, over what measurement window?
- Where are the constraints defined, in what units, and who can change them?
- What is the worst-case decision time, and where does inference run?
- What checks each action before it reaches the plant, and is that layer independent of the model?
- What was the measured plant-model gap before closed loop, and how often is it rechecked?
- What happens when no safe action exists?
- What documentation do we own at the end, and could our engineers maintain the controller without you?
A good answer to the last question matters most for a contract research engagement, where the deliverable is the controller and its validation record, not a subscription.
What we measured on our own control stack
We hold our own work to the same list. On the control stack we delivered under the OptiVX programme, where our work package was AP1, core AI and ML models, the measured figures were:
- Model: growth-model accuracy with R-squared above 0.95.
- Safety layer: under 2 ms per check, independent of the learned policy.
- Latency: end-to-end edge latency of 285 ms, reduced from 1.2 s, with inference running at the process rather than in the cloud.
- Validation: 400 simulated years certified, then a 500 L pilot basin, with zero safety violations.
The process there is biological rather than thermochemical, which makes the point: the five conditions do not depend on the industry. They depend on the authority you are about to hand a model.
FAQ
Does AI replace PID controllers in industrial plants?
Not in the deployments that are documented. The learned layer sits above PID and adjusts setpoints, and the safety instrumented system stays untouched. Direct control by a learned policy exists but remains rare.
Is AI process control the same as advanced process control (APC)?
No. APC coordinates multiple loops to hold a process near its targets. An AI optimisation layer can decide whether those targets still make economic sense as feed and equipment conditions change. A plant can run both.
What data does a plant need before starting?
Historized records of the manipulated variables, controlled variables, targets and constraints, plus lab data when quality or yield is an objective. Closed loop additionally needs reliable write-back connectivity to the control system and a change-management process around it.
Is a learned controller fast enough for real-time control?
Often faster than the alternative. A trained policy is a single forward pass, while MPC solves an optimisation problem at every step. What matters is the worst case against your sampling period, measured on the hardware that will actually run it.