Key takeaway: A credible AI business case has to include integration, evaluation, monitoring and ongoing maintenance labour, not just inference cost. Omitting that half is why so many approved projects come in over budget without anyone having lied.
What Gets Counted and What Does Not
A typical proposal estimates monthly token spend at a projected volume and calls that the cost of the AI feature. It is a real cost and it is frequently the smaller one.
Missing from the same calculation: the engineering time to build the retrieval pipeline, the evaluation set construction, the prompt iteration cycles, the integration into existing systems, the monitoring and alerting, and the ongoing maintenance as the underlying model or data changes. For most production features, this labour cost exceeds inference spend by a wide margin in the first year, and it does not disappear afterward — it becomes a smaller recurring cost rather than a one-time cost.
A More Honest Cost Structure
| Cost category | Often included in the business case | Typically the larger share |
|---|---|---|
| Inference / API spend | Yes | No |
| Initial engineering build | Partially | Often yes |
| Evaluation set construction | Rarely | — |
| Ongoing monitoring and on-call | Rarely | — |
| Prompt and pipeline maintenance | Rarely | — |
| Model migration when deprecated | Almost never | — |
Evaluation construction deserves specific mention because it is the cost most consistently omitted and most directly determines whether the feature can be trusted in production. A defensible evaluation set takes real analyst or engineer time to build and is not optional overhead — without it, the “it works” claim in the business case has no evidence behind it.
Where the Benefit Side Goes Wrong Too
The benefit side of these calculations commonly uses a best-case adoption and accuracy assumption drawn from a demo, rather than a measured pilot result under realistic conditions. A demo run by the team that built the feature, on curated examples, with no time pressure, systematically overstates what production usage will look like.
The correct benefit estimate comes from a structured pilot with real users on real tasks, measuring the actual outcome — tickets resolved, time saved, error rate — rather than the team’s confidence in the capability.
Building a Business Case That Survives Scrutiny
State inference cost at a realistic volume projection, not the pilot volume, since unit economics at scale frequently differ from a small pilot in ways that matter.
Add a labour line for build, evaluation and first-year maintenance, estimated from comparable past projects rather than from optimism. If no comparable project exists internally, treat this as a genuine unknown and budget conservatively rather than omitting it.
Base the benefit estimate on a real pilot measurement, not a demo, and report a range rather than a single confident number, since AI feature performance genuinely varies more than typical software estimates.
Revisit the calculation after three months in production. The gap between the original estimate and reality is itself useful information for the next proposal, and organisations that track this gap over several projects get measurably better at estimating.
The Bottom Line
Include engineering labour, evaluation construction and ongoing maintenance in the cost side of any AI business case, not just inference spend. Base the benefit side on a real pilot measurement rather than a demo, and revisit the estimate against actual results after the feature has run in production for a quarter.
