Artificial Intelligence in the OT

Artificial intelligence in production can run in two places: centrally in the cloud, or locally at the plant, at the so-called edge. The choice is not a matter of taste; it follows from three requirements that weigh differently in the OT than in the office.

First, latency. Even under good conditions, a cloud request needs anywhere from a few tens to a few hundred milliseconds for the round trip. For a visual inspection that is meant to stop the line before the next cycle, or a control loop adjusting a speed in real time, that is often too slow. A local decision right on the device, by contrast, costs only the time of the computation itself.

Second, data sovereignty. Process data from production is among a company’s most sensitive data — it reveals recipes, cycle times, and utilization. Whoever processes it locally does not have to send it to someone else’s data center to benefit from it. That matters especially where contractual requirements from customers, certifications, or status as an operator of critical infrastructure dictate where data may reside.

Third, availability. An edge application keeps running when the internet connection fails — a cloud application does not. In a production line that runs around the clock, that is not an edge case; it is an operating state that eventually occurs.

None of this means cloud AI has no place in the OT. It means the question has to be answered before the project, not after it.

In practice, the answer is usually both, just at different points in time. Training a model — learning from large volumes of historical data — needs compute that is easier to provide centrally: many examples, plenty of storage, often specialized hardware that barely pays off for a single site. Operating the finished, trained model — so-called inference, meaning its application to new, continuously arriving values — needs little compute but does need continuity and low latency. That is usually better solved locally, on compact hardware right next to the plant, than over a permanent cloud connection.

This split is not the exception; it is the rule:

The third row is the one most often overlooked. A model nobody watches loses accuracy without anyone noticing — an effect known as drift and covered in detail in our article on Industrial AI and machine learning. For the OT, an additional question comes up: who makes sure a trained model actually reaches the edge devices reliably — all of them, not just the first one?

Analytics in production typically moves through four maturity levels that build on one another. Each stage answers a different question, and each depends on the one before it.

Descriptive answers what happened: a dashboard shows temperature curves, unit counts, downtime. Diagnostic answers why it happened: a correlation between a sensor value and a rise in scrap. Predictive answers what will happen: the classic predictive-maintenance case that flags a bearing failure two weeks out. Prescriptive answers what to do: not just the warning, but the suggestion to lower the speed by five percent to avoid overheating.

Most OT projects stop at the first two stages — dashboards and reports are visible and easy to justify. But the economic leap sits between stage three and four: a prediction alone does not change a process yet. Only a recommended action concrete enough to be followed affects scrap rate, downtime, or energy use.

Each stage depends on the one before it — jumping straight to a recommended action usually skips the foundation it would need to stand on.

A model that works on one machine is not yet a solution — it is proof that it can work at all. The step toward real impact is the second one: bringing the same intelligence to hundreds of identical machines, several lines, or several sites, without starting a separate project for each one.

Two building blocks make that possible. The first is technical: when a model is packaged like a containerized application, it can be rolled out unchanged across different edge devices, managed centrally, and swapped out via update when needed — much like an app on a phone, just without an app store and without user interaction. The second building block is structural, and it is easy to overlook: a model only transfers from machine one to machine two if both machines name their values the same way. If a value on one line is called sps-3-db12-dw4 and something else on the identical neighboring line, the model has to be rebuilt for every plant instead of simply copied.

Whoever solves both — uniform naming and containerized distribution — turns a single pilot project into a platform. Whoever solves only one of the two ends up with either many one-off solutions, or distribution without a shared language.

The closer an AI gets to taking action, the more trust it needs — and trust rarely appears all at once. In practice, a graduated approach has become the norm.

With human-in-the-loop, the model proposes an action and a person confirms it before it is carried out — for example, a maintenance suggestion that only becomes a work order after approval. With human-on-the-loop, the system acts on its own within defined limits, while a person monitors continuously and can step in at any time — for example, an automatic parameter adjustment that moves within a defined corridor and flags an overshoot instead of acting on it.

Moving from the first stage to the second is not a technical upgrade; it is an organizational decision based on demonstrated reliability — not accuracy in a test run, but experience from live operation over time.

One boundary stays untouched by any of this: functional safety is not learned. A model may observe, warn, and suggest; shutting down, when in doubt, remains the job of certified safety technology, not the model. How the European AI Act classifies AI systems in manufacturing is covered in detail in our article on Industrial AI and machine learning.

pronubes does not supply an AI model. The platform supplies the infrastructure without which a model in the OT can neither be reliably fed with data nor brought to effect in a controlled way.

pronubes Edge connects machines, sensors, and systems through standard connectors — OPC UA, MQTT, REST, SQL, file formats — and is a natural place to run a trained model close to the plant instead of sending every request beyond the factory network.

pronubes Zones holds the uniform naming that carries a model from the first plant to the second — the prerequisite for the scaling described in the previous section.

pronubes Insights shows which source is delivering, which has gone quiet, and how current a value is — the monitoring of input data without which neither drift nor a silent outage gets noticed.

For connecting to AI and analytics platforms such as Snowflake, production data can be handed over in a structured form, near real time. Through an MCP server, relevant production data, context information, and functions can additionally be made available in a standardized way for AI applications and agents — so a model gets not just numbers, but the context from real production that actually makes them meaningful.

The payoff of AI in the OT does not show up in the first model on the first machine, but in how quickly the second one follows.

More about the platform