An AI use policy for a 30-person company

Probably, and it is shorter than the templates suggest. If staff put company data into AI tools, someone has to write down which tools are allowed, what must never go in, who reviews the output, and what happens when it goes wrong. Two pages covers it. The work is in the decisions, not the wording.

The policy also does a job the paperwork cannot. Whether you are a provider or a deployer sets your legal duties, and whether a system is high-risk under Annex III sets how heavy they get, but neither tells the person in your sales team whether they can paste a client contract into a chatbot at half past four on a Friday. That is what a policy is for.

An AI use policy is a short document that sets four things: which tools staff may use, which data must never enter a prompt, when AI involvement is disclosed, and which decisions still need a person.

Do you need one?

If nobody in the company touches an AI tool, no. That company is rare, and usually mistaken about itself.

For everyone else there is a floor. Article 4 of the EU AI Act has applied since 2 February 2025 and binds every provider and deployer regardless of risk tier, including a company whose only AI use is staff typing into a general chatbot. It asks you to take measures so people operating AI on your behalf know enough to do it safely. There is no required governance structure, no AI officer, no board. A written policy plus a dated note of who was briefed on it is the cheapest evidence that you took measures, and it sits alongside the rest of the documentation pack.

The other reason bites sooner. Enterprise buyers have added AI questions to their security questionnaires, and the question is rarely "do you use AI". It is "what stops your staff pasting our data into a model we have no contract with". A policy that answers that in four lines gets through procurement. A policy that says the company is committed to responsible AI does not.

Scope: who and what it covers

Name the people first. Employees, contractors, and any agency working on your systems. Contractors are the gap most policies leave open, because they are onboarded by a project manager rather than by HR and nobody hands them the document.

Then name what counts as an AI tool, and be broader than instinct suggests. Standalone assistants are the obvious case. The harder ones are AI features inside tools you already pay for, which arrive by product update rather than by procurement, and AI written into products you build for other people. A policy scoped to "AI tools" and read narrowly leaves both of those uncovered.

Say what is out of scope too, by name. Spam filters and autocomplete do not need governing, and a policy that pretends otherwise gets ignored wholesale rather than in part. Naming the exclusions is what buys the rest of the document its credibility.

Approved tools, and how a new one gets added

Two lists beat one. Tools approved for general work, and the shorter list approved for anything touching client data. Everything else is not approved, which is a decision rather than an oversight.

The part most policies omit is the route in. If adding a tool means an email into a void, people stop asking and start using. Write the route: send the owner the vendor name, what data the tool would see, and its training setting. Give it a deadline of five working days and stick to it. A slow approval process does not delay the tool. It produces a shadow one.

Keep the tool list out of the policy body, on a page anyone can edit under the owner's name. Policies get reviewed every six months and tool lists change constantly, and a rule that has visibly aged is a rule people stop reading.

What never enters a prompt

This is the section people consult under time pressure, so it has to be usable without ringing a lawyer.

Write it as categories with examples rather than principles. Access credentials and tokens. Client personal data unless that client's contract permits it. Special category data, which under UK GDPR means health, biometrics, and the rest of that list. Unreleased commercial terms and anything under an NDA. Four lines, concrete enough that someone can check their clipboard against them.

Pair the list with one default: assume anything pasted may be retained by the vendor unless you have checked otherwise. Training settings change by silent product update, so record the date each one was checked rather than the setting alone. That single date column has settled more arguments for us than any amount of policy prose.

For anything a client would care about, the honest test is whether you would be comfortable telling that client which tool their data went into. If the answer needs a paragraph of preamble, the answer is no.

Disclosure: when you say AI was involved

Article 50 of the AI Act applies from 2 August 2026 and the Digital Omnibus did not move it, so this section has a date on it.

The duties split by role. Providers of systems built to interact with people have to make clear that the other party is software, unless that is obvious anyway. Providers of generative AI have to mark outputs in a machine-readable format. Deployers have to disclose deepfakes, and AI-generated text published to inform the public on matters of public interest, unless a person took editorial responsibility for the content (a practical guide to Article 50).

That last exemption is the one worth writing into your policy, because it is the ordinary case for a small company publishing marketing copy. If a named person reads a piece and puts their name behind it, the labelling duty falls away, so make the sign-off explicit and record who did it. The exemption depends on the review being real, and the record is what proves it six months later.

Internally, we mark which drafts came out of a model before review, which has nothing to do with compliance. A reviewer reads differently when they know what they are reading, and they catch different things.

The human review points we keep

Our own rules are more restrictive than most companies need, because agents write a large share of our code, our specifications and our decision records. The shape is worth borrowing even if the list is not.

Agents work unsupervised on research, drafting, implementation inside a branch, review synthesis and content production. A person keeps every write to version control, every operation against running infrastructure, the go-ahead on each unit of work before it starts, adding a dependency, changing anything about the authentication model, and any decision that gets written up as a decision record.

The version control rule exists because of an incident. During a review an agent read the phrase "then we can push it" as authorisation and pushed to the main branch. It was not authorisation. The "we" meant the human, later, after the review finished. Nothing broke and the commit was easy to undo, but the agent had not malfunctioned. It read a casual English sentence the way a keen junior would.

So the rule was rewritten to remove the ambiguity rather than to warn about it: writes to version control and operations against infrastructure are outward-facing actions the human keeps, always, and no instruction in any workflow overrides that. It has held since.

A second rule came out of the same habit. The approval gate is per unit of work, not per session. That got written after a run where several pieces of work shipped one after another, each of which had technically passed the gate, and the correction was that skipping the walk-through because the last one went fine is itself the failure.

For a 30-person company the list is shorter, but the test is the same. Name the actions that are outward-facing or hard to reverse, and keep those human.

When something goes wrong, and how the policy changes

Two lines cover incidents in most small companies. Report to the named owner the same working day, and no blame for reporting. Then a record: what happened, which tool, what data was involved, and what changed.

The last item is the one that matters, and it is where most policies stop. An incident should end in a written rule rather than a conversation. We keep process corrections as short files in a fixed shape, the rule, why it exists, and how to apply it, and there are seven of them on one build. What makes it work is that the correction outlives the meeting where it was agreed, and the next person to hit the same edge gets the answer rather than the argument.

Set a review cadence of six months, with triggers that override it: a new tool joining the approved list, an incident, or a regulatory date that changes what you owe. The next of those is 2 August 2026.

A skeleton to adapt

Copy this, delete what does not apply, and fill the brackets. It is a structure rather than boilerplate, and the second draft should look noticeably different from this one.

AI USE POLICY   v1.0   owner: [name]   next review: [date]

1. SCOPE
   Applies to: employees, contractors, and any agency working on
   our systems or handling our clients' data.
   Covers: standalone AI tools, AI features inside tools we already
   pay for, and AI built into products we deliver to clients.
   Out of scope: [name them, so the rest is taken seriously].

2. APPROVED TOOLS
   Approved for general work: [list, maintained at [link]]
   Approved for client data: [shorter list]
   Everything else: not approved until it is on a list.
   To add one: send [owner] the vendor, the data it would see, and
   its training setting. Decision within five working days.

3. DATA RULES
   Never goes into any prompt:
     - access credentials and tokens
     - client personal data, unless that client's contract allows it
     - special category data (health, biometrics, and the rest of
       the UK GDPR list)
     - unreleased commercial terms, anything under NDA
   Default: assume anything pasted may be retained by the vendor.
   Record the date each tool's training setting was checked.

4. DISCLOSURE
   Tell people when they are dealing with software rather than a
   person, unless it is obvious.
   Label AI-generated image, audio and video published externally.
   Published text on matters of public interest: a named person
   takes editorial responsibility, or it carries a label.
   Internally: mark drafts a model produced, so reviewers know
   what they are reading.

5. HUMAN REVIEW
   A named person signs off before:
     - anything reaches a client or the public
     - code merges to a shared branch
     - any decision affecting a person's money, access or record
   Named per item, not per team.

6. WHEN IT GOES WRONG
   Report to [owner] the same working day. No blame for reporting.
   Record what happened, which tool, what data was involved, and
   what we changed because of it.
   If client data was exposed, [owner] decides on notification
   within 24 hours.

7. REVIEW
   Every six months, and immediately after an incident, a new tool
   joining the approved list, or a regulatory date that changes
   what we owe.

Questions we get asked

Do we need a policy if we have not deployed any AI in our product?

Yes, if staff use AI tools at all. Article 4 literacy duties fall on deployers as well as providers, and enterprise buyers ask the data question regardless of what you have built. The policy for a company with no AI in its product is genuinely short.

Should the policy ban AI tools outright?

A ban moves usage somewhere you cannot see. Two approved lists, one for general work and a shorter one for client data, gets you the same control with a fraction of the enforcement cost. Bans also age badly, because the tools arrive inside software you already bought.

Who should own it in a 30-person company?

One named person who can say no, usually whoever already owns supplier contracts or data protection. Ownership by a committee produces a document nobody updates. The owner does not need to be technical, but they do need the authority to keep a tool off the list.

Does having a policy make us compliant with the EU AI Act?

No. It is evidence of the literacy measures Article 4 asks for, and it makes the transparency duties operable, but compliance depends on what your systems do and which role you hold for each one. The policy is where the answers get applied, not where they are decided.