An AI governance evidence pack is the board's audit-ready record of why an AI system may operate, who owns it, which controls are live, what evidence proves they work, and what decision or review date changes that permission.
Use it when a board, audit committee or risk committee needs to approve an AI go-live, review a live system, or respond to internal audit, external audit or a sector regulator. It is not a policy library. It is the index of dated proof that decisions, controls and exceptions exist outside the board paper.
Key takeaways
- A board evidence pack should answer one question: what proof shows this AI system is owned, controlled, monitored and still within the permission the board gave it?
- The pack belongs at system level, not policy level. A general AI policy cannot prove that a claims triage model, surveyor assistant or customer chatbot is operating within its approved limits.
- Good evidence is dated, owned and testable. Minutes, policies and attestations matter, but the strongest records come from the system itself: ledgers, logs, thresholds, test results and exception queues.
- The pack should map to board duties, internal controls, NIST AI RMF functions, data protection obligations and the sector regulator's language, so the same evidence can answer more than one assurance question.
- Do not wait until annual reporting. A go-live pack becomes a review pack when the system changes model, data, user group, process step, supplier or residual risk.
Who needs it, and what the board decides
The pack is for boards that need evidence before permission, not a retrospective file after something has gone wrong. It is most useful when the organisation is about to deploy AI into a regulated process, extend an existing tool to new users, change the underlying model, or rely on AI-generated outputs in a decision that affects customers, tenants, patients, pupils, service users or staff.
The board does not need to inspect every prompt, embedding store or model parameter. It does need to decide five things:
- Purpose: whether the AI use is within the organisation's strategy, duties and risk appetite.
- Permission: which users, data, decisions and downstream actions are in scope, and which are not.
- Accountability: who owns the system, the controls, the exceptions and the decision to pause it.
- Evidence: which records prove the controls are working, how often they are reviewed and who checks them.
- Exit route: what would trigger a withdrawal, remediation plan, human-only fallback or new board approval.
This is where the pack differs from a broad AI governance framework for UK boards. The framework tells the organisation how AI is governed. The pack tells the board whether this system has earned permission to operate today.
What belongs in an AI governance evidence pack
Start with the board decision and work backwards. If the board is being asked to approve a system, the pack should contain the minimum evidence needed to make that approval specific, conditional and reviewable. If the system is already live, the pack should show whether the original permission still holds.
A practical pack normally contains:
- Decision record: the board or committee paper, the decision made, the scope approved, the conditions attached and the review date.
- System description: the use case, user group, supplier, model type where known, data categories, affected process and downstream actions.
- Risk register entry: the named risk owner, residual risk rating, current controls, thresholds and latest evidence, ideally linked to a living AI risk register.
- Control evidence: test results, monitoring logs, access permissions, human approval records, exception reports and change records.
- Data protection file: lawful basis, data minimisation, DPIA where required, transparency wording, rights handling and automated decision analysis where personal data is involved.
- Security file: supplier assurance, access model, data flow, incident route, vulnerability handling and secure operation evidence.
- Assurance map: which evidence answers which framework, policy, regulator or internal control requirement.
- Open issues: unresolved assumptions, exclusions, accepted residual risks, owner, due date and escalation route.
The best packs are short because the evidence is well indexed. The board paper can be ten pages; the pack may point to many artefacts. What matters is that an auditor can follow the trail from a board condition to a control and from that control to dated proof.
Controls and evidence that audit can test
Treat each control as a claim that needs proof. "Human review in place" is too weak unless the pack shows who reviewed what, when, against which threshold and what happened when they disagreed with the system.
| Control area | Evidence to keep | Owner | Board question |
|---|---|---|---|
| Scope and permitted use | Approved use case, prohibited uses, user groups, data categories and change trigger | Executive sponsor | What is the system allowed to do, and what would require fresh approval? |
| Human decision point | Review queue, approval record, reject or amend reasons, escalation path | Process owner | Can we show that a human decision happens before the external consequence? |
| Data protection | DPIA, lawful basis, privacy wording, data minimisation, retention rule, rights route | Data protection officer or equivalent | Where personal data is used, what evidence shows lawfulness, fairness and transparency? |
| Model and supplier change | Version log, supplier notice, release notes, re-test record, material-change assessment | Technology owner | How would the board know the system changed beneath the original approval? |
| Output quality | Test set, acceptance threshold, sampling result, false-positive or false-negative review, exception trend | Risk owner | What measure tells us the control is still working? |
| Audit trail | Append-only decision ledger, prompt/output record where proportionate, user action, timestamp | System owner | Can we reconstruct a disputed output without asking people to remember? |
| Security and access | Role permissions, privileged access review, incident route, dependency register | Security owner | Who can use the system, who can change it, and how is misuse detected? |
| Board review | Dashboard, assurance report, action log, residual risk movement, next review date | Company secretary or governance lead | What changed since the last board or committee review? |
The audit trail deserves special care. An append-only decision ledger turns a governance promise into a record: input, output, user, model, decision, reason and timestamp. Not every system needs the same granularity, but every regulated use needs enough evidence to reconstruct the decision path.
Map the pack to frameworks and regulators
The same artefact should answer several assurance questions. That is the point of building a pack rather than separate files for legal, risk, audit, security and the board.
| Source of obligation or guidance | What to map | Evidence that usually belongs in the pack |
|---|---|---|
| FRC UK Corporate Governance Code and FRC code guidance | For listed companies, AI controls may form part of the board's material internal controls. Provision 29 applies from 1 January 2026 for the declaration on effectiveness. | Board scope decision, material-control assessment, control owner, annual review evidence, exceptions and remediation. |
| NIST AI RMF Core | Use Govern, Map, Measure and Manage as the evidence spine. | Governance owner, system context, measurable thresholds, control results and action taken on exceptions. |
| ICO guidance on AI and data protection | Where personal data is involved, show accountability, lawfulness, fairness, transparency, DPIA reasoning and rights handling. | DPIA, privacy information, lawful-basis note, bias and fairness assessment, automated decision review route. |
| NCSC secure AI development guidelines | Evidence should cover secure design, development, deployment, operation and maintenance. | Threat model, access control, supplier dependency record, deployment approval, monitoring and incident response route. |
| GOV.UK AI regulation response | The UK approach expects regulators to apply principles such as safety, transparency, fairness, accountability and contestability within existing remits. | Regulator mapping, stakeholder impact assessment, explanation route, appeal or redress route, owner for regulatory change. |
| FCA AI approach and Consumer Duty | For financial services, link AI use to governance, accountability and customer outcomes. | SM&CR owner, customer outcome evidence, fair-value or support impact where relevant, complaints and redress evidence. |
ISO 42001 can sit alongside this without becoming a separate bureaucracy. If your organisation uses an AI management system, the pack becomes the evidence index for roles, risk treatment, monitoring and improvement. For board readers, the simpler question is still the better one: which proof would we hand to audit if this system was challenged tomorrow?
Common mistakes that weaken assurance
The first mistake is treating the pack as a launch document. AI assurance decays when the supplier changes terms, the model changes behaviour, the user group expands, or the process starts relying on the output in a way the original paper did not describe. Put change triggers on the front page.
The second mistake is keeping only meeting records. Minutes prove that a discussion happened; they do not prove that a control operated. A useful pack links the minute to the artefact: the exception queue, threshold report, access review, DPIA, test result or incident record.
The third mistake is confusing ownership with sponsorship. A sponsor can argue for the system. The owner must act when the evidence says the system has moved outside permission. Use the questions in Questions every UK board should ask about AI to separate enthusiasm from accountability.
The fourth mistake is hiding assumptions. If the board is relying on supplier documentation, a limited test set, a draft regulator position or a manual workaround, say so. Weak evidence can be acceptable when it is named, dated and attached to a review plan. It becomes dangerous when it is implied to be stronger than it is.
The fifth mistake is writing for one audience. A board may ask for risk, an auditor for control design, the ICO for data protection reasoning, the NCSC for security operation and a sector regulator for customer or service-user impact. Build one evidence map that can answer all of them without rewriting the story each time.
Next step: turn evidence into readiness
For a single system, start with the smallest pack that would allow a board committee to say yes, no or yes with conditions. For a portfolio, use the same fields across every material AI use: purpose, owner, data, decision impact, controls, evidence, exceptions and review date. That consistency is what makes readiness-index work credible later. It allows patterns by sector, control type and maturity without inventing a new narrative every quarter.
If you need a fast baseline, run the Board AI Scorecard and use the results to identify missing evidence. If the system is close to go-live, route the pack into the AI governance diagnostic so the decision, controls and assurance map can be tested before the board is asked to approve deployment. Our trust page explains how we think about evidence, audit trails and human accountability in live systems.
Sources: FRC UK Corporate Governance Code · FRC Corporate Governance Code Guidance · NIST AI RMF Core · ICO guidance on AI and data protection · NCSC secure AI development guidelines · GOV.UK AI regulation government response · FCA AI approach · FCA Consumer Duty
