What should management report to the board about AI?

Most boards now get an AI update. Very few get an AI report. The difference is that an update describes activity and a report lets the board form a view it could defend, and the gap between the two is where oversight quietly stops happening. This page sets out what belongs in front of a board each meeting, what belongs once a year, and the four things that are almost always presented instead.

What a board usually gets#

Four formats recur, and each of them is information rather than assurance. A count of use cases or pilots, which measures activity and says nothing about control. A vendor slide, often the vendor's own deck with a logo changed, which is a claim made by somebody who is paid if the board is reassured. A maturity score out of five, which converts a set of judgements into a number that cannot be interrogated. And an anecdote: the one deployment that went well, presented as evidence about the estate.

None of these is dishonest. Each is what management has to hand, and each answers the question management was asked. The board's problem is that it can read all four and still not know which decisions its machines are making, who could stop them, or how it would hear if one went wrong.

The five things a board should see every meeting#

Short enough that they fit on two pages, and stable enough that the board can watch them move.

One. The decision list, and what changed on it. Every outcome a system may determine without a person deciding, with the executive who approved each. What a board is watching for is not the length of the list but the additions it was not told about. A list that grows between meetings without anyone bringing the change to the board is the finding.

Two. The stop list, with the last rehearsal date. For each system on the decision list: who can stop it, how long a stop takes end to end, and when that was last tested. A stop that has never been rehearsed is a plan rather than a control, and the date is what tells the board which it is looking at. Designing a stop button people will use sets out why the willingness matters more than the mechanism.

Three. Incidents, against a written definition. How many, of what kind, how the board heard, and how long it took. This only works if the definition was written before the incident, so agreeing what counts as a serious AI incident belongs in a quiet quarter.

Four. Overrides and disagreement. How often a person disagreed with a system's output, and what happened next. This is the single most useful number on the page and almost nobody produces it. An override rate of zero means the oversight is ceremonial, not that the system is perfect. A high rate with no resulting change means people are working around the system rather than governing it.

Five. One assurance, and what it rests on. Rather than a page of them, take one claim management is making this quarter and ask what evidence sits behind it. A sampling regime, a reviewer disagreement rate, a log, a rehearsed stop. Over a year that tests twelve claims properly instead of waving through a hundred. The difference between a claim and evidence is set out at how a board knows management's claims about AI are true.

The three things a board should see once a year#

Slower questions, and they do not belong in a monthly pack.

What the organisation could no longer do by hand, and whether that was chosen or discovered. This is capability debt, and a year is about the right interval to notice it moving.

Where the AI in material controls sits, which from accounting periods beginning on or after 1 January 2026 connects directly to what the board has to declare about the effectiveness of those controls. The declaration is about material controls generally rather than about AI, so the work is identifying which material controls now have a machine inside them.

What the organisation stopped. Boards hear about starts continuously and about stops almost never, and a portfolio that only ever grows is not being governed. Which AI investments should we stop.

Who writes it, and why that is the hard part#

The obvious answer is the chief information officer or the chief technology officer. That is usually the wrong one. Three of the five items are not technology facts. Whether somebody would stop a system mid-quarter is a leadership fact. Whether people override it is a culture fact. Whether the organisation could still do the work by hand is a workforce fact. A report written entirely by the function that deployed the systems will be accurate about the systems and silent about everything the board actually needs.

The arrangement that works is a named accountable executive who owns the report, drawing on technology, risk, legal and the operating functions, with the company secretary ensuring it arrives in the pack rather than as a verbal update. Where that oversight sits, and whether it belongs to a committee, is argued at should AI oversight sit with the full board or a committee.

How to ask for it without getting a project#

A board that asks for AI reporting in the abstract will be presented with a programme to build AI reporting, and will see the first output in nine months. The alternative is to ask for the five items at the next meeting in whatever state they exist, including the parts that are blank. A blank is information: it says the organisation does not know, which is the finding the board needed. The list improves every meeting after that, and the board has been governing from the first one rather than from the third quarter.

What this does not show#

No regulator requires this report and nothing here is a compliance requirement. The UK Corporate Governance Code does not mention AI, and the FRC has published no AI guidance for boards. This is a reporting model argued from what boards have found useful and from what the oversight evidence says goes wrong, not a standard anybody has validated. There is no published research comparing boards that receive this against boards that do not, and there may never be. Treat it as a starting agenda to argue with rather than as a template to adopt.