What belongs in an AI roadmap for the boardroom

A roadmap for a board is not a shortened technical plan. It is a different document with a different job, and treating it as a summary of the real plan is why so many of them get a polite nod and no decision.

The board does not need to understand how the thing works. It needs to decide whether to fund it, who is accountable, and what happens if it fails. Everything in the document should serve one of those three, and anything that does not is costing you attention you will need later.

The three questions a board will actually ask

Before the structure, the questions. In our experience these come up in almost every session, usually in this order:

What does this cost us in total, including the parts that are not invoiced? Not the licence fee. The internal hours, the process change, the manager's attention for six months.

Who is accountable when it goes wrong? Boards are considerably more interested in this than in accuracy percentages, and they are right to be.

How do we stop? A board that cannot see the exit will not approve the entrance. Making the stopping condition explicit is what makes approval easy, not what makes it harder.

If your document answers those three clearly, the rest is detail. If it does not, no amount of detail rescues it.

Someone presenting a chart. Every number on the slide must be one you can defend when asked.

The table of contents we deliver

This is the actual structure, not an idealised one. Roughly eight to twelve pages, which is short on purpose.

1. The decision being asked for, on page one. One paragraph naming the amount, the period, and the owner. Not a summary of the analysis. The board should be able to read page one and know exactly what it is being asked to approve.

2. Where the business stands now. Two or three findings from the assessment, phrased as facts about this company rather than statements about AI. "Quoting takes an average of four days, of which three are waiting" is useful. "AI adoption in the sector is accelerating" is not.

3. What we are betting on, and what we are deliberately not doing. Both halves. The exclusions do more work than the inclusions, because they are what tells a board that a choice was actually made.

4. The first item, in detail. Only the first one. What it is, who owns it, what proof is required by which date, and what that proof would cost to obtain. This is the section that gets read most carefully.

5. Everything after the first item, in one page. Deliberately thin. Committing detail to items three and four of a roadmap is a signal that the sequencing has not been thought about, because item two's outcome should change what item three is.

6. What it costs, split into invoiced and not invoiced. The second column is the one that builds trust. Every board has been burned by a project whose real cost was internal time nobody counted.

7. What would make us stop. Written before starting, agreed in the room. This is the section people want to cut and the one that most often saves the project, because it converts an awkward conversation in month five into a decision that was already made in month one.

8. Risks, including the regulatory ones, in plain language. Which risk class the application falls into under the AI Act and what that means practically, referencing the risk-tier decision tree rather than reproducing the whole regulation. Plus who is liable if it goes wrong, which is covered separately in Wie is aansprakelijk.

A meeting in progress. The document exists to produce one decision, not to inform.

The same content, two audiences

The right-hand column is not a simplification of the left. Several rows contain information the technical plan does not have at all, which is why summarising the technical document does not produce the board document.

What we deliberately leave out

The omissions are as deliberate as the contents, and they are usually where a technical plan goes wrong when reused for a board.

Model architecture and vendor comparison tables. If the board is choosing between vendors, something has gone wrong upstream. That is the owner's job to have done.

Accuracy percentages without a business consequence attached. "Ninety-two percent accurate" means nothing to a board. "Wrong in roughly one in twelve cases, which is why a person reviews every rejection before it is sent" means something.

A benefits case built on industry averages. If the numbers come from a vendor's white paper rather than from your own operation, a board will discount the entire document, and it will be right to. Build the case on your own figures, as described in De ROI van AI berekenen op je eigen cijfers.

Anything past twelve months in specific terms. You do not know, and pretending otherwise costs credibility that you need for the first item.

The one-sentence test

Before presenting, try to state the document in one sentence of this shape: "We want to spend X over Y months on Z, owned by name, and we will stop if condition."

If you cannot fill in all five slots from your own document, the document is not finished, regardless of how many pages it has. In practice the slot that is most often empty is the last one.

About this page

The eight-section structure is the actual table of contents Radical delivers, written out rather than kept as an internal template. The three board questions are drawn from our own sessions. Cross-references point to the earlier pieces on risk classification, liability and own-figures ROI on this site rather than restating them. Written by Radical's own team; no client data was used.