AI governance board reporting

An AI governance report to the board shows directors what AI the organisation runs, who owns it, where the risk sits and which decisions need them, usually once a quarter. Board reporting on AI tends to go wrong in one of two directions. Some reports are a list of pilots and a paragraph of enthusiasm that tells directors nothing about risk. Others are a dump of every assessment and control that no director can absorb in a meeting. The useful report sits between them. It shows the board that the AI footprint is under control and that risk decisions are owned, and it asks for decisions where they are needed.

What boards ask about AI

Directors’ questions about AI cluster around a small set. A report that answers these in advance makes for a shorter, better meeting.

• What AI do we have? How many systems and agents, which are material, which are new since last quarter, and is the list complete?
• Who is accountable? Does every material system have a named owner and an accountable executive, and do they know it?
• Where are we exposed? Which systems carry high or critical risk, and are we inside our risk appetite?
• Is the governance current? Are assessments and reviews up to date, or are some describing systems that have since changed?
• What went wrong? What incidents and near misses occurred, what did they cost and what changed as a result?
• Are the controls working? What did runtime guardrails block or redact, and what did monitoring catch?
• What is coming? Which laws, standards, vendor changes or customer demands will change what we need to do?
• What do you need from us? Which decisions are outside management’s delegation and need the board?

What the board needs to see

A board is overseeing, not operating, so it needs enough to discharge that duty without operational detail. Show the shape of the AI footprint, the material systems and who owns them, the risk decisions that have been taken and by whom, the incidents of note and what was done about them, and where the programme stands against a recognised reference such as ISO/IEC 42001 or the NIST AI RMF.

Accountability is the thread. Most frameworks put it at the top, and the NIST AI RMF expects executive leadership to take responsibility for decisions about AI risk (GOVERN 2.3). The board report should therefore turn on ownership. Does every material system have a named owner and a recorded decision? Keep it to the level a director can act on, and keep the detail underneath for when someone asks.

What a quarterly report contains

Use the same structure every quarter so directors can compare periods. A report of four to six pages, plus appendices, usually covers the following.

1. Summary and decisions sought

Half a page. What changed, what went wrong, what is outside appetite and the specific decisions the board is asked to take. If a director reads nothing else, this is enough.

2. AI footprint

• Systems and agents by stage (proposed, in development, testing, live, retired) with movement since last quarter.
• New systems added and systems retired.
• AI found through discovery that was not on the register, and what was decided about it.
• AI use requests received, approved, declined and escalated.

3. Material systems and ownership

A short table of the systems that matter most, with each one’s purpose, owner, accountable executive and current risk rating. Flag any material system without a named owner as a finding.

4. Risk position

• Count of systems by risk rating (low, moderate, high, critical) and how that changed.
• Risks above appetite, the controls in place and residual risk accepted, with who accepted it.
• Controls derived from assessments that are not yet implemented or tested.

5. Currency of governance

How many assessments, reviews, model cards (short factsheets describing each model) and ownership attestations (owners confirming they still own a system) are current, ageing or stale. A system whose risk assessment predates its last material change is the single most useful red flag in the whole report.

6. Incidents and near misses

Each incident of note in two or three sentences. What happened, who was affected, what it cost, whether any notification was made and what changed as a result. Report near misses too, because they show the controls working.

7. Live controls and monitoring

• Requests blocked, redacted and escalated by gateway guardrails, with a note on any spike.
• Budget and rate limit breaches.
• Open monitoring alerts and how old the oldest is.
• Security test runs and failing findings.
• KPIs against target, such as the share of live systems with a current assessment or the share of staff with current AI training.

8. Horizon

Regulatory changes, standards, vendor model retirements and customer requirements that will change the work in the next two to four quarters, each with its expected effect.

Appendices

The full register summary, the risk register extract, incident reports and the KPI series. Directors rarely read them, but they should exist and be consistent with the body of the report.

How to build the report

Step 1: Agree what the board wants to oversee

Settle with the chair or the risk committee which of the questions above the report must answer, the risk appetite it reports against, which committee receives it and how often. Write this into the governance committee’s charter.

Step 2: Fix the report structure

Use the eight sections above, or your own version of them, and do not change the structure without telling the board. Consistency is what lets directors see movement.

Step 3: Draw the figures from the record

Every number in the report should come from the governance record. That means the AI register, the risk register, the incident log, gateway enforcement data, monitoring and the learning system. A report assembled from team spreadsheets each quarter will contradict itself within a year, and it cannot be checked later.

Step 4: Write the narrative

Lead with what changed. Explain each figure that moved in a sentence or two. Name owners. Say plainly where the organisation is outside appetite and what is being done. Avoid technical vocabulary unless it is explained.

Step 5: Review with owners

Before finalising, have the owners of the systems mentioned and the governance committee chair check the sections that concern them. This catches errors and also makes ownership real, because an owner who has read what the board will see about their system tends to act on it.

Step 6: Finalise and hold the detail

Lock the report for the period so it cannot change after the meeting, and start a new one for the next period. Keep the supporting records available, because a director, an auditor or a regulator may later ask to see what sat behind a figure.

Reporting to other readers

The board is one of several readers who ask a version of the same question. A regulator wants to see that the governance meets its expectations and is evidenced, in detail and on the record, so the conversation moves from summary to the records themselves. An enterprise customer wants to know your AI will not become their risk, usually through a questionnaire, which the due-diligence guide covers. An auditor wants to test it, which the audit preparation guide covers. Work out which reader you are answering before you decide what to show. The same record serves all of them at different levels of detail.

If you hold or are working towards ISO/IEC 42001, the quarterly report also feeds the management review the standard requires at clause 9.3. That review considers the status of previous actions, changes in internal and external issues, performance and audit results, and opportunities for improvement.

Where Aicura fits

At Pro, Aicura drafts the board report from the governance record for the period and the systems you choose. The footprint comes from the AI register, ratings from the risk assessments, incidents from Incidents, enforcement from the gateways and progress from your KPIs. The author edits the draft and finalises it, which fixes the document for that period, and the next period gets a new one.

For the currency section, the Cadence view, which tracks when each piece of governance work is next due, shows which pieces of work on each system are current, ageing or stale, worst first. For the appendices, Aicura generates point-in-time reports on individual systems, agents, assessments, policy reviews, incidents and security testing. The report, and the judgement in it, belong to the author.

A note on this page

This guide is general information on reporting AI governance to a board. It is not legal advice and it does not set out the duties of directors in any jurisdiction. For how this applies to your organisation, take your own professional advice.