The demo took ten minutes. A document appeared in seconds, the supplier answered every question and the room could already picture the time being saved. Then came the request for budget.
A demo proves that something can happen. A business case must prove that it should.
UK government AI adoption research, based on 3,500 business interviews, found that one in six businesses was using AI. Among adopters, 85% were using natural-language processing or text generation. Most reported some productivity improvement, yet only around one in eight had seen revenue increase. That gap is why boards need to look past speed and ask where the value will actually show up.
The government’s AI Playbook is written for the public sector, but its core disciplines travel well: understand what AI can and cannot do, buy carefully, protect data and design governance before deployment.
A specific business problem
The proposal should begin with the work that needs to improve. It should describe the current time, cost, delay or quality problem and identify the people affected.
“Using AI” is not an objective. Reducing the time needed to review a defined type of document, while maintaining an agreed level of accuracy, is something that can be assessed.
A credible measure of value
Ask how success will be measured and what the current baseline is. A percentage improvement means little without knowing the starting point, the volume of work and whether saved time can be used elsewhere.
The business case should also state when benefits are expected and who is responsible for achieving them. Buying a tool does not create value on its own.
Evidence that the data is usable
AI systems depend on accessible, relevant and sufficiently accurate information. The proposal should explain which data is needed, who controls it, where quality problems exist and whether its use is lawful.
If several months of data work are required before the tool can operate, that effort belongs in the cost and timetable.
The full cost of live operation
Include licences, usage charges, integration, data preparation, security testing, staff training, monitoring and ongoing review. Costs can change significantly as use grows, particularly where suppliers charge by transaction or volume.
The board should see a range rather than a single optimistic number, together with the assumptions behind it.
A named owner
Every AI system needs a business owner accountable for its purpose, performance and safe use. Technology teams can support delivery, but they should not be left to decide whether the output is acceptable for the business process.
The proposal should also say who can pause the system and who deals with complaints, errors and unexpected outcomes.
Clear safeguards and human decisions
Leaders should know what information users can enter, which outputs require human review and where AI must not make a decision alone. Controls should match the possible harm, not the excitement around the tool.
For higher-impact uses, the business case should include testing for accuracy, bias, security and privacy before live use.
A pilot with an exit decision
A pilot should answer defined questions. At its end, leaders should be able to proceed, change the approach or stop. Agree those decision points and minimum evidence before the pilot begins.
This avoids a common pattern in which a temporary experiment becomes a permanent service without formal approval.
The decision the board is making
A sound paper makes the approval explicit: the amount being committed, the limits of the work, the accountable owner and the evidence required before wider use. It should include the option to wait if the data, process or safeguards are not ready.
Independent challenge is useful when a supplier has shaped the business case or internal enthusiasm has moved ahead of the evidence. The goal is not to slow useful work. It is to approve the right work for clear reasons.