AI Usage Policy: A One-Page Template

Most AI policies fail in one of two directions. Either they are three words long, use AI sensibly, which decides nothing, or they run to thirty pages of definitions nobody opens twice. A usable AI usage policy fits on one page and settles five questions: which tools are approved, what data must never go into them, what a person checks before anything leaves the building, when customers get told, and who to ask when something is unclear.

What the document is actually for

Not compliance theatre. The point is to remove the moment of hesitation where an employee with a deadline decides for themselves whether pasting a customer list into a chat window is fine. Left to individual judgement under time pressure, that decision goes badly at a predictable rate.

It also gives you something to point at afterwards. When a client asks whether you use AI on their work, or a supplier questionnaire asks about your AI controls, a one-page document that has existed since before they asked is worth considerably more than an assurance composed in the reply.

The five clauses

1. Approved tools

Name them. Actual product names, actual accounts, and who pays. Vague permission to use AI responsibly means everyone picks their own tool with their own terms and their own data retention, and you now have twelve vendors instead of two. Before adding one to the list, check what happens to inputs, which is a five minute exercise covered in how to check whether an AI tool trains on your data.

2. Data that never goes in

The clause that earns its place. List categories rather than examples, because examples get read as an exhaustive list. Customer personal data, credentials and keys, unreleased financials, anything under an NDA, anything you would not put in an email to a stranger. State the fallback too: if the work genuinely needs that data, the approved route is a tool covered by an appropriate agreement, not the free tier and a hope.

3. Human review before it leaves

Define which outputs need a named person to check them before they reach a customer, a regulator, or production. Draft emails, no. Anything with a number in it that someone will act on, yes. Code, yes. Keep the bar concrete so nobody has to interpret it at five in the afternoon.

4. Disclosure

Decide once, in writing, whether you tell clients that AI is involved in their work, and under what conditions. The debate is genuinely contested and worth having deliberately rather than accidentally, which is why whether to tell clients you use AI deserves its own conversation before it lands in the policy.

5. Who to ask

One name. Not a committee, not an inbox nobody reads. The most common reason people break a policy is that the approved route to ask a question is slower than the deadline.

The template

Copy this, change the bracketed parts, delete anything that does not apply. It is deliberately short.

# AI usage policy
Last reviewed: [date]  |  Questions: [name, contact]

## Approved tools
- [Tool A], company account, paid plan. Approved for [purposes].
- [Tool B], company account. Approved for [purposes].
- Any other AI tool requires approval from [name] before use on company work.

## Never put these into any AI tool
- Customer or employee personal data
- Passwords, API keys, access tokens
- Unpublished financial information
- Anything covered by a client NDA
- Source code from [systems], unless using [approved tool]

If the work needs this data, ask [name]. There is usually an approved way to do it.

## Check before it leaves
A named person reviews AI-assisted output before it goes to a customer,
into production, or into any external filing. This applies to:
- Anything containing figures, dates, prices or legal statements
- All code merged to main
- Any communication sent under a customer's name

## Telling people
[We disclose AI involvement when ... / We do not disclose routine AI
assistance, but we always disclose when ...]

## When in doubt
Ask [name]. Asking is never the wrong call, and no one is penalised for it.

Why an AI usage policy that bans AI backfires

The instinct to prohibit AI entirely is understandable and it does not work. Prohibition does not remove the deadline pressure that made the tool attractive, it removes your visibility of what people do about it. Staff use personal accounts on personal devices, which is strictly worse than the thing you banned: same data leaving, no logs, no approved account, no terms you have read.

This is the mechanism behind shadow AI, and the practical response is not stricter rules but a fast approved route. If the sanctioned tool takes ten minutes to get access to and the unsanctioned one takes ten seconds, the policy loses on latency alone. Adoption is a design problem as much as an enforcement one, which is where getting a team to actually use the approved tools becomes part of the control.

Contractors, freelancers and agencies

The clause most policies forget. People outside your payroll frequently do the work most exposed to AI tooling, on their own machines, under their own accounts, and your internal document does not reach them unless you put it in the contract.

Two sentences in the engagement terms usually cover it: that your data rules apply to any AI tool they use on your work, and that they will tell you if AI is materially involved in a deliverable. You are not trying to police their toolchain, you are trying to make sure your customer data does not end up somewhere with retention terms nobody has read. Agree it at contract time, because raising it mid-project reads as an accusation rather than as housekeeping.

What to leave out

• Definitions of artificial intelligence. Nobody reading your policy needs one, and it dates instantly.

• Model-specific rules. Write about categories of tool, not versions, or you will be editing it monthly.

• Aspirational language about ethics. Either it maps to a rule someone can follow or it is filler.

• Anything you will not enforce. An unenforced clause teaches people the rest is optional too.

Where the obligations become legal

For most small companies this is an internal control, not a regulatory filing. Two exceptions are worth knowing. If you operate in the EU, the AI Act's Article 4 obligation on AI literacy expects providers and deployers to ensure staff have a sufficient level of understanding of the systems they use, and a policy plus a short briefing is the cheapest way to evidence that. If you build or deploy anything in a high-risk category, obligations go considerably further than a page of house rules.

If you want a structure to grow into rather than a rulebook, the NIST AI Risk Management Framework organises the same territory into four functions: govern, map, measure and manage. It is voluntary, it is written for larger organisations, and its first function is exactly the document above.

Keeping it alive

Put a review date on it and actually review it, quarterly is plenty. The approved tools list is the part that goes stale fastest, followed by the data clause as your business takes on new kinds of customer information. Read it once alongside your existing rules on what should never go into a prompt, because if those two documents disagree, people follow neither. It also belongs beside the rest of your thinking on running a small business with AI in it, rather than in a folder on its own.

Questions people ask

How long should an AI usage policy be?

One page, or two if you are in a regulated sector. The length correlates inversely with how many people have read it. If a clause cannot survive being cut to a sentence, it probably belongs in a separate procedure rather than in the policy.

Do we need one if we are five people?

Yes, and it is easier at five than at fifty. At that size it takes an afternoon and one conversation, and it means the habits forming now are the ones you want later. It also answers client due diligence questions that arrive at the worst possible moment.

Should staff sign it?

An acknowledgement is useful and a signature is rarely the point. What changes behaviour is a fifteen minute walkthrough where people can ask what counts as customer data, since that is where the genuine confusion lives.

What if someone breaks it?

Treat the first instance as a policy failure rather than a personal one and ask what made the wrong route easier than the right one. If the answer is that the approved tool was slow, missing or unknown, the fix is upstream. Repeat instances after that are an ordinary conduct matter.