What your board actually needs to know about AI.

Why do AI board sessions go wrong?

Because they are built backwards. Someone opens with model families and adoption curves, twenty minutes disappear into vocabulary, and the meeting ends with the only question that mattered still unasked: what are we being asked to decide?

We have sat in these rooms since 1999, through every wave that was going to change everything. The boards that came through each one well were never the most technical. They were the ones that insisted on business language and a clear ask.

What are the four questions?

• Opportunity. Is there real value here for us, or are we reacting to noise? What specifically becomes better, for which customers, at what scale?
• Risk. What could go wrong, how likely is it, and can we live with it? Who owns each risk we are accepting?
• Consequence. If this fails, what happens to customers, reputation and the organisation? If it succeeds, are we ready for that too?
• Decision. What exactly is the board being asked to approve, why now, and what does it cost to wait?

A paper that answers those four in plain language will beat any deck full of architecture diagrams, whatever the subject and whatever the wave.

What should the board refuse to accept?

Vague ethics assurances instead of named controls. Enthusiasm instead of evidence. Pilots reported as achievements, when the achievement is adoption. And any proposal whose success measure is activity: workshops run, tools deployed, models trialled. Activity is what spending looks like. Outcomes are what value looks like.

The board should also refuse false urgency. A considered decision beats a panicked commitment, and refusing panic is not the same as waiting: start something small now, and let evidence carry the bigger call. The pressure to move at wave speed is exactly the pressure a board exists to resist.

What does good look like at board level?

The executive can state, in one sentence each, what is being done, why, and how success will be judged. Risk owns a live view of exposure and can explain it without slides. And there is a simple test running underneath the portfolio: for each capability we have funded, would the people using it fight to keep it? If nobody would, the board is funding theatre.

Common questions

How much technical detail should a board ask for?

Very little, unless the business answers fail to convince. A board governs consequence, not architecture.

Should the board approve individual AI projects?

No. Approve the appetite, the guardrails and the significant commitments, then hold the executive to outcomes.

What is a reasonable board rhythm?

A proper decision session once, then a short standing item: what changed, what we learned, what we stopped.

Is waiting the safe option?

No. Doing nothing is not standing still: usage runs ahead of permission whether or not anyone has looked, and fluency takes months that cannot be bought. So refuse the big panicked commitment and start something small and governed now. The evidence does the deciding after that.