An AI usage policies guide earns its place only if the document it produces fits on two pages and answers six questions: which tools staff may use, what data may never go into them, when a human has to check the output, what happens to work produced with AI, who grants exceptions, and what follows a violation. Everything else is padding. We write these for companies between 10 and 500 people, and the pattern holds regardless of sector. The drafting is not where these efforts fail. They fail in the ninety days after signature, when an employee under deadline pastes a client contract into whichever browser tab is open. This piece covers both halves: what to write, and what makes the writing hold.
The Six Rules This AI Usage Policies Guide Recommends
Read the rest through these six points. They are the whole policy, and each one exists because we have watched its absence cost a client something real.
- Name the approved tools, by product name. A policy that says “approved AI tools” without a list is not a policy, it is a preference.
- List the data classes that never go in. Client PII, payment data, health records, credentials, source code, unreleased financials. Write the list, not the principle.
- Require a named human on anything that leaves the building. Customer-facing, legal, financial and safety work gets reviewed by a person who signs their name to it.
- Say who owns the output. Staff remain accountable for accuracy. AI is not a defense when a number is wrong.
- Give exceptions a real front door. People route around rules that have no path to yes. One owner, one form, a written answer inside a week.
- State the consequence plainly. Loss of access first, disciplinary process second. Vagueness here reads as a bluff and gets treated like one.
Our reader for this is usually a compliance officer or a general counsel wearing three other hats, at a company with no dedicated privacy team and no budget for one.
Why AI Usage Policies Fail Inside Small Companies
AI usage policies fail in small companies because the document is written to survive an audit rather than to be read by the person it governs. We see the same three failure modes across nearly every engagement, and none of them are drafting problems.
The Policy Is Too Long to Be Read
A twelve-page acceptable use document written by outside counsel is defensible and useless. Staff open it once, scroll, sign, and never return. The counter-argument is fair: longer documents cover more ground, and a thin policy leaves gaps a regulator can drive through. Both are true. What we have found is that the length that survives contact with a sales rep at 4pm on a Thursday is two pages, and the coverage a regulator actually asks about is narrower than most drafts assume. The longer version can exist as an annex nobody is required to read. The two-page version is the one that governs behavior. If your organization already maintains a written security policy, the AI rules belong as a section inside it rather than as a free-floating document.
Nobody Owns the Grey Area
Most AI questions are not “may I use this,” they are “may I use this for this.” A marketing draft is obviously fine. A summary of an anonymized client call is arguable. A first pass at an employment letter is not. Policies that only publish a red list and a green list leave the entire middle unassigned, and unassigned questions get answered by whoever is under the most pressure. The opposing view holds that naming an exception owner creates a bottleneck and slows the business down. In practice the bottleneck is smaller than the alternative, which is dozens of individual judgment calls made privately and never recorded. One named owner with a one-week service level costs less than one bad call.
Writing It Is Treated as Finishing It
The signature is the start of the work. Behavior changes when the rule shows up at the moment of the decision, not in an onboarding folder. This is the same dynamic that explains why employees violate cyber security policies they genuinely agree with: the rule was not present when the choice was made. Some argue this is a training problem and that a quarterly refresher closes it. Training helps at the margin. What moves the number is putting the approved-tool list where people look for tools, and making the unapproved path visibly harder than the approved one.
What a Workable Two-Page AI Usage Policy Contains
A workable AI acceptable use policy contains six sections and no preamble, and each section resolves to a decision an employee can make alone in under a minute. We build them in this order.
The Approved Tool List and the Reason It Is Short
Name the products: the ChatGPT or Copilot or Claude tenant your company pays for, under the company account, with the enterprise or business tier that keeps prompts out of training data. The consumer tier of the same product is a different tool with different terms and belongs on the prohibited side. Keeping this list short is deliberate. Every additional tool is another vendor holding your data under terms nobody in the building has read. The reasonable objection is that a short list drives people to use unapproved tools quietly, which is the shadow IT risk that grows quietly inside expanding companies. That risk is real, which is why the list needs a working exception path rather than more entries. Add tools deliberately, on request, with a named reviewer.
The Prohibited Data Classes, Written as Nouns
Do not write “sensitive information.” Write the nouns your staff recognize from their own work: client names paired with case details, cardholder data, protected health information, passwords and API keys, unreleased financials, unfiled legal filings, and anything covered by a client confidentiality clause. Specificity is what makes the rule usable. A person can check a noun against the document in front of them. They cannot check an abstraction. This is also where an AI policy connects to the rest of your data governance practice, because the classes you prohibit in AI tools should match the classes you already classify everywhere else. If those two lists disagree, staff will follow whichever one is more convenient.
The Human Review Line and Who Signs It
Draw the line at work that leaves the company or creates an obligation. Customer-facing copy, contracts, financial figures, medical or safety guidance, and anything filed with a regulator gets read by a named person before it goes out. That person is accountable for the content, not the model. This clause does more work than any other because it converts a vague worry about accuracy into an ordinary approval step your business already knows how to run. Some teams push back that review slows delivery. It does, slightly, and the trade is worth naming out loud rather than pretending it does not exist. The alternative trade is a wrong number in a client deliverable with no one’s name on it.
How to Enforce an AI Usage Policy Without a Compliance Team
Enforcement of AI usage policies in a small company comes down to three moves, none of which require dedicated headcount. The gap between a signed policy and changed behavior is where nearly all of the residual risk sits, so this is the half most guides skip.
Put the Rule Where the Decision Happens
The approved-tool list belongs in the same place people go to find software: the intranet page, the pinned channel message, the browser bookmark bar pushed by policy. A rule in a signed PDF is a rule nobody consults. We also recommend a single reminder line inside the tools themselves where the platform allows a custom notice. The counter-position is that reminders create noise and get ignored after a week. Often true. The version that keeps working is short, appears at the point of use, and names the two or three data classes that matter most in that team’s work rather than repeating the full list.
Make the Approved Path the Easy Path
Every hour the company account takes to provision is an hour someone spends on a personal login. Fast provisioning is an enforcement control, not an IT convenience. The same logic applies to capability: if the sanctioned tool is a worse product than the free one people already use at home, the policy is arguing against gravity. It is worth paying for the tier that actually does the work. This is also the point where the security question deserves a real answer, because AI tools carry their own attack surface and the enterprise tier is usually where the tenant controls live.
Review the Policy on a Calendar, Not on an Incident
Put a quarterly date on it and give the review an owner. Vendors change terms, a tool moves tiers, a new product arrives that half the company is already asking about. A policy that has not moved in a year is describing a market that no longer exists. Pair the review with a short refresher rather than a full training cycle, since ongoing security awareness training works better in small repeated doses than in annual blocks. The same discipline that keeps your broader security policies current and maintained applies here without modification.
Frequently Asked Questions
How long should an AI usage policy be for a small business?
Two pages is the working target for the version employees are required to read. Anything longer can live as an annex for auditors and insurers, but the governing document should resolve a real decision in under a minute. Length correlates with defensibility, not with compliance.
Do we need a separate AI policy or a section in our existing one?
A section inside your existing acceptable use or information security policy is usually the better structure. It inherits the signature process, the review cadence, and the enforcement path you already run. A standalone document is worth it only when AI use is central enough to your operation to warrant its own owner.
What should we do about employees already using unapproved AI tools?
Treat the first pass as discovery rather than discipline. Ask what people are using and what they are using it for, then decide what to sanction. Opening with penalties drives the activity underground, which removes the visibility you need to write an accurate policy in the first place.
Can an AI usage policy satisfy a client security questionnaire?
Often yes, provided it names tools, prohibits specific data classes, requires human review, and shows a review date. Questionnaires increasingly ask whether an AI policy exists and when it was last updated. A dated, signed two-page document answers both, where a general statement about responsible AI does not.
Who should own the AI policy inside a small company?
One named person, usually whoever already owns information security or compliance. Shared ownership between IT and legal reliably produces a document with no exception path, because neither side wants to be the one saying yes. Name the owner in the policy itself.
Talk Through Your AI Policy With Someone Who Has Written a Few
The takeaway is narrow on purpose. A written AI usage policy is worth having, it should be short, it should name products and nouns rather than principles, and the work does not end at signature. Most of the risk that remains after you publish sits in the ninety days that follow, in the gap between what the document says and what a person under deadline actually does. Closing that gap is a matter of putting the rule at the point of decision, making the sanctioned route the fast one, and reviewing the whole thing on a calendar you set in advance.
If you want a second set of eyes on what you have drafted, or you are starting from a blank page, our team can walk you through where your current exposure sits and what a right-sized policy looks like for your headcount and sector. A structured AI risk assessment is often the cleanest starting point, because it tells you what you are actually governing before you write rules about it. Book a free strategy call and we will look at it with you.
