Reading time: approx. 7 min · Cluster: manufacturing

AI in maintenance is one of the most over-promised and least honestly described topics in industry today. Some sell it as a crystal ball that foresees every breakdown a week ahead. Others bounce off their first pilot and declare that "it doesn't work." The truth sits in three concrete uses that hold up, and two areas where AI in maintenance regularly disappoints – worth knowing before you sign off a budget.

This post is for maintenance managers, plant leads and anyone tasked with deciding whether a project makes sense. No talk of "revolution." Pros and cons next to every point.

Contents

Data first, model second

Every use of AI in maintenance rests on one foundation: data you already collect, or can start collecting without rebuilding the whole shop floor. If your failure history lives only in a foreman's head and a notebook in the workshop, no model will fix that. This is not an excuse – it is the order of work.

A simple rule holds in practice: a model is only as good as the repeatability of the phenomenon it is meant to recognise. Where the same fault recurs in a similar way and leaves a trace in the data (vibration, temperature, current draw, cycle time, CMMS entries), AI has something to learn from. Where failures are one-offs driven by human factors or chance, even the best model will be guessing.

Use 1: anomaly detection in machine signals

This is the most mature and most honest use. Instead of promising that the model will predict a breakdown, we give it a humbler task: notice that a machine is behaving differently than usual, and raise a flag before the operator does.

The model learns the normal operating profile – bearing vibration, gearbox temperature, motor current draw – and signals deviations. It does not say "the bearing will fail in three days." It says "this node has been running outside its norm for two shifts, check it." That is enough to turn some unplanned breakdowns into planned inspections.

Pro: a low barrier to entry if you already have sensors; gives real warnings without false precision.
Con: it generates false alarms until you tune the thresholds; it needs someone in maintenance to review those flags and mark what was accurate.

Use 2: a knowledge assistant for maintenance technicians

The second use does not touch sensors at all. It is about knowledge you already hold – in equipment manuals, inspection sheets, repair history in the CMMS and notes nobody reads because you have to dig for them in binders.

An assistant built on your documentation answers a technician's plain-language question: "what is the procedure for replacing the seal in pump X" or "what did we do last time this line threw the same error." The model does not invent – it points to the manual section and the historical entry its answer is based on. This shortens downtime, because knowledge reaches the technician on the floor instead of staying on the desk of your most experienced employee.

This use matters especially where knowledge leaves the company as people retire. A related thread – the limits of such an assistant and how to feed it knowledge – we cover in our piece on the difference between private AI and SaaS.

Pro: needs no sensors; runs on documentation you already have; directly shortens downtime.
Con: it is only as good as how well your documentation is organised; messy manuals translate into weak answers.

Use 3: planning and work prioritisation

The third use is decision support, not automation. Maintenance juggles planned inspections, requests from production and breakdowns every day. AI can help rank these tasks by risk and impact on production, drawing on history: which machines are bottlenecks, which faults most often escalate, where deferring an inspection led to a longer stoppage.

This is not "AI builds your schedule." It is more of a second opinion in planning – a proposed order the planner accepts or rejects. The value shows up where there are more requests than hands and someone has to decide what waits.

Pro: brings order to decisions under limited resources; learns from your history, not generic assumptions.
Con: without a clean request history the suggestions are weak; the planner must keep the last word, or the system loses the team's trust.

Letdown 1: failure prediction "to the day"

The most common letdown starts with a promise: "we will predict the breakdown a week in advance." It sounds good on a slide and bad on the floor. Remaining useful life (RUL) prediction works well in aviation and power generation, where machines are expensive, uniform and covered in sensors, and where failure data is gathered over years.

In a typical mid-sized factory the machine park is varied, sensors are few, and failures of a specific type are – fortunately – rare. The model has nothing to learn "to-the-day" prediction from. Promising that precision ends in a loss of the team's trust after the first missed alarm. That is why anomaly detection (Use 1) is a more honest goal than hard prediction.

Letdown 2: one model for the whole machine park

The second letdown is the assumption that you can buy one universal model that handles a press, a compressor and a welding robot at once. Each of these nodes has a different operating profile, different data and different failure modes. A model tuned to fan bearings will say nothing useful about a hydraulic system.

In practice, deployment is a series of narrow solutions for specific, critical machines – not one "everything from day one" platform. That reframes the budget conversation: you start with a single bottleneck, check whether it holds up, and only then expand. Whoever buys "the whole thing at once" usually pays for features they will not use.

How to start sensibly

A sensible start does not require overhauling the whole shop floor. Three steps are enough. First, pick one machine that is a bottleneck and whose downtime genuinely hurts. Second, check what data you already have on it and what its failure history looks like. Third, set a modest goal – anomaly detection or a knowledge assistant – instead of a "to-the-day" prediction promise.

If you are wondering whether your company is ready in terms of data and organisation, a good starting point is our piece on when on-prem AI in manufacturing makes sense, and when it doesn't – because it is often the same conversation about data, infrastructure and control.

Prefer to check on your own first? The readiness mini-audit takes 10 minutes and leaves no data behind, and the value calculator gives you the order of magnitude.