AI use policy: one page people actually read

An AI use policy exists for one very concrete purpose: so that anyone, on a Tuesday at eleven, knows whether they can paste that document into an AI tool or not. If answering that question means opening a fourteen-page PDF, the policy does not exist. What exists is a document somebody signed to feel safe while the team carries on doing whatever seems reasonable.

This is not theory. In most mid-sized companies AI already came in through the back door: someone in marketing drafts with an assistant, someone in finance asks it to summarise a contract, someone in support translates a reply to a customer. Nobody has forbidden it and nobody has authorised it. The policy almost always arrives late; the goal is that it arrives useful.

This guide is for directors, IT leads and compliance owners who want a short, workable policy they can defend in an audit or in front of a customer who asks.

What is an AI use policy, and what is it not?

It is the internal document that defines what you can do with AI tools, with which data, and under what supervision. It is not a technical manual, it is not a statement of intent about "responsible AI", and it does not replace your GDPR record of processing activities or your risk assessment.

Three things an AI use policy has to settle, and almost none do:

• The borderline case. Not the obvious one (no, don't paste the customer database). The borderline one: can I ask an assistant to rewrite an email to a supplier if the email contains the agreed price?
• The escape route. If someone needs to do something the policy does not allow, there has to be a door: who to ask, and how fast they answer. If there isn't one, people route around it.
• The consequence. What happens if it is breached. No need for a threatening tone, but it should be written down that this is a workplace rule, not a suggestion.

What it is not: a list of banned tools. That list expires in three months and it pushes people towards shadow AI — use on a personal phone, which is exactly what you don't want.

A policy that works doesn't classify tools. It classifies data. Tools change every quarter; the sensitivity of a payroll file never does.

Which data never leaves? The decision that orders everything else

Before talking about tools, the group has to agree on three or four data tiers. With more tiers nobody remembers them. A scheme that works in companies of 30 to 300 people:

| Tier | Examples | With approved enterprise AI | With public tools | |---|---|---|---| | Public | Press releases, website, catalogue | Yes | Yes | | Internal | Procedures, internal decks, ordinary email | Yes | Only with names and figures removed | | Confidential | Contracts, pricing, proprietary code, identifiable customer data | Yes, with usage logging | No | | Special / critical | Health, minors, criminal records, credentials, trade secrets | Only after a case-by-case assessment | Never |

The row that generates the most argument is "confidential". That is where you should be explicit with examples from your own business, not abstract categories: "a product cost breakdown", "a patient report", "an employee file". People recognise examples; they don't recognise taxonomies.

If your company processes personal data at scale, the AI policy has to connect with the groundwork on data protection. We cover that in GDPR and AI and, when you need to work with real data without exposing it, in data anonymisation.

Which tools get approved, and on what criteria?

Approve categories with conditions, not brands. For each category, define the entry criteria:

• General-purpose generative assistants. Minimum condition: a corporate account (not personal), training on your data turned off, and known, acceptable conversation retention.
• AI built into software you already run (ERP, CRM, office suite). It usually inherits the contract you already have, but you need to check whether the AI feature adds a new sub-processor.
• Vertical tools (meeting transcription, contract review, customer support). These touch the most sensitive data and most often arrive without IT ever seeing them. Require a data processing agreement and clarity on where processing happens.
• Models deployed on your own infrastructure. More control, more maintenance cost. Relevant when the data cannot leave by contract or by regulation.

A practical test for onboarding a new tool, in five questions that fit on a form:

1. What data will it see, at what classification tier? 2. Is there a data processing agreement, and where is the data processed? 3. Does it train on our data? How long are conversations retained? 4. Who will use it, and for what specific task? 5. Who reviews it in six months, and what happens if we cancel?

If a request doesn't pass those five, it isn't banned: it's pending. The difference matters, because it keeps the team asking instead of hiding.

Who reviews the output, and who owns the mistake?

This is the part copied policies skip, and the part that actually prevents trouble. The base rule: the person using the tool signs off the result. AI is not an author and not accountable; it produces a draft.

Define three levels of supervision depending on the impact of the task:

• No mandatory review. Internal drafts, summaries for your own use, brainstorming. Low risk — don't bury it in process.
• Review by the author. Anything that goes outside, customer replies, technical documentation. Reviewed before sending, and it is clear that the error belongs to the author, not "to the system".
• Second pair of eyes plus logging. Decisions affecting people (hiring, performance, credit, individualised pricing) or safety. Here you need to be able to reconstruct who decided what and on what basis, because that is what you will be asked.

That last level is also where European regulation bites: some uses are classified as high risk and carry obligations on human oversight and traceability. If you touch any of them, read what the EU AI Act means for SMEs before drafting that section.

What does a one-page AI policy look like?

A real page, in this order. If it runs longer, the surplus belongs in an annex nobody needs in order to work:

| Section | What it says | Length | |---|---|---| | Why it exists | One sentence: safe and useful AI at work | 2 lines | | Who it applies to | Staff, interns, freelancers and suppliers with access | 2 lines | | Which data never leaves | The tier table with examples from your business | 8 lines | | Approved tools | Categories and conditions, linked to the live list | 6 lines | | How to request a new one | Form, who to ask, response time | 3 lines | | Output review | The three levels of supervision | 6 lines | | Prohibited uses | A short, concrete list | 5 lines | | What happens if breached | Reference to the existing disciplinary framework | 2 lines | | Who maintains it | Name and role, next review date | 2 lines |

The "live list" of approved tools lives separately, on the intranet, with a last-updated date. That way you can add a tool without re-approving the whole policy.

Prohibited uses worth naming explicitly, because they cause real incidents: uploading credentials or keys; generating content that impersonates a real person; using AI to make a final decision about a person without human review; putting proprietary code into unapproved tools; and publishing generated content as your own without checking it.

Why do copied policies fail?

We have seen enough downloaded templates to recognise the pattern. They fail for four reasons:

• They ban everything. A policy that says "the use of generative AI is not permitted" in 2026 guarantees exactly one thing: that the usage moves to personal phones, outside any control. Banning without an alternative makes the risk worse.
• They talk about technology, not work. Paragraphs about language models and algorithmic bias tell nobody whether they can summarise meeting minutes.
• They have no owner. Without a name and a review date, the document ages and nobody notices. Put both on the last line.
• They are never taught. Publishing the policy in a folder is not rolling it out. You need a 30-minute session per team, using that team's real cases. It is the same adoption problem as always, and we cover it in AI training for teams and in change management.

There is a fifth, less visible reason: the policy gets written in compliance and published without IT checking what is already happening. Before drafting, look at network traffic or at corporate card spend. You will discover tools in use you didn't know existed, and that list is the best index for your policy.

How do you roll it out so it doesn't end up in a drawer?

Four weeks is a reasonable timeline for a company of 50-300 people:

| Week | What happens | Who | |---|---|---| | 1 | Inventory of actual usage + data map by department | IT + department heads | | 2 | Drafting the page and the live tool list | Compliance, reviewed by management | | 3 | 30-min sessions per team with their own cases; questions collected | Each department head | | 4 | Adjust with the questions collected, publish, open the request channel | Compliance |

From then on, two routines: a half-yearly review of the document, and a review of each new tool as it comes in. Add a fixed five-minute slot to the management meeting; it is cheaper than an emergency audit.

Frequently asked questions

Is an AI use policy mandatory?

No rule demands that specific document under that specific name. But if you process personal data, GDPR requires you to demonstrate adequate organisational measures, and if you use high-risk systems, the EU AI Act requires oversight and traceability. The policy is the practical way to evidence both.

Can the team use personal accounts on AI tools?

That is the scenario that causes the most incidents: no contract, no control over retention, and no way to revoke access when that person leaves. The recommendation is to prohibit personal accounts for work and, at the same time, provide a corporate alternative. Banning without an alternative does not work.

How often should the policy be reviewed?

Every six months as routine, and whenever a new tool with access to confidential data arrives or a relevant legal obligation changes. If the last review date is more than a year old, the document is no longer protecting anything.

Who should own the policy?

Someone with the authority to say no and the time to answer within 48 hours: usually IT leadership, compliance, or a small committee with both. What does not work is spreading responsibility across five people with no name in the document.

---

If you would rather start from a real picture before writing anything, our audit includes an inventory of the AI already in use across the company and a data map by department — exactly the material a policy that holds up is built from. And if you already have a draft on the table, let's talk: half an hour is usually enough to see whether it protects anything or just provides reassurance.