The business case that survives second line
Most AI business cases are built on hours saved and die the moment somebody prices the controls. The number that matters is the one nobody put in the model.
The standard AI business case has three lines: a headcount-hours figure, an adoption curve, and a licence cost. It clears the investment committee comfortably. It then meets the first serious risk review and loses roughly forty per cent of its value in an afternoon, because the controls the system actually needs were never in the model.
This is not a failure of optimism. It is a failure of scope.
What gets left out
The build is the cheap part, and everyone knows it. What does not appear in the case is the run: the evaluation suite and the person who maintains it, the monitoring, the annual revalidation, the second-line hours consumed by review, the incident process, the retention and the storage that the retention implies.
Individually none of these is large. Together they are frequently the majority of the five-year cost, and they arrive as a surprise because the innovation budget that funded the build has no line for any of them.
A business case that ends at go-live is not a business case. It is a construction estimate.
The tiering shortcut
The reason this matters commercially rather than just procedurally is that control cost is not uniform — it scales with risk tier. A use case that can be honestly tiered low carries a fraction of the assurance overhead of one that cannot.
Which means the single highest-leverage move in most business cases is not squeezing the licence cost. It is designing the use case so that it sits in a lower tier: keeping a human decision in the loop where the decision is consequential, narrowing scope so the failure mode is recoverable, choosing not to touch the data that drags the whole thing into a higher regime.
That is an architecture decision with a price attached, and it is almost always made before anyone thinks to price it.
Writing the case backwards
The version that survives is built in the opposite order. Start from the tier the use case will land in. Take the control set that tier requires as a given cost, not a negotiation. Add the run-rate for the whole life of the system, with a named owner and a budget line. Then see what value is left.
Sometimes the answer is that the case does not work — and finding that out in a planning cycle is enormously cheaper than finding it out after eighteen months of build. More often the case still works, but the shape has changed: smaller scope, tighter boundary, a slower rollout that clears review rather than a fast one that stalls in it.
The number to lead with
If you present one figure, make it total cost of ownership over five years including assurance, against benefit that has been discounted for adoption you can evidence. It is a less exciting number than the one on the first slide. It is also the only one that will still be true in a year, which is the entire point of putting it in front of people who have to fund it.