AI Safety & Trust

How to Write an AI Usage Policy for Your Team (Five Sections, One Page)

Date Published

Policy document with a shield surrounded by team figures, illustrating a team AI usage policy

An AI usage policy for a team fits on one page and answers four questions: which tools are approved, what data may never go into them, when people must check the output, and whether they should say they used AI. Most teams do not have one, which means everyone is quietly making their own rules. Writing it with AI takes an afternoon, and the draft is the easy part; the version that works is the one the team helped edit.

Why does a small team need a written AI policy?

Because the absence of a rule is a rule, and it is usually the wrong one. Without guidance, one person pastes client contracts into a personal chatbot while another refuses to use AI at all, and both think they are doing the right thing. Template collections from HR bodies like SHRM and HR publishers like AIHR exist because companies kept discovering the gap only after a leak or an embarrassing hallucination reached a customer. A page of shared rules is cheaper than either.

What should the policy cover?

Approved tools, data rules, verification, disclosure, and who to ask. Keep it to five sections. Approved tools: which accounts people may use, ideally the company plan rather than personal logins. Data: a traffic light of what is fine to paste, what needs redaction, and what never leaves the building. Verification: outputs that reach customers, legal, finance, or the public get checked by a human. Disclosure: when to say AI was involved. Contact: one named person for questions. Everything else, from tone guidance to prompt libraries, can live elsewhere.

Traffic light with green, amber and red lamps beside document icons, illustrating data categories

How do I draft it with AI?

Give it your context and the five sections, and ask for plain language. Prompt: 'Draft a one page AI usage policy for a [size] team in [industry] that handles [kinds of data]. Five sections: approved tools, data traffic light, when human review is required, disclosure, and who to ask. Plain language, no legal tone, written for people who are not technical.' Then push it: 'Rewrite the data section as three lists, green, amber, red, with concrete examples from our work.' The concrete examples are what people remember; 'confidential information' means nothing until it says 'customer contracts and salary spreadsheets'. For the privacy settings each approved tool should have, point people to our guide on stopping AI training on your data.

Checklist with ticked app icons and a padlock, illustrating a list of approved AI tools

How do I get the team to actually follow it?

Let them edit it, then make the safe path the easy path. Share the draft in a 30 minute session, ask what is unclear or unrealistic, and change it on the spot. A rule the team wrote is a rule the team keeps. Then remove friction: if the policy says use the company account, make sure everyone has one before the policy goes live. On disclosure, decide together; our piece on whether to tell people you used AI lays out the trade-offs so the team can pick a norm rather than inherit one.

Team around a table with a document and thumbs up, illustrating agreeing on a policy together

What does the verification rule look like in practice?

Anything external, financial, legal, or about a person gets a human check before it leaves. Write that sentence into the policy and give two examples: a customer email drafted by AI is read fully before sending; a contract summary is checked against the original before anyone relies on it, following the approach in reviewing contracts safely with AI. Internal brainstorming and first drafts need no ceremony. The rule is about where the output goes, not about whether AI touched it.

How often should the policy change?

Review it quarterly, and whenever a tool or a law changes. Put a date and an owner at the top. Tools change their data terms, new AI features appear inside software the team already uses, and rules like the EU AI Act keep adding obligations. A policy with a review date stays a living document; one without becomes a page nobody has read since the day it was written.

The point of an AI policy is not to slow people down. It is so nobody has to guess.

Draft the five sections with AI this week, book thirty minutes with the team to edit it, and publish it with a date and a name on top. One page, owned by the people who use it.

Frequently asked questions

Does a small team really need an AI policy?

Yes, because without one everyone invents their own rules, and the risky ones only show up after a leak. One page of shared rules prevents most of it.

What should never go into an AI tool?

Whatever your red list says: typically customer personal data, contracts under NDA, credentials, salary and health information, and unreleased financials. Write the list with concrete examples.

Should employees disclose when they used AI?

Decide as a team. A common norm is that AI assistance on internal work needs no label, while external or published work discloses when it matters to the reader. Write the norm down so nobody guesses.

Can AI write the policy itself?

It can draft a good first version from your context. The version that works is the one your team edited, with your own examples, tools, and a named owner.

How often should we update the policy?

Quarterly, and whenever a tool changes its data terms or a new regulation applies. A review date on the document keeps it from going stale.

Sources