Answer the three real questions
Whatever is asked out loud, a board is deciding on cost, risk, and verifiability. Technical explanation is not persuasive to that audience, and time spent on how models work is time not spent on what they need to approve.
Lead with the workflow, not the technology
“We spend roughly this much on this recurring process; this is the step we are changing” is a business case. “We are implementing AI” is a category. Starting from the expensive workflow makes the proposal legible to people who don’t care what a model is.
Boards fund a solved problem with a number attached. They don’t fund a technology with ambition attached.
State the failure mode plainly
Say what happens when it is wrong, who catches it, and what it costs. A proposal that claims no meaningful downside reads as naive; one that names the escalation and review path reads as considered.
Bring the stopping criteria
Define what result means continue and what means stop, in advance. That single slide is what separates a funded experiment from a pilot that runs forever, and boards recognise the difference.
Include the whole cost
Model spend is the smallest line. Review time, knowledge maintenance, and the escalation load are the real budget — presenting only the API bill guarantees an awkward conversation later, as the running costs are mostly staff time.
Ask for a small, bounded commitment
Two weeks and a defined question is easy to approve and easy to conclude. A transformation programme requires a belief; a bounded proof of concept only requires a decision.