An AI use policy for a small 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.

What changed on 28 September 2026: the literacy duty behind this policy became lighter on 27 July, when the Digital Omnibus rewrote Article 4, and the next section says what it asks for now.

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. 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. Since 2 February 2025, Article 4 of the EU AI Act has bound every provider or deployer, and staff using a general chatbot at work make a company a deployer. Under the version the Digital Omnibus put in place on 27 July 2026, the duty is to take measures supporting the AI literacy of the people who use AI for you.

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. 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, on purpose.

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 produces a shadow tool.

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. 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 setting and the date you checked it, because a dated record answers a client who asks what a tool's setting was in March.

For anything a client would care about, the 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. Telling people they are dealing with software, and marking generated output, fall on providers. A company that only uses AI is a deployer. It owes disclosure of deepfakes, and of AI-generated text it publishes on matters of public interest unless a person took editorial responsibility for it (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, 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.

Human review: where a named person signs off

"A person reviews the output" is where most policies stop, and it fails because it names neither the person nor the moment. A review rule that works names the action and the person who signs off before it happens.

Start with the actions that are outward-facing or hard to reverse. For a small company that usually means anything that reaches a client or the public, code that merges to a shared branch, and any decision that affects a person's money, access or record. Keep the list that short, because a gate on everything gets worked around.

Write each rule so it cannot be read two ways. An AI tool that can act on your systems has none of the context a colleague would use to read a casual "looks fine to me". It can treat the remark as permission, the way a keen junior might. So say it as an absolute: a merge to the shared branch needs the named reviewer, every time, and nothing written in a prompt or a template overrides that.

Approval covers one piece of work at a time. A yes given on Monday does not cover Thursday's release, and skipping the check because the last one went smoothly is the failure the rule exists to prevent. The usual failure is a run of pieces each passing its check alone while the check does less on later ones; run it on each piece separately.

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 most policies never get there. An incident should end in a written rule, and each rule should be short and carry the reason it exists. 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 most recent were the Article 4 rewrite on 27 July 2026 and the Article 50 duties on 2 August.

A skeleton to adapt

Copy this, delete what does not apply, and fill the brackets. 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 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 the AI use policy in a small 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.