Writing an AI Usage Policy
Write a short, usable policy for agents at work: what data can go where, what needs review, approved tools, and how to handle mistakes.
Without a policy, organizations drift into one of two bad states. In the first, people use whatever AI tools they like, paste in whatever they want, and nobody knows where customer data has gone. In the second, people are so unsure what's allowed that they avoid agents entirely, or use them quietly and hope no one asks. Both are worse than having clear rules.
A good AI usage policy fixes this, and it doesn't need to be long. The best ones fit on two pages and get read. This lesson shows you how to write one: classifying data, choosing approved tools, deciding what needs review, adding rules for agents that take actions, and handling mistakes. It ends with a template you can copy and adapt.
What a good policy does
A usage policy exists to help people make good decisions quickly. Every line should answer a question someone will actually face: "Can I paste this contract into the assistant?" "Do I need to tell the client this was drafted with AI?" "The agent sent the wrong file. Now what?"
That means a good policy is:
- Short. Two pages people read beat twenty pages they don't. Put details in linked appendices.
- Concrete. "Don't put sensitive data in AI tools" is useless because people disagree about what's sensitive. "Customer payment details never go into any AI tool" is usable.
- Enabling. It tells people what they can do, not only what they can't. A policy that's all prohibitions pushes usage underground.
- Owned and dated. It names who maintains it and when it was last reviewed, because the tools change faster than most policies.
What it shouldn't be: a statement of AI principles, a vendor comparison, or a substitute for security engineering. Principles are fine in a separate document. This one is operational.