Most AI policies I see in small businesses have one of two problems. Either there isn't one, and everybody is quietly working it out for themselves, or there is a nine-page document somebody adapted from a corporate template that nobody has opened since the day it was circulated.
Both end up in the same place. People use these tools because they are useful, and in the absence of a rule they can remember, they guess.
Write it for the size of business you actually are
A policy written for a company with a compliance department assumes a compliance department. It talks about approval workflows and registers of processing and escalation paths, none of which exist in a business of six people, so the whole thing reads as though it is describing somebody else.
What works at small scale is one page, written in the same voice you use for everything else, covering the handful of decisions that actually come up.
Length is not thoroughness. A policy people can recall while they are mid-task is doing more work than a comprehensive one they would have to go and look up, because nobody goes and looks it up.
Do not ban it outright
A blanket ban is the most tempting policy and the least effective one. It does not stop people using AI. It stops them using it where you can see, which means the use moves to personal accounts on personal phones, on the most permissive terms available, with no record that it happened.
People generally call this shadow AI, and a ban is the most reliable way to produce it. If the tool genuinely helps somebody get through their day, "no" is not a position that survives contact with a deadline.
Giving people an approved route is what actually moves the behaviour, because the approved route is easier than the workaround rather than harder.
The six things a policy needs to answer
Everything else is optional. These are the questions people genuinely have:
- Which tools may we use? Name them. "Approved AI tools" without a list means everybody picks their own.
- Which account? The business one. Say so explicitly, because the default is whatever somebody already had.
- What must never go in? The most important line in the document, and the one to be most concrete about.
- What has to be checked before it goes out? Draw the line at anything reaching a customer or making a commitment.
- Who do I ask? A name, not a function.
- What happens if I get it wrong? Answer this honestly, because the unspoken answer determines whether anyone tells you.
A template you can lift
This is roughly what I hand people. Change the names, cut what does not apply, keep it on one side.
Approved tools: [tool], on the business account. If you want to use something else for work, ask first.
Never paste in: customer or staff personal details (names, addresses, phone numbers, health or financial information), anything covered by a confidentiality agreement, passwords or card details. If you need the shape of the data, replace the real details with placeholders.
Always check before it leaves: anything going to a customer, anything quoting a price or a date, anything you would put your name to. AI drafts, a person sends.
Never let it decide: who we hire, what we charge, or anything else about a specific person. It can help you think. It does not get the final say.
If you are unsure, ask [name]. Asking is always the right call and never a fuss.
If something goes in that should not have: tell [name] the same day. Nobody is in trouble for telling us early. The only thing that causes a problem is us finding out late.
That last line does more than the rest of the document combined. Almost every bad paste I have heard about happened because somebody did not want to look like they were making a fuss over something small, and then it was too late to mention it.
Make it concrete or it will not be followed
"Do not share sensitive information" sounds like a rule and functions as a nudge, because everybody draws that line somewhere different. A customer's email address does not feel sensitive to the person pasting it.
Naming the categories, with examples from your actual work, is what turns it into something checkable. For a plumbing business that is customer addresses and job notes. For a clinic it is anything at all about a patient. For an agency it is client documents under NDA. Write yours in your own vocabulary.
Take one real task somebody on your team does with AI and walk the policy through it. If the policy does not clearly say yes or no to that specific task, it is not finished yet.
Landing it, then keeping it alive
Circulating a document is not implementation. Three things make the difference between a policy that holds and one that decays:
- Say it out loud once. Ten minutes in a team meeting, with the reasoning, beats an email nobody replies to. People follow rules they understand the point of.
- Put it in induction. Otherwise it applies only to people who happened to be there in the week you wrote it.
- Revisit it when the tools change. Not annually, which is arbitrary. When you adopt something new, change plan, or a provider changes its terms.
Put a review date on it and name who owns it. A policy with no owner ages badly, and an out-of-date policy is worse than none, because people notice it is wrong and stop treating any of it as binding.
Where a policy is not enough on its own
A policy governs what people do. It does nothing about what your systems can do, which is a separate question. If you have an AI assistant connected to your inbox or your records, the limits on that need to be built in rather than written down, because a document cannot restrain software.
That side is covered in what a chatbot should and should not be allowed to do and in prompt injection, explained without the jargon. If your policy has to cover customer information specifically, the regulatory shape of that is in can I use AI on customer data. The whole picture is in my guide to using AI safely in a small business.
If you would rather not start from a blank page, working out the approved tools and the actual boundaries for a specific team is part of what the AI Setup Package covers.