How to Write an AI Use Policy for Your Small Business

Here's the uncomfortable part: if you have not written an AI policy, you still have one. It's whatever each person on your team decided was fine. Someone pasted a client contract into a free chatbot to get a summary. Someone else sent a customer an AI-written email and didn't check the details. Neither of them thought they were doing anything wrong, because nobody told them otherwise.

Most owners react to this in one of two unhelpful ways. They ban AI outright — which doesn't stop anything, it just moves the usage onto personal phones where you can't see it. Or they say nothing and hope. The middle path is a short written policy that answers the handful of questions people actually have.

This does not need to be a legal document. It needs to be one page your team can read in three minutes and remember.

Why a one-pager beats a real policy document

Long policies fail for a simple reason: nobody reads them twice. A twelve-page document written by a lawyer gets signed on day one and forgotten by day three. The behaviour it was meant to change never changes.

What works is a document short enough to pin next to the coffee machine. It should be specific enough that someone facing a real decision — can I put this spreadsheet into this tool? — can find the answer without asking you. If your policy can't answer that question in under thirty seconds, it isn't doing its job.

You can always add formal language later, once you know what your team actually does. Start with the one-pager.

The six things every AI policy needs

1. Which tools are approved

Name them. Not categories, not "reputable AI providers" — actual product names, and which account tier. This matters more than people expect, because the consumer version and the business version of the same tool often have very different terms about whether your inputs can be used for training.

Keep the list short. Three approved tools that everyone understands beats fifteen that nobody can keep straight. Add a line about how to request a new one: who approves it, and how long that takes. If requesting a tool is slow and painful, people will stop asking and start using it anyway.

2. What must never go in

This is the most important section, and the one people get wrong by being vague. "Don't share confidential information" means nothing, because everyone draws that line differently. Be concrete about the categories that matter for your business. For most companies that means:

• Customer personal data — names, addresses, phone numbers, account numbers
• Payment and banking details of any kind
• Employee records, salaries, health information, performance notes
• Signed contracts and anything covered by an NDA
• Passwords, API keys, and access credentials
• Anything a client has explicitly told you to keep in-house

Then add the practical workaround, because a rule without an alternative just gets broken. Usually that workaround is: strip the identifying details first. "Summarise this contract" becomes safe when the names, figures, and dates are replaced with placeholders. Teach the redaction habit and the rule becomes easy to follow.

If you want to go deeper on which tools handle data well, we covered that separately in Is It Safe to Put Your Business Data Into AI Tools?

3. What always needs a human check

AI writes confidently whether or not it's correct. Your policy should name the outputs where somebody has to read every word before it leaves the building. A reasonable default list:

• Anything sent to a customer, prospect, or supplier
• Anything with a number in it — quotes, invoices, forecasts, deadlines
• Anything published publicly, including social posts and website copy
• Anything that references a law, regulation, or contract term
• Anything involving an employment decision

Put a name against the check where you can. "A second person reviews it" is a rule. "The account owner reviews it" is a rule someone will follow.

4. When you tell people you used AI

Disclosure is a judgement call, and your team will be relieved to have it made for them. A workable default: you don't need to disclose AI help on internal drafts, research, or first passes. You do disclose when a customer could reasonably feel misled — an AI voice on a call, a chatbot presented as a person, or content where authorship is part of what they're paying for.

Some industries and some contracts require more. Check yours. But make the decision once, write it down, and stop making your team improvise it.

5. Who owns the output

Two lines will cover most cases. First: work produced with AI assistance on company time belongs to the company, same as any other work. Second: AI-generated material may not be original and may resemble existing work, so anything going out publicly gets a plagiarism-and-accuracy check first. That second line protects you from the failure mode where someone ships AI output and assumes it came with a warranty.

6. What happens when something goes wrong

Most policies end with a threat. Yours should end with an invitation. If someone pastes the wrong document into the wrong tool, you need to hear about it within the hour — not next quarter, and not never. That only happens if reporting a mistake is safer than hiding one.

So write it plainly: tell your manager immediately, we fix it together, honest mistakes reported quickly are not a disciplinary matter. Then name the person to tell. A policy that makes people afraid will simply be routed around.

The template

Copy this, fill in the brackets, and you have a working policy in about twenty minutes:

[Company] AI Use Policy

Approved tools: [Tool 1, business plan], [Tool 2, business plan]. To request another, ask [name]. We respond within [X] business days.

Never put into any AI tool: customer personal data, payment or banking details, employee records, signed contracts or NDA material, passwords or keys. If you need AI help with one of these, remove the identifying details first — or ask [name].

Always human-reviewed before it leaves: anything sent to a customer, anything containing numbers, anything published publicly, anything referencing law or contract terms. Reviewer: [role].

Disclosure: no disclosure needed for internal drafts and research. Disclose when a customer might reasonably think they're dealing with a person and they aren't.

Ownership: AI-assisted work done on company time belongs to [Company]. Check public-facing output for accuracy and originality before publishing.

If something goes wrong: tell [name] the same day. Reporting quickly is always the right call and is never a disciplinary issue.

Reviewed: [date]. Next review: [date + 6 months].

Rolling it out so it sticks

Handing out a document is not a rollout. Three things make the difference between a policy that works and a PDF nobody opens.

1. Walk through it live, once. Fifteen minutes in a team meeting. Read it out, take questions, and — this is the part that matters — work through two real examples from your own business. The abstract rule doesn't land. The example does.
2. Put it where the work happens. Pinned in your team chat, linked from the onboarding checklist, printed near the desks if that suits your team. Not buried in a shared drive folder.
3. Date it and review it. Tools change, terms change, and your list of approved tools will be wrong within six months. A review date on the document is what stops it quietly going stale.

Onboarding is the easy win here — new people should get the policy on day one, alongside everything else. If you're formalising that process anyway, our guide to automating new hire onboarding covers where it fits.

The mistakes that make a policy useless

• Writing it in legal language. If your team needs to reread a sentence, they won't follow it. Plain words, short lines.
• Banning everything. A blanket ban pushes usage into places you can't see and can't protect. You lose the visibility and the productivity at the same time.
• No named owner. "The company will review" means nobody reviews. Put a person's name against every decision point.
• Rules with no alternative. Every "don't do this" needs a "do this instead." Otherwise you've just described a problem.
• Writing it once and never again. An eighteen-month-old AI policy is usually wrong about which tools exist and what they do with your data.

Where this fits in the bigger picture

A policy is a guardrail, not a strategy. It tells your team what's safe — it doesn't tell you where AI would actually make you money. Those are separate jobs, and doing them in the right order helps: the policy takes an afternoon and removes the immediate risk, which then frees you to look calmly at where automation is worth building. That's the Diagnose step of the NCFEE Blueprint, and it goes much faster when nobody's worried about what's already been pasted where.

Write the one-pager first. It's the cheapest risk reduction available to a small business right now, and it takes less time than the meeting you'd spend debating whether to allow AI at all.

The bottom line

You don't need a policy because AI is dangerous. You need one because your team is already making these calls individually, without guidance, and inconsistently. One page — approved tools, what never goes in, what gets checked, when to disclose, who owns it, what to do when it goes wrong — gives everyone the same answer. Write it this week, review it in six months, and get on with the actual work.