AI board reporting should tell directors what AI is in use, what changed since the last meeting, which risks moved, which controls operated, what evidence exists and what decision is required. Treat the pack as an accountability record, not an innovation update.
The UK picture makes that discipline practical rather than optional. The government's February 2024 response confirmed five cross-sectoral AI principles for regulators to apply within their remits: safety, transparency, fairness, accountability and contestability. The FRC's 2024 UK Corporate Governance Code also brings sharper attention to material internal controls, with Provision 29 applying to financial years beginning on or after 1 January 2026 for companies in scope. An AI paper that only says "pilots are progressing" is not enough for either frame.
The report should sit under the board's wider AI oversight model. It shows whether the risk appetite is being breached, whether committee terms are working, and whether conditions from an AI approval paper have been met.
Key takeaways
- The board pack should separate information, assurance and decisions, so directors can tell what they are being asked to note, test or approve.
- A useful AI report starts with the current system inventory, changes since the last meeting, risk movement, incidents, control evidence and decisions required.
- The evidence standard should be dated artefacts: DPIAs, risk register entries, human review logs, supplier notices, model-change records, incident records and assurance findings.
- Framework mapping is not decoration. ISO/IEC 42001, NIST AI RMF, UK GDPR, the UK AI principles and FRC internal-control reporting all point back to named owners, controls and records.
- The most common failure is a narrative update without a decision. If nothing can be approved, challenged or escalated, the board is being briefed, not governing.
Who this applies to
This article is for chairs, non-executive directors, company secretaries, audit and risk committee members, chief executives, chief risk officers and CIOs who need a repeatable AI item in the board pack.
Listed companies should read it alongside the FRC Code. The Code applies to companies listed in the commercial companies category or closed-ended investment funds category, and the FRC notes that many companies outside formal scope still use it as a governance benchmark. Private companies, charities, housing associations, education providers and regulated firms should adapt the same reporting logic to their own duties and regulator.
The reporting pack is not a substitute for the board asking questions. It is the evidence base for those questions. If directors have not yet agreed what to ask, start with the 20 questions every UK board should ask about AI, then turn the answers into a standing pack.
What AI board reporting must answer
The board-level decision frame is simple. Every AI paper should let directors answer these questions without asking management to prepare a second pack:
- What has changed? New systems, new suppliers, new model versions, new integrations, new user groups, new data sources or new jurisdictions.
- Which risks moved? New, increased, reduced, accepted or closed risks, with the reason for the movement and the date it was assessed.
- Which controls operated? Controls that actually ran in the period, not controls described in policy, with evidence that can be inspected.
- What requires a board decision? Approval, rejection, risk acceptance, budget, escalation to a committee, a stop/go decision or an assurance request.
- Who owns the next action? One named owner, one date and one route back to the board or committee.
That frame changes the tone of the paper. The executive is not reporting that "AI adoption increased". It is reporting that the customer-service assistant moved from pilot to production, now touches personal data, has a DPIA dated 9 June 2026, has had two prompt-injection test failures corrected, and needs the board to approve the residual risk before wider deployment.
The minimum evidence table
A board does not need raw model logs. It does need a short index to the artefacts that prove management is governing the system.
| Report item | Evidence the board should see | Owner or board question |
|---|---|---|
| AI system inventory | Current list of bought, built and embedded AI uses, including owner, purpose, data touched and status | Is this complete enough to govern, including unsanctioned or embedded AI? |
| Risk movement | Dated updates to the AI risk register, showing likelihood, impact, control and residual risk | Which risks moved, and what changed in the system or environment? |
| Data protection | DPIA status, lawful basis, data flows, affected people and residual risks where personal data is involved | Does the ICO's AI guidance require a new or refreshed DPIA? |
| Human review | Review route, reviewer authority, overturn record and evidence that decisions can be changed | Is "human in the loop" meaningful, or just a step in the workflow? |
| Security and resilience | Threat model, prompt-injection testing, supplier security position, incident log and remediation status | Do the controls reflect the NCSC secure AI guidance and AI-specific attack paths? |
| Supplier and model change | Contractual notices, model-version changes, retesting record and exit route | Would a supplier update change the risk decision already minuted? |
The table should be short enough to appear in the board pack and specific enough to be auditable. The underlying evidence can sit in a data room, governance workspace or management-system repository. The board pack should point to it by name and date.
Map the pack to the frameworks
Framework mapping is useful only when it changes what appears in the pack. The point is not to show that management has heard of the frameworks. It is to make sure each framework has a visible reporting artefact.
| Framework or duty | What it means for the board pack | Reporting artefact |
|---|---|---|
| UK AI principles | Regulators are expected to apply safety, transparency, fairness, accountability and contestability within their remits | Principle-to-control map for each material AI system |
| FRC Code Provision 29 | Material internal controls, including compliance, operational and reporting controls, need board monitoring and review where the Code applies | Control effectiveness note, exception log and annual assurance plan |
| ICO AI guidance | A DPIA should describe processing, data flows, human involvement, risks, safeguards and residual risk where AI processes personal data | DPIA summary and unresolved risk record |
| NIST AI RMF 1.0 | Govern, Map, Measure and Manage give the pack its operating sequence: accountability, context, measurement and treatment | One page risk movement report by function |
| ISO/IEC 42001 | The AI management system should establish policies, objectives and processes for responsible development, provision or use of AI systems | Management-system review pack, policy exceptions and improvement log |
| DSIT AI Cyber Security Code of Practice | AI has distinct security risks, including data poisoning, model obfuscation and indirect prompt injection | Secure-design and secure-operation evidence, tested before production |
The board does not need every framework every time. It does need a consistent rule for which framework appears against which system. A low-risk internal summarisation tool may need inventory, policy and supplier controls. A system that informs decisions about people needs data protection, human review, fairness testing and contestability evidence. A system exposed to customers or external attackers needs security testing and incident reporting. The UK AI governance framework sets out that layered approach in full.
Common mistakes
The first mistake is reporting activity as if it were governance. "Thirty teams now use generative AI" may be useful context, but it is not a board conclusion. The board needs to know which of those uses are approved, which are conditional, which are prohibited and which are unknown.
The second is accepting supplier dashboards as assurance. A vendor uptime score or model-quality score may be part of the evidence, but it is not the organisation's control environment. The board still needs to know whether the supplier can use organisational data for training, whether model changes trigger retesting, and who can switch the system off.
The third is hiding residual risk inside colour. Red, amber and green can help scanning, but only if the paper shows what moved the colour. A risk that stays amber for four quarters without a changed control, changed metric or changed owner has probably not been reviewed. It has been carried forward.
The fourth is treating human review as an assertion. The ICO guidance asks organisations to record the degree and stage of human involvement in decision-making and to make review meaningful where automated decisions are subject to human intervention or review. A board paper should therefore show who can overturn the system, how often they did, and what happened when they disagreed with it.
The fifth is making the AI item annual. AI use changes through new features, supplier updates, employee adoption and new data connections. A board pack that updates annually will miss the way most AI exposure enters the organisation. The risk register should be triggered by change, not by the calendar.
Next step
For the next board cycle, ask management to populate the minimum evidence table for one material AI system and bring it back with a decision request. If that cannot be done, the gap is not the report format. It is the governance system behind the report.
To establish the baseline, use the Board AI Scorecard. To turn one material system into a board-ready evidence artefact, generate a first pass with the AI Risk Register Generator, then test every row against the evidence table above. To turn the gaps into an owned programme, the GovernIQ diagnostic maps current AI use against board accountability, controls, evidence and the frameworks above.
Last reviewed: 17 June 2026.
Sources: FRC UK Corporate Governance Code 2024; ICO AI accountability guidance; NCSC secure AI system development guidance; DSIT AI regulation government response; NIST AI RMF 1.0; ISO/IEC 42001; DSIT AI Cyber Security Code of Practice.
