The Three Questions Every Board Should Ask Before Funding AI

The approval is the easy part

Boards are good at approving AI budgets. What they're less good at is asking the questions that make the approval meaningful. A line item gets presented, it's framed as competitive necessity, someone mentions what a rival is doing, and the number gets waved through. That's not governance. That's momentum.

The problem isn't that boards are careless. It's that AI proposals are usually pitched in language that resists scrutiny — "transformation," "efficiency gains," "future-proofing." None of that is falsifiable. You can't hold anyone to it in twelve months because it was never specific enough to fail.

There are three questions that cut through this. They're not technical questions. You don't need to understand a model architecture to ask them. You need to understand how decisions get made in your organisation, and be willing to insist on specificity before money moves.

Question one: what decision gets better, and who makes it today?

Every AI investment should be traceable to a decision that gets made faster, more accurately, or more cheaply. Not a process — a decision. "We'll have better data" is not an answer. "The operations manager currently takes two days to approve a reorder because she's checking three systems by hand, and this collapses that to an hour" is an answer.

If the person presenting the budget can't name the decision, the decision-maker, and the current cost of that decision being slow or wrong, they haven't done the diagnostic work yet. They've found a tool they like and are working backwards to justify it. That's the single most common failure mode in AI spending, and it's entirely preventable at the approval stage if someone in the room insists on this level of specificity.

Ask it plainly: six months after this is live, which named person is doing their job differently, and how will we know?

Question two: what does this depend on that we don't currently control?

AI systems are only as good as what feeds them. If your CRM, your finance system and your operations tools don't agree on basic facts — customer status, inventory levels, project stage — no model sitting on top of that mess will produce something trustworthy. It will produce confident-sounding nonsense faster than your team could have produced uncertain-sounding nonsense manually.

This is where most proposals quietly fall apart. The pitch focuses on the shiny layer — the chatbot, the dashboard, the automation — and says nothing about the data underneath it. Ask directly: which systems does this draw from, do they currently agree with each other, and if not, is fixing that in scope or is it being assumed away?

If the answer is vague, you're being asked to fund a demo, not a system. Demos work on clean, curated data. Production doesn't get to choose its inputs.

This also tells you something about sequencing. If the honest answer is "our data doesn't agree across three systems," that's not a reason to shelve the AI project — it's the actual first project. Unifying the data is usually cheaper and faster than people expect, and it's the dependency everything else sits on. Approving the exciting layer before the dependency is fixed is how six-figure budgets produce nothing anyone trusts.

Question three: who owns this once the build is finished?

The build is the easy half. Every AI project has a quiet second phase where the system works technically and nobody uses it, because nobody retrained their habits, nobody was told it existed in terms of their actual job, or the person who championed it has moved on to the next initiative.

A board approving a budget should ask who owns adoption, specifically, and what happens in the weeks after launch. Not "IT will manage it" — a named owner, with time allocated, who is accountable for usage rates, not just uptime. If that person doesn't exist yet, the project isn't ready to be funded. It's ready to be funded once that gap is closed.

This is also where you should ask about training — not whether training is planned, but whether it's role-specific. Generic AI training teaches people a tool. Good training teaches people how their actual workflow changes. If the proposal has a training line that says "onboarding session," singular, for an entire department, that's a budget for a demo day, not for adoption.

What good answers sound like

A proposal that survives all three questions sounds different from one that doesn't. It names a decision and a decision-maker. It's honest about which systems don't currently agree and treats that as the first deliverable, not a footnote. It has a named owner for adoption and a plan for what happens in week eight, not just week one.

Across six industries and a wide range of engagement sizes, we've consistently seen automation work pay for itself within two to three months once it's actually adopted — and consistently seen the ones that don't hit that mark trace back to a gap in one of these three areas, not to the technology itself. The technology is rarely the problem. The diagnostic discipline before the spend is.

Your job on the board isn't to evaluate the model. It's to insist that someone else has already done the harder work of answering these three questions before you're asked to sign off. If they haven't, the budget isn't ready — no matter how good the deck looks.