What a board should ask before approving an AI budget

The AI board questions that matter are not about the technology. Directors do not need to understand transformers any more than they need to understand database indexing to approve a CRM. They need to know which business decision the system changes, whether the data exists to make it work, what it will cost every month after launch, who will own it, and how anyone will know if it worked. A proposal that cannot answer those five in plain language is not ready, however impressive the demo.

This is a CEO guide to AI budget approval written from the other side of the table: we build these systems, and we have seen which questions, asked early, prevent the expensive kind of failure.

Why AI budget approval needs different questions

Ordinary software spend has a well-understood shape: a build cost, a licence cost, a support cost, and a delivery risk that experienced directors can judge. AI spend has two features that break the pattern. The quality of the system is uncertain until it is tested on real data, so the proposal may be describing something that cannot be built to the standard promised. And the running cost scales with usage in ways that are easy to underestimate, so a project that is cheap to build can be expensive to operate.

The questions below are designed to expose both risks before money moves. They are also useful for a CEO reviewing a proposal from a function head, or a founder reviewing a vendor's pitch.

The five AI investment questions

Question one: which decision changes?

Every useful AI system changes a decision: what gets approved, who gets called, which answer a customer receives, which document goes to a human. If the proposal cannot name the decision, it is describing a capability in search of a use. Ask who makes that decision today, how long it takes, how often it is wrong, and what a wrong decision costs. The answers give you the value ceiling. If the ceiling is low, the budget should be low.

A follow-up worth asking: what will the system be forbidden to do? A proposal that includes policy gates, human review for high-stakes cases and a shadow-mode period before autonomy has been thought through. One that promises full automation from day one has not.

Question two: what is the data readiness?

Data readiness is the difference between a system that can be built and one that cannot. The right evidence is not a data inventory; it is a benchmark. Has anyone taken a few hundred real examples, labelled them and run candidate models against them? If yes, the results are the strongest thing in the proposal. If no, approve a small discovery budget to produce them and defer the larger decision. A ten-day discovery sprint exists for exactly this purpose and costs a small fraction of a build.

Ask also about access and permission. Data that exists but cannot legally be used, or sits in a system with no API, is not ready, and the preparation work is ordinary engineering that should be priced separately.

Question three: what does it cost monthly?

Build cost is the visible number. Running cost is the one that determines whether the investment pays back. Ask for a monthly figure broken into inference (model calls), channels (per-minute voice, per-message WhatsApp), hosting and retrieval, and support. Ask for it at current volume, double volume and five times volume. Ask what assumptions about tokens per task or minutes per call sit underneath, and whether they were measured or guessed.

A proposal that shows this table has done the work. One that does not is asking the board to approve an open-ended operating expense. The components are explained in How much does AI development cost in 2026? and in the companion piece on total cost of ownership for AI systems.

Question four: who owns it?

AI systems drift. Models get deprecated, policies change, the questions customers ask change, and a system nobody owns degrades quietly until an incident makes it visible. Ownership has two parts. An operational owner in the business who reviews the system's decisions weekly at first and monthly later, and who has the authority to pause it. And an engineering arrangement, in-house or a support plan, that handles model updates, evaluation reruns and incidents with a defined response time.

Ask who will own the code, prompts and evaluation data. If the answer is the vendor, the company is renting a capability, not buying one, and the budget should be judged as an operating expense with an exit cost.

Question five: how will success be measured?

One metric, chosen before launch, with a baseline captured now. For a support agent, resolution rate per intent with reopens subtracted. For document processing, straight-through rate at an agreed accuracy. For a sales tool, a conversion or cycle-time figure the finance team already trusts. Refuse metrics the system reports on itself, and refuse "adoption" as a proxy for value. Set a review date, usually ninety days after launch, and decide now what result would lead to expansion, continuation or shutdown. The reasoning behind choosing resolution over deflection is in AI ticket deflection is the wrong metric.

A worked example

A hospital network's executive team brought a proposal for a voice agent to handle appointment calls in several languages. The first draft answered none of the five questions well: the decision was "improve patient experience", the data was "our call recordings", the cost was a build figure, the owner was IT, and the metric was call volume handled. The board deferred and funded a discovery sprint instead. The second proposal named the decision (book, reschedule or route to a person), showed a benchmark of speech and language models on real call samples in each language, priced per-minute running cost at three call volumes, named the patient-services head as owner with a support plan behind her, and set booking completion rate with a baseline as the metric. It was approved, built with a shadow-mode period, and is described in the multilingual voice agent case study.

Team and timeline

Answering the five questions properly takes two to three weeks if the data benchmark is done as part of it, and a day if it is not, which is why the benchmark is the part most proposals skip. We run the benchmark, cost model and written recommendation as Sprint Zero, a ten-day AI discovery sprint at a fixed $3,250 or ₹2,00,000, credited to the build if the answer is go. It sits within our AI product strategy service, whose output is designed to be read by a board. Ownership after launch is typically covered by a Care Plan, from $1,000 a month; all figures are on the pricing page.

Before you start: a checklist

• Require the decision the AI changes to be stated in one sentence
• Ask for benchmark results on real data, or fund a discovery sprint to get them
• Ask for a monthly running cost at three volumes with assumptions shown
• Confirm a named business owner with time allocated and authority to pause the system
• Confirm who owns the code, prompts, models and evaluation data after delivery
• Agree one success metric with a baseline captured before launch
• Fix a ninety-day review date and the decision rule for expand, continue or stop
• Ask what the system is forbidden to do and how that is enforced

Questions clients ask

• Should the board see a demo? Only after seeing the benchmark. A demo shows what the system can do on chosen inputs; a benchmark shows what it does on yours.
• How large should a first AI budget be? Large enough for discovery and a proof of concept on real data, and no larger until those have reported.
• What about regulatory risk? Ask where data is processed, what the retention terms are and whether a human reviews high-stakes outputs. Sector regulators publish expectations; India's MeitY and the NIST AI Risk Management Framework are useful references.
• Is a vendor proposal enough? Ask the vendor the same five questions. A good one will have already asked your team.
• What if the proposal is for a platform rather than a use case? Be cautious. Platforms without a first decision to change rarely earn their cost.

Related reading

AI readiness assessment: the ten questions before you build is a longer version of question two, and How to choose an AI development company: a 12-point checklist covers the vendor side of the decision.

Five questions, answered in writing, are the difference between funding an AI investment and funding an experiment that will not report back.