AI
Quantifying ROI on Industrial AI Deployments: A Framework for CFOs
Most enterprise AI pilots stall before reaching production. We break down a four-quadrant model for evaluating AI investment returns across efficiency, revenue, risk, and strategic optionality.
Most industrial AI business cases are wrong in the same direction, and it is not the direction people expect. They are not too optimistic about model accuracy — modern models usually hit their accuracy targets. They are too optimistic about what accuracy is worth, and they omit the cost structure that determines whether a working model is also a profitable one.
Accuracy is not the objective function. Expected cost is.
A defect-detection model is not deployed to be accurate. It is deployed to reduce the total cost of defects and of reacting to them. Those are different objectives, and optimising the first can worsen the second, because false positives and false negatives almost never cost the same amount.
On an inspection line, a false negative ships a defective unit — warranty claim, recall exposure, customer relationship. A false positive scraps or re-inspects a good one. If the first costs 200× the second, the decision threshold that minimises error rate is badly wrong, and the correct threshold follows directly from the cost ratio.
E[C](τ) = cFN · p · ( 1 − TPR(τ) ) + cFP · ( 1 − p ) · FPR(τ)
Prevalence matters as much as the cost ratio, and it is the term that quietly invalidates pilots. A model validated on a curated set with 8% defects behaves very differently at a real 0.3% prevalence: at low prevalence, even an excellent false-positive rate produces a majority of alarms that are false, and operators stop trusting the system within weeks.
PPV = TPR · p / [ TPR · p + FPR · ( 1 − p ) ]
The cost side that gets left out
Model development is usually a minority of lifetime cost, and every serious study of production machine learning has found the same thing. The business case must carry the whole stack.
| Cost category | Share of 5-yr TCO | Notes |
|---|---|---|
| Data acquisition & labelling | 20–35% | Recurring, not one-off — drift forces relabelling |
| Model development | 10–20% | The part everyone budgets |
| Integration (MES/SCADA/historian) | 15–25% | Almost always underestimated |
| Inference infrastructure | 5–15% | Edge hardware or cloud spend |
| Monitoring & retraining | 15–25% | Recurring for the full service life |
| Change management & training | 5–15% | Determines whether it is actually used |
Two of these are recurring, and that is what breaks naive payback calculations. Labelling and retraining do not stop after go-live, because the process the model observes does not stop changing. New suppliers, new tooling, seasonal material variation and equipment wear all shift the input distribution, and a model that is not retrained decays at a rate set by how fast the plant changes.
Discount the cash flows, and be honest about when they start
Simple payback ignores the time value of money and the ramp period, and both matter for capital projects with multi-year horizons. Use net present value, and model benefits as ramping rather than switching on at go-live — adoption is gradual, and the first months typically deliver a fraction of steady-state value.
NPV = −C0 + ∑t=1T [ Bt · αt − Ot ] / (1 + r)t
Where the benefit is throughput or availability rather than direct cost, derive it from OEE rather than asserting it. The decomposition is standard and it forces the claim to be specific about which of the three factors the system actually moves.
OEE = A × P × Q
Sensitivity analysis is the deliverable, not the point estimate
A single NPV figure conveys false precision. What a capital committee needs is which assumptions the answer depends on, and how wrong each can be before the decision changes. Vary each input across its plausible range while holding the others at base case, and rank by the swing in NPV.
In our experience the ranking is remarkably consistent across industrial AI projects: adoption rate first, then true prevalence of the event being predicted, then integration cost, then model performance. Model performance — the thing that consumes almost all of the project's attention — is typically fourth. A project that hits every accuracy target and is not adopted returns nothing, and that outcome is common enough that adoption deserves the same rigour as the model.
The test a business case should pass
- Metrics restated at true operating prevalence, not pilot prevalence.
- Decision threshold set from the cost ratio, with both costs written down.
- All six TCO categories present, with recurring costs recurring for the full horizon.
- Benefits attributed to exactly one OEE factor, with no mechanism counted twice.
- Cash flows discounted at the hurdle rate with an explicit adoption ramp.
- A sensitivity table showing which assumption the decision actually rests on.
A case that passes these is not necessarily a case that clears the hurdle rate. That is the point. It is far cheaper to discover a project does not pay in a model than to discover it in year two, and the organisations that build this discipline stop having the argument about whether AI works — they start having the far more useful argument about which application to fund first.
Explore how Root Digit can support your team
From discovery workshops to production deployment, our engineers and consultants partner with you across the lifecycle of your AI, robotics, and IoT initiatives.