ع
Start Topics Teams Reference What's new Saved
For your team

Your team's first AI ground rules

A policy nobody reads isn't a policy — it's a document. The version that actually changes behaviour is short enough to remember, permissive enough to be worth following, and clear about one thing: who's accountable.

11 min read · Updated 2026-08-07
Your team's first AI ground rules

Ask around your company and you’ll find three groups. A few people are using AI for everything and telling nobody. A larger group used it once, got nervous about whether they were allowed, and stopped. And someone in a leadership meeting has said “we should probably have a policy on this” at least twice, and nothing has happened since.

That’s not a failure of will. It’s that “write an AI policy” sounds like a quarter-long project involving legal, and so it never starts. Meanwhile every day without a rule is a day where each person is inventing their own — which is the actual risk you’re carrying, and it’s larger than anything a one-page document would have exposed you to.

So write the one-pager. This is what goes in it.

Why the long version fails

The instinctive move is to write the comprehensive document: definitions, scope, appendices, an approved-tools matrix, a section on generative AI versus machine learning that nobody needed.

It fails for a mechanical reason, not a philosophical one. A rule only works if it’s in someone’s head at the moment they’re deciding. Nobody opens a policy portal at 4pm with a spreadsheet in hand and a deadline in twenty minutes. They go with what they remember, and they remember about five things.

So you get five. Everything else is commentary, and commentary can live in a longer document that exists purely so your auditors have something to read.

The second failure mode is tone. A policy that’s a list of prohibitions gets read once, resented, and routed around — and the routing-around is invisible to you. A policy that leads with permission gets read and followed, because it’s giving people something they wanted: certainty that they’re allowed.

Rule 1 — Green, amber, red data

The core of the whole thing, and the part people actually need. Three buckets, not four, because a one-pager has to be memorable:

  • Green — go ahead, no approval. Public material, internal drafts, processes, templates, anonymized data, your own notes. This is most work. Say so loudly.
  • Amber — redact or ask. Named customers, named employees, unreleased numbers, anything under an NDA. Usable, with a step first.
  • Red — never, without a written decision. Regulated data: payment details, national IDs, health records, anything a law or a signed contract specifically governs.

If you want the fuller reasoning behind these lines — and the three separate questions people confuse when they ask “is this safe” — that’s the subject of can I put company data into AI. For the one-pager, three colours is enough.

Rule 2 — Use the company account

Short, boring, and the highest-leverage line in the document.

The account determines the terms: what’s retained, what’s used for training, what admin visibility exists, and whether your company has any contractual relationship with the vendor at all. Someone doing perfectly sensible work on a personal login is in a different position from the person beside them doing exactly the same thing on a company seat.

This rule has a prerequisite, and it’s on you, not on them: there has to be a company account to use. Half the shadow usage in most organizations exists because nobody bought seats. If you write this rule without provisioning access, you’ve written a rule that says “stop working.”

Rule 3 — Name the human

The rule that separates a serious policy from a nervous one:

Every piece of AI-assisted work has exactly one human who is accountable for it, and it’s the person whose name is on it.

Not the tool. Not “the AI got it wrong.” Not the vendor. This does more work than any of the technical controls, because it settles in advance every argument you’d otherwise have after something goes wrong. It also quietly makes people careful in a way that no amount of mandatory training does.

And it’s the honest position. Accountability was never a thing you could delegate to software — that’s precisely why the roles built around it are the ones AI doesn’t dissolve, as we argue in will AI take my job.

Rule 4 — Verify before it leaves the building

Anything going to a customer, a regulator, a board, a public channel, or into a system of record gets a human check first. Specifically a check of the things that would be embarrassing if they were invented: figures, names, citations, dates, claims about what something does.

This is not a general instruction to be careful — those don’t work. It’s a named step with a named trigger: crossing the boundary out of your team. Internal drafts don’t need it. Anything external does, every time.

The reason it needs to be a rule rather than common sense is that the failure mode here is invisible. A fabricated number arrives looking exactly like a correct one; there’s no tell, no hedging, no formatting difference. Why AI makes things up is worth circulating alongside the policy for exactly this reason.

Rule 5 — Say when it matters

The disclosure rule, and the one teams most often overcomplicate. Two failure modes: disclosing nothing, and disclosing everything.

Blanket disclosure — labelling every email and document as AI-assisted — becomes noise within a fortnight and gets dropped, taking the useful cases with it. Nobody discloses their spell-checker.

So scope it. Disclose when the fact that a machine was involved changes how someone should read it: work sold as bespoke human effort, anything that looks like independent verification or research, creative work where authorship is the product, and anywhere a client contract or professional body requires it. Otherwise, treat it like any other tool.

The one-page template

Adapt the specifics; keep the shape and the length.

How we use AI at [Company]

AI tools are approved and encouraged. These five rules apply to everyone.

1. Data. Green — public and internal material, drafts, processes, anonymized data: use freely, no approval needed. Amber — named customers or employees, unreleased numbers, NDA material: redact it, or get approval from [name/role]. Red — regulated data (payment details, national IDs, health records, anything a client contract specifically governs): never, without a written decision from [name/role].

2. Accounts. Company accounts only, for any work purpose. Request access from [name/role].

3. Accountability. Every AI-assisted output has one accountable human: whoever’s name is on it. “The AI produced it” is not an explanation.

4. Verification. Anything leaving the team — customers, regulators, public channels, systems of record — gets checked by a person first, with particular attention to figures, names, dates, and citations.

5. Disclosure. Tell people when it changes how they should read the work: client deliverables sold as bespoke, research or verification, creative work, or where a contract requires it. Otherwise, it’s a tool like any other.

Questions, or think a rule is wrong? [name] owns this document. Reviewed [date]. Next review [date].

That’s it. If yours is longer than a page, the extra material belongs in an appendix that exists for auditors, not in the thing people are supposed to remember.

Rolling it out without killing usage

The document is the easy part. Three things determine whether it works.

Open with an amnesty. Say clearly, in the launch message, that the situation was previously unclear, nobody is in trouble for anything before today, and this is the line from now on. Skip this and every person who’s been quietly using a personal account learns that the safe move is to keep quiet — and you lose your best source of information about how work actually gets done.

Ship it with access, not before it. A policy that arrives before the seats do reads as a ban. Seats first, or same day.

Name an owner and a review date. Not a committee — one person, with the authority to change it. This is a document that will be wrong within two quarters, because the tools will have changed. Something with a visible review date gets updated; something published once and forgotten gets ignored the first time reality diverges from it.

Beyond the rules themselves, the wider mechanics of getting a team genuinely using this — pilots, champions, capturing what works — are in our team rollout playbook and, for the Desktop-first version, rolling out Claude on Desktop.

What good looks like in six months

Not zero incidents — that’s a target that only rewards people for not telling you.

What good looks like is that someone forwards you a message saying “this is amber, right? I stripped the names before I sent it.” That’s the whole objective in one sentence: the rule is in their head, they applied it without asking permission, and they told you. You can’t audit your way to that. You get there by writing something short enough to remember and generous enough to be worth following.

Topics

Questions people ask

Won't a policy just slow everyone down?
Only if you write the wrong kind. A policy that's mostly prohibitions does slow people down and gets routed around. A policy whose first move is to say yes — these categories of work need no approval, use it freely — speeds people up, because the thing actually slowing your team down right now is uncertainty. Most people aren't avoiding AI because they're forbidden; they're hesitating because nobody told them what's okay.
Do we need to ban anything outright?
One category, usually: regulated or contractually fenced data, where a specific law or client contract dictates how it may be processed. That's a real hard stop and it should be written as one. Almost everything else works better as a condition than a ban — redact it, use the approved account, get a sign-off — because conditions can be followed under time pressure and bans just get ignored.
Who should own this — legal, IT, or the team?
Draft it where the work happens, red-line it with legal and IT, and have it owned by an operating leader rather than a compliance function. Policies written entirely by legal optimize for defensibility and get ignored; policies written entirely by the team miss real obligations. The pattern that works is: the team writes what it needs, the specialists mark what's actually not allowed, and one named person owns keeping it current.
What if people have already been using AI against the rules?
Open with an amnesty and mean it. Say plainly that the old situation was unclear, that nobody is in trouble for what happened before this document, and that from today there's a rule. You need honest information about how people are actually working far more than you need a disciplinary case — and one punished early adopter will drive the rest of your usage permanently underground.
Put it into practice
Browse the topics
Start