Policy

What to put in an AI acceptable-use policy

A practical, section-by-section guide to what an AI acceptable-use policy should contain, and why a policy only counts when paired with evidence.

29 May 2026 · 7 min read

Most organisations now have an AI acceptable-use policy, or know they need one. The harder question is what should actually go in it. A policy that is too vague gives staff no real guidance; one that is too restrictive gets ignored, and shadow use moves out of sight. The aim is a document people can read in ten minutes and act on, that a regulator, auditor or customer would recognise as a genuine control.

This is a working guide to the sections an AI acceptable-use policy should cover, and the reasoning behind each one. It is not legal advice, and you should adapt it to your sector and your own risk appetite.

Start with purpose and scope

Open by saying why the policy exists. Staff are more likely to follow rules they understand, so explain in plain terms that the organisation wants people to use AI tools productively while protecting client data, confidential information and the organisation's reputation.

Then define scope precisely, because ambiguity here is where most policies fail:

  • Who it applies to — employees, contractors, temporary staff and anyone acting on the organisation's behalf.
  • Which tools — public chatbots, AI features built into existing software, browser extensions, and any API-based tools or agents your teams build or integrate.
  • Which devices — corporate laptops, personal devices used for work, and mobile.

If the policy is silent on personal devices or embedded AI features, people will assume those are out of bounds and use them anyway.

List the approved tools

Vague guidance such as "use approved tools only" is not enough if no one can find the list. Maintain an Approved AI Register: a short, named list of the tools staff may use, with the approved plan or tier, and what each may be used for. A free consumer chatbot and an enterprise instance with data-processing terms are not the same risk, and the register should make that distinction explicit.

The register also tells you what *good* looks like when something goes wrong. If an incident involves a tool that was never on the list, you have a clear answer about whether policy was followed.

Say what must never go into AI

This is the section staff will refer to most, so make it concrete. Set out the categories of information that must never be entered into an AI tool unless it has been explicitly approved for that purpose:

  • Client and personal data — names, contact details, case information, anything that identifies an individual.
  • Confidential and commercially sensitive material — contracts, pricing, strategy, unpublished financials, intellectual property.
  • Credentials and secrets — passwords, API keys, access tokens, internal system details.

Give examples drawn from your own work so the rules feel real rather than abstract. The point is not to ban AI but to stop sensitive material leaving your control through a prompt box.

Explain how output must be used

AI output is a draft, not a decision. State clearly that anything an AI tool produces must be reviewed by a competent person before it is sent to a client, relied on in a decision, published, or used as the basis for advice. Make a named human accountable for the result, not the tool.

AI can speed up the first 80% of a task. The remaining 20% — checking the facts, the tone, the legal position — is still a human responsibility, and the policy should say so.

This matters most where output feeds a regulated decision: lending, eligibility, hiring, clinical or legal judgements. Spell out that AI may assist but must not be the decision-maker.

Be transparent about monitoring

If you monitor AI use, tell people. Transparency is both fair and, in the UK and EU, a legal expectation. Cover three things:

  • A staff notice that explains AI use is monitored, what is captured and why.
  • A lawful basis for that monitoring under data protection law.
  • A DPIA (data protection impact assessment) where monitoring captures the content of prompts and responses, rather than just metadata.

A sensible default is to capture metadata — which tool, when, by whom — rather than full content, escalating to content capture only where the risk justifies it and the assessment supports it. Covert monitoring is rarely defensible; the policy should commit you to doing it openly.

Address personal accounts and shadow AI

Shadow AI — staff using personal accounts or unapproved tools to get work done — is the most common way policies are quietly bypassed. Name it directly. State whether personal AI accounts may be used for work at all, and if not, give people an approved alternative so they are not stuck. A policy that bans the convenient option without offering a workable one simply drives use underground.

Set out roles, breaches and review

Close with the operational detail that makes the policy enforceable:

  • Roles and responsibilities — who owns the policy, who maintains the Approved AI Register, who approves new tools, and where staff go with questions.
  • Breaches — what happens when the policy is not followed, how to report a suspected breach, and that honest mistakes reported promptly will be handled differently from deliberate misuse.
  • Review cadence — a fixed date, at least every six to twelve months, because the tools and the law are moving quickly. A policy dated two years ago and never revisited signals neglect.

A policy is not evidence

Here is the part that is easy to miss. A well-written policy tells people what to do. It does not, on its own, prove that anyone did it. If a client, auditor or regulator asks how you know your rules were followed, a PDF in a shared drive is not an answer.

To make the policy real, pair it with two things. First, a tamper-evident record of AI use, so you can show what was used, by whom and when — the difference between *we have a policy* and *here is the evidence it was followed*. This is what Evaident is built to capture. Second, for API-based tools and agents, real-time gateway enforcement that can actually block UK PII, secrets and customer-defined terms before they leave your environment, rather than relying on staff to remember the rules under deadline pressure. Enforcement turns a policy from an aspiration into a control.

Writing the policy is the easy part. To see where your current AI use sits and what evidence you can produce today, start with an exposure check. Evaident provides brandable templates — an AI acceptable-use policy, an approved-AI register and a staff notice — as a practical starting point you can adapt. For a guided rollout, our partners deliver these alongside implementation, or see how we handle trust and evidence. These resources support your compliance work; they are not a substitute for legal advice.

See where your firm stands

The free AI Exposure Check gives you an instant score across visibility, shadow AI, evidence, governance and data-leak risk — no data connection needed.