The Questions a Board Asks Before Approving AI Spend

The tone of these conversations has changed. Two years ago an AI proposal could be carried by showing what the technology could do, because the capability was the news. That period is over. Boards have now seen the capability, several of them have funded something that did not land, and the questions have become considerably more ordinary.

That is good news for well-constructed proposals and bad news for demonstrations. Here is what actually gets asked.

What does this cost when it works?

Not the project cost. The running cost at full volume, which is the number most proposals omit because it is genuinely harder to estimate.

Usage-based pricing means the cost scales with success, which is an unfamiliar shape for a software business case. A board that has been through one surprise invoice will ask for the cost per transaction, the assumed volume, and what happens if volume is triple the estimate. Have a ceiling in the answer — a hard spend cap configured at the provider, not a promise to monitor it.

What happens when it is wrong?

Every board now knows these systems produce confident errors. The question is not whether that will happen but what the consequence is when it does.

The answer has to be specific to the use case. If the system drafts something a person approves, the exposure is low and the argument is easy. If it makes a decision that reaches a customer without review, the exposure is the decision, and the board will want to know the volume, the error rate, and the remediation path.

The credible version of this answer includes the limits designed into the system: what it is allowed to do on its own, what requires approval, and what it refuses. A proposal that says the system is very accurate is weaker than one that says what happens on the occasions it is not.

Can we explain a decision afterwards?

In a regulated sector this is usually the decisive question, and it is asked in a particular form: if a regulator, a customer or a court asks why this outcome occurred, can we produce an answer that stands up?

An unrecorded system cannot. This is why audit logging is not a phase-two item — a system that cannot reconstruct what it saw and why it acted is one the organisation will eventually have to switch off rather than defend, and the board would rather know that now.

Where does our data go, and under what terms?

Expect this to be specific. Which data, to which provider, in which jurisdiction, retained for how long, and used for what. Whether the contract permits training on it. What happens to the data when the contract ends.

For many organisations the answer that unblocks the conversation is that the sensitive data does not leave at all. Open-weight models have made self-hosting practical enough that this is now a design choice rather than a compromise, and it removes a class of objection entirely rather than mitigating it.

What is the fallback?

Two versions of this. If the provider has an outage, what happens to the business process — does it queue, degrade, or stop? And if this vendor becomes unacceptable, commercially or otherwise, how long does it take to move?

The second question is really about concentration risk, and the reassuring answer is architectural: the model sits behind an interface, the prompts and evaluation sets are ours, and switching is a matter of weeks rather than a rebuild.

Who is accountable?

Not which team is delivering. Which executive owns the outcome.

Boards have learned that AI projects with only a technology owner stall, because the decisions that unblock them — changing a process, retraining a team, amending a policy — are not technology decisions. A proposal that names an accountable business owner gets a materially easier hearing than one that does not.

What does success look like, in numbers we already track?

The strongest proposals state a baseline measured before the project, a target in an existing operational metric, and a date at which the comparison will be made. The weakest describe capabilities.

If the current figure is not known, that is worth saying plainly — and measuring it is worth doing before asking for the money, because without it there is no way to demonstrate the result afterwards, which means there is no way to justify the next request either.

The underlying shift

The board is no longer evaluating a technology. It is evaluating an operational change that happens to involve one, against the same criteria it applies to any other: cost at scale, exposure when it fails, auditability, dependency, accountability, and a measurable outcome.

Proposals written that way get funded. Proposals built around a demonstration increasingly do not, and the reason is not scepticism about AI. It is that everyone has now seen a demonstration.