Most industrial AI pilots succeed technically and die commercially. The model hits its accuracy target, the report is written, everyone is pleased, and eighteen months later it is still running on one line. Nobody killed it. It simply never became anything.
The failure is almost never model accuracy. It is one of four things, and all four are decided before a single sensor is fitted.
1. The alerts belong to nobody
A pilot that surfaces predictions on a dashboard has not changed anything. Somebody must open that dashboard, believe it, and act.
In practice, the maintenance planner already has a system that tells them what to do: the CMMS. It generates work orders, it assigns technicians, it tracks completion, and it is what they are measured against. An alert that lives outside that system is an interruption competing with their actual job.
The fix is unglamorous. The model must write a work order into the CMMS, with the asset, the predicted fault mode, the confidence, and the recommended action. Then the alert has an owner, a due date, and an audit trail. Then, and only then, does someone notice when it is ignored.
If your pilot's integration scope stops at "expose an API," you have built a science project.
2. The model was trained on one sensor placement
A vibration model is not a model of a pump. It is a model of that accelerometer, mounted at that orientation, at that distance from the bearing housing, on that foundation.
Move to the identical pump on the next line, where the sensor sits 15cm further along and the baseplate is stiffer, and the frequency signature shifts. The model's learned thresholds no longer mean what they meant. Accuracy quietly falls, the maintenance team stops trusting the alerts, and the rollout stalls without anyone filing a defect.
This is survivable, but only if you plan for it:
- Standardise mounting, orientation, and sampling rate across assets before the pilot, not after
- Budget for per-asset recalibration in the rollout, rather than assuming zero-cost replication
- Track drift per site, and treat a drop in precision as an operational incident, not a research problem
The generalisation you get for free is the architecture. The calibration is always paid for.
3. Inference depends on a link that drops
Sending raw sensor data to a cloud region for inference makes a production-line decision dependent on a WAN connection, an availability zone, and someone else's maintenance window.
Plants lose connectivity. It happens during shifts, and it happens most often when something else has already gone wrong. A predictive maintenance system that goes blind exactly when the plant is having a bad day is worse than no system, because operators learned to rely on it.
Run inference at the edge, on-premise, next to the PLC. Ship model updates out; ship aggregates and predictions back. The link becomes a convenience rather than a dependency. In regulated or defence environments, this stops being an availability argument and becomes a hard requirement: operational technology data cannot leave the facility at all.
There is a second reason, which is latency. Vision-based inspection at line rate has a budget measured in tens of milliseconds. A round-trip to a cloud region does not fit inside it. You will end up at the edge regardless; better to design for it than to discover it during commissioning.
4. The pilot proved accuracy instead of proving a workflow
This is the one that actually kills rollouts.
A pilot scoped as "demonstrate ≥90% detection on bearing faults" will report ≥90% detection on bearing faults. It will not tell you whether a planner acted on the alerts, whether the parts were in stock when they were needed, whether the intervention was scheduled into a planned window, or whether the failure was actually prevented.
None of the questions a CFO will ask have been answered. So the pilot is judged a technical success and a commercial unknown, and unknowns do not get capital.
Scope the pilot as a workflow, end to end:
- The model detects degradation on a named asset
- It writes a work order into the CMMS with a lead time long enough to act on
- The planner schedules the intervention into a planned window
- The part is available because the lead time allowed procurement to react
- The intervention happens; the fault is confirmed on teardown
- Finance records the avoided unplanned stop at contribution margin
Run that loop even five times and you no longer have a model. You have a documented, costed, repeatable business process with a machine learning component in it. That is a thing that gets a rollout budget.
The uncomfortable summary
The hard parts of industrial AI are, in order: getting labelled failure data, integrating with systems built in 2004, and persuading a maintenance planner to trust an alert. Model selection is somewhere far below those, and it is the only one most pilots optimise.
We scope pilots as workflows, deploy at the edge, and write into the CMMS you already run — because we have watched the alternative not work. If you want to talk about a specific line, get in touch.