Writing an AI Policy for a Small Team

Your office manager pastes a tense customer email into a chatbot and asks for a calmer reply. Your bookkeeper uploads a spreadsheet to have it summarized. A salesperson has an AI tool write a proposal and sends it without reading the last page. Nobody asked permission, because nobody knew they needed to.

None of this is bad. Most of it is your team trying to get more done. But each one raises a question you have not answered yet: what may go into these tools, which tools, and who checks what comes out. A short written policy answers those questions once, so your people stop guessing and you stop finding out after the fact.

Why one page is enough

A small business does not need a binder. It needs something a new hire can read in five minutes and remember. A policy nobody reads protects nobody.

Cover four things: data, tools, review and disclosure, plus who to ask. Use plain language and examples from your own work, not legal phrasing borrowed from a large company.

Data: what never goes in

This is the section that matters most. Text typed into an AI tool goes to another company’s servers, and what happens next depends on the tool, the plan and the settings. Your team will not know which is which, so the policy decides for them.

Sort your information into three groups:

• Never. Customer financial details, Social Security numbers, passwords, health information, anything covered by a client contract, and employee records.
• Only in approved tools. Customer names and contact details, internal numbers, pricing, drafts of contracts and proposals.
• Fine anywhere. Public information, your own published marketing, general questions with no names in them.

Give two or three examples from your business for each group. “Never paste a client’s tax return” lands better than “do not input sensitive financial data.” If your business works under rules like HIPAA or handles card payments, the “never” list is not up to you, and our piece on AI and compliance explains why.

Tools: which ones, and on whose account

Name the tools your team may use for work. For each one, note who manages it and whether it is approved for the middle group of data above.

Two rules do most of the work here.

Work happens on work accounts. A business plan in the company’s name, set up by you, with settings you have checked. Not personal accounts on personal email. When someone leaves, you can remove their access, and the work they did stays with the business. The same thinking runs through our plain-English cybersecurity checklist.

New tools get asked about first. Not banned, asked about. AI features now turn up inside software you already pay for, and some browser extensions can read the pages you have open. A quick “is this okay?” to one named person is enough.

Review: a person owns the output

AI tools write with confidence whether or not they are right. They invent figures, misquote policies and occasionally make up a source. The policy should say plainly that whoever sends, publishes or acts on AI output is responsible for it, exactly as if they had written it.

Then be specific about what gets a second look:

• Anything sent to a customer that includes a price, a date, a promise or a policy
• Anything published under the company name
• Any figure, legal statement or claim about a competitor
• Anything that touches hiring, firing or performance

Summarizing your own meeting notes or drafting an outline can skip the second reader. Put checks where mistakes are expensive, not everywhere. If you are moving past chat tools to agents that take actions, the same idea applies with more structure, which we covered in what an AI agent should never do without asking.

Disclosure: when to say AI helped

You do not need to label every email AI helped tidy up. You do need to be honest where it matters to the person on the other end:

• Customers talking to a bot should know it is a bot. A chat assistant on your website should say so, and offer a person.
• Images and video showing real results should be real. A generated photo of a finished kitchen is not your kitchen.
• Client work follows the client’s rules. Some contracts say whether AI may be used at all. Check before the work starts, not after.

Who to ask, and what happens next

End the page with one name: the person who answers AI questions and keeps the approved tool list current. In a small business that is often the owner or the office manager. Add one line saying that mistakes get reported, not hidden, and that reporting one is never the problem. People who are afraid of getting in trouble stop asking and keep doing.

Put a review date on it. Tools change quickly, so reread the policy each quarter and update the tool list and examples.

A one-page outline

1. Why we use AI and what this page is for, in two sentences
2. Data: never, only in approved tools, fine anywhere, with your own examples
3. Approved tools, who manages each, and the rule about work accounts
4. What gets a second reader before it goes out
5. When we tell people AI was involved
6. Who to ask, how to report a mistake, and the next review date

Write the draft in an afternoon. Read it at the next team meeting and ask what is unclear. The questions your team asks are the examples the page is missing.

Where we come in

A policy is the start, not the whole job. Our AI Training program trains teams by role on their real workflows and helps put clear safe-use policies in place. When the questions get bigger, such as regulated data, a stalled pilot or vendors to weigh, a Fractional CAIO sets the policy and guardrails: scope, approval, retention and audit, before anything runs.

If your team is already using AI and nobody has written down the rules, book a call and bring the tools they use today.