A generative AI policy template UK boards can use should classify uses, set data-entry rules, require human approval for high-risk outputs, name evidence owners and create a review rhythm. The document is only defensible if each clause leaves a record.
Use a template as the board's first draft, not as the control itself. The ICO's AI and data protection guidance still anchors UK personal-data risk as at 17 June 2026, although the ICO says that guidance is under review following the Data (Use and Access) Act 2025. The policy therefore needs a living evidence layer, not a one-off PDF.
Key takeaways
- A board-ready policy classifies uses, not tools: the same chatbot can be low-risk for public drafting and prohibited for special-category personal data.
- The data rules, human control rules and supplier rules need owners and evidence, otherwise the policy cannot be tested after adoption.
- The UK Government AI Playbook is a useful benchmark even outside government: lawful use, secure use, meaningful human control, lifecycle management, skills and assurance all belong in the policy.
- The template should map to ISO/IEC 42001, NIST AI RMF, UK GDPR, cyber-security guidance and, where relevant, EU AI Act duties.
- The next step is to turn the policy into a draft the board can amend, then test it against live AI use through the Scorecard or diagnostic.
Who this applies to, and what the board must decide
This applies to UK boards, company secretaries, risk leaders, data protection officers and senior responsible owners who need one policy covering staff use of public generative AI tools, approved workplace assistants and vendor AI built into existing systems. The policy should sit beside the wider AI policy anatomy guide, the acceptable-use policy guide, the shadow AI policy and the organisation's AI governance framework.
For listed companies, the FRC's 2024 UK Corporate Governance Code asks boards to consider material internal controls and the evidence used to assess their effectiveness. A generative AI policy is not named in the Code, but the same discipline applies: if AI use creates compliance, operational or reporting risk, the board needs to know which controls are material and how they are reviewed.
The board should decide five things before management writes the clauses:
- Which AI uses are allowed without approval, which need conditions and which are prohibited.
- Which categories of data may never be entered into public or unapproved tools, and when a DPIA for AI is required before use.
- Which decisions require human approval, documented reasoning or board notification.
- Which suppliers must answer AI due-diligence questions before procurement or renewal.
- Which evidence will appear in the quarterly AI report: approved uses, exceptions, incidents, training, supplier reviews and overdue actions.
What a generative AI policy template UK needs to decide
Start with scope. A policy limited to "ChatGPT" will age badly because the risk now appears inside office suites, CRMs, meeting tools, procurement systems and specialist SaaS. The UK Government AI Playbook tells public bodies to understand what AI is, its limitations, lawful use, secure use, meaningful human control, the full AI lifecycle and the skills needed to use it. Those headings translate well into a board policy for private, charity and public-sector organisations.
The second decision is the use model. Classify use by data and consequence, not by the name of the product. Public drafting from a blank page may be permitted. Summarising an internal but non-personal policy may be conditional. Entering personal data, confidential client material, credentials, unpublished financial information or special-category data into an unapproved public tool should be prohibited unless a separate assessed arrangement covers that processing.
The third decision is human control. The Playbook says organisations should have meaningful human control at the right stages and human validation for high-risk decisions influenced by AI. In a policy, that means naming the decisions that cannot be approved by AI output alone: recruitment, safeguarding, eligibility, complaints, disciplinary action, credit, allocation of services, legal judgement and any decision with a material effect on an individual.
The fourth decision is disclosure. If the organisation operates in or serves the EU market, the EU AI Act matters even though the UK has no single AI Act. Article 4 requires providers and deployers to take measures to ensure sufficient AI literacy, and Article 50 sets transparency obligations for systems interacting directly with people and for certain AI-generated content. The main application date is 2 August 2026, with some provisions applying earlier, so disclosure wording should be reviewed before then.
Controls and evidence the policy must create
The test is whether the policy changes work. The NCSC secure AI development guidelines frame AI security across secure design, development, deployment and operation, and state that security should be a requirement throughout the lifecycle. A board policy should not attempt to restate all technical controls, but it should point to the evidence that those controls exist.
| Policy clause | Control behind it | Evidence the board can ask for | Owner |
|---|---|---|---|
| Approved and prohibited uses | Three-band use classification with examples | Current use register; exceptions log; declined-use record | AI owner or risk lead |
| Data-entry rules | Data-classification check before prompts or uploads | DPIA or legitimate-interest assessment where personal data is involved; processor review | DPO or legal |
| Human control | Named approval points for high-risk outputs | Approval record showing reviewer, decision, rationale and source material | Business owner |
| Supplier AI features | Procurement questions for AI use, training data, retention and audit logs | Vendor response pack; contract clauses; renewal review | Procurement |
| Security and incident response | Logging, prompt-injection controls, access limits and reporting route | Security test notes; incident log; near-miss register | Security lead |
| Training and acknowledgement | Role-based induction and annual refresh | Completion report; board training record; policy acknowledgement | HR or company secretary |
Treat the table as a minimum viable evidence set. A larger organisation may add model cards, assurance reviews, audit logs and test results. A smaller charity or school may keep a simpler register. The point is the same: each clause has a named owner and a record that can be inspected.
Map the clauses to current frameworks
A template becomes safer when it maps to recognised frameworks without pretending those frameworks are identical. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and ISO describes it as applying to organisations that provide or use AI-based products or services. NIST's AI Risk Management Framework is voluntary and aims to improve the ability to include trustworthiness considerations in AI design, development, use and evaluation; its 2024 Generative AI Profile adds risks specific to generative AI.
| Framework or duty | What it contributes to the policy | Practical clause |
|---|---|---|
| UK GDPR and ICO guidance | Accountability, data protection by design, fairness, transparency, security and data minimisation | No personal data in unapproved tools; DPIA trigger for high-risk processing |
| ISO/IEC 42001 | AI management system, objectives, policies, risk treatment and continual improvement | Named policy owner, review cadence and AI-use register |
| NIST AI RMF and Generative AI Profile | Trustworthiness and generative AI risk categories | Test prompts, validate outputs, record known limitations and misuse risks |
| NCSC secure AI guidance | Secure lifecycle, logging, monitoring, incident response and supply-chain attention | Access controls, incident route and supplier-security evidence |
| FRC 2024 Code, where applicable | Material controls and board evidence for effectiveness | Quarterly report on AI controls, failures, near misses and overdue actions |
| EU AI Act, where applicable | AI literacy, transparency and certain content-disclosure duties | Training record and disclosure wording for public-facing AI interaction |
Do not overclaim. ISO/IEC 42001 certification is not required for every organisation using generative AI, and NIST AI RMF is not UK law. Their value here is practical: they stop the policy being a list of wishes and turn it into a management system with reviewable evidence.
Next step: turn the template into a board-ready draft
Write the first version quickly, then test it against reality. If the organisation has not yet mapped current AI use, run a short discovery exercise first: sanctioned tools, unsanctioned tools, supplier features, personal-data touchpoints and board-visible decisions. The questions every UK board should ask about AI are a useful opening agenda.
Then draft the policy in nine sections: purpose, scope, definitions, use bands, data rules, human oversight, supplier rules, incidents, training and review. Use our AI policy generator to create a sector-aware starting draft. It is deliberately a draft for amendment, not a document to adopt unread.
After the draft exists, test governance maturity. The Board AI Scorecard is the fast route if the board needs a gap list. The AI governance diagnostic is the assessor-led route if the harder question is whether the policy, the risk register and the real AI use in the organisation match.
