Most AI business cases compare a licence cost against an estimated benefit. Both sides of that comparison are usually wrong, but the cost side is wrong in a more predictable way.
What gets counted
Seats, or consumption. Sometimes implementation. That is typically the whole cost side.
What usually does not
Data preparation. The work of making the inputs usable — connecting sources, resolving identifiers, agreeing definitions. This is frequently the largest single line and it is almost never in the original case, because it is discovered afterwards.
Integration and maintenance. Not the initial build — the ongoing cost of keeping it working when a source system upgrades, a field changes meaning, or an API version is retired.
Human review. If outputs require checking before they are acted on, that review time is a running cost of the system, not an implementation phase. A tool that saves ten minutes and requires four minutes of verification saves six.
Governance and oversight. Access decisions, acceptable-use policy, audit trail, and someone accountable for what the system produces.
Change and enablement. Not the training session. The productivity dip while people learn, and the ongoing cost of onboarding new staff into a new way of working.
Model drift and rework. Performance degrades as the world moves. Somebody has to notice and somebody has to fix it, on a recurring basis.
Why the omission changes the answer
Illustrative arithmetic for a mid-sized deployment:
| Line | Year 1 |
|---|---|
| Licences | $120,000 |
| Implementation | $80,000 |
| Subtotal — what the case included | $200,000 |
| Data preparation | $150,000 |
| Integration and maintenance | $40,000 |
| Human review (2 FTE-equivalent hours/day) | $95,000 |
| Governance | $30,000 |
| Enablement and productivity dip | $45,000 |
| True year-one cost | $560,000 |
A benefit estimate that clears $200,000 comfortably may not clear $560,000 at all. The initiative was not badly chosen; it was compared against a quarter of its cost.
The useful discipline
Before approving, ask for the cost of the seventh item — the one after licences, implementation, data, integration, review and governance. If nobody can name a seventh, the case is a licence quote with a narrative attached.
And ask the harder question: what measure will tell us this worked, what is it now, and who will check in twelve months? A business case with no baseline is a purchase decision, not an investment decision.
The benefit side is usually worse
Everything above concerns the cost column. The benefit column is typically weaker still, because it rests on one of three unreliable foundations:
Vendor-supplied benchmarks. Drawn from unnamed customers in unstated conditions, and selected for publication precisely because they were favorable.
Self-reported time savings. People who chose to adopt a tool report that it helps. This is the most commonly cited evidence in the category and the least reliable — it measures satisfaction, not throughput.
Extrapolation from a pilot. A pilot runs with motivated volunteers and dedicated support. Neither condition survives general rollout, and both are doing much of the work in the result.
What a defensible case contains
Three things, all established before deployment:
- A named business measure — throughput, cycle time, cost per unit, rework rate — not a tool-side metric
- That measure's current value, at the grain and definition it will be re-measured at
- A named person and a date for the twelve-month re-measurement
If the second cannot be produced, the honest position is that the return will not be measurable. That may still be an acceptable reason to proceed — some investments are made on strategic grounds — but it should be stated rather than disguised as a business case.
Establishing what your organization can actually measure is a prerequisite for evaluating any of this honestly.