There is a moment in almost every industrial AI project that decides its fate, and it does not happen in a data-science notebook. It happens at the control room door — the first time an operator, three hours into a night shift, looks at an alert from the new system and decides whether to act on it or ignore it. Everything the project becomes flows from that decision. Most pilots never survive it.
The uncomfortable part is that the pilots that die are usually technically successful. The model detected the seeded fault. The accuracy numbers cleared the acceptance criteria. The vendor's case study got written. And then, over six quiet months, the plant stopped looking — because the pilot was designed to prove a model, not to survive contact with an operating plant. Having spent years on both sides of this — building the models and sitting with the operations teams who receive them — we see the same five failure modes again and again.
1. Alerts without physics don't earn trust
A pure data-driven model finds statistical anomalies. An operator needs to know what is physically happening — is the exchanger fouling, is the bearing degrading, is the instrument drifting? When an alert arrives as "asset health score dropped to 62" with no engineering explanation, the operator does the only reasonable thing: cross-checks it against their own experience, finds it either obvious or inexplicable, and mentally downgrades the system. Two or three false alarms later — and every statistical model produces them — the system is background noise. The fix is not a better algorithm; it is coupling the analytics to process models and failure modes, so every alert arrives with a physical story and a recommended action an engineer can defend.
2. The alert economics are wrong
Data-science teams optimize detection accuracy. Control rooms run on attention, which is scarce and expensive at 3 a.m. A system that produces forty alerts a week — even if thirty are technically correct — costs more attention than it returns and will be muted within a quarter. The systems that survive are ruthlessly conservative: a handful of alerts a month, each one high-confidence, explained, and actionable. In our experience the right question at design time is not "what can we detect?" but "what deserves to interrupt a shift supervisor?" — and the honest answer cuts the alert volume by an order of magnitude.
3. The data plumbing was assumed, not engineered
Every pilot plan allocates two weeks for "data integration." Every real plant then reveals what twenty years of historian growth actually looks like: tags renamed across DCS migrations, compression settings that flattened the very transients the model needed, instruments that have been frozen for months without anyone noticing, and criticality lists that live in a spreadsheet last updated two reorganizations ago. Pilots that treat data readiness as a preliminary step fail on it; programs that treat it as engineering work — screened, reconciled, documented, with instrument fixes fed back to maintenance — build the foundation everything else stands on.
4. The plant never owned it
If the model lives in a vendor's cloud, is retuned by a data scientist in another city, and its logic is a trade secret, then from the plant's perspective it is a black box owned by someone else — and plants do not build their routines around things they do not own. The deployments that stick transfer ownership deliberately: reliability engineers are trained to read, retune and retire models; documentation explains every threshold; and the site can answer "why did it alarm?" without a support ticket. Knowledge transfer is not an afterthought of deployment. It is the deployment.
5. It never entered the workflow
An insight that lives in a separate dashboard is homeless. Plants run on shift handovers, morning meetings, work orders and permits — and an AI system either joins those rituals or watches them from outside. Joining them is unglamorous integration work: alerts that create draft work orders in the CMMS, health summaries that land in the morning meeting pack, thresholds wired to the same escalation paths operators already trust. None of it demos well. All of it is the difference between a pilot and a practice.
What the survivors have in common
Reading the list backwards gives the recipe. Start from criticality, not from available data — ten assets that matter beat a hundred that were convenient. Engineer the data before modeling it. Design alert economics for a night shift, not a demo. Anchor every model in physics and failure modes so alerts carry explanations. Integrate into the CMMS and the morning meeting, not alongside them. And plan the ownership handover from day one, so the system still has a champion when the deployment team leaves.
None of this is a criticism of the AI platforms — the good ones are genuinely good, and getting better. It is an argument about what surrounds them. Industrial AI succeeds when it is deployed as an engineering discipline: validated against physics, sized to human attention, wired into existing workflows, and owned by the plant. That layer — the one between a capable platform and an operating plant — is where pilots either die or become practice.