Business Strategy
How to Write an AI Use Policy for Your Team - A One-Page Version That People Actually Follow
How to write an AI use policy for your team without producing a document nobody reads: the four questions it must answer, what to put on the never list, and how to keep it to one page.
AI Educator, AI Tools and Training Club · August 15, 2026 · 8 min read
The short version
- One page, four questions: what goes in, what never goes in, who checks the output, and who to ask.
- Name the tools you approve. A policy about AI in general gives nobody a decision they can make.
- The never list is the only part that must be absolute, and it is mostly about customer and staff data.
- Write it so a new starter could follow it on day one without asking a follow-up question.
The Short Answer
An AI use policy for a small team should be one page that answers four questions: which tools are approved, what information must never be typed into them, who is responsible for checking the output before it leaves the business, and who to ask when something is unclear. Anything longer stops being read, and a policy nobody reads is the same as no policy at all.
Why You Need One Even With a Small Team
The reason is not compliance theatre. It is that people on your team are already using these tools, and in the absence of guidance they are each making their own judgment about what is acceptable to paste in. Those judgments vary enormously, and the variation is where the risk lives.
The common failure is not someone acting recklessly. It is someone helpful pasting a customer email, a spreadsheet of contacts, or a draft contract into a tool in order to work faster, without ever considering that they had just moved that information outside the business. A one-page policy removes that ambiguity in about ninety seconds of reading.
Question One: Which Tools Are Approved
Name them. A policy that talks about AI tools in the abstract leaves every person deciding for themselves whether the new thing they found counts. Name the specific tools your business pays for or has reviewed, and state that anything not on the list needs a conversation first.
- The tools you have approved, listed by name.
- Whether people should be signed in on a business account rather than a personal one.
- What to do about a tool they want to try that is not listed, which should be a short request to a named person rather than a formal process.
Keep the route to approving something new short. If asking is harder than quietly using it, people will quietly use it, and you will have written a policy that generates hidden behaviour rather than preventing it.
Question Two: What Never Goes In
This is the section that must be absolute and specific. Vague wording like avoid sensitive information does not help, because everyone draws that line differently. List the categories in the plainest possible terms.
| Do not paste in | Why |
|---|---|
| Customer names, addresses, phone numbers, or emails | It is other people's information and it is not yours to move |
| Anything from a staff file, including pay and performance notes | The same reason, with employment obligations on top |
| Card numbers, bank details, or anything from a payment system | There is no version of this that is acceptable |
| Contracts, pricing, or documents covered by a confidentiality agreement | You may have promised in writing not to share it |
| Passwords, API keys, or login details of any kind | These should never leave a password manager |
The never list, in plain terms
Question Three: Who Checks the Output
The single most useful line in the whole document is that the person who used the tool owns the result. Not the tool, not the person who approved the tool. If it goes to a customer with their name on it, it is theirs.
Then be specific about what needs checking before anything leaves the business. Facts, figures, names, and anything that sounds confident but specific. That last category is where the real risk sits, because a plausible wrong number is far more dangerous than an obviously wrong one.
- Anything going to a customer gets read in full by a person first.
- Any number, date, or name gets verified against the source it came from.
- Anything that will be published or sent to many people gets a second pair of eyes.
- Internal drafts and notes need no formal check, because that is where the speed benefit lives.
Question Four: Who to Ask
Name one person. Not a department, not an inbox that nobody monitors. The purpose is to make the cost of asking lower than the cost of guessing, and a named person with a clear invitation to be asked achieves that better than any process.
Add the sentence that matters most, which is that nobody will be in trouble for asking, and that raising a mistake quickly is treated well. Without it, the first real error gets hidden rather than reported, and hidden errors are the expensive kind.
Keeping It to One Page
The discipline is to write only what changes behaviour. Definitions of artificial intelligence, statements of principle, and paragraphs about innovation add length and remove readership. If a sentence does not tell someone what to do or not do, cut it.
Read it back and ask whether a new starter could follow it on their first day without asking a follow-up question. If they would need to ask something, that gap is the next sentence you write, and it should replace something rather than be added to the end.
Where to Go From Here
Write the never list first, because it is the section with real consequences and the one you already know the answers to. The other three questions take fifteen minutes once that is down. Then send it to the team as a message rather than an attachment, because attachments do not get opened.
Inside the AI Tools and Training Club, members share the actual one-pagers they gave their teams and we cut the parts that nobody would follow. Join at businessbuildersclub.co for $9/month and bring yours for a read.
Frequently asked questions
How long should an AI use policy be for a small team?
One page. Length is the main reason these documents go unread, and an unread policy provides no protection. If it does not fit on a page, you have included principles and definitions rather than instructions.
What should never be pasted into an AI tool?
Customer contact details, anything from a staff file, payment or bank information, documents covered by a confidentiality agreement, and any password or key. List these by name rather than saying avoid sensitive data, because everyone draws that line differently.
Should the policy name specific tools or stay general?
Name them. A general policy leaves each person deciding whether the new tool they found counts as approved. List what you pay for or have reviewed, and give a short route to asking about anything else.
Who is responsible when AI output turns out to be wrong?
The person who used the tool and sent the result. Writing that down clearly is the most useful line in the document, because it removes any ambiguity about whether the tool shares the blame.
Does everything produced with AI need to be checked by a person?
No, and requiring it would remove the benefit. Anything going to a customer, and any number, date, or name, gets verified. Internal drafts and notes do not, because that is where the speed gain actually lives.
How often should the policy be reviewed?
Put a date on it about six months out. Tools change quickly, and a scheduled review turns an out-of-date document into a routine task rather than an unnoticed gap.