Predictive maintenance is the most frequently promised and least frequently delivered industrial AI application. The pitch is straightforward: sensors detect the signature of an approaching failure, work is scheduled before it happens, and unplanned downtime disappears.
Predictive maintenance with AI does work, and the projects that succeed spend most of their effort on data and process rather than modelling. The ones that fail usually started without enough recorded failures to learn from.
You need failures to learn from
A model predicting failure needs examples of failure, labelled with what broke and when. A well-run site may have very few per machine per year, which is excellent operationally and a genuine obstacle for supervised learning.
Count them before committing. If a critical asset has failed twice in five years, no amount of sensor data will teach a model its failure signature, and a different approach is needed.
Anomaly detection is the realistic start
Where failure examples are scarce, learning what normal looks like and flagging deviation is more achievable. It will not tell you what is about to break or when, and it will flag things that turn out to be nothing.
That is still useful if the alert reaches someone who can look. Treated as an early warning that invites inspection rather than a prediction, it earns its place quickly.
Maintenance records are the weak link
Sensor data is usually plentiful and maintenance records rarely are. Work orders that say "fixed" with no cause, repairs recorded days after the event, and replacements logged against the wrong asset all make supervised learning impossible.
Improving how work is recorded is unglamorous and often the highest-value first project. Six months of properly coded maintenance history is worth more than any modelling effort applied to poor records.
Everyone wants to talk about the model. The project is won or lost on whether your work orders say what actually broke.
David Kwon, Head of Automation, Engineered With AI
Choose assets where it pays
Focus on equipment where failure is expensive and warning is actionable: long lead-time spares, production-stopping machines, anything whose failure creates a safety or environmental issue.
Equipment that is cheap to replace, quick to swap or already maintained on a sensible schedule rarely justifies the investment, however much data it produces.
Decide what an alert means
An alert with no defined response is noise. Each one needs an owner, an action, a timescale and a way to record what was found, otherwise alerts accumulate and are ignored within a month.
Record the outcome of every alert too. That record is how the system improves and how you demonstrate it caught something real.
Expect and manage false alarms
Early systems produce more false positives than teams expect, and each one costs an inspection. Set the threshold deliberately against that cost, and review it as confidence grows rather than leaving it at the default.
Be honest with maintenance staff about the expected rate. A team told the system is reliable loses trust at the third false alarm; a team told to expect some accepts them as the price of early warning.
Start simpler than you think
Threshold alarms on the few variables engineers already watch, trend charts reviewed weekly and condition-based rules capture a surprising share of the value for a fraction of the cost and complexity.
Those simple measures also generate the labelled history a model would later need, so the simple version is a step towards the advanced one rather than a detour, as described in taking an AI pilot into production.
Measure downtime, not accuracy
The measures that matter are unplanned downtime, emergency call-outs, spares held for urgent replacement and overtime spent on breakdowns. A model with impressive accuracy that has not moved those figures has not yet paid for itself.
Establish those figures before the project starts, because reconstructing them afterwards is difficult and the comparison is what justifies the next phase.
Get the engineers involved early
Maintenance engineers know which machines misbehave, what the early signs are and which readings drift for harmless reasons. A model built without that knowledge rediscovers it slowly and expensively, and one built with it starts from a sensible list of variables and a realistic view of what a warning should look like.
Their involvement also decides whether anyone acts on the output. A system the maintenance team helped design gets used; one delivered to them as a finished product tends to be tolerated for a few weeks and then ignored.
Check the sensors before trusting them
Sensor data arrives with gaps, drift, duplicated timestamps and readings from instruments that were recalibrated or replaced mid-history without anyone recording it. A model trained across that history learns the instrumentation changes as though they were machine behaviour, which is a failure mode that looks like success on paper.
Wondering whether your data supports this?
We will assess your maintenance records and sensors before you invest.