An AI acceptable use policy tells people which AI uses are permitted, conditional or prohibited, who approves exceptions, what data may enter tools, and what evidence proves compliance. For boards, it is the operating rulebook that turns AI risk appetite into daily behaviour.
The policy is not a staff handbook paragraph saying "use AI responsibly". It is the bridge between the board's risk appetite, the organisation's AI policy, its shadow AI discovery work, the first generative AI policy draft, and the control evidence a regulator, auditor or data protection officer can inspect.
Key takeaways
- Acceptable-use rules should classify uses, not brand names. A sanctioned tool can still be used badly, and an unsanctioned tool can process data the board remains accountable for.
- The board has to decide the red lines: personal data, special-category data, client confidentiality, automated significant decisions, regulated advice and public-facing output.
- A three-band model works best: permitted, conditional and prohibited. The conditional band is where approval routes, data minimisation, human review and logging sit.
- Evidence matters more than wording. The board should expect approval logs, training records, incident reports, tool inventories and review minutes.
- UK data protection duties apply now. The ICO's AI guidance covers accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights.
- The next step is not another blank template. Generate a working draft, then test it against actual use through the Scorecard or a diagnostic.
What an AI acceptable use policy must decide
The board's job is not to approve every prompt. It is to set the boundary conditions under which people may use AI without escalating each routine task. That needs five board decisions.
First, decide what counts as AI for the policy. A narrow definition that names only ChatGPT or Copilot will miss embedded AI in CRM, HR, finance, meeting transcription, search and document tools. Use a functional definition: systems that generate content, make predictions, recommend decisions, classify records or summarise material from data.
Second, decide which data may never enter an external or consumer AI tool. The ICO's guidance on AI and data protection anchors the data-protection issues: accountability, transparency, lawfulness, fairness, accuracy, security, data minimisation and individual rights. An acceptable-use rule should therefore name prohibited inputs in plain terms: personal data without an approved lawful basis and processor route, special-category data, credentials, confidential client material, unpublished board papers, commercial secrets and security information. Where the use case is likely to be high risk for individuals, the rule should point to the DPIA guide rather than leaving teams to self-assess.
Third, decide when human review is mandatory. The UK government's AI Playbook, published on 10 February 2025, includes meaningful human control, secure use, lifecycle management and assurance among its principles. For a board, that means no AI output should be treated as final where the output affects a person, a customer, a resident, a trustee decision, a regulated recommendation, a procurement decision or a public statement.
Fourth, decide who may approve conditional use. This cannot be "ask your manager" in every case. The approver should be named by risk type: data protection officer for personal data, legal or compliance for regulated advice, information security for tool access and integrations, HR for workforce monitoring or recruitment, and a senior business owner for material operational decisions.
Fifth, decide what evidence reaches the board. The standing report should show the number of conditional-use approvals, red-line incidents, tools added or declined, training completion, policy exceptions, and open risk-register items. That links the document to the wider UK AI governance framework and gives directors something they can challenge.
Who it applies to, and where use sits
The policy should cover employees, directors, trustees, contractors, volunteers, agency staff and suppliers who access organisational information. In charities, schools, housing associations and professional-services firms, the least formal users can handle the most sensitive material, so the policy should not stop at payroll employees.
The practical structure is a three-band model.
| Band | Examples | Rule |
|---|---|---|
| Permitted | Drafting from a blank page, summarising public documents, preparing internal first drafts, formatting notes | Use an approved tool, verify the output, disclose AI assistance where the document owner requires it |
| Conditional | Internal confidential material, anonymised data, supplier analysis, staff-facing guidance, board-pack summaries | Named approval, data minimisation, approved tool only, output checked by a competent person, decision logged |
| Prohibited | Special-category data in consumer tools, credentials, client secrets, personal data without an approved route, automated significant decisions, regulated advice treated as final | Do not use AI unless the board has approved a separate assessed system with documented safeguards |
This model also gives staff a route to ask rather than conceal. A blanket ban often moves use to personal accounts, which weakens the evidence trail the board needs. The better control is to make low-risk use easy, conditional use visible, and prohibited use precise enough to enforce.
Public-sector organisations can borrow the discipline of the AI Playbook even when they are not formally in scope. It says AI users should know AI's limitations, use it lawfully, use it securely, maintain meaningful human control and use the organisation's policies with assurance. Those are acceptable-use requirements, not abstract principles.
Controls and evidence the board should expect
The policy has done its job only when each rule has an owner and evidence.
| Control | Evidence | Owner |
|---|---|---|
| Tool inventory | Register of approved, conditional and blocked AI tools, including vendor, data terms and owner | CIO or technology lead |
| Data-entry restrictions | Data-classification rule, blocked examples, approved enterprise tool settings, staff acknowledgement | Data protection officer |
| Conditional-use approval | Approval log showing use case, data type, approver, expiry date and conditions | Risk or compliance lead |
| Human review | Record of reviewer, decision type, output checked, changes made and final accountable person | Business owner |
| Incident route | AI incident category in the existing breach, security or conduct reporting route | General counsel or risk lead |
| Training and literacy | Role-based completion record, induction material and refresher cadence | People lead with risk support |
| Supplier controls | Procurement questionnaire, processor terms, training-data position and notice of AI feature changes | Procurement and legal |
| Board reporting | Quarterly report with approvals, incidents, exceptions, new tools and unresolved risks | Executive sponsor |
Security deserves its own line because generative AI changes the boundary between instruction and data. The NCSC warns in its prompt-injection guidance that current large language models do not enforce a security boundary between instructions and untrusted content inside a prompt. An acceptable-use rule should therefore restrict high-risk workflows where an AI tool reads untrusted emails, web pages, documents or tickets and is also allowed to take action.
Supplier controls also need more than a yes or no answer. The board should know whether prompts and outputs train the supplier's model, where data is processed, how logs are retained, who can administer access, whether outputs can be exported, and whether the supplier gives notice before new AI features are switched on. Those questions belong with the board questions about AI, the AI procurement checklist and the supplier due-diligence guide, not in an IT appendix nobody reads.
Framework mapping for UK organisations
Different frameworks use different language, but they point to the same practical policy duties.
| Framework or regulator | What it means for acceptable use |
|---|---|
| ICO AI and data protection guidance | Rules for data entry, DPIAs, lawfulness, transparency, fairness, security, data minimisation, accuracy and individual rights |
| NIST AI Risk Management Framework | A voluntary risk framework for improving trustworthiness across the design, development, use and evaluation of AI systems |
| ISO/IEC 42001 | An AI management system standard for organisations providing or using AI-based products or services, with requirements for maintaining and improving the management system |
| EU AI Act | If in scope, the Act's Article 4 requires AI literacy measures for staff and others dealing with AI systems, and Article 50 includes transparency duties for certain AI interactions and synthetic content |
| FCA approach to AI | For financial-services firms, the FCA says it does not plan extra AI regulations and will rely on existing frameworks, including Consumer Duty and senior-manager accountability |
| NCSC prompt-injection guidance | Acceptable-use rules should treat untrusted content, tool actions and integrations as security risks, not only as accuracy risks |
This mapping matters because the UK does not ask every board to follow one single AI statute. A policy is therefore the place where the board joins existing duties into one operational rule: data protection from the ICO, security from NCSC, sector accountability from the relevant regulator, and management-system discipline from ISO 42001 where certification or assurance is part of the organisation's plan.
Common mistakes that weaken the policy
The first mistake is writing a tool list instead of a use rule. Tool lists age quickly and can produce false comfort. If the policy permits an approved chatbot for "general drafting", staff need to know whether a tenant complaint, a safeguarding note, a client file or an employee grievance counts as general drafting. The answer should be in the use band, not in a buried FAQ.
The second mistake is putting every difficult case in the prohibited band. If the policy has no conditional route, people either stop useful work or continue without asking. A conditional route lets the organisation learn what demand exists, approve low-risk variants, and refuse uses that cross the board's red lines.
The third mistake is treating disclosure as a moral preference. Disclosure is context-specific. A board paper may need an internal note that AI assisted the first draft. A public chatbot may need a clear user-facing notice. A regulated recommendation may need a stronger human-review record. The EU AI Act's transparency rules are one reason to date and scope this section carefully for organisations with EU-facing systems.
The fourth mistake is omitting review. The policy should have an owner, a review date, and triggers for earlier review: a serious incident, a new supplier, a new class of AI feature, a sector-regulator update or a material change in the organisation's risk appetite. A policy adopted once and forgotten is weak evidence.
The fifth mistake is ignoring adoption. A policy that no one uses is an unmanaged risk. Track approved-tool usage, conditional requests and incident reports together. If the approved tool has no adoption but staff surveys show AI use, the policy is not controlling behaviour.
Next step
Use the Governance AI policy generator to produce a first board-ready draft, then test that draft against what staff and suppliers actually do. If you need a ten-minute gap check first, use the Board AI Scorecard. If the policy needs to sit inside a wider governance system, the AI governance diagnostic reviews policy, risk register, controls, evidence and board reporting together.
Sources
- ICO, Guidance on AI and data protection
- GOV.UK, Artificial Intelligence Playbook for the UK Government
- NCSC, Prompt injection is not SQL injection
- NIST, AI Risk Management Framework
- ISO, ISO/IEC 42001:2023
- EUR-Lex, Regulation (EU) 2024/1689, Artificial Intelligence Act
- FCA, AI and the FCA: our approach
- Governance AI, AI policy generator
