Does predictive maintenance AI actually save money?

Predictive maintenance AI saves money only after every failure path is priced

Predictive maintenance AI saves money on an advisory asset only when expected avoided loss exceeds the full cost of false alarms, missed failures, human review, fallback operation, integration, model maintenance, and the deterministic safety boundary. A percentage copied from an industry survey cannot answer that question.

The familiar savings range also changes with the comparison baseline. A Department of Energy national laboratory says past studies estimated savings of 8% to 12% against preventive maintenance, while facilities dependent on reactive maintenance could find opportunities exceeding 30% to 40%. Both figures describe maintenance programs, not the incremental return from adding an AI model to one asset, and the source presents them as estimates rather than measured AI outcomes. ¹

For one asset, the useful calculation is:

Annual net value = expected avoided failure loss + avoided planned work − review cost − false-action cost − fallback cost − integration cost − model maintenance cost − safety-boundary cost

The model remains advisory throughout this calculation. It can rank an inspection, recommend a work order, or attach evidence to an alert. It does not trip equipment, suppress an alarm, change a setpoint, or replace an interlock.

The comparison baseline determines whether the claimed saving exists

"Predictive maintenance" can mean a vibration threshold, an OEM health-monitoring package, a statistical anomaly detector, or a supervised failure classifier. The ROI changes depending on which capability is new.

A site moving from run-to-failure maintenance may gain from basic sensing and deterministic thresholds before machine learning contributes anything. Charging the entire improvement to AI overstates the model's value.

A site already using preventive intervals has a different counterfactual. Its benefit may come from extending an inspection interval, finding a defect between inspections, or ordering a spare before an outage. Each mechanism needs separate evidence because each removes a different cost.

The comparison should therefore be an explicit operating policy:

Current policy → proposed advisory policy → permitted maintenance action → economic consequence

Before pricing the model, classify the proposed system correctly. Generative AI, predictive AI, and automation solve different problems explains why a predictor and an automated controller require different evidence and governance.

A failure taxonomy exposes costs hidden by accuracy scores

A predictive model does not produce savings directly. It emits a score that passes through alert logic, human review, work planning, parts availability, and physical intervention. Failure at any stage changes the return.

This taxonomy prevents a common accounting error: treating every historically detectable failure as avoidable loss. A failure contributes to expected benefit only if the model detects it early enough, a reviewer accepts the recommendation, and the intervention succeeds.

In a maintenance log, a compressor that the model flagged, that an inspector opened up, and that turned out to have a bearing well within tolerance looks identical to a genuine save unless someone reads the inspector's note describing normal wear. Counting that inspection as avoided loss because the model triggered it, rather than as a false alarm, is how the benefit side of the ledger gets inflated before the cost side is even priced.

False alarms deserve their own ledger. A heavy-industry condition-monitoring study needed a correction method that reduced false alarms by 90.25% on average relative to stand-alone outlier detection. The result does not transfer directly to another plant, but it shows why raw anomaly counts cannot be treated as maintenance decisions. ²

A worked one-asset model can reject an attractive deployment

Consider an advisory model for one gearbox. The following figures are stated assumptions for a modelled estimate, not measurements from production hardware.

Assume an unplanned failure has a net avoidable loss of $300,000 after subtracting the repair cost that planned intervention would still incur. Assume a baseline failure probability of 0.08 per asset-year, production recall of 0.70, actionable lead time on 0.60 of detected events, and successful intervention on 0.90 of actionable alerts.

The modelled annual avoided loss is:

$300,000 × 0.08 × 0.70 × 0.60 × 0.90 = $9,072

Now price the system needed to obtain that benefit. These are modelled assumptions for the same asset.

The modelled annual net value is $9,072 − $47,440 = negative $38,368. The modelled ROI is negative 80.9%, calculated as negative $38,368 divided by $47,440.

Under these assumptions, the modelled break-even avoidable loss per failure is approximately $1.57 million:

$47,440 ÷ 0.08 ÷ 0.70 ÷ 0.60 ÷ 0.90 = $1,568,783

That result does not prove predictive maintenance AI is uneconomic. It identifies the assumption that must change. The asset needs a greater failure consequence, a higher base rate, better actionable recall, lower delivery cost, or benefits shared across more assets.

The table also prevents a pilot from hiding fixed costs. If historian and CMMS connectors already exist, calculate both marginal ROI and fully allocated ROI. Label them separately. A marginal case can justify adding an asset to an existing platform without proving that the original platform investment paid back.

The safety boundary is an independent system, not a model threshold

A predictive score is unsuitable as the protection layer because its behavior is inferred from data and can change outside the validated operating envelope. The safety system must continue to act from predetermined conditions even when the model is wrong, stale, or unavailable.

NIST SP 800-82r3, using the ANSI/ISA-84.00.01 definition, describes a safety instrumented system as sensors, logic solvers, and final control elements that take a process to a safe state when predetermined conditions are violated. ³

For facilities covered by process safety management, 29 CFR 1910.119(d)(3)(i)(H) separately identifies interlocks, detection systems, and suppression systems as documented safety systems. ⁴

The integration design should reflect that separation. Model output can enter a dashboard or CMMS queue. It should not write to the safety PLC, alter alarm limits, inhibit trips, or become a prerequisite for deterministic protection.

Price this boundary. The cost includes hazard review, access control, interface testing, management-of-change work, and verification that loss of the advisory service leaves the approved maintenance and safety policies intact. Assigning zero cost because the model is "advisory" ignores the work required to prove that it remains advisory.

The same principle applies to generative explanations attached to alerts. They may help a reviewer inspect evidence, but they do not belong in a deterministic control path. Keep generative AI outside deterministic control loops covers that boundary in detail.

Deterministic thresholds and preventive schedules are serious alternatives

A deterministic condition-monitoring rule is the first alternative. A threshold on bearing temperature, vibration amplitude, lubricant debris, or pressure differential is inspectable and cheap to validate when the failure mechanism is known. Its limitation is coverage: it cannot represent interactions the rule author did not encode.

An OEM monitoring package is the next comparison. It may arrive with sensor placement, signal processing, and service procedures already defined. Its economic cost can include opaque alert logic, restricted data access, per-asset licensing, and dependence on the vendor's maintenance workflow.

A revised preventive schedule avoids model operations entirely. It remains competitive when failure modes correlate with age or duty cycle and inspections are inexpensive. Its cost is unnecessary planned work and exposure between intervals.

Run-to-failure is also a valid baseline for redundant, inexpensive, non-safety-critical assets with short replacement lead times. Predictive AI loses against it when the expected consequence is lower than the combined sensing, review, and maintenance burden.

Compare these alternatives using the same failure taxonomy. Do not let the AI option claim avoided downtime while the threshold option is evaluated only on software cost.

Production evaluation must preserve the real failure base rate

Balanced validation sets are useful for comparing classifiers, but they cannot establish production alert economics. A helicopter vibration benchmark built from flight-test data uses validation patterns split equally between abnormal and healthy examples. ⁵

The deployment population will have its own prevalence. Positive predictive value changes with that prevalence even when sensitivity and specificity remain fixed. A model evaluated on an equal class split can therefore look operationally precise while producing mostly false alerts on a fleet where target failures are rare.

Apply the ROI calculation in this order:

1. Define the failure event narrowly enough that maintenance records can confirm it. Record the observation window and required lead time.

2. Measure the current policy. Capture failures, preventive interventions, downtime, inspection labor, parts, and censored assets that have not yet failed.

3. Backtest with time-based splits and the production class distribution. Keep assets, operating regimes, and post-maintenance periods from leaking across the split.

4. Run in shadow mode. Count alerts, reviewer time, late alerts, unavailable periods, and cases where an alert could not have changed the outcome.

5. Admit benefit only after a documented causal chain. The alert preceded the decision window, the reviewer selected a feasible action, and the action removed or reduced the expected loss.

6. Recalculate the ledger after deployment. Separate avoided-loss estimates from observed spending because an averted failure remains a counterfactual, while labor, parts, and integration invoices are directly observable.

Review design also affects adoption. If maintainers cannot see the signal history, operating context, and reason for escalation, they must reconstruct the case manually. That labor belongs in the ROI model, and repeated low-value alerts will change whether the workflow is used at all. Will my staff actually use it?

The model fails where the asset does not produce usable evidence

Predictive maintenance AI does not solve failures that leave no detectable precursor in the available sensors. It cannot create lead time after a sudden event, recover missing maintenance records, or make an unavailable spare arrive before the outage.

It also breaks when labels encode the old maintenance policy rather than physical condition. Consider a reliability technician who has learned to replace a bearing whenever the vibration alert fires, whether or not a teardown would show real wear. If technicians replace parts after alarms, the dataset records interventions but may never reveal whether the asset would have failed. Training on those records can teach the model to reproduce historical alerting behavior, which looks like agreement with the technician and is actually the absence of a counterfactual.

Cross-asset pooling can improve the amount of failure data, but only when sensor placement, sampling, operating regimes, and failure definitions are comparable. A fleet identifier is not evidence that two assets share a predictive relationship.

Feedback can corrupt evaluation after launch. Reviewers investigate high scores more often, so confirmed defects accumulate around the model's existing decisions. A maintenance planner who only schedules teardown for the gearboxes the model already flagged will find, months later, that every confirmed defect in the maintenance record happens to be a gearbox the model had already scored high. That pattern reads as validation, but it is the review policy, reflected back at the model that produced it. Retraining on those confirmations without accounting for selective inspection makes the model appear better while narrowing what the dataset can reveal.

Most importantly, predictive maintenance AI does not replace deterministic protection. If the business case requires model output to trip equipment, suppress an alarm, or override a safety function, the proposal has crossed from advisory maintenance into control-system engineering. The original ROI calculation no longer describes the system being built.