A board can easily end up meeting artificial intelligence at only two moments. The first is approval: a business case, a pilot result, a request to proceed. The second is an incident: a complaint that escalated, an output that should never have reached a customer, an auditor’s question that nobody could answer quickly. If those are the only two moments, and AI is not treated as something the board should follow in between, the board ends up overseeing something it only sees at the start and in a crisis.
That gap matters more for AI than for most technology. A core system approved three years ago broadly does what it did on the day it was approved. An AI use case rarely stays still. Its scope widens as teams find new uses for it, vendors update the models underneath it, and new features arrive inside software the organisation already pays for, sometimes switched on by default. What the board approved and what is running today can drift apart without anyone deciding that they should.
Boards in regulated entities are typically used to receiving regular reporting on credit, market and operational risk. When AI sits outside that rhythm, discussed when there is something to approve, absent the rest of the time, that drift is exactly what goes unseen. In my view, the answer is not more presentations about AI. It is a short, recurring report designed for oversight rather than reassurance.
None of this means board members need to become AI experts. It does mean they need a basic grounding: enough shared understanding of how these systems behave to read such a report and know which questions it should prompt. That grounding deserves its own discussion. This article focuses on the report itself.
What follows is what that report should show, how it should be put together, and why the first version can be smaller than most people expect.
Activity is not oversight
When AI does reach the board between approvals, it is tempting to report activity: how many use cases are live, how many pilots started this quarter, how many hours a process saved. Those figures are not useless. They tell the board that the programme is moving. They do not tell it what it is now accountable for.
The distinction is one boards already apply elsewhere. A credit committee does not judge a loan book by the number of loans approved; it looks at where exposure is concentrated, what has deteriorated and what needs a decision. An AI report built around adoption figures is the equivalent of reporting only origination volume. It invites the board to applaud progress and gives it nothing to challenge.
A report that only shows progress asks the board for applause. A report built for oversight asks it for a decision.
What the report should actually show
A handful of content does most of the work, and none of it requires technical expertise to read.
Where AI touches people or decisions. Not the full inventory, which belongs with management, but the uses whose outputs act on customers, employees or financial decisions, each with a named owner. The board does not need the technical detail of each one. It needs to know which ones would become its problem if they failed.
What changed since the last report. New uses, uses whose scope expanded, models retrained or replaced, a vendor that changed the model behind a service, an AI feature that appeared in an existing tool. Change is where approval and reality drift apart, so it deserves the most space, more than the list of what stayed the same.
What went wrong, including the small things. Incidents, near misses, complaints linked to an automated output, cases where staff overrode the system. A quarter with nothing in this section deserves one sentence explaining how the organisation would have known, whether the absence reflects a clean quarter or simply that nobody was asked.
What is waiting for the board. Decisions that belong at board level rather than in management: a use that sits in a grey zone between existing policies, a proposal in an area the organisation has previously avoided, a dependency on a single vendor that has grown large enough to matter. If this part is always empty, it is worth asking whether those decisions are being taken somewhere else by default.
Who writes it matters as much as what it says
A report on AI written only by the teams that build and run AI will, without anyone intending it, describe their work favourably. That is not a criticism of those teams. It is the same reason financial statements are not audited by the people who prepared them. The report becomes more credible when its inventory and incident record come from a register shared across functions, and when the risk or compliance function adds its own view rather than simply signing the document.
The report also needs to say how complete it is. If the register only captures the uses that teams chose to declare, the report should say so. If AI embedded in purchased software has not yet been reviewed, it should say that too. A board can work with a known gap. It cannot work with a gap presented as full coverage.
Start with one page
My recommendation is to resist designing the perfect report before producing the first one. A single page, built from whatever register exists today and stating its gaps openly, is enough to change the conversation. The second edition will be better because the board will have asked for what the first one lacked, and those requests are the clearest signal of what the board actually needs.
Where a risk committee already exists, the report can sit on its standing agenda alongside other risk reporting, with the board receiving a summary. The placement matters: it turns AI from an occasional topic into a recurring one, and recurrence is what allows the board to see drift before it becomes an incident.
The cost of doing this is modest. The cost of not doing it is that the board’s first detailed look at the organisation’s AI happens after something has gone wrong, when the questions are harder and the answers are slower.
The goal is not a board of AI experts. It is a board with enough grounding to read the report, and a report that shows it, every quarter, what changed in what it is accountable for.
Rhisco’s Risk, Models & AI Governance practice creates control artefacts and AI governance architecture for organisations putting new risk models or AI into use. If the reporting your board receives on AI today is closer to a showcase than to an oversight tool, www.rhisco.com/services sets out how we work.
This article was co-created with the assistance of artificial intelligence under strict supervision, editing, and verification of our team.