How to Write an AI Acceptable Use Policy for a Small Team

Most small teams already use AI tools at work, whether or not anyone approved them. Someone drafts client emails in a chatbot, someone else pastes a spreadsheet into an assistant to summarise it, and a developer uses a coding assistant on the company repository. None of that is necessarily a problem. The problem is that nobody has decided what is acceptable, so each person makes their own call about client data, accuracy, and disclosure.

An AI acceptable use policy fixes that. For a team of five to fifty people it does not need to be a long legal document. Two or three pages that people actually read will do more than a twenty-page policy nobody opens. This article explains what to include, offers wording you can adapt, and covers the mistakes that make these policies useless in practice.

This is general guidance, not legal advice. If you handle regulated data (health, financial, children's data) or operate in a jurisdiction with specific AI rules, have a lawyer review your final version.

Start with an inventory, not a document

Before writing anything, find out what is actually being used. A short anonymous survey or a team conversation works. Ask three questions:

1. Which AI tools do you use for work, and on which accounts (personal or company)?

2. What do you use them for?

3. What kind of information do you put into them?

The answers usually reveal the real risks quickly. A policy written without this step tends to ban things nobody does and miss the things everybody does.

The sections your policy needs

1. Scope and purpose

One short paragraph. Who the policy applies to (employees, contractors, interns), which tools it covers (chat assistants, AI features inside existing software, coding assistants, image and voice generators), and why it exists. Keep the tone practical: the goal is to let people use useful tools safely, not to discourage them.

2. Approved tools and accounts

This is the section people will refer to most, so make it a simple list. For each tool, state whether it is approved, which account type must be used, and any limits.

The distinction between business and consumer accounts matters. Many AI providers offer different data handling terms for business plans than for free consumer use, including whether inputs may be used to train models and how long they are retained. Check each vendor's current terms rather than assuming; they change.

Include a short process for requesting a new tool: who to ask, and what they will check. If the process is slow or unclear, people will skip it.

3. Data rules

The most important section. Sort information into a few plain categories and say what may go where. For example:

• Public: published marketing copy, public web pages. Any approved tool.

• Internal: internal process documents, non-sensitive drafts. Company-approved tools only.

• Confidential: client data, contracts, financials, unreleased product details, source code. Only tools specifically approved for confidential data, and only when necessary.

• Restricted: passwords, API keys, payment card details, government ID numbers, health information. Never entered into AI tools.

Add one practical instruction: remove or replace names, email addresses, and identifying details before pasting text, unless the tool is approved for that data. Most tasks (summarising, rewriting, structuring) work just as well with placeholders.

If you have client contracts with confidentiality or data-processing clauses, check whether they restrict the use of third-party processors. Some do.

4. Accuracy and human review

AI output can be wrong in ways that look confident and polished. State clearly that the person who uses AI output is responsible for it, exactly as if they had written it themselves. Then specify where review is mandatory:

• Anything sent to a client or published externally

• Numbers, dates, legal or financial statements, and claims about third parties

• Code merged into production

• Any decision affecting a person: hiring, performance, pricing for an individual customer

For the last category, consider prohibiting AI from making the decision at all, while allowing it to help organise information for the person who decides.

5. Disclosure

Decide when the team must tell people that AI was involved. Reasonable defaults for most small businesses:

• No disclosure needed for internal drafting help, spelling, or formatting

• Disclosure when a client has asked for it or the contract requires it

• Disclosure for customer-facing chatbots, so people know they are not talking to a human

• Follow any platform rules for AI-generated images, video, or voice

6. Intellectual property

Two short points. First, do not paste third-party copyrighted material you are not licensed to use into AI tools for reproduction. Second, be aware that the legal status of AI-generated content varies by country and is still developing. If ownership of a deliverable matters (a logo, a brand name, a key piece of code), get advice before relying on purely AI-generated output.

7. Security

• Use company single sign-on where available

• Do not connect AI tools to email, drives, or code repositories without approval, because connected tools can read far more than what you paste

• Treat AI agents that can take actions (send email, make purchases, change files) as higher risk than tools that only produce text

• Report accidental sharing of confidential data immediately, without fear of punishment for honest mistakes

8. Ownership and review date

Name one person who owns the policy and set a review date, for example every six months. AI tools change quickly, and an outdated approved-tools list is one of the most common reasons people stop following a policy.

Sample wording you can adapt

Short, direct sentences work better than legal phrasing. A few examples:

• "You may use approved AI tools to draft, summarise, and brainstorm. You remain responsible for anything you send or publish."

• "Never enter passwords, payment details, or client personal data into an AI tool unless it is listed as approved for confidential data."

• "If you are unsure whether something is allowed, ask before you paste."

• "If you make a mistake, report it to [name] the same day. We will fix it together."

Mistakes that make AI policies fail

• Banning everything. Blanket bans push usage onto personal accounts where you have no visibility at all.

• Writing it once and forgetting it. A list of approved tools from a year ago is likely to be wrong.

• No examples. "Do not share confidential information" means different things to different people. Concrete examples remove the guesswork.

• Policy without training. A 20-minute walkthrough with real examples from your own work is worth more than an emailed PDF.

• Punishing honest reporting. If people are afraid to report a mistake, you will only find out about it when a client does.

Useful frameworks if you want to go further

Larger organisations, or teams building AI into their own products, may want a more structured approach to risk. The NIST AI Risk Management Framework is a voluntary, freely available framework that many organisations use as a reference for identifying and managing AI risks. It is more than a small team needs day to day, but it is a useful checklist when deciding what your policy might be missing.

If you are still working out where AI fits into your operations at all, the overview of how AI agents are being used in small businesses gives useful context, and the guide to Claude AI's features and use cases shows the kind of capabilities your policy will need to account for.

Keep it short enough to follow

The test of a good AI use policy is simple: could a new hire read it in ten minutes and know what they can and cannot do on their first day? If yes, it is probably the right length. Start with the inventory, write the data rules carefully, name an owner, and revise it as your tools change.