An AI usage policy for small business is a short written list of what an AI tool is allowed to do on your behalf, what it must never do, and what it has to hand back to a person. It does not need a lawyer and it does not need to be long. One page, written before the tool starts acting for you, is enough to stop the two failures that actually happen: the assistant saying something about your business that is not true, and the assistant answering a customer it should have passed to you.
If you have an AI tool drafting replies, writing posts, sorting your inbox or handling first-line enquiries, you already need one. Here is what to put in it.
What is an AI usage policy, and why does a small business need one?
Most small businesses think of a policy as something for staff handbooks. This one is different. It is not about whether your team may use ChatGPT. It is about what an automated tool is permitted to do in your name, where a mistake is published, sent, or said to a customer before anyone sees it.
The gap is easy to miss because the tool is usually helpful. It drafts a decent reply. It writes a reasonable post. The trouble is that it has no idea which claims about your business are true, which numbers you are allowed to quote, and which messages are worth more than a quick answer. It will guess, confidently, and the guess goes out with your name on it.
A written list closes that gap in a way that a careful prompt does not. Prompts drift, get edited, and get forgotten. A list you can point at is what you check the output against.
What should an AI usage policy actually say?
Four sections. That is the whole thing.
What it may do without asking
Be specific and generous here, because this is where the time saving lives. Draft replies to routine questions. Sort and label the inbox. Write the first version of a post. Pull the week’s numbers into a summary. Anything where the worst case is a wasted five minutes belongs in this list.
What it must never do
This is the short, absolute list, and it should read like a set of rules rather than advice. No inventing customer stories, testimonials or results. No quoting a figure nobody has given it. No claims about what your product does that are not true of the version people can actually buy today. No discounts, no commitments on price, no promises about dates.
Write these as flat prohibitions, not preferences. “Avoid exaggerating” is a preference and it will be negotiated away. “Never state a number that is not on this list” is a rule and it holds.
What it must escalate to a person
Anything where the reply is worth money or trust. Someone asking to hire you. Someone asking about price. Someone reporting a fault. A journalist. A partnership approach. A complaint.
The escalation itself needs a defined shape, or it quietly becomes a suggestion. Where does it go — a file, a phone notification, a specific inbox? What does the tool do while it waits: nothing, or send a holding line you have written word for word? Decide both now, in writing.
What it must record
Every action, with enough detail to check it later. What went out, where, and when. This is the part that turns a policy into something you can actually verify rather than hope about — and it is the only way you will ever notice that a scheduled job has quietly stopped running.
How do you write one in an afternoon?
Start from what the tool already does, not from a template. List every action it takes in a normal week. Beside each one, write which of the four buckets it belongs in. Most items will be obvious within seconds; the two or three you hesitate over are the ones worth the afternoon.
Then do the test that matters: hand the list to someone who does not work in your business and ask whether they could follow it without asking you a question. If they cannot, it is not written plainly enough to constrain a machine either.
Keep it in one file, keep it short, and change it when something goes wrong rather than on a schedule. A policy that gets edited the week after an incident is a living one. A policy reviewed annually is decoration.
A real example: the rules our own AI marketing assistant runs on
We run an AI assistant that writes and publishes Codeora’s own marketing every day, unattended. Nobody reads the posts before they go live, which means the written rules are the only safety net — so they are unusually strict, and worth copying.
It may never invent a testimonial, a customer or a result. It may never state a usage or revenue figure that has not been supplied to it directly. Every claim about Receiply, our receipt-scanning app, has to be true of the shipped version, and the privacy wording is fixed word for word rather than paraphrased, because a paraphrase of a privacy claim is a new claim.
The rule that has earned its place most often is the escalation one. If someone replies asking about hiring us, pricing, a bug or a partnership, the assistant is forbidden from answering. It writes the enquiry to a file, sends a notification, and stops. A person then supplies the words and the assistant posts them. That single line is the difference between an assistant that handles your admin and one that negotiates on your behalf without your knowledge.
It works because it was written down before the tool was switched on, not after something went wrong.
What happens when you skip it?
Nothing, for a while. That is the difficulty. An AI tool without a policy behaves acceptably most of the time, which is exactly why the missing rules are never noticed until the day they are needed.
The failures, when they come, are dull and expensive. A plausible statistic in a post that nobody can source. A confident answer to a pricing question from someone who was ready to buy. A claim about what your product does that is one version out of date. None of these look like a system fault. They look like your business being careless, which is worse.
Writing the rules down is an hour. Explaining an invented customer quote to a real one is not.
FAQ
Does a small business really need a written AI usage policy?
If an AI tool sends, publishes or replies to anything without a person reading it first, yes. If every output is reviewed by a human before it leaves the building, the policy matters much less — the reviewer is the policy.
How long should an AI usage policy be?
One page. If it runs longer than that, nobody will check outputs against it, which means it stops doing the only job it has.
What is the single most important rule to include?
Never state a number, quote or customer result that has not been supplied by a person. Fabricated figures are the most common failure, the hardest to spot in a well-written draft, and the most damaging to trust.
Should the policy cover which AI tools we use?
Keep that separate. Tools change every few months; what an assistant may do in your name does not. Tie the rules to the actions, not to the product name.
Who should write it — us or the people who build the automation?
You. The builders can tell you what is technically possible, but only you know which enquiries are worth money and which claims about your business are true. If you are having an automation built, hand the policy over as part of the brief.
Getting this right from the start
We build workflow automation and AI agents and copilots for businesses, and the written rules go in before the first line of code, not afterwards. If you want an automation that knows where to stop, tell us what it would be doing and we will tell you honestly which parts should still be yours.
Related reading: Human in the loop automation: when AI should ask you first and 7 admin tasks you can automate today.
