Why a written policy matters, and what this template is
The risk with workplace AI is rarely a single dramatic incident. It is the steady accumulation of small, undocumented decisions: an employee pastes a customer list into a free chatbot to draft an email, a contractor uploads source code to summarize it, a manager ships AI-written copy without checking the facts. None of these people are acting in bad faith. They simply have no guidance, so they improvise. A short written policy replaces improvisation with a shared expectation everyone can point to.
This document is a template, not a finished policy. It is organized into sections you can copy, edit, and drop into your own employee handbook or standalone AI policy. Each clause is written as a plain statement an SMB can adapt to its actual tools, data, and risk tolerance. Treat the wording as a draft to review with your own legal and compliance counsel before you adopt it, especially if you operate in a regulated industry or handle personal, health, or financial data. The goal is a policy people will actually read and follow, so keep it short, specific, and free of jargon.
Scope and purpose: define what the policy covers
Start by stating plainly what the policy is for and who it applies to. Scope should cover employees, contractors, and anyone acting on the company's behalf, and it should name the kinds of AI tools in play: general assistants like chatbots, AI features built into software you already use, coding assistants, and any AI agents or automations that act on their own. Being explicit here prevents the common excuse that 'I didn't know this counted as an AI tool.'
The purpose statement should set the tone: the company supports using AI to work better, and this policy exists to make that use safe, approved, and accountable, not to ban it. People follow rules they understand the reason for. A policy framed as 'here is how to use AI well' earns more compliance than one framed as a list of prohibitions, while still drawing clear lines around the things that genuinely create risk.
Approved tools and data handling: the two clauses that prevent most problems
The single most effective control for an SMB is a short list of approved tools. When the company names which AI services are allowed, and which account tiers or settings to use, employees stop quietly defaulting to whatever free tool they found. Pair the list with a simple request path so that adding a new tool is easy and sanctioned rather than something people do in the shadows. The point is not to slow people down; it is to make the safe option the easy one.
Data handling is the other half. The hard truth is that anything typed into an external AI tool may leave your control and be processed by a third party, so the policy must classify what is allowed in and what is forbidden. Be concrete: name the categories that must never be pasted into a general AI tool, such as customer personal data, credentials and secrets, regulated records, and confidential business information. Then point people to the approved, contracted tools for any work that genuinely needs sensitive data. Read the data and retention terms of the specific tool tier you approve, because consumer and business plans often handle your inputs very differently.
Human review and accountability: AI drafts, people decide
AI output is fluent and confident, which is exactly why it needs review. The policy should establish a simple principle: AI produces drafts, and a responsible person remains accountable for anything used, published, or acted on. This closes the gap where fluent-sounding output gets a free pass that no junior employee's first draft would ever get. The person who uses the output owns it, the same as if they had written it themselves.
Make the level of review proportional to the stakes. Low-risk internal drafts may need only a sanity check, while anything customer-facing, legal, financial, or safety-related needs a knowledgeable human to verify facts, figures, and claims before it goes out. Spell out that AI must not be the sole basis for decisions that significantly affect a person, such as hiring, credit, or termination. Accountability that lives with a named role, not with 'the AI,' is what keeps a confident-but-wrong output from becoming a confident-but-wrong action.
Roles, training, and enforcement: making the policy stick
A policy with no owner becomes stale the week after it is written. Assign clear roles: someone accountable for the policy overall, someone who maintains the approved-tools list and reviews new requests, and a clear expectation that every employee follows the rules and asks when unsure. In a small company these can be part-time responsibilities held by existing staff, but they should be named so there is always a person to go to.
Finally, the policy only works if people know it exists and understand it. Plan a short onboarding briefing, a periodic refresher, and a named contact for questions, so the policy is a living reference rather than a forgotten document. State the consequences of violations in the same measured way you would for any other workplace policy, and review the whole thing on a set cadence because tools, vendors, and risks change quickly. A policy you revisit twice a year stays useful; one you write once and file away does not.
A short, specific AI policy that names approved tools, forbidden data, human review, and a real owner prevents far more harm than a long one nobody reads, but adapt it with your own legal and compliance counsel before you adopt it.