An AI governance assurance map is the board's route from risk to proof: it names each material AI use, the control that governs it, the evidence that shows the control operating, and the committee that will test it.
The audit committee should not receive a slide saying AI is governed. It should receive a route it can follow. For each material system, directors need to see the risk, the owner, the control, the evidence artefact, the assurance source and the decision required. That is how the board moves from policy comfort to testable oversight.
This article is for boards, company secretaries, audit committee chairs and risk leaders who already have an AI governance framework, an emerging AI register, or a readiness exercise in progress. The map completes the cluster by turning readiness scores and evidence packs into a committee decision record.
Key takeaways
- The assurance map is not another register. It is the board view of how AI risks, controls and evidence connect.
- Audit committees should test whether evidence proves a control operated, not whether a policy says the control exists.
- The strongest maps route each system through named owners, dated artefacts, control frequency, assurance source and board decision.
- UK boards should map against the FRC internal-control lens, the government's five AI principles, ICO data-protection expectations, NCSC security guidance, NIST AI RMF functions and any sector regulator.
- The next useful action is to baseline the organisation through the Board AI Scorecard or commission a diagnostic that converts the map into an evidence pack.
What the board and audit committee decide
The board decides risk appetite, materiality and the systems that require assurance. The audit committee tests whether management can prove the controls are operating. That split matters, because AI governance often fails when committees are asked to approve tools they have not traced to evidence.
The first decision is scope. Include any AI system that influences people, money, compliance, safety, reporting, customer treatment or public trust. That includes vendor features embedded in existing platforms, not only models built internally. If a system would be uncomfortable to explain after a poor outcome, it belongs on the map.
The second decision is assurance depth. Not every AI use needs internal audit, but every material AI use needs a named evidence source. For low-risk drafting tools, that might be an acceptable-use attestation and a sample review. For a model informing tenant, citizen, student, employee or customer outcomes, the committee should expect a system record, impact assessment, test results, human review route, exception log and update history.
The third decision is who acts when evidence is weak. A map is only useful if red entries change behaviour: stop deployment, commission testing, require a data protection impact assessment, amend supplier terms, or ask management to return with dated evidence. This is where the board AI risk register and the assurance map meet. The register holds the risk; the map shows how the board knows the response is real.
The governance anchor is familiar. The FRC's UK Corporate Governance Code 2024 asks boards to monitor and review the effectiveness of risk management and internal controls, with Provision 29 applying from financial years beginning on or after 1 January 2026. AI assurance should sit inside that control discipline, not beside it as a technology project.
Build the AI governance assurance map
Start with one row per material AI use, then make each row answer six questions.
| Map field | What the board should see | Evidence standard |
|---|---|---|
| AI use | The system, purpose, data touched and affected group | Current system-register entry |
| Material risk | The board-level risk if the system fails or is misused | Risk rating with rationale and date |
| Control | The process, technical constraint or approval gate that reduces the risk | Control description tied to policy |
| Evidence | The artefact proving the control operated | Dated log, test result, minute, assessment or ledger |
| Assurance source | Who checked it and at what frequency | Management review, second-line review, internal audit or external assurance |
| Board decision | What the committee is asked to approve, challenge or defer | Minute showing decision, condition or follow-up owner |
The map should be short enough for a committee pack and precise enough for a regulator or auditor. Avoid generic cells such as "human review in place" or "supplier controls". The better entry says who reviews, when the review is triggered, what they can override, where the override is recorded, and how exceptions are escalated.
For systems that generate board papers, advice, case summaries or customer-facing text, the evidence artefact is often the deciding factor. An append-only decision ledger can show the prompt, output, source material, human decision and timestamp. A conventional approval note cannot do that unless someone reconstructs the history after the event.
There is no need to map every experiment at the same depth on day one. Use the first board cycle to map the top five material uses. Then require any new AI use to enter the map before go-live. That turns assurance from a periodic exercise into a gate.
Controls and evidence to test
The audit committee should press on the evidence column first. If the artefact is weak, the rest of the row is commentary.
| Control area | Board question | Evidence to request | Typical owner |
|---|---|---|---|
| Inventory and ownership | Do we know where AI is used and who is accountable? | System register with owner, purpose, data and status | AI governance owner |
| Data protection | Does the system process personal data lawfully and fairly? | DPIA or assessment, privacy information, Article 22 review route where relevant | DPO or privacy lead |
| Security | Has the system been designed, deployed and operated with AI-specific threats in view? | Threat model, access controls, monitoring logs, incident route | CISO or technology lead |
| Human oversight | Can a person review and change a significant AI-assisted outcome? | Review workflow, override log, response-time record | Operational owner |
| Supplier control | Do supplier claims match what we can verify? | Due diligence file, contractual disclosure duties, model-change notices | Procurement and legal |
| Performance and fairness | Has the system been tested in the context where it is used? | Test set description, results by relevant cohort, exception trend | Product or service owner |
| Board reporting | Did assurance lead to a decision? | Committee minute with condition, approval, rejection or follow-up | Company secretary |
The ICO's AI and data protection guidance is the source to use where personal data is involved. It frames AI through accountability, governance, transparency, lawfulness, accuracy and fairness. The evidence should therefore include the assessment work, not just a privacy notice.
For security, the NCSC's secure AI system development guidance is useful because it follows the AI system lifecycle: secure design, secure development, secure deployment, and secure operation and maintenance. A board assurance map can borrow that route directly. Ask what was checked before build, before deployment and after the system started operating.
For financial services, the FCA's AI approach states that it does not plan extra AI regulations and will rely on existing frameworks, including Consumer Duty and accountability rules. That makes the assurance question sharper, not softer: show how the AI use preserves customer outcomes, senior-manager accountability and evidence-based risk assessment.
Mapping the assurance route to frameworks and regulators
A useful map avoids framework theatre. It does not list every standard the organisation has heard of. It shows which framework or regulator supplies the question, then points to the evidence that answers it.
| Lens | What it asks the board to evidence | Where it appears on the map |
|---|---|---|
| FRC internal control | Has the board monitored, reviewed and reported on material controls? | Materiality, assurance source, committee decision |
| UK AI principles | Which control answers safety, transparency, fairness, accountability and redress? | Risk, control and evidence columns |
| ICO data protection | Where personal data is used, how are accountability, fairness, transparency and automated-decision safeguards evidenced? | DPIA, privacy information, review route, fairness tests |
| NCSC secure AI | How were AI-specific security risks addressed through design, development, deployment and operation? | Security control, threat model, monitoring evidence |
| NIST AI RMF | How does the system Govern, Map, Measure and Manage AI risk? | Owner, context, metric, control and exception route |
| Sector regulator | Which existing duty applies to this use case? | Sector-specific evidence and accountable owner |
The government's AI regulation response confirmed five cross-sectoral principles for existing regulators to apply within their remits: safety, security and robustness; transparency and explainability; fairness; accountability and governance; contestability and redress. The map is the practical bridge between those principles and a committee pack.
The NIST AI Risk Management Framework gives the same work a risk-management structure. Its Core is organised around Govern, Map, Measure and Manage, with Govern operating across the other functions. That is a useful test of the assurance route: if a row has no owner, no context, no measurement and no management action, it is not ready for board assurance.
ISO 42001 can sit behind the same route where the organisation wants a management-system approach. Use the internal AI governance framework to connect policy, controls, evidence and assurance, then use this map to decide which rows need deeper review.
Common mistakes that weaken assurance
Treating assurance as a policy check. A policy can be current and the control can still be absent. Ask for the artefact that proves the control operated in the period under review.
Mapping frameworks without mapping systems. A spreadsheet that says "NIST: yes" tells the board nothing. The committee needs to see which AI use is governed, measured and managed, not whether a framework name appears in a document.
Leaving vendor AI outside scope. The most material AI may arrive as a feature inside an HR, finance, CRM or case-management platform. Supplier assurance should include disclosure of AI functionality, model-change notice, data-use terms, testing evidence and an exit route.
Using traffic-light ratings without provenance. Red, amber and green need a source, date and method. A green rating based on management opinion is weaker than an amber rating based on a dated test with a clear owner.
Forgetting the board decision. An assurance map is not complete until it records what the committee did with the evidence: approved, deferred, challenged, escalated or required action before go-live.
The questions every UK board should ask about AI are a useful companion here. The assurance map turns those questions into rows that can be tested and minuted.
Next step: turn the map into an evidence pack
If you do not yet know which systems belong on the map, start with the Board AI Scorecard. It gives a board-level baseline and identifies where governance is still asserted rather than evidenced.
If you already have the register, policy and first controls, the next step is the AI governance diagnostic. The diagnostic traces material AI uses through risk, control, evidence and assurance, then turns the map into a board-ready evidence pack.
The test is simple enough for the next committee cycle. Pick one material AI system. Ask which risk it creates, which control governs it, what evidence shows the control operated, who checked that evidence, and what decision the board is being asked to make. If the route is visible, assurance can start. If the route breaks, the map has done its job before an external reviewer has to do it for you.
Last reviewed: 18 June 2026.
Sources: FRC UK Corporate Governance Code 2024 · GOV.UK AI regulation government response · ICO guidance on AI and data protection · NCSC secure AI system development guidance · FCA approach to AI · NIST AI Risk Management Framework
