How do you build the business case for an AI project?

The AI business case is a structured estimate of an AI project's costs and benefits, built to survive the CFO's questions before the technical acceptance test. The classic return-on-investment calculation breaks down on this terrain because it treats AI like a fixed-cost software project, while the real cost varies with actual usage, with the quality of the starting data and with how much human supervision remains necessary after go-live. The distinctive method is building three explicit scenarios (conservative, realistic, optimistic) instead of a single number no decision maker really believes, and listing the line items that improvised business cases forget: per-token cost and its variability (see AI tokenomics), data preparation work, residual human oversight, prompt and evaluation maintenance, and the cost of organizational change. A pilot that never reaches production, in this framework, is not automatically money lost.

See also: AI tokenomics · The economics of AI tokens: what inference really costs, how it is measured (cost per million tokens) and how it is kept under control.

Why the classic calculation breaks down

A traditional software project has a development cost that gets amortized and a nearly flat operating cost. An AI system instead has a variable and unpredictable cost component: token consumption grows with real usage, which is hard to estimate before launch, and model prices shift over time. On top of that sits a line item that rarely shows up in initial spreadsheets, namely data preparation and cleaning work, which often absorbs more time than building the model itself. It is also worth accounting for the fact that automation rarely removes human supervision entirely: it shifts people's work from execution to quality control, and that control carries a recurring cost. Finally, the prompts and automated evaluations that measure whether the system still works well require ongoing maintenance, not a one-off effort, because models change versions and system behavior shifts with them.

The three-scenario method

Instead of presenting a single-point return estimate, which anyone who has watched a project slip knows is little more than a wish, the method builds three parallel columns with the same cost and benefit line items, varied against explicit and stated assumptions: user adoption, accepted error rate, real usage volume. The conservative scenario assumes slow adoption, high oversight and delayed benefits; the realistic one uses pilot data, when it exists; the optimistic one assumes adoption and learning curves play out as expected. The useful decision is not "does AI pay off or not", but whether the project holds up even in the conservative scenario, and how wide the gap is between the realistic and optimistic scenarios: a narrow gap signals a solid business case, a wide one signals the need for more data before committing budget.

The pilot that produces an asset, not just a result

A pilot that never reaches production can still generate reusable value: clean, documented data that will serve the next attempt, a use case clarified with precision (what the system needs to do, rather than the vague original idea), internal skills that stay with the company even if that specific project stops. This is not a way to excuse every failure: a pilot that produces none of these three assets, and never reaches production, is simply a failed pilot. But treating every interrupted pilot as pure waste pushes teams to force unready systems into production rather than admit a sunk cost, which is worse than the interrupted pilot itself.

Why it matters for decision makers

Whoever signs off on an AI project's budget wants to know two things: what it costs if things go wrong, and what remains in the company if the project never reaches steady state. A business case with three scenarios and the hidden cost items listed in a column answers both, and shifts the conversation from an optimistic pitch to an informed risk decision, the same discipline FinOps applies to cloud spend. The business case does change with what is being funded, though: proof of concept, prototype and MVP are not synonyms, and that is the confusion you pay for once the budget is on the table.