AI Acceptable Use Policy for a Small Business: Outline and Rules

01What an AI acceptable use policy should do

Your team is probably already using AI tools, some through software you pay for and some through personal accounts. A policy turns those individual choices into a few shared rules people can follow without asking every time. Some businesses call it a generative AI policy or an AI usage policy, and the contents are the same. It should answer five questions: which tools are approved, what data may go into them, who checks the output, when AI use is disclosed, and who to tell when something goes wrong.

NIST's Generative AI Profile, a voluntary companion to its AI Risk Management Framework, suggests organizations define acceptable use policies for generative AI. Keep yours short enough to read in five minutes. This guide describes common policy content, not legal advice; have your attorney review the final version for your industry and state.

• Write rules people can apply during real work, such as never paste a customer's payment details into any AI tool.
• Avoid rules nobody can follow, such as a total ban that pushes use onto personal phones.
• Date the policy and say when it will next be reviewed.

02Start with an inventory of the AI tools already in use

Before writing rules, find out what people use. Ask each person which AI tools they've tried for work, what they used them for, and whether the account is personal or paid by the business. Include AI features built into software you already have, such as writing assistants in email, document, CRM or accounting tools, because those often switch on with an update.

NIST's profile suggests keeping an inventory of generative AI systems, deciding in policy how to treat AI embedded in other software, and recording details such as the underlying model, human oversight roles and any sensitive data involved. A small business can do this in a shared spreadsheet with one row per tool.

• Record the tool, vendor, plan, account owner, who uses it and for which tasks.
• Note whether the vendor trains on your data by default and how long it keeps chats or files.
• Mark each tool as approved, approved for limited data, or not approved.

03Approved tools and company accounts

Name the approved tools in the policy, including the plan, because data terms often differ by plan. For example, OpenAI's help center says it may train on content from its individual ChatGPT plans unless the user opts out, while it does not train on ChatGPT Business or Enterprise workspace data by default. A rule that says ChatGPT is approved is too vague; a rule that says use the company ChatGPT Business workspace is clear.

Require company-controlled accounts for work so the business can remove access when someone leaves. Say who approves a new tool or a new connection to company systems, and what they check first.

• Approved: list each tool and plan, and the account people must sign in with.
• New tools: one named person approves them after reading the vendor's data and retention terms.
• Connected apps and AI agents that can read or change company systems need separate approval for each connection.

04Data classes: what may go into which tool

Many AI policy mistakes involve data. Sort your information into three or four classes with examples your team recognizes, then say which class may go into which tool. Keep the restricted class short and absolute so nobody has to judge it under deadline pressure. If a contract, regulation or client agreement sets stricter terms, that agreement wins over this table.

05Review rules: who checks AI output before it counts

Set review by consequence rather than by tool. An internal draft can be checked by the person who asked for it. Anything sent to a customer, published or used in a contract needs that person's full check of facts, numbers and promises, and the most sensitive items need a second reviewer. Decisions about people, such as hiring, pay, discipline, credit or pricing for an individual, stay with a person who reviews the facts directly.

Vendor terms can say the same. OpenAI's usage policies, for example, prohibit automating high-stakes decisions in areas such as employment, credit, insurance and housing without human review.

• The person who sends or publishes AI-assisted work is accountable for it.
• Check every figure, date, name, quote and citation against its source before use.
• Code written with AI assistance goes through the same review and testing as any other code.

06Disclosure, honesty and ownership rules

Say when people must disclose AI use: to a client whose contract requires it, in work a client expects your team to have created, and anywhere a customer might reasonably believe they are dealing with a person. Ask your attorney whether any state law or industry rule adds requirements for your use.

In 2024 the FTC's chair said there is no AI exemption from the laws on the books. The agency's rule on consumer reviews and testimonials, in effect since October 21, 2024, prohibits writing or selling fake or false reviews and testimonials. Your policy also needs a rule on ownership. The U.S. Copyright Office concluded in January 2025 that AI output is protectable only where a human determined sufficient expressive elements; prompts alone are not enough.

• Never use AI to write customer reviews or testimonials, or to make product claims you can't support.
• Keep a note of the human contribution on work your business needs to own, such as designs, copy or code delivered to clients.
• Check client contracts for AI clauses before using AI on their work.

07Ownership: name who keeps the policy current

A policy without an owner goes stale when vendors change their plans. Name one policy owner, usually the owner or office manager in a small business, and one account owner for each approved tool. NIST's Generative AI Profile, organized around the AI Risk Management Framework's GOVERN, MAP, MEASURE and MANAGE functions, includes documenting roles, responsibilities and lines of communication under GOVERN 2.1.

The policy owner keeps the tool list, approves new tools, answers questions and reviews the policy on a schedule. Quarterly is a reasonable starting point for a small team, plus any time a tool changes its data terms.

• Policy owner: maintains the document, the tool list and the training record.
• Tool account owner: manages seats, settings and offboarding for one tool.
• Every employee: follows the rules, asks when unsure and reports problems early.

08Incident reporting: what to report and how fast

Tell people exactly what counts as an AI incident and make reporting quick and blame-free, because early action limits the damage when data has gone somewhere it shouldn't. Report the same day for restricted or confidential data pasted into the wrong tool, wrong AI output sent to a customer, an AI agent or connected app taking an unexpected action, or a tool behaving as if an email or document gave it instructions.

NIST's profile lists minimum fields for incident reports, such as reporter, system, date, description and impact. A short form or email template with those fields is enough for a small business.

• Report to the policy owner by phone or chat, then follow up with the written details.
• Contain first: delete the chat if the tool allows it, disconnect the app, revoke a shared key or recall a message.
• The policy owner decides whether customers, clients or a professional adviser need to be told.

09AI usage policy template: a one-page outline to adapt

Use this outline as a starting structure and replace the example wording with your own tools, data and roles. Keep each section to a few sentences. If a section needs pages of detail, move that detail into a procedure and link to it.

10Train people on the policy, then check that it works

Run a short session where each person brings a real task, sorts the data it involves into a class and tries it in the approved tool. Many questions come up in that session, and the answers belong in the policy or a short FAQ. Have each person acknowledge the policy in writing, repeat training when tools or rules change, and ask the team after a month which rules were unclear or ignored.

• Use examples from your own work, including one that should be refused.
• Keep a record of who completed training and when.
• Treat repeated workarounds as a sign the rule or the approved tool needs to change.