Building the Board Business Case for an AI Initiative: What Funders Ask For and How to Evidence It

Building the Board Business Case for an AI Initiative: What Funders Ask For and How to Evidence It

An AI proof of concept can work and still fail to get funded. The model performs, the demo lands, the sponsor is enthusiastic, and the board paper comes back with questions the team did not expect: what are we deciding, compared with what, on what evidence, and what is the most we can lose before we know? A funder is not judging whether the technology is clever. They are judging whether the request is a decision they can defend later. This guide sets out the five questions a board or innovation fund tends to ask, how to evidence each from a proof of concept, and how to show unit economics without inventing a return.

Start with the decision, not the technology

The first mistake in most AI business cases is the title. "AI-powered claims triage" describes a capability. A funder needs a decision: "Release the next stage of funding for a claims triage service covering one product line, with a review at the end of that stage." A decision has a size, a scope, an owner and an end point. A capability has none of those.

Write the request in four parts:

• What is being funded, and what is explicitly not.
• For how long, and what happens at the end of that period.
• Who is accountable for the outcome inside the organisation.
• What the funder gets in return, stated as a capability or a decision, not a promised financial figure.

A narrow, staged request is easier to approve than a transformation programme, and easier to defend later. Our reading is that boards are wary of AI requests that look open-ended, partly because the category is moving quickly and partly because many have seen pilots that never ended.

What this article is, and is not

We have written separately about what a proof of concept should deliver. This piece starts at the other end: the funder's questions first, then the evidence they require. It is not a template with numbers in it. We give no return figures, because we do not know your baseline, and a figure borrowed from someone else's project would not survive the first challenge from a finance director.

Question one: compared with what? Establish the baseline

Every benefit in a business case is a comparison, so the baseline is the foundation of the case. If you cannot describe how the work is done today, how often, by whom and with what error or delay, you cannot say what changes.

Collect the baseline before the proof of concept starts, not after. Practical elements include:

1. Volume. How many cases, transactions or decisions go through the process in a representative period?
2. Effort and time. How long does each take, and who does the work?
3. Quality. What is the current error, rework or complaint pattern?
4. Constraints. What limits capacity today: people, data, systems, rules?
5. The alternative to AI. What is the best non-AI option, such as better rules, a process fix or a simple automation? A funder will ask, and a case that has not considered it looks naive.

If a process fix would deliver most of the benefit, the board should hear that from you. Naming the alternative, and explaining why AI is still the right choice or why the two should be combined, builds more trust than leaving it out.

Question two: what is the evidence? Use the proof of concept properly

A proof of concept can produce three kinds of evidence, and each answers a different funder concern.

• Technical evidence: the system performed to a stated standard on realistic data, and you can show where it fails.
• User evidence: the people who would use it, or be affected by it, behaved in ways that support the case when they used it for real tasks.
• Operational evidence: the system can fit into the real process, systems and controls, including how errors are caught and who intervenes.

Funders often find user and operational evidence more persuasive than a headline accuracy figure, because it tells them whether adoption is plausible. Report accuracy with its conditions: which data, which scenarios, what standard, and what the system got wrong.

State the limits of the evidence in the paper itself. A test on historic cases does not show how the system behaves under live variation, and a small staff group does not show how a whole department will respond. The funder will think of these points, so say them first.

Innovify AI Labs, which we describe at the end of this article, is built around the claim that enterprise teams can run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. For a board, the practical value of that structure is comparability: when several ideas are tested against the same questions, the paper can show why one was chosen. Where you run your own proofs of concept, the same discipline applies: one set of questions, applied to each.

Question three: what does it cost to run, and how would we know? Show unit economics without inventing a return

This is the section where business cases most often go wrong. Pressure to show a return pushes teams to project a large benefit from a small test. We recommend doing something less dramatic and more defensible: show the unit economics and let the funder see how the case behaves when assumptions change.

Unit economics, not forecasts

Break the proposal into a unit that the business already understands: a case handled, a document processed, a decision made. For that unit, set out the components of cost, each labelled with where the number came from.

• Run cost of the AI component, including model usage, hosting, monitoring and any human review.
• Run cost of the surrounding process, including the people who check, correct and escalate.
• Cost and effort to build and integrate, shown separately from running costs.
• What the unit costs today, from your baseline.

Mark each figure as measured in the proof of concept, estimated by the team, or supplied by a vendor. Do not blend the three.

Treat model pricing as a moving assumption

Model usage prices change. An Anthropic newsroom item on cache pricing for its Haiku 5.5 and Sonnet 5.5 models, dated 7 October 2026, was read by our market monitoring as lowering unit costs for small and mid-tier models. That is a vendor claim, we quote none of its figures here, and the pricing relevant to your workload will depend on your usage pattern. Our reading is that the practical lesson is about method: put model cost in the case as an explicit, labelled assumption, show how the unit cost moves if it halves or doubles, and agree to re-check it at each stage gate. A case that only works at one price point is fragile.

Sensitivity beats a single number

Rather than one projected benefit, show a range and the conditions behind it. Which assumption has the largest effect on the outcome? What would have to be true for the case to fail? A funder who can see the assumptions that matter most can judge them, and that is worth more than a precise figure they cannot test. A return stated without a basis is not evidence, and a board paper should not promise outcomes it cannot show.

Question four: what could go wrong, and who is accountable?

The risk section should be written for the people who will be asked about it later. For AI initiatives in UK financial services, that usually means covering four areas.

• Conduct and customer outcomes. If the system touches customers, how are outcomes monitored and who can intervene?
• Accountability. Which senior individual owns the system and its results?
• Data and security. What data does it use, where does it sit and who can access it?
• Model behaviour. How are errors, drift and unexpected outputs detected and handled?

The Financial Conduct Authority set out its thinking on AI in a speech on 19 October 2026, reported as applying existing frameworks, including the Consumer Duty and senior-manager accountability, to AI rather than creating a separate rulebook for agents. Read the speech itself before relying on any detail: this article summarises a reported position and is not legal or compliance advice. Our reading is that a board paper which maps the initiative to existing accountability and conduct obligations will meet less resistance than one that treats AI as a category apart.

If your product or customers reach the European Union, the scope of the EU AI Act may be relevant. Article 2 describes providers and deployers outside the EU as covered where the output of the AI system is used in the Union, and the European Commission reported in an item dated 19 October 2026 that the first harmonised standard had been published and gave 2 December 2027 as the application date for high-risk systems. Whether this applies to you needs a proper legal review. Verify the position in primary sources and with your legal advisers before it goes into a paper.

Question five: how do we limit what we can lose? Stage gates

Boards approve stages more easily than programmes. Break the request into stages with an explicit decision at the end of each.

1. Proof stage: test the riskiest assumption with real users, as above.
2. Build stage: deliver a limited production version in one area, under the controls you described in the risk section.
3. Scale stage: extend only if the evidence from the previous stage meets the thresholds you set.

For each gate, write down what would lead you to proceed, change course or stop, before the work begins. State the maximum commitment at each stage, so the board knows the most it can lose before it next has a chance to decide. A case with a clear stop condition reads as more credible, not less: the team is managing a bet rather than defending a conclusion.

For innovation fund applications, the same structure helps. Funds publish their own criteria and the weightings differ, so read the guidance for the programme you are applying to and map each of its questions to a section of your case. The five questions here are our framework, not a standard form.

A one-page structure for the paper

When the evidence is in, we suggest the board paper follows this order, in one or two pages, with detail in an appendix.

• Decision requested and the stage it covers.
• Why now, in one short paragraph and without hype.
• Baseline, including the best non-AI alternative.
• Evidence, labelled as technical, user or operational, with limits stated.
• Unit economics and sensitivities, with the source of every figure.
• Risks and accountability.
• Stage gates and stop conditions.
• What you are not asking for.

The final line tells the board you have thought about scope and stops the discussion drifting into funding nobody requested.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and we design compliance in from day one. We are not a regulated financial institution, so regulatory judgements stay with you and your advisers.

If you are still generating the evidence for a case, Innovify AI Labs is our stated approach: enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. If the board has approved a stage and you are moving into build, our AI/ML development team works on taking AI products from pilot into production. Use the questions above as a test of any adviser, including us: ask what evidence they would expect to see at each gate.

FAQ

What should an AI business case for the board include?

It should include the decision requested, the baseline, the evidence from a proof of concept, unit economics with their sources, the main risks and who is accountable, and a set of stage gates with stop conditions. Lead with the decision and keep detail in an appendix. A funder should be able to see what is being asked for and what the maximum exposure is.

How do you build an AI business case without ROI figures?

Show unit economics and sensitivities instead of a single projected return. Break the proposal into a unit the business understands, set out the cost components with their sources, and show how the result changes when the main assumptions move. This is more defensible than a forecast, because the funder can test each assumption themselves.

What do boards and innovation funds ask about AI pilots?

They typically ask what decision is being requested, how the result compares with today's process, what evidence supports the claim and how strong it is, what could go wrong and who is accountable, and how the organisation can stop if the evidence disappoints. Programme-specific criteria differ, so read the guidance for any fund you are applying to.

How should we treat model cost in an AI investment case?

Treat it as an explicit assumption that is likely to change. Label the source of each figure, show how the unit cost moves if usage prices rise or fall, and agree to re-check it at each stage gate. Vendor announcements about lower unit costs are claims about their products, and your own workload may behave differently.

How is this different from a proof of concept report?

A proof of concept report describes what was tested and what happened. A business case asks someone to commit resources on the strength of that evidence. It adds the baseline, the unit economics, the risk and accountability position and a staged plan, and it is written for a decision maker rather than for the project team.

Conclusion

Funders back decisions they can defend. A strong AI business case starts with a narrow request, shows the baseline and the best alternative, reports proof of concept evidence together with its limits, treats unit costs as labelled and changeable assumptions, and sets stage gates with the right to stop. It avoids invented returns because it does not need them: the funder can see how the case behaves and judge it for themselves.

Related reading

• AI Development Services in the UK: The Stages, Sign-Off Points and Contract Terms Worth Agreeing First
• What an AI Proof of Concept Should Deliver: Scope, Real-User Evidence and the Business Case That Gets Funded
• Test Before You Build: How Enterprise Teams Validate New Product Ideas With Real Users Before a Full Build Budget

Explore next: Answers to common questions