A plain-English AI usage policy your team will actually read

The AI usage policy that ships with ToolRoster doesn't name a single AI tool. No ChatGPT, no Claude, no Otter, nothing.

That was the hardest call in the whole document and it's the one we'd defend hardest. The moment a policy says "employees may use ChatGPT for non-confidential work," it starts rotting. Someone adds a transcription tool in March and the policy is wrong. Someone's browser extension quietly starts reading page content and the policy doesn't cover it. Within two quarters you have a document that describes a company you used to be — and the second people notice that, the whole thing stops being load-bearing, because nobody follows a policy they've caught being out of date.

So the policy holds the rules that don't change, and points at a list that does. The list is allowed to churn weekly. The policy sits still and stays true.

One thing to be upfront about before handing this over: we're a small studio, not a thirty-person company, so we can't tell you how this landed with a team that size. What we can tell you is why every line is worded the way it is, because each one was written against a specific failure we wanted to avoid. Take the text, change the parts that don't fit you.

The template

# AI Usage Policy

**Status:** current

This policy explains how our team uses AI tools at work. It exists to make
AI use open and safe — not to slow you down.

## The short version

1. Use tools from the **Approved** list freely, within their stated use cases.
2. **Restricted** tools are allowed only under the rules listed on the tool's page.
3. Never use **Blocked** tools for work.
4. Want something new? Submit a tool request — most reviews are quick.

## What you may paste into AI tools

Each tool in the registry lists what data is allowed and what is forbidden.
If a tool's page doesn't say, treat everything except public information as
off-limits and ask the tool's owner.

As a general rule, **never paste** into any AI tool:

- Customer data or anything identifying a customer
- Personal data (yours or anyone else's)
- Credentials, API keys, or secrets
- Confidential business information (contracts, financials, roadmaps)
- Source code, unless the tool's page explicitly allows it

## Requesting a new tool

Submit a request from the registry. Include what you want to use it for and
what kind of data you expect to put into it. An admin will review it and the
tool will be added to the registry as Approved, Restricted, or Blocked.

## Accounts

Use your work email for AI tool accounts wherever possible. Don't share
accounts or paste company data into personal accounts of AI tools.

## If something goes wrong

If you accidentally paste sensitive data into an AI tool, tell the tool's
owner or an admin immediately. The goal is fixing it fast — not blame.

## Acknowledgment

By acknowledging this policy you confirm you've read it and will follow the
registry's tool statuses and data rules.

That's the whole thing. Around 300 words, six sections, no defined terms.

The second line is doing more work than it looks like

"It exists to make AI use open and safe — not to slow you down."

Every AI policy we tried to write wanted to open by establishing authority. That's the instinct, and it's wrong for a small team, because the reader's actual first question is "is this the document where I get told off for using the thing that makes my job easier?" If the answer isn't clearly no in the first two lines, you've lost the people whose behaviour you were trying to change.

Then The short version goes at the top, four numbered rules, before any detail. Write it assuming the reader skims and stops. If someone reads only the first screen, they should still come away with the four things that matter: use the approved ones, respect the restricted ones, don't touch the blocked ones, ask for new ones. Everything below it is elaboration for the person who came back with a specific question.

The data rules name things, not categories

The forbidden list is deliberately concrete nouns. Customer data. Credentials. Contracts, financials, roadmaps. Source code.

The version we first wrote said "sensitive or confidential information," which is what most policies say, and it fails in a specific way: "sensitive" is a judgement call, and people make that call generously at 5:40pm when they're trying to finish something. Nobody thinks the contract they're summarising counts as sensitive — it's just work. So the list names the actual documents that pass through a small company's day, and it doesn't leave the reader an interpretive gap to be optimistic in.

The line before it matters just as much: if a tool's page doesn't say, treat everything except public information as off-limits and ask the tool's owner. That's a default-deny fallback, and it exists because in practice the unknown case is the common case — most of what you'd want to know about a given AI tool's terms depends on which tier your team is on, and half the time nobody's written that down. A policy that only works for tools you've fully assessed doesn't work.

Accounts is there for the same reason. Personal accounts are where the tier problem actually lives: the free consumer account someone opened in a hurry is the one most likely to be training on whatever gets pasted into it.

The no-blame line is the one we'd fight to keep

"The goal is fixing it fast — not blame."

Cut that sentence and the rest of the document stops working. The whole premise of a register is that people tell you things — what they're using, and when something went wrong. If the honest answer to "I pasted a client contract into the wrong tool" is a disciplinary conversation, you get told about exactly one incident and then never again, and you're back to having no idea what's happening. Which is the problem you wrote the policy to solve.

There's a version of this document with an enforcement section. We understand why bigger companies need one. At twelve people it buys you nothing and costs you the reporting.

What we left out on purpose

No definitions section — nobody needs "artificial intelligence" defined to follow four rules. No "shall." No disciplinary process. No signature block. No specific vendors, per the opening. No attempt to cover model outputs, IP ownership, or client disclosure obligations, all of which are real questions and none of which belong in the document whose job is to stop sensitive data going somewhere it shouldn't. If you need those, they're a second document, and we're not the people to write them for you.

Three ways this goes wrong afterwards

It's written in legalese. A policy nobody finishes reading protects nobody.

“Length is a risk, not a sign of rigour.”

It's never versioned. A policy is a claim about what your team agreed to at a point in time. If you edit the doc in place, you can no longer say which text anyone actually agreed to — which is the only thing that turns a policy into evidence when a client asks.

And "I posted it in Slack" counts as acknowledgment. It doesn't. A message in a channel proves the message was sent. It's the weakest part of most small teams' setup, and it's usually the part they're most confident about.

That last pair is the only place our product genuinely earns a mention here. In ToolRoster, publishing appends a new version and never edits an old one, and an acknowledgment is recorded against a specific version — so republishing with changed data rules means the previous round of agreement doesn't silently cover the new text, and the "who hasn't acknowledged this" list is about the version that's actually current. It's not live yet, and the template above works fine in a Google Doc. But if you do keep it in a doc, at least date your versions and keep the old ones.

Publish version one this week

The failure mode we'd actually worry about isn't a policy that's too short. It's the four-week draft that never ships because someone wants it to be comprehensive first.

Take the text above, delete the sections that don't apply, fix the ones that describe a company you're not, and publish it as version one. Then send it round and keep a note of who confirmed they read it, with the date. If your data rules change in three months, publish version two and ask again — that's not bureaucracy, it's the difference between having a policy and being able to show you have one.