An AI policy for a UK SME should tell staff what they may use, which information must stay out, where human review is required and how a mistake is reported. It should be short enough to use and specific enough to stop an employee guessing at the boundary.
This guide is a starting structure, not legal advice. Adapt it to the organisation's work, contracts, sector and data responsibilities, then obtain appropriate professional review.
Quick Answer
A practical first AI policy needs seven sections: purpose, approved tools, permitted uses, prohibited data and actions, human-review rules, incident reporting and review ownership. Name the policy owner and effective date. Link to the existing privacy, security and acceptable-use rules rather than trying to replace them.
Do not write "staff may use AI responsibly" and leave the decisions undefined. Give examples from the actual business.
1. State The Purpose And Scope
Explain why the policy exists and who it covers.
Example:
"This policy sets the minimum rules for employees and contractors using generative AI or AI-assisted features for company work. It applies to prompts, uploads, generated outputs, automated decisions and integrations used on company devices or with company information."
Name the tools and work types covered. Include AI features embedded in office, design, CRM, support and meeting software, not only public chat tools.
2. Maintain An Approved Tool List
Record which tools are approved, the account type to use, the policy owner, allowed data class and review date. A free personal account and an organisation-managed account may have different controls and terms.
The list should answer:
- May staff create their own account?
- Is a company account required?
- Can prompts or files be retained by the provider?
- Is provider model training disabled where required?
- Which integrations are approved?
- Who reviews material changes to terms or features?
"Approved" is not permanent. Set a review trigger when the provider, use case or data type changes.
3. Define Permitted Uses
Use examples staff will recognise.
Lower-risk uses may include:
- Brainstorming from public or invented information.
- Rewriting non-confidential draft copy.
- Summarising an approved public document.
- Creating an internal checklist for human review.
- Drafting code or formulas that are tested before use.
- Producing meeting actions from an approved note source.
State that outputs are drafts. The employee remains responsible for checking accuracy, bias, copyright, confidentiality, tone and suitability.
4. Define Prohibited Data And Actions
Name what must not be entered without a separately approved route.
Typical boundaries include:
- Passwords, API keys and authentication details.
- Payment-card or bank information.
- Unredacted customer, employee or applicant records.
- Special-category or highly sensitive personal information.
- Confidential contracts, legal advice or commercially sensitive plans.
- Third-party material the business has no right to upload.
- Live production data or account access outside an approved integration.
Also prohibit unreviewed customer messages, pricing decisions, legal or HR decisions, deletion of records and autonomous changes to live systems unless a specific workflow has been assessed and approved.
The ICO UK GDPR guidance and NCSC data-security guidance are useful public starting points. Sector-specific obligations may add more.
5. Set Human Review Rules
Define the reviewer by risk, not by vague seniority.
A practical matrix can require:
- Author review for internal low-risk drafts.
- Subject-matter review for technical, medical, financial or legal-adjacent content.
- Manager approval for customer commitments, prices and deadlines.
- Data-protection or security review for personal data and integrations.
- Executive approval for high-impact automated decisions.
Require the reviewer to check sources and calculations, not merely read for tone. If the output cannot be verified, it should not be used as fact.
6. Add Transparency And Record-Keeping
Decide when customers, staff or suppliers should be told that AI assisted the work. The answer depends on context and risk, but the organisation should not improvise each time.
For higher-risk workflows, keep a lightweight record:
- Tool and version where available.
- Purpose.
- Data class used.
- Human reviewer.
- Final decision.
- Incident or correction.
- Review date.
This creates enough evidence to investigate a problem without recording every harmless prompt forever.
7. Create An Incident Route
Staff need a no-blame first action when confidential information is uploaded, an output is sent incorrectly or an automation behaves unexpectedly.
The policy should say:
- Stop the workflow or sharing where safe.
- Preserve the relevant details.
- Notify the named owner immediately.
- Do not conceal or independently delete evidence.
- Follow the existing security, privacy or customer-incident process.
- Record the correction and policy change.
An incident route is more useful than a policy that only threatens disciplinary action after the mistake.
Copy-And-Adapt Policy Skeleton
Use this structure for the first draft:
- Policy owner, effective date and review date.
- Purpose and people covered.
- Approved tools and account rules.
- Permitted uses with company examples.
- Prohibited data and actions.
- Required human review by risk.
- Transparency and record-keeping.
- Incident reporting route.
- Exceptions and approval process.
- Training and acknowledgement.
- Scheduled and event-driven review.
Keep the document beside the workflow register and approved-tool list. A policy without a working owner or tool inventory will become stale quickly.
Test The Policy With Real Scenarios
Run five short scenarios before launch: summarising a public report, drafting a customer reply, uploading a contract, generating a quote and connecting an inbox. Ask staff to identify what is allowed, what needs review and what is prohibited.
If reasonable people choose different answers, the policy needs a clearer example. Track questions during the first month and update the examples without weakening the boundary.
Use Halo's AI audit flow guide to select the first workflow and the automation guide to define approval before live implementation.
What To Send Halo
Send the current acceptable-use or privacy policy, the approved tools, one proposed AI workflow and the highest-risk information involved. Redacted examples are enough for an initial review.
Use the free AI audit to map the first workflow, approval line and proof signal. Legal, employment, privacy and security advice remain with the appropriate qualified professionals.
FAQ
Does a small business need an AI policy?
If staff or contractors use AI for company work, a short written policy helps make tool, data and review boundaries consistent. The exact legal and governance requirements depend on the business and use case.
Can we use a free AI policy template unchanged?
No. Adapt it to the tools, information, contracts, sector and decisions in the organisation, then obtain appropriate review.
What should employees never paste into an AI tool?
Unless a specifically approved route permits it, keep passwords, keys, payment information, unredacted personal records, confidential contracts and other sensitive business or third-party data out.
Who should own the AI policy?
Choose a named person with authority to maintain the approved-tool list, coordinate privacy and security review, handle incidents and schedule updates.
How often should an AI policy be reviewed?
Set a regular review, such as every six months, and review sooner when a tool, provider term, data type, integration, regulation or business use changes.