How should boards and management be reported to on AI?

What should a board report contain?

A board report should contain, in summary form, the number and type of AI systems in use, the high-risk and prohibited-practice screening position, the conformity and registration position for high-risk systems, the transparency position, the incident and change picture, the supplier and model dependency picture, and the open items with owners and dates. It should distinguish between systems that are live, systems in development, and systems retired, and should highlight new risks, new guidance, and decisions that need board approval. The report should be based on the registers, not on anecdote, and should include the date of the underlying data, so that the board knows how current the picture is. A report that lists only the number of systems, without risk, conformity, incident, and open-item information, does not give the board the picture it needs to oversee AI risk.

How often should reporting happen, and in what form?

Reporting cadence should match the volume and risk of AI activity: a regular report, for example quarterly, for the standing picture, with immediate reporting for serious incidents, material changes, authority contact, or decisions that cannot wait. The form should be concise, with a summary, a risk picture, a decision section, and an appendix of open items, so that board members can grasp the position quickly and can follow up on detail where needed. Reporting should use plain language, define terms, and avoid technical detail that obscures the decision, while providing the evidence behind each statement in the appendix or in a linked file. The cadence, form, and owner should be recorded in the governance operating model, so that reporting is a planned activity rather than an ad hoc response to a crisis.

For the broader regulatory framework, see AI governance planning checklist.

What decisions should boards and senior management take?

Boards and senior management should take decisions on risk appetite for AI, on the governance operating model, on the deployment of high-risk systems, on the response to serious incidents, and on material changes to the AI portfolio. Those decisions should be recorded as minutes or decision logs, with the facts considered, the options, the decision, and the follow-up actions. Management should not delegate a board-level risk decision to a working-level team without a clear mandate, and working-level teams should not make a board-level decision informally because a board meeting is not imminent. The escalation route should bring board-level decisions to the board in time, with the information the board needs to decide, and should record the board's decision and the actions that follow from it.

How should reporting link to risk, audit and assurance?

AI reporting should link to enterprise risk reporting, to internal audit, and to any external assurance, so that AI risk is visible in the organisation's overall risk picture and is subject to independent challenge. The link should be recorded as shared risk entries, shared audit plans, and shared assurance findings, with named liaison owners. Internal audit should periodically test the AI governance file, including the inventory, classification decisions, evidence chains, incident handling, and change management, and should report findings to the board or audit committee. Assurance work should be independent of the teams that built or deployed the systems, and findings should be tracked to closure with owners and dates. A board report that is not linked to risk and audit will present AI as a separate matter, rather than as part of the organisation's risk and control picture.

How should open items and accountability be shown?

Open items should be shown with the system, the issue, the owner, the due date, and the status, so that the board can see what remains unresolved and who is responsible for resolving it. Overdue items should be highlighted, with the reason for delay and the revised date, rather than being removed from the report. Accountability should be shown by naming the accountable executive for the programme, the owners for each open item, and the forum that will decide any item that cannot be resolved at working level. A report that shows only completed work, without open items, gives a misleading picture of assurance, because it hides the work that remains. The board should challenge open items, ask for evidence where a claim is made, and record its challenge and the response, so that oversight is evidenced as well as exercised.

Continue with AI governance operating model.

What does this guide not decide?

This guide does not decide what reporting a particular board must receive, what risk appetite an organisation should set, or whether a board decision was correct. It does not design a board pack or assess a governance record. Those questions depend on the organisation's structure, its AI portfolio, its risk profile, and its legal duties as a board. An organisation should design its reporting to fit its governance, base it on the registers, link it to risk and audit, and confirm the design with a competent adviser where the board's oversight position is material to a regulatory or legal question.

Frequently asked questions

Continue through this AI Act cluster

• AI governance planning checklist
• AI governance operating model
• Documentation registers for AI systems
• Incident handling and escalation for AI
• EU AI Act overview
• AI literacy in practice