How to Set AI Ground Rules for Your Team

Nobody reads the ten-page version

Somewhere in your organisation there may already be an AI policy. It was written by people who are paid to reduce risk, it runs to eleven pages, and it contains the phrase where appropriate more than once. Your team has not read it. If they have, they cannot tell you what it permits.

That is not a failure of discipline. It is a failure of format. A rule that people cannot recall at the moment they need it is not a rule, it is a document.

What you need is one page, ideally half of one, that answers four questions your team is genuinely asking: what can I paste in, what must I never paste in, when do I have to say I used AI, and who is on the hook if it is wrong.

The four questions

What may be pasted in. Be specific and generous where you safely can. Public information, your own drafts, internal notes with no personal or commercial detail, anonymised examples, general questions. If your team cannot see a list of things that are clearly fine, they will assume everything is risky and either stop using it or use it secretly. The second one is worse.

What may not. Also specific. Customer names and contact details, staff records, salaries, anything under a signed confidentiality agreement, unreleased financials, credentials and passwords, source code if your organisation says so. Name the categories, not the principles. Do not treat sensitive information carefully is not a rule anyone can apply at four in the afternoon.

When to disclose. Set a plain threshold. A useful default: no disclosure needed when AI helped you draft, tidy or summarise something you then reviewed. Disclosure needed when the output goes to a customer largely as generated, when it informs a decision about a person, or when someone reasonably assumes a human wrote it personally.

Who is accountable. One sentence, and it is always the same sentence. The person who sends it owns it. Not the tool, not the drafter, not the team. This single line prevents most of the arguments you would otherwise have later.

Write a one-page AI ground rules note for my team.
Team: [9] people doing [what they do]
Tools they use: [ChatGPT / Claude / Gemini / Copilot], on [free personal / company] accounts
Existing company policy says: [paste the key lines, or write none that I know of]
Requirements:

Under 300 words, plain English, no legal phrasing
Exactly four sections: what you can paste in, what you must never paste in,
when to say AI was used, who is accountable
Short bullets, concrete examples, no principles without examples
End with one line telling people who to ask when unsure
Do not add sections I did not request.

Write the permissions first

Most policies are written as a list of prohibitions, and they fail in a predictable way. People read them, conclude that AI is dangerous and vaguely forbidden, and then quietly use it on their phones where you cannot see it, help or correct anything.

Lead with what is allowed. If the first half of your page is a genuine list of things people can do freely, the second half carries far more weight, because it reads as a small set of real exceptions rather than a wall of no.

Make it survive contact

Test it before you publish. Take five things your team did last week, hold each against your draft, and see whether the rule gives a clear answer. Any case that leaves you shrugging is a case your team will resolve by guessing.

Here is my draft AI ground rules note:
[paste it]
Here are five real situations from my team last week:

[situation]
[situation]
[situation]
[situation]
[situation]
For each situation, say what my rules tell the person to do. If the rules are
ambiguous or silent, say so plainly and suggest the single shortest sentence
that would fix the gap. Do not rewrite the whole document.

Then read it aloud in a team meeting, all four sections, in under two minutes. If you cannot get through it in two minutes, it is too long, and you have written the eleven-page version with better formatting.

Cut this AI ground rules note to under 200 words without losing any rule.
Remove every sentence that only restates a principle.
Keep all concrete examples, since those are the part people remember.
Return the shorter version only, no commentary.

Revisit it in three months. Tools change, your team's habits change, and a rule written before anybody had used these tools properly will have at least one line in it that now looks silly.