AI in manufacturing: the plant floor is walled off by design
Manufacturing has a constraint that reads as an obstacle and is in fact a safety decision. Operational technology, meaning the systems that run the production line, is deliberately separated from the corporate information network, and in several environments that isolation is a regulatory requirement rather than a preference. So getting plant data into a system that can reason about it is an architecture project with safety implications, not an access request that somebody can approve. Teams arriving from other sectors treat this as a permission problem and spend a quarter finding out that it is not one. The second constraint is quieter: predictive maintenance, which is the use case everyone raises, needs failure data, and a well-maintained plant does not produce much. The project that lands first here touches neither of those, and it is sitting in a filing system.
Manufacturing, in short
| The constraint | Operational technology is separated from information technology by design and often by regulation, so getting data out is an architectural question rather than a permission one. |
|---|---|
| The distraction | Predictive maintenance, which requires failure data most plants have too little of to train on. |
| A first project that works | Technical documentation retrieval for maintenance and quality teams, which needs no plant-floor integration at all. |
| Where ground truth lives | Maintenance logs and quality incident reports, which are usually written in a shorthand only the team understands. |
What shows up most often, not a description of any particular organisation. No named clients and no case studies: see editorial policy.
Why the separation is not negotiable
The isolation between operational and information technology exists because a production line must keep running and must fail safely. A network path that lets data out is also a path that could let something in, and the consequence is not a data breach but a stopped line or a safety incident.
The people guarding that boundary are usually right, and the productive posture is to treat them as engineers with a legitimate constraint rather than as an obstacle. The conversation that works starts by asking what would have to be true for a one-way data path to be acceptable, rather than by asking for access.
There are established patterns, including one-way gateways and historian databases that already sit on the corporate side. Frequently the data needed is already out, in a historian nobody thought to mention, and an hour spent asking what already crosses the boundary saves a quarter of architecture work.
Predictive maintenance needs failures you may not have
The logic is appealing: sensors produce continuous data, models find patterns, failures are anticipated. The difficulty is arithmetic. Learning to predict a failure mode requires examples of it, and a plant that maintains its equipment properly produces few.
Worse, the examples that exist are usually spread across dissimilar machines, in different conditions, over years during which the equipment was modified. A model trained on that will not generalise, and the evaluation set to prove it either way does not exist.
This does not mean the use case is invalid. It means the honest first step is often a data collection programme rather than a model, with a realistic statement of how long it will take before anything can be learned. Saying that clearly is unpopular and is considerably cheaper than a year spent training on noise.
The documentation project, which can start on Monday
Manuals, standard operating procedures, engineering change notes, past incident reports, supplier specifications. Maintenance and quality teams hunt through these constantly, and the hunt is slow because the material is scattered across systems and formats.
Making it searchable requires no plant-floor integration whatsoever, which means it can begin while the operational technology conversation continues in parallel. It produces a visible result for the people who most need one, and it builds the credibility that makes the harder project authorisable later.
It also has the usual advantages of a good first project: high volume, checkable output, and a human reading the result anyway. A technician who gets the right procedure in thirty seconds rather than twenty minutes will tell their colleagues, which is a better rollout mechanism than any training plan.
The shorthand in the incident reports
Maintenance logs and quality reports are written by the people who will read them, in a compressed vocabulary that is precise inside the team and opaque outside it. Machine nicknames, abbreviated fault codes, references to a modification made in 2017 that everyone remembers and nobody wrote down.
A system that normalises this away discards the information. What works is building the glossary explicitly with the team during stage one, as a deliverable in its own right. It takes a few sessions, it is the only way retrieval will work on the real corpus, and the glossary tends to outlive the project because nobody had ever written it down.
Shift patterns change what a rollout looks like
A plant running three shifts has three separate populations of users who do not overlap and who will not attend the same session. A rollout designed for an office, with a launch meeting and a training slot, reaches one of them.
What works is embedding the introduction into the shift handover, which already exists and which everybody attends, and accepting that adoption will progress at different speeds across shifts. The night shift is frequently the most receptive, because there is less support available and the system fills a real gap.
The five stages hold, with stage two dominated by the operational technology boundary and stage four shaped by a rota rather than by a calendar.
