How do organisations calculate AI roi without inflating the result?

Why AI ROI gets inflated so easily

AI ROI is most often overstated when teams count a visible upside but ignore the full cost stack behind delivery. The result is a headline number that looks strong but does not survive scrutiny. A credible calculation treats AI as an operating change, not just a model fee, and it measures only value that can be evidenced in the same period as the costs.

That means the comparison has to include direct costs such as hosting, licences and build effort, plus indirect costs such as data cleansing, integration, monitoring, governance, human review and exception handling. It also means avoiding “soft” gains that have not yet shown up in operations, because forecast value is not the same as realised value.

For organisations building a formal business case, the safest framing is to separate gross value from net value, then attribute only the uplift that can be tied to the AI use case rather than to broader process changes. NHIMG’s Identity and NHI Security Business Case Guide is useful here because the same discipline applies: evidence the value, state the assumptions, and surface the full cost of control.

What costs and benefits belong in the calculation

A defensible ROI model starts by defining the baseline process before AI was introduced. That baseline should cover current cycle time, error rate, labour effort, rework, and any existing tooling cost, otherwise the AI benefit can be exaggerated simply because the comparison point was too weak.

On the cost side, include everything needed to run the use case in production: model hosting or API spend, prompt or workflow design, data preparation, integration work, evaluation, monitoring, governance reviews, change management, and the staff time needed to handle edge cases. If the use case depends on humans stepping in when the model is uncertain, that review cost belongs in the model rather than being treated as an afterthought.

On the benefit side, distinguish between hard savings, avoided cost, revenue uplift, risk reduction and service quality improvements. Some of these can be monetised directly, while others should be tracked as separate operational outcomes until there is enough evidence to convert them into financial value. This is how you avoid treating expected improvement as if it were already achieved.

How to keep AI ROI from being overstated

The cleanest approach is to use the same measurement window for both the baseline and the post-deployment period, then apply a pre-agreed attribution rule. That stops teams from crediting AI for seasonal demand shifts, staffing changes or broader process redesign that would have changed the result anyway.

It also helps to calculate ROI in two layers. Gross value shows the raw improvement in the business metric, while net value subtracts all costs required to realise that improvement. If the gross number is the only one reported, the AI programme can appear more successful than it is operationally or financially.

Where multiple changes are happening at once, attribution should be conservative. If the organisation cannot show that the AI system caused the outcome, or cannot separate its contribution from automation, policy change or human process redesign, the benefit should be discounted rather than assumed in full. That makes the result slower to look impressive, but far more useful for investment decisions.

Risk and Threat Considerations

AI ROI is vulnerable to a measurement problem as much as a delivery problem. When teams optimise for a persuasive business case, they can undercount operating costs, overstate adoption, or assume future gains that depend on controls not yet in place. That creates a governance risk because capital is then allocated on the basis of inflated returns rather than repeatable performance.

Failure mechanism: The calculation breaks when the benefits are measured before the enabling controls, review workload and exception handling are stable, or when savings are attributed without a defensible baseline and attribution method.

Impact: The organisation may scale an AI use case that looks profitable on paper but erodes margin in production, while also masking where human review, data quality or monitoring are consuming most of the value.

Practitioner Guidance

What to verify: Require a baseline, an attribution rule and a cost inventory before accepting any ROI figure. If the business case does not separate gross from net value, treat it as directional rather than decision-grade.

What to prioritise: Put the hardest-to-see costs into the model first, especially data preparation, monitoring, human review and exception handling. Those items are the most common source of inflated results because they are easy to postpone in planning and expensive to ignore in production.

Decision rule: If the claimed gain depends on future adoption, future accuracy improvements or future process redesign, record it as a forecast scenario, not as current ROI. Only realised and evidenced benefits should enter the main calculation.

Practitioner takeaway: The safest AI ROI number is usually smaller, because it includes the real operating burden of making the benefit durable.

Related resources from NHI Mgmt Group

• How should teams calculate AI agent ROI without overstating savings?
• How should organisations calculate AI ROI across security, finance and productivity goals?
• How should security teams measure AI ROI without relying on pilot metrics?
• How should organisations calculate the ROI of AI-powered MDR services?