The gap between AI opportunity and AI approval
Many AI proposals fail to get funded despite having a legitimate use case, available technology, a capable team, and genuine organizational need. The failure is not usually a failure of the idea. It is a failure of the investment case.
A business team arrives at a budget conversation with a confident pitch: "AI can automate our claims processing and save significant time." The CFO has five questions they always ask and need answered before they can approve anything:
- What does this process currently cost us?
- What, specifically, will AI change about it?
- How much will the implementation cost, fully loaded?
- When might we see measurable impact?
- What happens if it underperforms or adoption is lower than expected?
If the business case cannot answer those five questions with numbers, the CFO cannot approve it. Not because they are being obstructive, but because those questions determine whether this is an investment or a speculation.
Your CFO does not need an AI pitch. They need an investment case.
The framing of an AI proposal changes everything about whether it gets approved. Consider the difference:
The second version is not better because it has numbers. It is better because it has visible assumptions. A CFO can challenge visible assumptions. They can push back on the adoption rate estimate, the loaded cost calculation, or the handling-time reduction expectation. That conversation is how a good business case gets stress-tested and strengthened. A business case without visible assumptions cannot be challenged, which means it also cannot be trusted.
Step 1: Start with the cost of the problem, not the cost of AI
The most common mistake in an AI business case is leading with the technology. The business case should start with the problem that technology is meant to address, because the value of an AI investment is only meaningful when compared against a credible baseline of the current state.
Before estimating any ROI, calculate what the existing process actually costs. Relevant components include: employee time on the affected workflow, labor cost at fully loaded rates (salary, benefits, overhead), external vendor or outsourcing costs, error rates and the cost of rework or correction, delays and their downstream business impact, opportunity cost of employee time spent on low-value tasks, and compliance overhead or manual audit work.
If you cannot quantify the current state, the ROI calculation has nothing defensible to compare against. The baseline is not just an input to the model; it is the evidence that a real problem exists and that it has a financial scale worth addressing.
Step 2: Quantify the opportunity without double-counting it
The typical formulas for AI value are well-understood. Labor savings: hours affected multiplied by loaded hourly cost. Error reduction: errors avoided multiplied by average cost per error. Throughput improvement: additional work completed multiplied by economic value per unit. Revenue impact: incremental revenue attributable to the initiative with clearly stated attribution logic.
The CFO-level distinction that most AI proposals miss is the difference between theoretical savings and cash-realizable savings. If AI reduces employee workload but the employees are neither removed, redeployed to revenue-generating work, nor replaced by fewer people, the theoretical labor saving does not automatically convert to cash. Capacity freed is not the same as cost eliminated.
A stronger business case identifies specifically what happens to the recovered capacity. Does it enable headcount reduction? Does it allow the team to handle higher volume without additional hires? Does it free senior staff for higher-value work that has a measurable outcome? Each of those is a different financial claim requiring a different level of evidence.
Step 3: Calculate the full cost of AI, not just the API bill
AI business cases routinely underestimate cost. The initial model or API fee is one input. The full cost of deploying, adopting, and sustaining an AI system is substantially larger.
| AI total cost of ownership components | |
|---|---|
| Initial implementation | Discovery, data preparation, architecture, UX design, engineering, integration, testing, security, compliance, deployment, change management |
| Ongoing technical costs | Model or API usage fees, cloud infrastructure, monitoring, evaluation, maintenance, retraining or fine-tuning where applicable, integration maintenance, vendor subscriptions |
| Organizational costs | Training, adoption programmes, process redesign, human review where required, governance, internal management overhead |
| Risk-adjusted costs | Expected cost of incidents, accuracy failures requiring human review at higher-than-modeled rates, integration failures, security events |
Not every AI project incurs all of these costs. The purpose of the framework is to ensure no cost category is omitted from the business case rather than to imply a standard cost structure. Source: illustrative framework based on common enterprise AI deployment components.
Step 4: Model three scenarios, not one ROI number
A business case built on a single ROI projection is a business case built on a single set of assumptions. CFOs who have approved technology investments before have usually seen the single projection miss. The antidote is scenario modeling.
| Variable | Conservative | Base | Upside |
|---|---|---|---|
| User adoption rate | Lower than planned | As expected | Above expected |
| Accuracy / task performance | More human review needed | As modeled | Higher automation rate |
| Implementation cost | Higher (scope adds, delays) | As scoped | At or under budget |
| Time to value | Longer than planned | As projected | Faster than projected |
| Annual operating cost | Higher usage, more oversight | As modeled | Stable or lower |
| Annual net benefit | [Insert calculation] | [Insert calculation] | [Insert calculation] |
| Payback period | [Longer] | [Base estimate] | [Shorter] |
Populate with actual project assumptions. The conservative case should be the planning floor, not the aspirational ceiling. The upside case should be labeled clearly as a non-planning scenario. Payback period formula: Total initial investment divided by annual net benefit equals years to break even.
The purpose of scenario modeling is not to triangulate a "real" number. It is to show decision-makers the range of plausible outcomes and the conditions that drive each one. A CFO who can see the conservative case and still justify the investment is a CFO who has made an informed decision. That is a much stronger basis for an approval than a single projection that later proves optimistic.
Step 5: Model the adoption gap, the business case mistake everyone makes
An AI system that demonstrates a 30% efficiency improvement in testing does not produce a 30% efficiency improvement in production unless employees actually use it at the expected rate, in the expected way, on the expected tasks. The chain from AI capability to realized financial value runs through multiple steps: AI capability leads to tool adoption which enables workflow change which drives operational improvement which produces financial impact.
Most business cases model the first step and the last step and assume everything in between. Deloitte's 2025 survey of 1,854 executives found that ROI capture is hardest when AI is introduced alongside broader transformation efforts, because it becomes impossible to isolate AI's contribution. A business case should separately model the adoption assumption, the process redesign required to capture the benefit, and the management investment needed to sustain the change.
The practical test: if adoption is 50% lower than projected, does the financial case still exceed the investment? If not, the business case rests heavily on an adoption assumption that should be treated as a risk, not a given.
Step 6: Name the risks before the CFO finds them
A sophisticated AI business case does not only model the upside. It explicitly names the conditions that could cause the initiative to fail or underperform, and what the financial consequence would be.
Common risk factors to address: lower-than-expected accuracy requiring more human review than modeled; lower employee adoption due to workflow friction or trust; integration failures that delay production deployment; usage costs that exceed projections at higher volumes; regulatory or compliance requirements that add implementation scope; model degradation over time requiring retraining investment; vendor dependency risk; data quality issues that limit the AI's performance on real production data rather than clean training data.
For each material risk, a business case should state whether the risk is managed (mitigated before deployment), transferred (contractual protection), accepted (within tolerance given expected return), or monitored (tracked and acted upon if it materializes). This turns the risk section from a disclaimer into a decision framework.
Step 7: Phase the investment, ask for evidence not transformation
A request for a large AI budget upfront is harder to approve than a request for a defined first step that generates evidence. This is not a presentation strategy: it is the correct way to manage the financial risk of a technology investment where outcomes depend on data, adoption, and integration variables that are unknown until production.
This structure turns the proposal into: "Approve the next evidence-generating step" rather than "Approve the AI transformation." A phased structure also establishes, before the investment is made, the conditions under which the organization will stop investing if the evidence does not support continuing. That is one of the most important elements any financial decision-maker needs and one of the elements most AI proposals omit.
Build vs buy vs development partner: a cost and capability question
Before estimating implementation cost, the business case should clarify whether the initiative involves configuring an existing SaaS AI platform, using a third-party AI API with internal engineering, building on an AI-enabled enterprise platform, building internally from scratch, or engaging an external AI development partner or consultant. The choice affects cost structure, time to value, differentiation, and data control.
A general principle: the more the value of the AI system depends on proprietary data, unique workflows, or integration with existing systems, the more likely custom development or specialist partnership is worth considering. The more the value comes from a commodity AI capability (summarization, classification, search) that does not require deep customization, the more likely an existing platform or API is sufficient. This decision belongs in the business case because it is a major driver of both implementation cost and capability ceiling.
The cost of doing nothing: make it quantifiable, not speculative
Many AI business cases include a section on competitive risk or industry transformation without quantifying either. A CFO's response to "competitors are investing in AI" is: "What does that cost us specifically, and when?"
The defensible version of the cost-of-inaction argument is grounded in current-state cost, not future-state speculation. If the business problem has a quantified annual cost today, that cost continues to accrue every year the organization does not address it. That is the most conservative and credible version of "cost of doing nothing." Strategic arguments about competitive positioning are supplementary, not substitutes for a financial baseline.