The phrase suggests a large model being asked when a machine will fail. That is not what it describes in working systems. The failure prediction still comes from time-series and anomaly-detection models trained on sensor, vibration, thermal or telemetry data. Generative models sit around that core: synthesising rare failure data for training, summarising alarm histories into work-order text, or answering a technician’s question against manuals and maintenance logs.
The divergence point is simple to state and easy to lose track of. Does the team ask the generative layer to produce the failure judgement, or to explain and package a judgement made elsewhere? Blur the two and you ship confident-sounding maintenance advice with no measurable relationship to asset condition. Keep the boundary explicit and you get an interpretability and workflow benefit on top of a detection stack that can still be validated against ground-truth failures.
Is predictive AI the same as generative AI?
No, and in a maintenance stack the line falls in a specific place. Predictive components consume numeric streams and emit a condition estimate or a remaining-useful-life flag. Generative components consume text, logs and documents and emit language. A large language model asked to forecast a bearing failure from raw vibration data is being used outside the job it is good at — which is why “can an LLM predict equipment failure on its own” is the wrong question to argue about. The useful question is which layer owns which output, and how each one is measured.
| Layer | What it does | How it is judged |
|---|---|---|
| Detection (conventional ML) | Anomaly and remaining-useful-life models on sensor, vibration, thermal, telemetry data | Lead time from first anomaly flag to failure; false-alarm rate per asset per month; unplanned downtime hours avoided |
| Generative (LLM / synthesis) | Alarm-history summarisation, work-order drafting, manual and log Q&A | Time from alert to a technician understanding the alert; share of generated work-order summaries accepted without edit |
| Synthetic failure data | Covering rare failure modes the historian never recorded | One test only: does detection recall on held-out real failures improve? |
Two things follow from that table. First, the measurable maintenance outcomes belong to the detection layer, not the generative layer. Second, synthetic data earns its place through a downstream detection metric, never through how realistic the generated traces look — a point that connects directly to how synthetic data is validated more generally in applied machine learning work.
The number to distrust
A single blended “AI accuracy” figure covering a whole maintenance platform should be treated as unmeasured. It cannot be decomposed: you cannot tell whether the detection model caught failures early, whether the false-alarm rate is tolerable for the crew, or whether technicians actually accepted the generated work orders. In our experience, that blended figure is the most common thing on a vendor slide and the least common thing in an evidence pack. Ask for the three detection metrics and the two generative metrics separately, per asset class.
There is also a case where the generative layer is honest overhead. If the crew already reads alarms fluently, the manuals are short, and work orders are three fields long, a language layer adds latency and review burden without buying interpretability. That is a legitimate answer, and it is worth reaching before procurement rather than after.
We develop the detection side of this — data readiness, model selection, and validation against real failure history — in more depth in the AI in predictive maintenance overview.
So: which of your reported maintenance numbers would survive being split into a detection metric and a workflow metric?
