7

Most AI predictive maintenance pitches promise the same thing: a model that notices a failure coming before a human does. That promise is real, and detection has improved a lot. But an alert is only the first step of a repair. Someone still has to work out which component is failing, what kind of failure it is, and how urgent it is.

That second step is where the hard problems sit. It is also the step that gets measured least.

What AI predictive maintenance actually does

Predictive maintenance uses telemetry from equipment to estimate when something will fail, so work can be scheduled before it does. The equipment might be a pump, a turbine, a fleet of vehicles or a rack of servers. The data looks similar in every case: many sensors, each producing a time series, all sampled continuously.

AI enters at three levels, and it helps to keep them separate.

• Detect. Is something abnormal happening right now, and when did it start?
• Explain. Which signals, and therefore which components, are responsible?
• Interpret. What kind of failure is this, how severe is it, and what should a technician do?

Each level depends on the one before it. Each is also much harder than the one before it.

Detection is the part that gets measured

Time series anomaly detection is a mature research field. There are dozens of methods, from statistical baselines to deep autoencoders, and a long list of public benchmarks to compare them on.

Most of those benchmarks score one thing: did the model flag the right time window? That is a useful question. It is not the question a maintenance team asks at 2 a.m.

The team wants to know where to look. A model that fires accurately but points at the wrong subsystem sends people in the wrong direction, and a wrong direction can cost more time than a late alert.

What a storage-system benchmark shows about the gap

A benchmark released in October 2026 tests all three levels on the same data. SHAD (Scality High-dimensional Anomaly Detection) was built by researchers at Inria and Scality from telemetry of a distributed object storage system, Scality RING.

The setup is close to what predictive maintenance looks like in production. Each recording covers 171 metrics from a multi-server cluster running a steady workload. Engineers then injected controlled faults in three families: disk failures, server failures such as network partitions and degraded links, and failures of individual software storage nodes.

What sets the dataset apart is the labeling. Every recording marks when the fault happened, which specific metrics trace back to the root cause, how critical it was, and a written description of what occurred. That makes it possible to grade a model on explanation and interpretation, not only on detection.

The results line up with the three levels.

Detection was workable. Across 18 detectors, semi-supervised methods performed best. No single method was accurate on every anomaly type, which matches what practitioners tend to see.

Explanation was close to random. When the authors asked the better detectors which metrics drove their anomaly scores, the answers were, in the paper’s words, “nearly indistinguishable from a random baseline in term of dimension localization.” Their summary is blunt: “good detection accuracy does not inherently translate into diagnostic utility.”

Interpretation was weak. Five large language models, prompted once with no task-specific training, struggled to name the anomaly type or point to the affected component. Supplying context about the system improved how well they placed the anomaly in time. It did not improve their judgment of severity.

These findings come from one system and one workload profile, and the LLM tests used single-call, zero-shot prompting. The authors say as much. The pattern is still worth taking seriously, because the conditions are not exotic.

Why explanation is harder than detection

Detection asks a yes-or-no question about the whole system. Explanation asks which of many correlated signals matters, and real infrastructure works against that question in a few ways.

Signals move together. A failing disk raises latency on the disk, then on the server, then on the client connections that touch it. A model sees many metrics deviate at once and has no built-in way to tell cause from consequence.

Resilient systems hide their own failures. Distributed systems are designed to absorb faults. In SHAD, storage node failures produced the faintest signal of the three families, because the cluster redistributed the work. Good engineering for availability makes the monitoring problem harder.

Failures can unfold over time. A cascade of disk failures, or a link that degrades slowly, looks different from a single clean break. A model trained mostly on abrupt faults may detect the gradual ones late or misattribute them.

None of this is specific to storage. Any machine built with redundancy and many interdependent parts shares the same traits.

Where large language models fit

LLMs are an obvious candidate for the interpretation step. They write fluent summaries, and many maintenance tools already use them to draft work orders or summarize incident history.

Drafting text from information a technician has already gathered is a different task from reading raw multivariate telemetry and naming the fault. The SHAD results suggest the second task is not something a general-purpose model does well out of the box. The improvement from added system context points to a more realistic role: an LLM that works with a detector, a component map and a history of past incidents, rather than one that reads sensor data alone.

What this means for a predictive maintenance program

For teams evaluating or building AI predictive maintenance, the practical lessons are less about models and more about data and evaluation.

Test the full chain. Ask any vendor or internal team how their system performs on explanation, not only detection. Ask what share of alerts point a technician to the right component on the first try. If nobody measures it, nobody knows.

Label for diagnosis, not just for alerts. Most incident records note that something broke and when. Far fewer record which signals traced back to the root cause, how severe the event was, and what was done. That richer labeling is what makes explanation trainable and testable later.

Keep the history. Raw telemetry plus well-annotated incidents is the asset that improves every future model. It is also easy to lose to short retention windows or aggressive downsampling. Long-lived, high-resolution sensor history fits naturally on a capacity tier built for scale, where it stays available for retraining without crowding out hot data.

Keep a human in the loop for diagnosis. Detection can be automated with reasonable confidence. On current evidence, root-cause attribution benefits from an expert who can confirm or reject what the model proposes.

What to take away

• Treat detection and diagnosis as separate capabilities. A system can be good at the first and close to useless at the second.
• Measure what the technician needs. Ask how often an alert points to the right component, not just how often it fires on time.
• Invest in labeled, retained telemetry. Context-rich incident history is what any future diagnostic model will learn from.

The through-line is simple. Predictive maintenance pays off when it shortens the path from alert to fix. Detection starts that path. Explanation and interpretation finish it, and they are where the open problems remain. Public benchmarks built from real systems, with labels for root cause and severity, are how the field will close that gap.

Frequently asked questions

What is AI predictive maintenance?

AI predictive maintenance uses machine learning on equipment telemetry to anticipate failures before they happen, so repairs can be planned instead of reactive. It typically involves anomaly detection on many sensor time series, plus tools that help technicians diagnose and act on what the model flags.

What is the difference between anomaly detection and root cause analysis?

Anomaly detection identifies that something abnormal is happening and when. Root cause analysis identifies which component or signal is responsible. A model can detect anomalies accurately and still struggle to localize the cause, especially in systems where many signals move together.

Can large language models diagnose equipment failures from sensor data?

In recent benchmark testing, general-purpose LLMs prompted once without task-specific training performed poorly at identifying anomaly type and location from multivariate telemetry. They are better suited to summarizing and documenting incidents, or to working alongside detectors and system context.

What is the SHAD benchmark?

SHAD is a public time series anomaly detection benchmark of 215 multivariate recordings from a distributed storage system, with labels for timing, root-cause metrics, severity and a written explanation of each fault. The code and data are available on GitHub under the AGPL-3.0 license.

What data does a predictive maintenance program need to keep?

High-resolution telemetry history and incident records that note the root cause, severity and resolution. That combination is what allows models to be retrained and evaluated on diagnosis, not just on detection.

Further reading: Detect, Explain, Interpret: An End-to-End Benchmark for Time Series Anomaly Detection, Explainability and Interpretability (arXiv, 2026) and Tiered storage for AI: scalable performance and cost control.