How to Write an AI Use Policy for a Small Team
A workable AI policy for a small team fits on one page and answers four questions: which tools are approved, what data must never be pasted into them, when you have to tell someone you used AI, and who to ask when the policy does not cover your situation.
Everything longer than that gets skimmed once during onboarding and never opened again. Meanwhile people keep using whatever is open in their browser, which is how you end up with client contracts in a free chatbot.
Start From What People Already Do
Before writing anything, find out what is actually in use. Ask, do not audit, at least the first time. Make it explicitly consequence-free: “I need to know what people are using so I can approve the good ones, not to catch anyone.”
You will usually discover three or four tools you did not know about and one person doing something genuinely alarming with customer data. That is the point of asking.
The Four Sections
Approved tools. Name them. A list of two or three specific tools beats a paragraph of principles, because principles require judgment at the exact moment people are in a hurry. Include what each is approved for. “Tool A for drafting and rewriting internal text. Tool B for code assistance in the sandbox repo only.”
The never list. Be concrete and short. Customer personal data. Anything under NDA. Credentials, keys, and tokens. Unreleased financials. Health or legal records. Source code from the client repos. Five to eight items, each recognizable in the moment.
Vague versions of this fail. “Do not share confidential information” means nothing at 4pm when someone is deciding whether an email thread counts.
Disclosure. State when it is required rather than leaving it to conscience. A reasonable default: no disclosure needed for grammar, tone, and formatting help; disclosure required when AI generated analysis, recommendations, or client deliverables; always disclose in hiring materials and regulated communication.
Who decides. One name. Not a committee, not “your manager,” one person who answers edge cases and can approve a new tool within a couple of days. If approval takes three weeks, people will route around it and your policy becomes decorative.
Write It So It Survives Contact
The difference between a policy that works and one that does not is usually tone.
Before:
Employees are expected to exercise appropriate discretion and sound professional judgment when utilizing generative artificial intelligence technologies in the course of their duties, ensuring at all times that organizational data governance standards, confidentiality obligations, and applicable regulatory requirements are fully upheld.
After:
Use Tool A and Tool B. Never paste customer data, NDA material, credentials, or unreleased financials into any AI tool, including those two. If you used AI to produce analysis or anything a client sees, say so. Anything not covered here, ask Priya before you paste.
The second version is enforceable, memorable, and can be read in fifteen seconds. The first version protects the person who wrote it and nobody else.
A Wrivio Context for this could say:
Rewrite this policy text as plain, direct workplace English. Short sentences, second person, active voice. Replace abstract phrases like appropriate discretion with concrete rules and named examples. Keep every rule, name, and deadline exactly as written and do not add rules that are not in the original. Keep it under two hundred words.
Press Ctrl+Shift+Space, paste your legal-sounding draft, and run it. Read the diff carefully on policy text specifically, because a rewrite that turns “must not” into “should avoid” changes what you can enforce.
The Local-Tool Shortcut
One thing that makes a small-team policy much simpler: approving a tool that processes text on the device.
If rewriting happens locally, most of the never list stops applying to that tool, because nothing is transmitted anywhere. That collapses a lot of case-by-case judgment into a single sentence, and it is why teams handling client or patient material often approve an on-device rewriter and restrict cloud chatbots to non-sensitive work.
Review It Twice a Year
Set a recurring date. Tools change, vendors change their data retention terms, and your never list will need updating after the first real incident.
At each review ask three things: has anyone hit an edge case the policy did not cover, has any approved tool changed its terms, and is anyone still using something unapproved. If the answer to the last one is yes, the problem is usually that approval is too slow.
Common Questions
Do we need a lawyer to write this?
Not for a one-page internal policy. Get legal review if you are in a regulated sector, handle health or financial data, or have client contracts with AI clauses.
What if someone breaks it?
Treat a first breach as a policy design failure and ask what made the wrong path easier. Repeat breaches are a management issue, not a documentation issue.
Should we block AI tools at the network level?
Blocking without providing an approved alternative reliably pushes usage onto personal phones, where you have no visibility at all.
Download Wrivio for Windows to give your team a rewriting tool that runs locally, so most of the never list stops being a daily judgment call.
Read Next
How to Run an AI Tool Audit for Your Team
Find out which AI tools your team is really using, what data has gone into them, and what to do next. A one-week audit that does not turn into a witch hunt.
Bring-Your-Own AI: Writing a Policy That Survives Contact With Reality
A large majority of workplace AI users bring unapproved tools. A policy that acknowledges that, gives followable rules, and closes the gap that caused it.
Shadow AI in 2026: What the Numbers Actually Say
Roughly a third of employees have put confidential data into public AI tools, and most workplace AI use is unsanctioned. The data, and why prohibition has failed as a strategy.
How to Write an API Deprecation Notice
What is going away, when, what to use instead, and what breaks if you ignore it. How to deprecate without losing the developers who depend on you.
This article is filed underPrivacy & Compliance, which has 53 articles.