The AI board memo: presenting an AI decision on one page
The AI board memo is the one-page document that turns an AI initiative into a decision the board can actually make: what opportunity you are pursuing, which options you compared, what risks you are taking on, what it costs, who is accountable, and what result will prove the investment was worth it. Boards do not approve technologies; they approve decisions with owners.
Many good AI initiatives die in the boardroom, not because the idea is bad, but because it was presented as technology rather than as a business decision. This guide gives you the structure that works and the mistakes that sabotage it.
What the board actually wants
The board does not want to understand transformers. It wants answers to five questions, in business language:
- What problem are we solving and what does it cost us today?
- What options exist and why do you recommend this one?
- What can hit us: risks, compliance, reputation?
- What does it cost, in money and people, and over what horizon?
- Who is accountable and how will we know, with numbers, that it was worth it?
Any slide that does not serve one of the five questions is noise. Technical jargon does not impress; it raises the suspicion that you do not command the subject in the terms that matter.
The one-page memo structure
- The decision requested, in the first sentence: "We request approval for an 8-week pilot of X, with budget Y and a scaling decision on written criteria."
- The problem in numbers: which workflow suffers today, what it costs in time, money, or quality, who feels it.
- The options compared: 2-3 roads (for example an existing product, integration on our data, building our own) with one line of pros and cons each. Your recommendation, with the reason. The build, buy, or integrate details belong in the annex, not the memo.
- The risks and how you keep them in check: system errors and the safety net, data and confidentiality, the classification under the EU AI Act and its obligations. Risk presented without mitigation is an alarm; risk with mitigation is maturity.
- The total cost over the horizon: implementation, licenses, people, operations. One number for the pilot, an estimate for scaling, separately.
- Ownership: who owns the result, who operates, who oversees. Names, not departments.
- The result that proves it: the indicator, the target value, the measurement date, and the go/no-go criteria for the next step.
This format fits on one page precisely because the decision is small and verifiable: a pilot with criteria, not a transformation with promises.
Presenting risks without killing the project
The temptation is to minimize risks so the proposal passes. The effect is the opposite: an experienced board senses a cosmetic presentation and cuts. The strategy that works is symmetry: every named risk gets its concrete mitigation.
- "The system can be wrong" becomes: errors are possible, which is why a human stays in the loop on sensitive decisions and a quality threshold is measured weekly.
- "We have compliance obligations" becomes: we classified the system under the EU AI Act, the obligations are X, we cover them through Y, owner Z.
- "The cost can grow" becomes: cost per transaction is measured in the pilot, with a written stop threshold.
A risk you cannot honestly mitigate is a signal to rethink the scope, not to hide it in the annex.
The classic mistakes
- A technology pitch: the memo talks about models and capabilities, not about the business workflow and numbers.
- Hype promises: spectacular savings without a measurement methodology. Conservative numbers with a source beat enthusiastic estimates.
- Missing success criteria: "we will evaluate as we go" translates to "we will never know whether it was worth it".
- A diffuse decision: the memo asks for "support for the AI direction" instead of a concrete approval, with budget and deadline.
- Avoided ownership: no name next to the result. The board reads that exactly as it is: nobody wants to be accountable.
The questions the board will ask
Prepare the answers in advance, ideally in the annex:
- What are competitors doing on this workflow?
- Why now, and what happens if we wait a year?
- What data do we use and what leaves the company?
- If the pilot succeeds, what does real scaling cost?
- If it fails, what have we lost and what have we learned?
- Who helps us: what do we do in-house and what expertise do we bring from outside?
The last question deserves an honest answer about internal capacity; overestimating it is among the most expensive errors in AI projects.
Checklist before the meeting
- The requested decision is stated in the first sentence, with budget and deadline.
- The problem has numbers, not adjectives.
- The compared options are in the memo, the details in the annex.
- Every named risk has its mitigation.
- The EU AI Act classification is clarified, with an owner.
- The cost is total: implementation, licenses, people, operations.
- The proving result has an indicator, a target, and a date.
- Next to the result there is a name, not a department.
FAQ
How technical should the memo be?
As technical as precision requires, no more. Technology appears once, under options, in functional language: what it does, not how it does it. Architecture details live in the annex, for whoever asks.
Do we present one project or a complete AI strategy?
For a first approval, a project with verifiable criteria convinces more than a sweeping strategy without evidence. Strategy is built credibly on the first project's result; you can sketch the 12-month direction in one paragraph, with the current project as the first step.
What if the board has read about AI risks in the press?
Use that as an ally: name exactly the risks from the public discussion, show how they map to your case, and the concrete mitigation. A board that sees you took the risks seriously before they did gives you more freedom, not less.
Who should sign the memo?
The business owner of the result, not just the technical or innovation team. The signature tells the board who comes back in 90 days with the numbers; the same person who will own the move to production if the pilot succeeds.
How long does a good memo take to prepare?
With the homework done (options compared, validation on real cases, written criteria), one or two days of writing. If the writing takes weeks, the homework is missing, not the words; go back to the options analysis and the validation.