Enterprise AI Business Case: How to Get Every Stakeholder to Yes
A CFO-ready financial model is only one piece. A complete enterprise AI business case needs to survive five different decision-makers, each asking a different question, in the same meeting.
Most AI investment proposals fail for a reason that has nothing to do with the technology. The case was built for one audience and then walked into a room full of five different ones. The CFO wants a number. The CIO wants an architecture diagram. The board wants a competitive framing. Legal wants a risk register. The business unit sponsor wants to know who is responsible when it goes wrong.
Write the case for the CFO and you lose the board. Write it for the board and you lose finance. Write it for the CIO and you lose everyone who actually makes the funding decision. The only way to get enterprise AI approved is to write one document that speaks to all five stakeholders without alienating any of them.
This is how to do that.
The Five Stakeholders and What Each One Actually Needs
Before building any financial model, map the room. Every enterprise AI investment decision involves at least five distinct perspectives, and each one has a primary concern and a secondary fear.
Competitive position and strategic relevance. Fear: approving something that looks embarrassing in two years.
Return on capital and cost of delay. Fear: approving assumptions that can't be defended to auditors.
Integration complexity and technical debt. Fear: owning a system no one can maintain.
Headcount impact and workflow disruption. Fear: being responsible for something that doesn't work.
Liability exposure and regulatory compliance. Fear: a post-deployment audit that surfaces something that was in the original deck.
Most cases are written for the CFO and presented to all five. That is why they fail. The financial model is necessary but it is not sufficient. It has to sit inside a larger structure that addresses each stakeholder's primary concern without creating new fears for the others.
Layer One: The Strategic Narrative
The strategic narrative is not a market overview. It is a one-paragraph answer to the question: what changes if we don't do this, and by when?
That framing has two parts. The opportunity: what becomes possible. And the cost of delay: what competitors or operational pressure makes inaction increasingly expensive. Boards and CEOs respond to the second part more than the first. Approving a new capability feels optional. Approving protection against a known threat feels necessary.
Our contract review process takes an average of 11 days per agreement. Peer firms using AI-assisted review have published cycle times of three to four days. At our current volume of 800 contracts per year, the gap costs approximately 14,000 attorney hours annually. The business case covers eliminating that gap.
Notice what that paragraph does not do. It does not say "AI is transforming the legal industry." It does not cite market research about AI adoption rates. It states a specific, measurable problem, anchors it to a competitive reference point, and quantifies the current cost. Everything else follows from that.
The strategic narrative should be no more than two paragraphs. If it needs more, the problem is not specific enough.
Layer Two: The Financial Model
Finance will build its own model from your assumptions. Your job is to supply assumptions that can survive audit, not a model that happens to produce the number you want.
Three components are non-negotiable.
A measured baseline, not an assumed one
The single most common reason AI business cases fail finance review is that the baseline was estimated rather than measured. If the case says "we spend approximately X on this process," finance will reduce that estimate by 30 percent and your ROI disappears. If the case says "we measured X over 12 weeks using three time studies," that number is defensible.
Measuring the baseline is also the most valuable thing you can do before a pilot. It forces specificity about what the AI is actually replacing, and it gives you the denominator for every ROI calculation that follows.
A pilot-derived improvement estimate
Vendor accuracy claims are not evidence. Independent analyst forecasts are not evidence. A four-week proof of concept run on your data, on your process, with your team, is evidence. Even a narrow pilot covering 10 percent of the workflow produces defensible numbers that no vendor claim can match.
If you don't have pilot data yet, frame the business case in two stages: initial funding for a time-boxed pilot, followed by a go/no-go on full deployment based on measured results. Finance respects staged investment far more than a single large ask with unvalidated assumptions.
Total cost of ownership, not just licensing
License fees are typically 30 to 50 percent of the real cost of an enterprise AI deployment. The full TCO includes integration and API development, data preparation and cleaning, security and compliance review, change management and training, and ongoing monitoring and evaluation. If your business case only shows licensing, finance will add these themselves, usually with a higher estimate than the real number.
Build this table with real estimates from your IT and procurement teams before the case goes to finance. When finance asks, and they will ask, you want to be able to say "we built that in" rather than "we'll need to add that."
Layer Three: The Risk Register
Legal and risk functions are not trying to kill your project. They are trying to protect the organization from surprises that were foreseeable in advance. A business case without a risk register signals that the proposer hasn't thought about failure, which is the fastest way to lose legal's support.
The risk register should cover five categories. For each one, rate severity and document the mitigation that is already in plan.
| Risk Category | Severity | Mitigation |
|---|---|---|
| Model accuracy below threshold | High | Human review gate on all low-confidence outputs; pilot success criteria defined before deployment |
| Data residency and privacy | High | Vendor DPA reviewed; no PII sent to model unless encryption and data processing agreement confirmed |
| Regulatory compliance (EU AI Act, sector rules) | Med | Legal review of use case classification; documentation of human oversight protocol |
| Vendor dependency and model deprecation | Med | Contractual SLA on model version stability; abstraction layer in integration design |
| Team adoption failure | Low | Business unit sponsor identified; change management budget included in TCO; 90-day adoption KPI tracked |
The goal is not to eliminate every risk. The goal is to show that each risk has been identified, severity-rated, and assigned a specific mitigation that is already budgeted or in progress. Legal can work with that. What they can't work with is silence.
If your use case touches hiring, credit scoring, critical infrastructure, law enforcement, or biometric identification, it may fall under EU AI Act high-risk or prohibited practice classifications. Provider obligations carry penalties up to 3% of global annual revenue. Prohibited practice violations carry penalties up to 7%. Flag classification early with legal, not at the vendor contract stage.
Layer Four: The CIO Section
The CIO is not primarily worried about whether AI works. They are worried about who owns the integration, how it connects to existing systems, and what happens to the team when the vendor relationship changes.
Three questions need answers before the CIO can say yes.
Where does this connect?
Map the integration points: which systems send data to the AI, which systems receive outputs, what the API call volume looks like at scale, and whether the current infrastructure can handle it. A one-page architecture diagram with labeled integration points is worth more to a CIO than three paragraphs of prose.
Who owns it in 18 months?
Enterprise AI projects that lack a named internal owner after the vendor implementation period ends are the ones that drift into unsupported technical debt. The business case should name the team responsible for ongoing maintenance and model evaluation, even if the staffing plan is still forming. "To be determined" is not an answer that satisfies a CIO who has inherited abandoned systems before.
What is the exit strategy?
This sounds pessimistic. CIOs ask it because they have been through vendor relationships that ended badly. The answer doesn't need to be elaborate: which data is owned by the customer, what export format it comes in, and how long implementation would take on an alternative platform. Vendors who refuse to answer this question clearly are vendors to be cautious of.
Layer Five: The Business Unit Section
The business unit sponsor has the hardest job in this conversation. They are accountable for results in a domain they understand deeply, and they are being asked to stake their credibility on a technology they may not understand at all. The business case has to give them something concrete to stand behind.
Two things matter here above all others.
Who gets time back. Not "the team will be more productive." Name the role, estimate the hours per week, and describe what they do with that time. "Each contract reviewer saves four to six hours per week on first-pass review, which they redirect to negotiation and client contact" is something a business unit head can defend. "Productivity improvements of 20-30 percent" is not.
What the failure condition looks like and who calls it. The business unit sponsor needs to know in advance: if the pilot doesn't hit the success criteria, who makes the call to stop, and what happens to the investment already made. Sponsors who don't know the answer to this are sponsors who will avoid being associated with the project when it gets difficult.
Putting It Together: The One-Document Structure
The five-layer case doesn't need to be five separate documents. It needs to be one document with five clearly labeled sections, each written at a level of detail appropriate for its audience. Executives read in sequence and stop when they find what they need. Each section should be self-contained enough to stand alone in a follow-up conversation with that stakeholder.
1. Executive Summary (1 page): Problem, proposed solution, financial summary (cost, expected return, payback period), and recommendation. Written for the board and CEO.
2. Strategic Context (1-2 pages): Problem definition with measured baseline, competitive framing, cost of delay. Written for the board and business unit.
3. Financial Model (2-3 pages): TCO breakdown, benefit quantification from pilot or comparable deployment, NPV at 12 and 24 months, key assumptions listed explicitly. Written for the CFO.
4. Technical Architecture (1 page): Integration map, ownership model, exit provisions. Written for the CIO.
5. Risk Register (1 page): Five-category risk table with severity and mitigation. Written for legal and risk.
6. Success Criteria and Governance (1 page): Named owner, pilot or rollout KPIs with thresholds, review cadence, go/no-go trigger. Written for the business unit sponsor and CFO.
The Pre-Submission Checklist
Before the document goes to any stakeholder, run through this list. A no on any item is a reason the case will come back with questions rather than a decision.
- Baseline is measured, not assumed, and the measurement methodology is documented
- Financial model uses pilot data or a comparable deployment reference, not vendor claims
- TCO includes integration, data preparation, change management, and monitoring costs
- Risk register covers data privacy, model accuracy, regulatory classification, vendor dependency, and adoption
- EU AI Act use case classification has been reviewed with legal
- Named internal owner identified for post-implementation maintenance
- Integration architecture reviewed by CIO or technical lead
- Business unit sponsor can describe the failure condition and who calls it
- Success criteria are measurable thresholds, not directional goals
- Review cadence and go/no-go trigger are defined in advance
What Happens After Approval
Approval is not the goal. Approval is the beginning. The business case that gets funded creates an obligation: you stated specific assumptions, specific success criteria, and specific owners. You now have to report against them.
The most valuable thing you can do in the first 30 days after approval is send a one-page status note to every stakeholder who attended the original review. Not an update on what you've been doing. An update on the three metrics you said you would track, and where each one stands against the baseline you measured.
Stakeholders who receive that note become advocates. Stakeholders who don't receive it eventually become skeptics who remember the last AI project that went quiet after funding.
The complete framework for structuring an enterprise AI pilot, including the go/no-go decision gate, is in The 90-Day AI Pilot Playbook. For the financial modeling detail, including NPV and TCO templates, see How to Build an AI Business Case Your CFO Will Actually Fund. For how to identify and prioritize which use case to build the case around, see AI Use Case Prioritization.
Need help building the business case for a specific AI initiative? I work with enterprise teams from problem definition through stakeholder approval.
Book a working session