NirjiX

Decision intelligence · Enterprise AI

AI ROI: Building a Business Case That Survives Finance Review

AI business cases usually fail review for the same two reasons: the benefit is asserted rather than baselined, and the cost stops at the build when most of the spend is in running, monitoring and changing the system.

A credible case names the metric, states the baseline before the work starts, models the full cost curve, and shows what happens when adoption lands at half the assumed rate.

Decision intelligenceWritten by NirjiX AI AdvisoryPublished January 2026Last reviewed February 202610 min read

Direct answer

How do you calculate ROI on an AI investment?

Define the single business metric the use case is meant to move, record its baseline before the build, and estimate the benefit as the modelled change in that metric multiplied by realistic adoption. Against it, count the full cost: discovery, data remediation, build and integration, inference and infrastructure, evaluation and monitoring, change management and training, and ongoing engineering to keep the system current. Then present a range with sensitivities on adoption, usage volume and benefit realisation, rather than a single number.

The cost lines most AI cases understate

Build cost is usually the best-estimated line and the smallest one over a three-year horizon.

AI cost categories and why each is commonly missed or understated.
Cost lineWhat it coversWhy it is missed
Data remediationAccess, quality, lineage and governance work required before the use case is buildable.Assumed to be already done because a platform exists; discovered after funding.
Integration and process changeWiring outputs into the systems and workflows where the decision is actually made.Treated as a small last step, when it is usually the largest engineering effort.
Inference and infrastructurePer-use cost at production volume, which scales with adoption rather than being fixed.Estimated from pilot volumes, then multiplied unexpectedly by success.
Evaluation and monitoringTest sets, quality measurement, drift detection and the people who review them.Not budgeted at all, because pilots are evaluated informally.
Change and enablementTraining, process redesign, incentives and the support period after go-live.Assumed to be absorbed by the business, which then does not do it.
Sustaining engineeringModel and dependency changes, prompt and pipeline updates, security patching.Modelled as near-zero, though the underlying components change frequently.

What makes a benefit claim defensible

  • One primary metric per use case, with a named executive owner who accepts the target.
  • A baseline captured before the build, from the operational system rather than from recollection.
  • An adoption assumption stated explicitly and modelled below plan as well as at plan.
  • A stated treatment of released capacity: whether it becomes cost reduction, absorbed growth, or nothing.
  • Benefit phased over time to reflect ramp, not booked from month one.
  • A stop rule: what result by what date would mean the investment is not continued.

How to build the case

  1. 01

    Fix the metric and baseline

    Before any build. If the baseline cannot be measured today, the first piece of work is instrumentation, not modelling.

  2. 02

    Model cost over three years

    Include run, evaluation and sustaining lines. A one-year view flatters AI investments more than almost any other technology spend.

  3. 03

    Apply adoption honestly

    Model the benefit at full adoption and at a materially lower rate. If the case only works at full adoption, it is a plan for disappointment.

  4. 04

    Stress-test the assumptions

    Vary usage volume, unit inference cost and benefit realisation. The board's question is what breaks the case, not what the mid-point is.

  5. 05

    Agree measurement and review

    Define who reports the result, from which system, and when the investment is reviewed against the stop rule.

NirjiX view

The NirjiX view

The strongest AI business cases we see are narrower than the weakest ones. They cover two or three use cases with baselines, real run costs and phased benefit, and they name what would falsify them. Portfolio-wide efficiency percentages applied to a headcount base do not survive contact with finance.

We also insist that released capacity be described honestly. If saved hours will not be converted into reduced cost or absorbed growth, they are not a benefit — and saying so early protects the credibility of the next case.

Frequently asked executive questions

What is a realistic payback period for enterprise AI?
It depends entirely on whether the use case removes a real cost line or improves a revenue-bearing decision, and on how quickly adoption ramps. Rather than adopting a benchmark payback, model your own three-year cost and phased benefit — a case that only pays back on an aggressive adoption curve should be presented as such.
How do we value productivity gains that do not reduce headcount?
State the mechanism. If released capacity absorbs growth that would otherwise require hiring, the benefit is avoided cost and should be tied to a specific plan. If it improves quality or cycle time, measure that directly. Hours saved with no downstream conversion should be excluded from the financial case and reported as an operational benefit.
Should inference cost be treated as fixed or variable?
Variable, and modelled at production volume with a growth assumption. Successful adoption raises this line materially, which is why cases estimated from pilot usage can turn negative exactly when the use case starts working.
Who should own the AI business case?
The executive who owns the metric it moves, supported by finance for the cost model. When the case is owned by the AI or technology function alone, the benefit assumptions rarely bind anyone whose budget would actually change.
How does this differ from a GCC business case?
The cost structure is different — AI is weighted toward run and sustaining cost, a capability center toward people, ramp and attrition — but the discipline is identical: your own baseline, full cost lines, phased benefit and sensitivity ranges instead of a single number.

The main guide on this topic

Should an enterprise build its own AI capability or buy a platform?

This page covers one part of the decision. The full NirjiX guide to AI build vs buy sets out the whole picture.

AI build vs buy →

Decide next

Related decisions

Continue

Related intelligence

Transparency

Sources and methodology

This page reflects NirjiX advisory practice rather than a survey or a vendor benchmark. The structure of the assessment — the dimensions, the maturity language and the sequencing logic — is the same framework used inside the NirjiX AI readiness assessment and the AI plan builder.

Where we describe patterns ("most organizations discover…"), we are describing what we observe across client engagements, not a measured statistic. We deliberately avoid quoting market numbers we cannot verify, because an AI investment case built on borrowed statistics collapses the first time a CFO tests it.

Any figure that ends up in your own plan should come from your own data: your cost base, your cycle times, your error rates, your volumes. The assessment and plan builder are designed to force that discipline.

Model the case on your own numbers

The AI plan builder captures baselines, cost lines and phased benefit for each prioritized use case, so the case can be defended line by line.

Build your AI planSpeak with an AI advisor

Outputs are preliminary and intended for advisor and finance validation before investment approval.