AI Policy Template for UK Businesses: Practical Rules Your Team Can Use

An AI policy template for a UK business should help someone make a good decision at the moment of use. If an employee has to ask “Can I paste this?” or “May I send this output?”, the policy should give a clear answer or route them to a named owner.

That is why a useful policy is not a collection of aspirations such as “use AI ethically”. It connects seven operational questions:

1. Which tools and accounts are approved?
2. What information may enter them?
3. What work may AI support?
4. What must a human verify or decide?
5. When must people be told about AI involvement?
6. What evidence must be retained?
7. Who stops, investigates and corrects a problem?

Use the interactive generator above to create a tailored first draft. Then work through this guide to replace the placeholders, test the rules against real scenarios and approve the right supporting procedures.

Start with three layers, not one oversized document

Many AI policies fail because they mix principles, staff instructions and technical controls into one long file. Separate them.

Layer	Audience	Purpose	Typical length
AI policy	Board, leadership, owners	Sets risk appetite, accountability and non-negotiable principles	2–4 pages
AI acceptable use standard	All users	Says what people may use, enter, create and share	2–5 pages
Use-case procedure	Named team and reviewers	Defines the exact data, steps, tests, approvals, records and fallback	As needed

The policy should remain stable. The approved-tool register and procedures can change more frequently as suppliers, models and workflows evolve.

For a small organisation, these may sit in one pack. Keep the headings distinct so a person can find the operational rule without reading a governance essay.

An interim rule you can publish in 48 hours

If staff already use public AI tools and no policy exists, do not wait months for a perfect framework. Publish a short interim notice while you inventory use.

Use only the organisational AI accounts currently approved by [owner]. Do not enter personal, client-confidential, commercially sensitive, privileged, credential, payment or special-category information unless that exact tool and use have written approval. Treat every output as unverified: check sources, accuracy, confidentiality, rights, bias and suitability before use. A human must approve anything sent externally, published, used to change a record or used in a decision affecting a person. Report suspected exposure, harmful output or unexpected tool behaviour to [contact] immediately.

This is deliberately conservative. Replace it with scenario-tested rules and a positive approved-use list quickly; otherwise employees may continue useful work through unrecorded workarounds.

Assign decisions to roles

“The company is responsible” does not tell anyone who decides.

Decision	Accountable role	Evidence to maintain
Policy risk appetite	Senior accountable owner	Approved policy and review record
Approved tools, accounts and connectors	IT / security / procurement owner	Register, supplier assessment, configuration
Personal-data use	Data protection owner	Purpose, lawful basis, DPIA decision, notices and terms where required
Correct output and human review	Process owner	Test set, acceptance criteria, reviewer guide
Workforce expectations and training	HR / learning owner	Communications, scenario training, completion evidence
Legal, contractual and sector questions	Legal / compliance owner	Advice, approvals and conditions
Incident containment	Security / privacy incident owner	Report, actions, notifications and lessons

One person may hold several roles in a small firm. The decisions still need to be explicit.

Build the approved-tool register first

A policy that says “use approved AI” without listing approved tools is incomplete. Maintain a register people can actually find.

Tool / embedded feature:
Approved organisational account:
Business owner:
Permitted users:
Permitted use:
Permitted information class:
Prohibited information:
Connected systems and permissions:
Retention / supplier-use configuration:
Output or action limits:
Required human approval:
Record category and retention:
Approval date and next review:
How to request a new use:

Do not assess only standalone chat services. AI may be embedded in email, meeting, design, analytics, CRM, recruitment, coding and customer-service platforms. A familiar vendor name does not mean every feature and connector has the same data path.

Use data traffic lights with real examples

Generic phrases such as “do not share sensitive data” require staff to invent the definition. Use examples from your work.

Green — permitted in named approved tools

• public webpages and published brochures;
• synthetic or fictional test cases;
• templates cleared for the intended tool;
• organisational information explicitly classified for that account and purpose.

Amber — ask the named owner before use

• internal plans, pricing or unpublished materials;
• ordinary personal information;
• customer or supplier content;
• contract-controlled information;
• source code, datasets or creative assets with uncertain rights;
• material that becomes more sensitive when combined.

Amber does not mean “allowed if careful”. It means a defined person must resolve the purpose, account, terms, access, retention and downstream use.

Red — prohibited unless a separately approved procedure exists

• passwords, secrets, access tokens and security keys;
• payment-card or bank credentials;
• special-category or highly sensitive personal information;
• legally privileged material;
• confidential information a contract forbids sharing;
• content used to evade controls, deceive or unlawfully discriminate;
• live data in an unapproved public or personal account.

These examples are not universal legal categories. Adapt them to your information-classification scheme and contracts.

Twelve sections for a practical workplace AI policy

The generator above produces starter text. Use these questions to make each section real.

1. Purpose

State the positive result: enable useful AI-assisted work while protecting people, information, rights, security and trust. Avoid promising zero risk.

2. Scope

Cover employees, contractors, temporary staff and anyone using AI for organisational work. Include standalone tools, embedded features, custom workflows and agents.

Clarify whether the policy covers personal devices or accounts. “We did not provide the tool” is not a control when work information enters it.

3. Ownership and exceptions

Name the accountable policy owner, operational contacts and approval route. Set a written exception process with a scope, conditions, expiry and reviewer. Verbal permission should not become a permanent control.

4. Approved tools and procurement

Require organisational accounts where appropriate. Assess supplier terms, model training or service-improvement use, retention, access, international transfers, sub-processors, security, export, deletion and exit before approval.

For connected tools, document every system and permission. A meeting assistant with calendar, microphone, transcript and document access is not simply a note-taking tool.

5. Acceptable uses

Give role-specific examples:

• summarise an approved internal document and verify against the source;
• draft alternatives from an approved brief;
• classify cases for a person to review;
• explain a public concept while checking authoritative sources;
• prepare code or formulas for testing, review and controlled release.

Positive examples reduce shadow use more effectively than a document made only of prohibitions.

6. Prohibited uses

Prohibit outcomes, not just categories of prompt. Include:

• exposing protected information or credentials;
• bypassing access, procurement or review controls;
• impersonation, deceptive media or misleading attribution;
• unlawful, discriminatory, harassing or harmful material;
• fabricated sources, evidence or records;
• unapproved legal, financial, clinical, employment or eligibility decisions;
• automatic publication, commitment, purchase, deletion or access change outside an approved procedure.

7. Verification and human review

“Check the output” is too vague. State what the reviewer must inspect:

• claims against authoritative sources;
• calculations and extracted fields;
• missing context and uncertainty;
• confidential or personal information;
• bias, accessibility and impact on affected groups;
• copyright, licence, attribution and brand rules;
• destination, recipient and exact action.

The reviewer must have competence, time, information and authority to reject or correct the output.

8. Decisions affecting people

Separate decision support from decision authority. Recruitment, performance, credit, insurance, access to services and other consequential areas need use-case-specific review.

Meaningful human involvement is not clicking accept. Define which additional evidence the decision-maker considers, how they challenge the model, what is recorded, what affected people are told and how they can request human intervention or contest the result where applicable.

9. Transparency and attribution

Do not force a generic “made by AI” label onto every internal spelling correction. Define when disclosure is material: public synthetic media, customer interaction with an automated service, professional or academic requirements, a decision materially influenced by AI, or wherever law, contract or reasonable expectation requires it.

Make the disclosure useful. Explain the role AI played and how a person can obtain help or challenge an outcome.

10. Intellectual property and confidential material

Require users to respect licences, confidentiality and third-party rights in both inputs and outputs. Generated content is not automatically safe to publish or own. Keep evidence of approved sources, licences and human contribution where the value or dispute risk warrants it.

11. Records and incidents

Define which uses create records. For a material output or action, retain proportionate evidence of the input sources, relevant output, reviewer, approval, tool/version and final decision.

Create a simple incident route for:

• suspected personal or confidential-data exposure;
• harmful, discriminatory or misleading output;
• unexpected connector or agent action;
• credential or account compromise;
• prohibited use or a material near miss.

Tell staff to stop, preserve relevant evidence and contact a named role. The incident team decides containment, investigation and any notification.

12. Training, monitoring and review

Train with scenarios from actual roles. A sales team, software team and HR team face different data, evidence and decision risks.

Review the policy after:

• a material supplier term or configuration change;
• a new model, connector, memory or agent capability;
• a new category of personal or confidential information;
• a use affecting people or customers;
• an incident, complaint or failed test;
• relevant legal or regulator guidance changes.

Set a regular review date as a backstop, not the only trigger.

Add a separate approval gate for higher-risk use cases

The everyday policy should route a proposal into deeper assessment when any of these are true:

• personal or special-category data is involved;
• the system acts across email, CRM, finance, HR or production systems;
• output reaches customers or the public without line-by-line review;
• the use influences a decision with legal or similarly significant effects;
• vulnerable people or essential services may be affected;
• the model monitors, scores or profiles workers;
• biometric, health, finance, legal or safety information is involved;
• failure is hard to detect, reverse or contain.

Use this approval card:

Use-case owner and purpose:
People affected:
Current process and decision rights:
AI role and explicit exclusions:
Data, sources and lawful basis where required:
Tool, supplier, account and connectors:
Expected benefit and baseline:
Normal, edge, bias, adversarial and prohibited tests:
Human review and challenge route:
Transparency and records:
Security, limits, fallback and incident response:
Specialist reviews required:
Approval, expiry and re-assessment triggers:

The output is a decision and operating procedure, not another general principle.

Test the policy against eight workplace scenarios

Training should make people practise the decision route.

Scenario	Expected policy answer
Rewrite a published webpage in an approved account	Usually green; verify accuracy, rights and brand
Paste an unredacted client complaint into a personal AI account	Stop; use the approved route and resolve confidentiality and personal-data questions
Summarise a contract with an approved enterprise tool	Amber; confirm tool, purpose, access, terms and legal-review boundary
Draft a job description	Permitted support; check discriminatory language and keep hiring decisions human
Rank candidates automatically	Higher-risk approval; assess data, fairness, transparency, meaningful human involvement and challenge route
Let an agent email customers from the CRM	Separate connected-use procedure with least privilege, approved claims, action limits, approval, monitoring and rollback
Generate an image in a living artist’s recognisable style	Route to rights and brand guidance; do not assume output is safe because it is generated
Notice that confidential information was entered into the wrong tool	Stop, preserve evidence and report immediately; do not quietly delete and continue

Record where participants disagree. That reveals the clause or example that needs rewriting.

The UK legal and regulatory context in August 2026

The UK does not reduce workplace AI governance to one universal “AI Act” checklist. Existing law and regulator expectations apply according to the use.

The ICO’s AI and data protection guidance explains how UK data-protection principles apply to AI systems processing personal data and points organisations to risk and transparency resources. It also makes clear that other frameworks—including equality and sector-specific law—may apply in addition.

The Data (Use and Access) Act 2025 changed parts of the UK data-protection framework, including provisions concerning solely automated significant decisions. The Act’s explanatory notes on automated decision-making describe safeguards including information, the ability to make representations or contest a decision, and human intervention for significant decisions based solely on automated processing. Do not translate this paragraph into a generic approval: determine the current provisions, commencement and application to the specific use with appropriate expertise.

The ICO’s technology guidance plan says final updated guidance on automated decision-making and dedicated agentic-AI guidance are due in winter 2026. Put that review trigger into the policy now.

For systems affecting consumers, the Competition and Markets Authority’s 2026 agentic AI work stresses that businesses remain responsible for fair consumer outcomes even when AI acts. For security, the UK Government’s AI Cyber Security Code of Practice offers baseline principles for developers and deployers.

Depending on the organisation, also consider employment and equality law, consumer protection, intellectual property, confidentiality, professional duties, records obligations, financial-services or health regulation, and contractual restrictions. A policy should route these questions to competent owners rather than pretending one template resolves them.

Common policy failures and the repair

“Use AI responsibly”

Why it fails: no operational decision.

Repair: list approved tools, information classes, permitted examples, prohibited outcomes, reviewers and incident contact.

A blanket ban nobody believes

Why it fails: useful embedded features and shadow AI continue without visibility.

Repair: provide a safe positive route, approved accounts and fast use-case requests while keeping red lines explicit.

A tool list without use limits

Why it fails: an approved platform may still be wrong for a particular dataset, connector or decision.

Repair: approve the combination of tool, account, information class, purpose and action.

Human review with no reviewer design

Why it fails: people rubber-stamp plausible output.

Repair: define evidence, competence, workload, decision authority and seeded-error tests.

Policy without technical controls

Why it fails: a paragraph cannot stop an over-privileged connector or irreversible action.

Repair: pair rules with identity, least privilege, allow-lists, limits, logs, approval gates and rollback.

No ownership after launch

Why it fails: tools and practices change while the document stays frozen.

Repair: assign owners, review evidence and use material-change triggers.

A seven-day implementation plan

Day 1 — discover current use

Ask teams which standalone and embedded tools they use, which accounts, what information enters them and which outputs affect external work. Make discovery learning-focused; a punitive tone hides the evidence.

Day 2 — publish interim boundaries

Name the owner, approved accounts, red data, external-output approval and incident contact.

Day 3 — assess and register tools

Record purpose, terms, configuration, retention, supplier use, access, connectors and exit. Suspend uses whose risks cannot yet be answered.

Day 4 — draft the three layers

Approve the policy principles, staff acceptable-use rules and a separate use-case card. Keep language observable: “must use”, “must not enter”, “requires approval from”.

Day 5 — scenario workshop

Run at least eight role-specific cases. Rewrite clauses that produce inconsistent answers.

Day 6 — configure and communicate

Apply access, sharing, retention and connector controls. Publish the tool register, request form, incident route and short manager briefing.

Day 7 — establish evidence and review

Record approval, owners, training, exceptions and next review. Select representative outputs or actions for proportionate quality and compliance checks.

Evidence that the policy is operating

A signed PDF proves approval, not effectiveness. Maintain a proportionate evidence pack:

• current policy, standard and use-case procedures;
• approved-tool and connector register;
• supplier and configuration decisions;
• training scenarios and completion evidence;
• approvals, exceptions and expiry dates;
• representative tests and review findings;
• incidents, near misses, corrections and lessons;
• review log after material changes.

Avoid collecting every prompt forever by default. Records themselves can create privacy, security and retention risk. Define what evidence is necessary for which use.

Useful operational measures include:

• percentage of active AI tools with a named owner and review date;
• percentage of higher-risk uses with an approved procedure;
• time from a use request to a reasoned decision;
• scenario-training error patterns;
• output-review failures by type;
• incidents and near misses, including whether staff reported them promptly;
• overdue tool, permission and policy reviews.

Do not reward a low incident count without context. It may mean staff do not recognise or report problems.

Questions for a supplier review

1. Which input, output and usage data are retained, where and for how long?
2. Are they used to train or improve models or services, and what controls exist?
3. Which subprocessors and international transfers apply?
4. Can administrators control sharing, connectors, memory and external actions?
5. Can we enforce least privilege and separate service identities?
6. What logs, exports, deletion and subject-rights support are available?
7. How are material model, term, security or data-use changes communicated?
8. What happens to our data, prompts, configurations and records at exit?
9. How does the service handle prompt injection, abuse, duplicate actions and compromised credentials?
10. Can we test the exact proposed use before commitment?

The answer “enterprise-grade” is not evidence. Record the contractual and configured control.

The practical next step

Generate the starter draft above and replace every placeholder. Then test it with three people from different roles using the eight scenarios. If their answers differ, improve the rule before adding more pages.

For a facilitated policy-and-practice session, use an AI workshop for business. If the policy must support connected systems or agents, combine it with the operating controls in the AI agents for business guide. For broader workforce capability, explore corporate AI training in London or online.