Industrial AI and machine learning in production

Industrial AI refers to machine learning applied to data from production and plant operations: measurements from controls and sensors, order and material data, maintenance history. The methods are the same as elsewhere — regression, classification, anomaly detection, and increasingly language models for documentation and operation. What differs is the data.

Three properties make the difference. Production data is time-bound: a value without a reliable timestamp cannot be related to any other.
It is incompletely labeled: there are millions of data points, but rarely a record of when something went wrong and why. And it is context-dependent: the same numeric value means something different depending on the order, material, and operating mode.

This is not a nuance. It shifts a project’s effort from modeling into the data work that precedes it — and explains why a method that convinces in the notebook fails on the shop floor.

A temperature reading of 78 °C at sensor 4711 is nothing on its own. It becomes usable once it is clear which unit supplied it, which order was running, which material was being processed, and what setpoint was intended. This assignment is called context, and it is the difference between an alarm and a statement.

Without it, a model reliably produces false alarms — it reports the recipe change as a fault, because the recipe change does not exist for the model. The cost of that is not the false alert itself, but what it triggers: after the third unfounded alarm, the shift stops paying attention, and the model is effectively switched off without anyone having switched it off.

Context does not arise in the plant. It arises in a structure that brings together values from operational technology with master data from information technology and names both consistently. A Unified Namespace is exactly the ordering principle for this: it gives every value a place that reads the same across all systems — and therefore also for every model later trained on it.

Four stages before a model is any good — and the return path nobody plans for.

Use cases differ less in method than in what they require in terms of data. This table is therefore more useful than a list of algorithms: it answers the question of whether a case is even within reach for you.

The simplest entry point is almost always anomaly detection, because it works without labeled faults: it learns the normal case and flags what doesn’t fit. The hardest is predicting remaining service life, because that requires failures — recorded ones. In most plants, failures are documented in maintenance staff’s heads and in the ticket system as “plant is down.”

The four stages in the diagram above build on each other. None can be skipped, and each costs work that falls due before the first model.

• Captured

  The value is available at all, at a known frequency, and it is noticeable when it stops arriving. Otherwise a gap nobody notices gets learned as a measurement.

• Named

  Every value belongs to exactly one object in a structure that reads the same across plants and sites. Without that, no comparison is possible — and without comparison, no model that works on a second machine.

• Time-ordered

  Timestamps come from a shared source, and the cadence is known. Two systems with a five-minute clock offset create relationships that don’t exist.

• Labeled

  It is recorded what went well and what didn’t — with a timestamp. This stage is the least popular and the decisive one: without labels, a model only learns what operation looks like, not when it goes off the rails.

The typical course is not failure, but getting stuck: a pilot works on one machine and does not transfer to the second. The causes are usually the same three.

• The naming is machine-specific. The model learned on sps-3-db12-dw4. On the neighboring line, the same value has a different name, and the model has to be rebuilt instead of copied.
• The data path was a special route. A direct connection was laid for the pilot that nobody operates. It holds until the controller is replaced.
• Nobody owns the result. There is no team that decides what happens when an alert fires. A model without an owner delivers reports, not actions.

None of these three are AI problems. They are architecture problems that surface underneath the AI project — and they occur just the same when a dashboard is built instead of a model. Anyone who solves them before the first model gets both.

A trained model is not a finished result, but a component in operation. It loses accuracy as soon as something changes beneath it: a new material, a replaced sensor, a different batch, a reworked process step. This effect is called drift and is the normal case, not the exception.

Three things therefore belong in place from the start. First, monitoring of the input data: if a source goes silent or its distribution shifts, that must be noticed before the predictions quietly get worse. Second, a comparison with reality — what the model predicted versus what actually happened, tracked over time. Third, a path back into training that does not require a new project.

This is the unspectacular part, and it decides whether the pilot becomes operations. A model nobody watches is more dangerous than none at all: it keeps delivering numbers, and nobody notices they are no longer correct.

Not every question in production needs a model, and some cannot tolerate one.

• Where a rule is enough. Limit monitoring is traceable, auditable, and needs no training data. A model in its place is more expensive and harder to explain.
• Where explanation is part of the requirement. In quality assurance, a decision must be justifiable. Methods whose justification consists only of weights are hard to defend there.
• Where safety is at stake. Functional safety is not learned. A model may observe and report; only safety technology may shut down.
• Where the data basis is too thin. Two documented failures do not produce a prediction, just a number with decimal places.

For classification as high-risk AI, the European AI Act recognizes two routes. One runs via Annex III: it lists application areas — biometrics, critical infrastructure, employment, and others. The other runs
via Annex I: an AI system counts as high-risk if it is a safety component of a product covered there and that product is subject to third-party conformity assessment.

For general manufacturing, this usually means: a model that plans maintenance or predicts quality does not appear in Annex III. It becomes serious where the model intervenes in a machine’s safety function, or where the operation itself counts as critical infrastructure — for example in energy or water supply.

The classification depends on the intended purpose and belongs in legal review, not in a trade article. What can be prepared technically, independent of that, is the same thing a model needs anyway: traceable data provenance, documented structure, and recorded results.

pronubes does not deliver a model. The platform delivers the data situation without which a model never gets past the pilot — the same foundation that also carries analysis and reporting.

• pronubes Edge connects sources via standard connectors — OPC UA, MQTT, REST, SQL, file formats — and buffers on connection loss so the history gets no unnoticed gaps.
• pronubes Zones holds the naming that carries a model from the first plant to the second. Without it, every model is a one-off.
• pronubes Insights shows which source is delivering, which has gone silent, and how old a value is — the input-data monitoring without which drift stays unnoticed.

The payoff doesn’t show up in the first model, but in the second.
More about the platform