Every AI-in-manufacturing pitch I've sat through front-loads the model and waves a hand at the work that actually decides whether it ships. That's backwards. In an industrial setting the model is almost never the hard part or the expensive part. The hard part is everything around it — the integration, the data, the people whose floor you're about to change.
A rough split of where the effort actually goes on a typical deployment: model development, maybe 20%; data and sensor work, 30%; integration with the existing control systems, 30%; change management with operators, 20%. The headlines cover the first 20%. The other 80% is where projects live or die. Misjudge that split and your pilot dies in pilot.
What's worth doing
Ranked by how cleanly you can attribute the value — because in low-margin manufacturing, an unprovable benefit is no benefit.
- Predictive maintenance. Sensors plus a forecasting model to catch failures before they stop the line. With a Midlands manufacturer this cut unplanned downtime substantially — but the return that mattered to them was the maintenance crew no longer losing weekends to emergency callouts. Attributable, and felt by the people doing the work.
- Quality inspection. Vision systems catching the defect a human misses at the end of a long shift. Designed right, it's a second opinion — the inspector still makes the call. Replace her and you lose the judgment that handles the edge cases the model never saw.
- Demand forecasting. Time-series models with weather, calendar and order history beat the old methods. Modestly — single digits to low double digits, not a revolution. In a low-margin plant, that margin is the year.
- Energy optimisation. Reshuffling when the high-load machines run to hit cheaper or lower-carbon grid hours. Real savings, no capital spend, which makes the business case unusually clean.
- Safety monitoring. Vision flagging a worker in a hazard zone without PPE, or a forklift overspeeding near people. Build it to warn and log without tipping into surveillance the floor resents — because that resentment is a real operational cost, not a soft one.
The 80 percent nobody scopes
This is the part I make every client stare at before they approve a budget.
Integration is the project. Talking to legacy PLCs, the SCADA layer, the MES and a creaking ERP is where the calendar goes. The model that took three weeks will spend six months learning to speak to systems that predate it.
Sensor hygiene beats model choice. Noisy, miscalibrated, inconsistent sensor data defeats any model you bolt on top. A fortnight of disciplined data work upfront is usually the highest-return activity in the entire programme — and the first thing cut when the timeline slips.
Operators decide whether it sticks. The plant's real knowledge lives in the heads of the people on the line. A tool imposed on them, or one that cries wolf, gets routed around without comment — and a system that's been worked around has failed, whatever its accuracy says. Bring operators in as participants early. The cost of that is trivial against the cost of a rejected deployment.
Legacy constrains the architecture. Many plants run control systems older than the engineers maintaining them. "Add an AI layer" should almost always mean "add a read-only observability layer that never touches the critical path." That's not a limitation to engineer around. It's the correct default, and fighting it is how a software project becomes a safety incident.
What "done well" looks like
A plant manager once described a deployment a year on: the alarms that used to fire at 3am didn't, the engineers weren't patching overnight breakages, and her Mondays had moved from triage to planning. That's the success metric. Not "transformation" — a measurable drop in unplanned interruption. If you can't point at a Monday that changed, the project didn't land.
Where to start
For a first-timer, the failure mode is scope. Narrow it, hard:
- One asset, one failure mode, one shift. The smallest scope that can produce a result. Ship it, then widen.
- Baseline against something specific. "Unplanned stops on line 3 from bearing failures, month over month." Not "efficiency." A vague baseline gives you an unprovable benefit, same as none.
- Pull in maintenance on day one. They'll tell you what's worth building, and they keep it alive after handover.
- Contract for the handover. The system has to be maintainable by someone who isn't the firm that built it. Put that in writing before work starts.
Two trends I'd watch, one I'd discount
Foundation models for industrial telemetry — general-purpose time-series models fine-tuned on a plant's own data — are genuinely dropping the cost of bespoke forecasting. I'd put them in a two-year plan. Vision-language models for operator support ("point your phone at the machine, ask, get a grounded answer") are close, and they'll reshape maintenance once the grounding is reliable enough to trust on the floor.
Digital twins I'd still treat with suspicion. The first generation was mostly marketing. The current one is starting to earn its keep in process simulation and operator training, but the term is broad enough that the burden of proof stays firmly with the vendor. Ask what decision the twin changes. No crisp answer, it's a demo, not a deployment.
