How to Write an AI Usage Policy Your Team Will Actually Follow
Most usage policies fail before anyone reads them. They’re too long, too abstract, or written in language that sounds like it came from a legal department rather than someone who understands how the work actually gets done. Your team skims it, signs off, and forgets it exists.
A usage policy that works is short, specific, and grounded in the actual workflows your team runs. Here’s how to write one.
What a Usage Policy Actually Needs to Cover
Four things: what Claude is for, what’s off-limits, what to do in gray areas, and who to ask when something’s unclear. That’s the whole document. Everything else is elaboration.
If you can’t summarize your policy in one page, it’s too long. Your team won’t remember a ten-page document. They’ll remember a clear set of rules they heard explained by someone they trust.
Start With What’s In Scope
Be specific about the workflows you’re encouraging. Not “Claude can be used for productivity tasks” — that’s meaningless. Instead, name the actual use cases: drafting client-facing communications, summarizing meeting notes, researching publicly available information, creating internal documentation, generating first drafts of proposals.
Specificity does two things. It tells your team exactly where Claude adds value so they actually use it. And it makes the off-limits list feel less arbitrary, because the in-scope list shows you’ve thought through what’s appropriate.
Be Direct About What’s Off-Limits
This section needs to name actual data categories, not vague risk language. “Sensitive data” isn’t a rule your team can act on. “Client financial records, protected health information, and any data covered by a client confidentiality agreement” is.
What Data Should Your Employees Never Put Into AI Tools
Walk through the categories that apply to your business specifically. If you work with healthcare clients, call out PHI by name. If your client agreements have data-sharing restrictions, reference them. The more your policy reflects your actual business, the more seriously your team will take it.
Build In a Yellow Category
Binary policies — allowed or not allowed — break down at the edges. Real work produces situations that don’t fit cleanly into either category. A client name attached to an internal summary. A financial projection that references a specific deal. A support case with personal details alongside technical information.
At Fast Slow Motion, we use a traffic-light model: green means proceed, red means never, yellow means stop and ask. The yellow category routes uncertain situations to someone who can make a call, rather than leaving the employee to guess or, worse, avoid using Claude entirely because they’re not sure what’s allowed.
How to Classify Your Business Data Before Rolling Out AI
Name a specific person or role as the yellow-category contact. “Ask your manager” is too vague. “Ask [name] or send a message to [channel]” is actionable.
Address Accountability Directly
Your policy needs to say plainly that AI assistance doesn’t transfer responsibility. When someone uses Claude to produce a document, a report, or a client deliverable, they own it. Claude helped. They’re accountable for the output — for reviewing it, checking it, and standing behind it.
This isn’t about blame. It’s about making sure your team applies judgment before anything Claude produces goes anywhere important. A sentence or two in the policy is enough. A conversation during training is better.
Keep the Language Plain
Write the policy the way you’d explain it to a new hire on their first day. If a sentence requires a second read to understand, rewrite it. Legal language signals that the document is for liability protection, not for the people who have to follow it. Your team will treat it accordingly.
Read it out loud before you finalize it. Anything that sounds awkward spoken will get ignored when written.
Train Your Team on It in Person
A policy document on its own isn’t enough. Schedule a 30-minute conversation with your team before they get access to Claude. Walk through the in-scope workflows, the off-limits categories, and a few real examples of gray-area situations from your actual business. Leave time for questions.
The questions are the most useful part. They surface the situations you hadn’t anticipated and give you the chance to answer them before someone makes a judgment call on their own.
The Business Owner’s Guide to Claude Governance
Update the policy when those questions reveal gaps. A usage policy that gets revised is a usage policy that’s being used.
Review It on a Schedule
Set a calendar reminder to review the policy every six months. AI tools are changing fast — features that didn’t exist when you wrote the policy may exist now, and workflows your team has developed may not have been on your radar when you wrote the original document.
A policy that was accurate a year ago may not reflect how your team is actually working today. The review doesn’t need to be a big project. It needs to happen.
Listen to the full podcast episode here.