AI use policy template for SMBs

Your employees are already using AI at work. The only question is whether they're doing it under rules you wrote or rules they're improvising — pasting who-knows-what into who-knows-which chatbot on a personal account. An AI use policy isn't about banning tools; it's about channeling use you can't stop into paths you can defend. Here's the policy, section by section, with the reasoning behind each part so you can adapt it instead of cargo-culting it. One note before the template: this is a template, not legal advice — have counsel review the final version, especially if you operate in a regulated industry.

The policy, section by section

1. Purpose and scope. One paragraph: this policy governs the use of AI tools — chatbots, assistants, code and content generators, transcription — by anyone doing work for the company, on any device, on any account. The "any account" clause is the load-bearing part: shadow use on personal accounts is precisely what the policy exists to surface.

2. Approved tools. A short, named list of the AI tools the company sanctions, at which subscription tier — because the enterprise tier of a tool and its free consumer tier have completely different data terms. Include the request path: how an employee proposes a new tool, and who decides. A policy without a request path teaches people not to ask.

3. Data rules. The most important section in the document. Define what may never be pasted, uploaded, or dictated into an AI tool outside your approved, contracted tiers: customer names and contact details, anything covered by an NDA, credentials and keys, financial records, employee personal data, unreleased plans and pricing. Tier it by tool trust level — what's permitted in the company-contracted tier with training-data exclusion is different from what's permitted in a free chatbot, which for confidential data is nothing.

4. Human review. AI drafts, humans ship. Anything that leaves the company — an email, a proposal, a contract clause, code in production, a social post — gets reviewed by the accountable person before it goes. The clause is a quality gate, not a loyalty test: the person who ships it owns it, however it was drafted.

5. Disclosure. When work is AI-assisted, when does anyone need to know? A sane SMB default: internal use needs no disclosure; client deliverables follow whatever the client contract says; and nobody presents AI output as an expert's independent judgment where that judgment was the thing being bought.

6. Accounts and access. AI tools are used through work accounts with MFA — not personal logins — so access ends when employment does and usage is auditable. No shared accounts: shared logins are how one person's bad paste becomes unattributable.

7. Enforcement and review. Violations follow the same ladder as any other acceptable-use policy. The policy itself is reviewed on a schedule — every six months is realistic while the tool landscape is moving this fast — and the approved-tools list can change between reviews without re-issuing the whole policy.

Why each section is there

The data rules are the whole ballgame for an SMB. Almost every real-world AI incident at small-business scale is a data-handling incident: the customer list summarized in a free chatbot, the contract pasted in for a redline, the credentials in a debugging prompt. Sections 2 and 6 exist to make section 3 enforceable — you can't reason about data paths if you don't know which tools and whose accounts. And tool tiering beats a blanket ban every time: banning AI outright doesn't stop usage, it just moves it to phones and personal laptops where none of your rules reach.

If you're in a regulated industry

This template is the floor, not the ceiling. A healthcare or dental practice needs the policy plus the deployment controls that HIPAA actually turns on — BAAs, training-data exclusion, audit logging, retention — which is a different document with different stakes: the HIPAA-compliant AI guide covers that checklist. Law and accounting firms carry confidentiality duties that make the data rules stricter by default — the professional services guide goes deeper. And to be precise about what a policy buys you: a policy is not compliance. Compliance lives in how tools are actually deployed and used; the policy is how you make that deployable.

The policy is step one, not the strategy

Writing the policy usually surfaces a bigger question: which of these tools is actually worth anything to the business? That's a different exercise — looking at where the hours go and what's worth automating properly, versus what's just novelty. The policy makes experimentation safe; an assessment makes it deliberate. For the wider picture of what AI adoption looks like at small-business scale — beyond individual chatbot use, toward systems that actually carry work — start with the rest of this pillar.