How to make the business case for AI investment

The gap between teams that get AI investment approved and teams that do not is rarely about the quality of the underlying technology. It is about how the case is constructed. Most AI proposals fail at the executive level because they are written by engineers for engineers: they lead with capability, demonstrate technical sophistication, and assume that a compelling demo translates to a compelling business case. It does not.

Finance and executive leadership evaluate investments differently than engineering teams do. They are not primarily asking whether the technology works. They are asking whether the investment is worth making relative to other uses of the same capital and the same people. Answering the first question without answering the second produces a proposal that gets indefinitely deferred.

What a business case actually needs to establish

A business case for AI investment has to answer four questions, in roughly this order:

What problem does this solve, and what is that problem worth? This is the foundation. An AI proposal that cannot quantify the cost of the problem it solves is asking leadership to trust a magnitude estimate they cannot verify. The quantification does not have to be exact, but it has to be traceable. “We spend roughly 400 hours per month on manual document review across the compliance team, at a fully-loaded cost of $150 per hour, which is $720K annually” is a quantified problem. “We have significant manual overhead in the compliance process” is not.

What does the proposed investment cost, in total? The most common failure in AI business cases is underestimating total cost. The quoted cost is usually the platform licensing fee or API budget. The real cost includes engineering time to build the integration, ongoing maintenance and monitoring, the evaluation infrastructure required to confirm the system is working correctly, and the cost of incidents and their remediation. A proposal that quotes $60K in API costs against $720K in current manual overhead sounds like a 12:1 ROI. A proposal that quotes $60K in API costs plus $200K in engineering plus $50K in ongoing maintenance looks like roughly a 2.5:1 ROI. Both may be accurate depending on scope. The second is more likely to match reality.

When will the return materialize, and what has to be true for it to happen? AI investments have a return curve that is not linear. There is a build period (no return), a validation period (partial return as the system is tuned), and a steady-state period (full return). Proposals that project return from day one do not match how these projects actually unfold, and experienced finance teams know it. A realistic curve with labeled phases and explicit assumptions is more credible than an optimistic line.

What are the risks, and how are they managed? Every investment proposal has risks. Proposals that do not name them are not low-risk proposals; they are proposals that have not done the risk analysis. For AI investments, the canonical risks are: the technology does not perform as expected on production data, the integration is harder than scoped, the team required to maintain the system is larger than anticipated, and the ROI depends on behavior change that is harder to drive than expected. Naming these risks and describing the mitigation for each makes the proposal more credible, not less. It signals that the proposers have thought seriously about what could go wrong.

The framing trap

AI investment proposals often fall into a framing trap: they are written to justify a technology decision that has already been made, rather than to evaluate whether the investment is the right use of resources.

This shows up as proposals that lead with “we should adopt AI because AI is transforming the industry” rather than “we have a specific problem that costs X, and we have identified an AI-based solution that addresses it with a credible ROI at a manageable risk level.” The first framing invites debate about AI as a category. The second invites scrutiny of the specific investment.

The second framing is more defensible because it is falsifiable. If the problem costs X and the solution costs Y with a realistic return curve, the decision is about the numbers and the assumptions, not about beliefs about AI. Skeptical reviewers can engage with specific numbers in ways they cannot engage with strategic narratives.

Building the quantified problem statement

The quantified problem statement is where most proposals stall. The engineering team understands the technical opportunity. They often lack visibility into the operational data that quantifies the cost of the current state.

The most direct path to this data is a short scoping conversation with the operational team that owns the process in question. How many people work on this process? How many hours per week? What is the error rate, and what does an error cost in rework or downstream impact? How often does capacity constrain throughput? This conversation, properly structured, takes an hour and produces the numbers needed to anchor the business case.

If direct data is not accessible, industry benchmarks can anchor the estimate, but they need to be clearly labeled as estimates and adjusted for your context. An estimate that is honest about its basis is more credible than a precise-looking number with an unclear source.

The three scenarios that finance actually wants

Rather than a single ROI projection, finance teams generally prefer to see three scenarios: conservative, base, and optimistic. This is not pessimism. It is an acknowledgment that return on AI investments depends on assumptions that will not all prove correct, and that the investment should be worth making even in the conservative case.

The conservative scenario assumes the technology performs at the lower end of your validation data, the integration takes longer than scoped, and the behavioral change required to realize the return takes twice as long as expected. If this scenario still produces an acceptable return, the investment is durable.

The base scenario reflects your best current estimate with realistic assumptions. This is the number you will be held to.

The optimistic scenario shows what happens if the technology outperforms expectations and adoption is faster than planned. This scenario is useful for communicating upside potential without making it the basis of the investment decision.

The approval meeting

The approval meeting is where business cases succeed or fail independent of the quality of the underlying analysis. Two things matter most.

First, know which objection you will face and have the answer ready before you are asked. The most common objections to AI investment proposals are: the ROI depends on optimistic assumptions (answer: here is the conservative case), the maintenance cost is understated (answer: here is the detailed cost model including ongoing maintenance), the technology is not mature enough for production (answer: here is the validation data from our pilot and comparable deployments), and the team does not have the capacity (answer: here is the resourcing plan and the trade-off we are making to fund it).

Second, know who in the room needs to approve and what they specifically care about. A CFO asking about the investment is primarily asking about ROI and risk. A COO asking about the investment is primarily asking about operational disruption and the capacity to implement. A CTO asking about the investment is primarily asking about technical risk and integration complexity. Tailoring the emphasis of your answer to the questioner is not manipulation; it is communication.

The business case is not the end of the process. Approval starts an implementation, and the implementation will surface gaps in the original analysis. The teams that succeed at AI investment are the ones that treat the business case as a living document that gets updated as the project advances, not a document that is filed after approval. When the implementation uncovers a cost that was not in the original estimate or a return that materializes differently than projected, updating the business case and communicating the change is better than hoping no one notices the gap.

The credibility you build by being honest about variance is worth more than the credibility you lose by admitting the original estimate was off. Finance teams have seen enough projects to know that estimates are estimates. What they remember is who was straight with them when the assumptions proved wrong.