Write Your Team's One-Page AI Policy

One page, and permissions first

Everything in this course now becomes a document your team can actually read. One page. Not a framework, not an appendix, one page that a new starter could absorb in three minutes and act on the same afternoon.

The single most important structural choice is the order. Permissions first, prohibitions second.

Almost every AI policy opens with a list of bans. Read one from your team's position: you already suspected AI was frowned upon here, and now you have a page confirming it. The safest response is to stop asking and quietly use your phone. That is how a document intended to reduce risk produces shadow AI instead.

Open with what people may do and the same page reads as permission with sensible limits. The prohibitions still appear, on the same page, in the same words. They just no longer set the tone.

The five things the page must contain

Permissions. Which tools, on which plans, for which kinds of work. Be specific enough to act on. "Approved assistants for drafting, summarising, formatting and rewriting internal material" is usable. "AI may be used where appropriate" is not.

Prohibitions. The red list from lesson two: client identifiable data, staff personal data, credentials, unreleased financials, anything under a confidentiality agreement. Plus nothing customer facing without a named reviewer. Keep it to five or six lines.

Disclosure expectations. When people say AI helped. Most teams land somewhere sensible: no need to flag routine internal drafting, but do flag it where a reader would reasonably assume unaided human work, and never present AI assisted analysis as though a person did it alone.

Who to ask. A named person, not a department. "Ask compliance" means ask nobody.

The no blame reporting line. Its own section, at the bottom, in plain words.

The no blame line is the part that pays for itself

If someone pastes a client list into a consumer tool at four on a Friday, you want to know at five past four. Not in three months, from the client.

You will only find out early if telling you is cheaper than hiding it. So the page has to say, without conditions, that reporting a mistake promptly will not itself be treated as a disciplinary matter, and that the only thing which will cause a problem is concealing one.

Then hold to it the first time it is tested, because the first case sets the price of honesty for everyone watching. Thank the person publicly for the report, fix the cause quietly, and change nothing about how you treat them.

Hidden mistakes are the expensive ones. A disclosed error is a support ticket. The same error found six months later by an outsider is an incident, and by then it has a history of people who knew and said nothing.

Build it outside this site

There is nothing to fill in here and nothing stored anywhere. Copy the template below into whatever your team already uses, a document, a wiki page, a pinned message. The point is that it lives where your team looks, not on a learning site they visit once.

TEAM AI POLICY
Team: [team name]     Owner: [your name]     Reviewed: [date]

WHAT YOU MAY DO
You may use [approved tool, on the plan our employer provides] for:

First drafts of internal documents, updates and emails
Summarising long documents and meeting notes
Reformatting, tidying and rewriting text we already have
Explaining unfamiliar material in plain language
Drafting replies that a person reads and sends
You are expected to use it. This is not a favour we are granting.

WHAT YOU MAY NOT PUT IN
Never paste:

Client or customer identifiable details (names, contacts, accounts)
Staff personal data (HR, pay, health, performance)
Passwords, keys, tokens or internal system links
Unreleased financials, pricing strategy or deal terms
Anything covered by an NDA or a client contract
The habit that makes this workable: if it does not need the name,
do not paste the name. Use Client A and Person B, then add the real
details back yourself.

BEFORE ANYTHING LEAVES THE TEAM
The person who sends it owns it. Before sending, check:

Every number, against its source
Every name and job title
Every date, deadline or commitment made on our behalf
Every claim about what we do or offer
Nothing goes to a customer or an outside party without a named
person having read it.

SAYING WHEN AI HELPED

Routine internal drafting: no need to flag it
Flag it where a reader would assume unaided human work
Never present AI assisted analysis as if a person did it alone
If you are unsure, say it helped. Nobody has ever regretted that.


IF YOU ARE NOT SURE
Ask [named person, contact]. Same day is fine. There is no
such thing as a silly question about this, and asking is always
faster than unpicking it afterwards.


IF SOMETHING GOES WRONG
Tell [named person] as soon as you realise.

Reporting a mistake promptly will not be treated as a disciplinary
matter. Hiding one will. We would far rather fix a problem on the
day than find it six months later.
Review date: [three months from now]

Adapt the AI policy below for my team.
My team: [size, function, what we actually do all day]
Our approved tools: [tools and plans, or write UNKNOWN]
Who people should ask: [name and role]
Things specific to us that must be covered: [anything unusual]
Rules:

Keep the order: permissions, prohibitions, checks, disclosure,
who to ask, no blame reporting
Keep it under 450 words
Plain English. No legal citations, no references to specific laws,
no threats of disciplinary action except for concealment
Do not invent what our tools do or what any vendor's terms say
[paste the template]

Here is the draft AI policy for my team:
[paste your version]
And here is what my team actually does each week:
[main recurring tasks]
Tell me:

Any rule that would make a normal task impossible or much slower,
and what a busy person would realistically do instead
Anywhere the wording is vague enough that two people would read
it differently
Whether a new starter could act on this on their first day
Any point where it reads as a warning rather than as permission
Then list the questions I should put to our legal, IT or compliance
contact before publishing. Do not answer those questions yourself.

What to do on Monday

Write the page. Send it to your legal, IT or compliance contact with the questions from the last prompt. Then read it to your team out loud, because reading a policy aloud is the fastest way to hear which sentences you do not believe.