AI in the Factory Needs More Factories

There is a question I have started asking early in any conversation about AI in manufacturing, and it usually reorganises the discussion.

How many times has this actually happened?

Not how accurate is the model, or which framework, or whether it runs at the edge. How many real examples exist of the thing you want to predict.

The answer is almost always the constraint, and it is almost never what people came to talk about.

The arithmetic

Take predictive maintenance on a specific class of equipment — a particular pump, spindle or compressor configuration.

To build something a maintenance manager will act on, you need failures. Real ones, with the preceding telemetry attached, not simulations.

A single plant might see three or four of those per year for a given asset class. Some years none. Train on that and you get a model that is statistically interesting and operationally ignored, because nobody takes a machine out of production on a prediction backed by four examples.

Now pool the same asset class across fourteen plants. Forty to sixty events a year. Within eighteen months, the model has been right often enough to earn trust, and trust is the only thing that converts a prediction into an action.

That is the whole argument, and it is about evidence rather than technology.

Where the same pattern repeats

Once you notice it, it turns up nearly everywhere in industrial AI.

Scrap and yield prediction depends on the interaction of material lot, machine state, ambient conditions and operator sequence. A single site observes a thin slice of that combinatorial space. Pooled across sites, the space fills in.

Demand-driven scheduling needs years of seasonal history to separate a real pattern from noise, and one site's history is short and confounded by its own local disruptions.

Anomaly detection works far better against a fleet baseline. A machine that has drifted three percent from its cohort is visible immediately. The same machine compared only against its own past looks fine until it crosses an absolute threshold, which is weeks later and occasionally too late.

Even quality investigations change character. Tracing a defect back through material lots is a different exercise when you can see every plant that received the same lot.

What this means architecturally

If event count is the constraint, the architecture question answers itself: the data has to pool somewhere, in a comparable format, with enough surrounding context to be usable.

Across multiple sites, that is a cloud. Which is why cloud manufacturing software matters — not because the algorithms need it, since plenty run better at the edge, but because the training data does.

The split that works in practice:

• Control stays on local controllers. Deterministic, never dependent on an external network.
• Latency-critical inference stays at the edge. Visual inspection cannot wait on a round trip.
• Operator interfaces run at the edge and survive disconnection, buffering locally and reconciling afterwards.
• History, training, optimisation and cross-site analysis live in the cloud.

Nobody credible argues for putting control in the cloud any more, and the industry damaged itself for years by implying otherwise.

The part that is genuinely hard

Pooling only works if the data means the same thing everywhere.

If one plant records downtime with forty reason codes and another with six, the combined dataset is not bigger. It is two incompatible datasets sharing a table, and a model trained on it learns to distinguish plants rather than to understand the process.

This is organisational rather than technical. Somebody has to own the taxonomy and make it stick — to decide that a particular kind of stoppage is recorded identically in two countries, against local preference and years of habit.

Programmes that treat this as a data engineering problem produce immaculate pipelines full of incomparable values. Programmes that treat it as a governance problem with a named owner produce something a model can learn from.

One caution about vendor AI

The AI bundled into manufacturing platforms is improving, and it is tuned for the average customer, which is not you.

The models that produce real margin are the ones encoding how your specific equipment behaves with your specific materials on your specific products. Those are almost always built on top of the platform rather than bought inside it.

So evaluate platforms on two unglamorous criteria: how cheaply and cleanly your data leaves, and whether external services can write decisions back. A recommendation that ends with a planner retyping it into another screen has already lost most of its value. We cover how that layer is usually structured in our piece on enterprise AI development.

Practical summary

Count your events before you choose an algorithm. Pool comparable data across sites, and take the taxonomy work seriously enough to assign it an owner. Keep control local, keep line-rate inference at the edge, and put history where it can be learned from.

Then test it on one line for ninety days, with a baseline measured beforehand and permission to conclude that it did not work.

---

Frequently Asked Questions

What limits AI performance in manufacturing?
Usually the number of real events available to learn from, not the algorithm. Single sites rarely see enough failures or defects to train a trustworthy model.

Does industrial AI have to run in the cloud?
No. Latency-critical inference belongs at the edge. The cloud is where training data pools and where models are trained and governed.

Why do taxonomies matter so much?
Because inconsistent reason codes between plants mean a model learns the difference between sites rather than the behaviour of the process.

Should we use the AI built into our platform?
Where it fits, yes. Expect the models that actually change margins to be built on top of the platform using your own production history.

How do we test an industrial AI use case cheaply?
Ninety days on one line, with a measured baseline, one closed-loop improvement, and permission for the conclusion to be no.

---

Full version: Cloud Manufacturing Software in 2026.