A board paper template for AI approval should force one decision: approve, reject or approve with conditions a named AI use case, with evidence on purpose, data, risk, controls, accountable owner, monitoring and the UK duties the board has considered.
That structure matters because AI is rarely a single technology purchase. It can affect data rights, service quality, employment decisions, supplier risk, information security and reputation. A good paper gives directors the record they need before a decision is made, not the justification assembled afterwards.
Use the paper after the board has set its AI risk appetite and agreed the wider oversight model. Once a use is approved, carry the conditions, evidence and review date into the standing AI report.
Key takeaways
- The paper should ask for approval of a specific AI use case, not a general endorsement of AI adoption.
- The decision should record the accountable owner, risk appetite, conditions of approval and the evidence the board relied on.
- UK boards should map the paper to the government's five AI principles, ICO expectations where personal data is involved, directors' section 172 duties and the organisation's own risk framework.
- The evidence pack should include a risk register entry, DPIA position, supplier terms, security assessment, human oversight design, assurance plan and review date.
- If the paper cannot show the control evidence, the board should defer approval or approve only a discovery phase.
Who should use it, and what the board is deciding
Use this format when an AI system could affect people, finances, regulated services, confidential data, public communications or a material internal control. That includes bought systems, embedded AI in existing software and internal tools that make recommendations for staff.
It is too heavy for low-risk drafting support that never touches personal data and never leaves internal review. It is too light for a high-risk programme that needs a full change case, procurement pack and assurance plan. Its proper job is board approval for a defined use case.
The board should decide:
- whether the proposed use is within the organisation's purpose, risk appetite and strategy;
- whether the benefits are specific enough to justify the data, supplier, security and conduct risks;
- whether the accountable executive has authority, budget and reporting lines;
- whether the proposed controls are evidenced, not merely promised;
- whether approval is unconditional, conditional, limited to a pilot or refused.
That decision should be minuted against directors' duties. Section 172 of the Companies Act 2006 requires directors to have regard to long-term consequences, employees, business relationships, community and environmental impact, reputation for high standards of conduct and fairness between members. AI approvals often touch several of those factors in one paper.
Use this board paper template for AI approval
The paper should fit inside the normal board pack. The discipline is not length. It is forcing each claim to point at an artefact.
| Paper section | Question it answers | Evidence to attach |
|---|---|---|
| Recommendation | What exact decision is requested? | Draft resolution, conditions of approval, proposed review date |
| Use case and boundary | What will the AI do, and what will it not do? | Process map, excluded uses, user groups, affected stakeholders |
| Strategic case | Why now, and what changes if we do nothing? | Benefits case, dependency map, implementation options |
| Legal and regulatory map | Which duties and regulators are engaged? | UK principles map, data protection assessment, sector obligations |
| Data and model position | What data is used, where it goes, and whether outputs affect people? | Data flow, lawful basis, DPIA position, model or vendor documentation |
| Risk and controls | What could go wrong, and what prevents or detects it? | AI risk register entry, control owners, test results, incident route |
| Human oversight | Who can intervene, overrule, pause or stop the system? | RACI, escalation path, approval log design, training plan |
| Monitoring and assurance | How will the board know whether the system is still within approval? | Metrics, reporting cadence, assurance owner, review trigger list |
The recommendation should be written so a company secretary can lift it into the minutes without interpretation. "Approve the deployment of AI" is too vague. "Approve a 90-day controlled pilot of the repair triage assistant for non-emergency inbound messages, subject to the attached data controls, named human review and monthly exception report to audit and risk" is a board decision.
Controls and evidence the paper should attach
Controls should be proportionate to the use case. A customer-facing system, a staff decision aid and a document summariser do not carry the same exposure. The common test is whether the board can see who owns the control, where the evidence lives and what happens when the control fails.
| Control area | Minimum board evidence | Named owner |
|---|---|---|
| Accountability | One accountable executive, one board or committee route, and a date for first review | CEO, COO or relevant executive sponsor |
| Risk register | A current AI risk entry with inherent risk, controls, residual risk and trigger events | Risk owner |
| Data protection | DPIA position, lawful basis, data minimisation, retention and transparency wording where personal data is used | Data protection officer or privacy lead |
| Human oversight | Which decisions require human review, what reviewers can change, and how interventions are logged | Process owner |
| Supplier governance | Contract position on training data, sub-processors, model updates, audit rights and exit | Procurement or legal lead |
| Security | Threat model, access controls, logging, incident route and model-update controls | CISO or security lead |
| Assurance | Test results, acceptance criteria, go or no-go threshold and post-launch review cadence | Internal audit, risk or assurance lead |
The ICO's AI and data protection guidance is the right starting point where AI processes personal data. The paper should show the data protection judgment reached, not just state that privacy has been considered.
Security needs the same specificity. The NCSC's guidelines for secure AI system development cover secure design, secure development, secure deployment and secure operation. A board paper does not need to reproduce that guidance, but it should say which parts of the security assessment were completed and who owns the open items.
For the risk record, link the paper to a live register entry rather than a static appendix. Our guide to AI risk registers as living evidence explains the difference between a spreadsheet row and evidence a board can inspect. If no register exists yet, use the AI Risk Register Generator to create the first board-level entry before approval.
Framework mapping for a UK board
Framework mapping prevents the paper becoming a local opinion. It shows the board which recognised duties, standards and regulators the proposal has been tested against.
| Framework or duty | What it contributes to the paper | Where it should appear |
|---|---|---|
| UK AI principles | The government's five cross-sectoral principles: safety, transparency, fairness, accountability and contestability | Regulatory map and controls section |
| UK GDPR and ICO guidance | Data protection, fairness, transparency, individual rights and accountability for AI using personal data | Data and legal assessment |
| NIST AI RMF | The Govern, Map, Measure and Manage functions give the paper a practical risk structure | Risk and assurance section |
| ISO/IEC 42001 | ISO/IEC 42001 specifies requirements for an AI management system that establishes, implements, maintains and improves AI governance | Policy, ownership and continual review |
| FRC Corporate Governance Code | The FRC says Provision 29 asks boards to declare on the effectiveness of material internal controls | Assurance and internal controls |
| EU AI Act | Regulation (EU) 2024/1689 should be scoped where the system or its output is used in the EU | Cross-border legal scope |
The mapping should be concise. The board does not need a textbook. It needs to know which standards were used, what they changed in the proposal and which gaps remain open. Our guide to what a UK AI policy must include is useful when the paper exposes a policy gap rather than a single project issue.
Common mistakes before approval
The first mistake is asking the board to approve a tool rather than a use case. "Approve Copilot" or "approve an AI assistant" tells directors almost nothing about data, decisions, outputs or controls. The same tool can be low risk in one workflow and unacceptable in another.
The second mistake is treating human review as a sentence. A paper should say who reviews, when they review, what they can change, what gets logged and what happens when the reviewer disagrees with the system. Without that, the control is not yet designed.
The third mistake is putting all assurance after launch. Some evidence belongs before approval: supplier terms, data flow, DPIA position, security review, risk entry and acceptance criteria. Other evidence belongs after launch: exception rates, override logs, incidents, user feedback and model-change reviews. The board paper should separate the two.
The fourth mistake is omitting the refusal route. A mature board paper should let directors say no, approve a narrower pilot or approve only after specific conditions are met. A paper that only permits approval is advocacy, not governance.
The fifth mistake is failing to ask the board-level questions. Before the item reaches the meeting, test it against our 20 questions every UK board should ask about AI. If the paper cannot answer the questions on ownership, data, oversight, risk register and assurance, it is not ready for approval.
Next step
Start with the evidence. Create or update the AI risk entry with the AI Risk Register Generator, then baseline the board's wider readiness with the Board AI Scorecard. Those two artefacts give the paper a risk record and a board-level context.
If the proposed AI use is already material, regulated or live, move straight to an AI governance diagnostic. The diagnostic turns the board paper into a sequenced evidence plan: what can be approved now, what needs conditions, and what should wait until controls are in place.
Last reviewed: 17 June 2026.
Sources: Companies Act 2006 section 172; ICO AI and data protection guidance; NCSC secure AI system development guidance; DSIT AI regulation government response; NIST AI RMF Playbook; ISO/IEC 42001; FRC UK Corporate Governance Code 2024; Regulation (EU) 2024/1689.
