Search for an AI acceptable use policy template and you get documents written by security firms for companies that have a security firm. They are good documents. They are also eight pages long, and nobody at a 15-person agency is going to read one, let alone follow it. This is the short version: seven sections, each with a sentence on why it is there, written for the owner who is also the IT department. Copy it, change the bracketed parts, send it Monday.
One honest line first: this is a starting point, not legal advice. If you have client contracts with confidentiality or data-handling terms, have your attorney read the finished policy against them.
Why bother with a policy at all
Because the alternative is not “no AI use.” It is AI use you can't see. In Goldman Sachs' survey of 1,256 small business owners this past winter, 76 percent said they already use AI, and data privacy was one of the three barriers most often named to going further. A policy does more for privacy than any setting in any tool, because it brings the personal-account, paste-the-client-brief-into-a-chatbot behavior that is already happening into the open, where you can put it on company accounts with company controls. We covered the account and permission side in our guides to the Team plan and connectors; this post is the human side.
The template
Replace anything in [brackets]. Cut what doesn't apply and keep it to a page.
1. What this covers
This policy covers any AI tool that reads, writes, or acts on company or client information: chat assistants, tools built into the software we already use, and automations that run on a schedule. It applies to employees and contractors.
Why it's here: the scope line stops the “but that's just the thing built into Gmail” conversation before it starts.
2. Approved tools and accounts
Use [Claude on our Team plan] and [list any others] through your company login. Do not use personal accounts for company work, even for the same tool. If you want to try a new tool, ask [Owner name]; the answer is usually yes, and it takes a day.
Why it's here: company accounts are the ones with admin controls, and the ones we can turn off the day someone leaves. The “ask, the answer is usually yes” line is what keeps people from routing around you.
3. What never goes into an AI tool
- Passwords, keys, or login details of any kind.
- Payroll, banking, and HR records.
- Anything a client contract marks confidential, unless [Owner name] has confirmed the tool and account are covered.
- Personal information about customers or staff beyond what the task needs.
Why it's here: the short list is the one people remember. Everything else is allowed by default, which is the point.
4. What needs a human check before it leaves the building
AI can draft anything. A person reviews before it goes to a client or the public: client-facing writing, any number or price, anything legal or medical, and anything sent under your name. Automations that read outside content (email, web pages) may draft and summarize; they do not send.
Why it's here: this is the Rule of Two in one paragraph, and the reason it works is that it matches how you already treat a new hire. The longer explanation is worth ten minutes if you want the reasoning.
5. Who decides
[Owner name] approves new tools, new connections between tools and our data, and any automation that runs unattended. Requests go to [channel or email]. Expect an answer within [two business days].
Why it's here: one named person, not a committee. On a Team plan this is the Owner role, and this section tells everyone else what to do with an idea.
6. Clients and AI
If a client asks whether we use AI on their work, the answer is yes, with a person reviewing anything they receive. If a client asks us not to, we don't, and we note it in their file. We do not connect a client's own systems to our AI tools without asking them first, in writing.
Why it's here: the question is coming. A prepared answer is calmer than an improvised one, and the “ask first” line is a relationship rule as much as a policy.
7. When something goes wrong
If you pasted something you shouldn't have, or a tool did something you didn't expect, tell [Owner name] the same day. There is no penalty for reporting. We would much rather know.
Why it's here: the single most useful sentence in the document. A policy people are afraid of is a policy that hides problems.
Review date: [three months from today]. Tools change; so will this.
Rolling it out without it landing as a crackdown
- Lead with section 2, not section 3. The message is “here is the account you should be using and it's better than the one you have,” not “here is what you're banned from.”
- Say the quiet part. Most people are already using something. Acknowledge it, without asking who, and frame the policy as moving that use onto accounts the business can stand behind.
- Read it together in fifteen minutes. One meeting, the page on screen, questions welcome. The questions will tell you which sections are unclear.
- Pair it with one workflow. A policy plus a concrete first use case (the ones in our Cowork guide are a good start) gives people something to do, not just something to avoid.
- Keep the review date. Ninety days later, ask what the policy got wrong. Something will have.
If you'd like a second pair of eyes on your version, or someone to run that first fifteen-minute meeting with your team, that is the kind of work Cedar & Loam does with agencies and small firms. Proudly based in Kansas City. Say hello.
Sources
- Small Businesses Embrace AI, But Need Training and Support to Fully Harness It, Goldman Sachs 10,000 Small Businesses Voices, survey of 1,256 owners, January 27 to February 4, 2026
- Use connectors to extend Claude's capabilities, Anthropic Help Center
- Agents Rule of Two, Meta AI
- FRSecure's AI acceptable use policy template, for the long-form version this one is a shortening of