How to Write an AI Use Policy for a Small Business

Here is the uncomfortable part: your employees are already using AI at work. Not next quarter. Today. They are pasting client emails into a chatbot to make them sound nicer, running spreadsheets through it, asking it to summarise contracts.

Almost none of them are doing it maliciously. Most of them think they are being efficient. And in the absence of a rule, they are each inventing their own.

Why most AI policies do nothing

The typical small-business AI policy is a page of principles. Be responsible. Protect client data. Use good judgment. It gets written, filed, and never affects a single decision anyone makes.

A policy that works answers questions people actually have at 4pm on a Tuesday:

• Can I put a client's name into this tool?
• Can I upload the contract, or only paste sections of it?
• Do I have to tell the client that AI was used?
• Who approves a new tool, and how long does that take?
• What happens if I already did something on this list?

If your policy does not answer those five, it is decoration.

What belongs in it

1. A tool list, not a tool ban. Name what is approved. Blanket bans do not stop usage; they stop reporting of usage, which is worse. You end up with the same risk and no visibility.

2. A data rule in plain language. Not "exercise caution with sensitive information." Something like: never paste client names, account numbers, medical information, or anything under NDA into a tool that is not on the approved list. Specific enough that someone can follow it without interpreting it.

3. A human review requirement, tied to consequence. Low stakes — an internal draft — needs a glance. High stakes — anything going to a client, a regulator, or a court — needs a named person to check it and to own the output.

4. A disclosure position. Decide once whether clients are told, and in what circumstances. Then be consistent, because inconsistency is what turns a question into a complaint.

5. An approval path with a name and a timeline. If getting a tool approved takes three weeks and an unanswered email, people will simply not ask.

6. An amnesty window. The single most useful clause, and the one nobody includes. Give people thirty days to tell you what they have already been doing, without penalty. You will learn more about your actual exposure in those thirty days than in a year of audits.

The part that determines whether it works

Adoption is not a document problem. A policy that is emailed once and stored in a shared drive changes nothing. A policy that is walked through in a thirty-minute session, where people can ask the awkward questions out loud, changes behaviour — because the awkward questions are the real policy.

A policy nobody can recall under pressure is not a policy. It is a liability shield that has never been tested.

How this connects to risk

If you have to explain your AI decisions later — to a client, an auditor, an insurer, a board — the question will not be whether you had a policy. It will be whether you can show what you decided, why, and who checked the output. That is a documentation habit, and it is far easier to build at the start than to reconstruct afterwards.

Frameworks help here. The NIST AI Risk Management Framework is the reference most auditors recognise, and it is free. It is written for large organisations, but the structure scales down cleanly.

Start here

Write the tool list. Write the data rule. Name the approver. Open the amnesty window. That is one afternoon, and it puts you ahead of most organisations several times your size.

If you would rather start from something already drafted, AI Policy Templates contains ready-to-adapt policy language for small organisations, and The AI Risk Workbook is a print-and-photocopy set of worksheets and audit-ready checklists aligned to the NIST AI Risk Management Framework.