Last updated:
If anyone on your team works at a computer, they are very likely using AI right now: to write an email, fix a bug, or maybe paste a spreadsheet of customers into a free account. The question isn't whether they use it. It's under what rules.
An AI usage policy is a short document that says which tools, with which data, for which tasks and with what responsibility are allowed in company work. For most teams one page is enough, as long as it's clear and everyone has read it.
What does an AI policy protect against?#
Five specific risks, one of which will eventually happen if there are no rules:
- Data leaks: customer information, keys or contracts in someone's personal account.
- Wrong output under the company's name: an article, a support reply or a number in a report that nobody checked.
- Legal problems: an image or text with unclear copyright status.
- Excess access: an agent or plugin connected to email, a code repository or a site admin panel without anyone knowing.
- Fraud: a fake message or voice that pushes someone to make a payment; details in AI scams.
Four core principles#
Against these risks, four sentences go at the top of the document, and the rest of the rules follow from them:
- A human owns the output. "The AI wrote it" excuses no mistake.
- Data is handled by its sensitivity, not by convenience.
- Only approved tools and accounts.
- No hidden use. If AI did a large part of the work, the reviewer should know.
How should you classify data?#
With three colors, green, yellow and red, so that an employee can decide in two seconds while working. This is the most important part of the policy:
| Color | Examples | Rule |
|---|---|---|
| Green | Public website text, public documentation, open-source code | Allowed in any approved tool |
| Yellow | Proprietary code, internal reports, sales data without names | Only with a company account and after removing names |
| Red | Passwords and keys, customers' personal information, ID and banking documents | Never, in any cloud tool |
Make no exceptions for red. We covered how to clean data before sending it in what you should never give AI.
Which tools and accounts are allowed?#
Those on the company's approved list, used with a company account. The details:
- A short list of approved tools, with a named owner for each.
- Company accounts instead of personal ones. These usually give you more control over data retention; check each service's official page for the exact terms.
- Turn off the option to use data for model training wherever possible.
- A simple way to request a new tool. If asking is hard, people install things without permission.
- Browser extensions, agents and connections to other services (for example through MCP) need separate approval, because they gain access to other data.
What rules should apply to code, content and customer replies?#
The general rule: every AI output goes through the same review as human work, and anything that leaves the team has been read by one person:
| Task | Allowed? | Condition |
|---|---|---|
| Internal text and work email | Yes | No red data in it |
| Content published on the site | Yes | Human review and fact-checking of claims |
| Code | Yes | The same review and testing as any other code |
| Customer replies | With care | Draft with AI, send by a human |
| Images for ads and the site | With care | Check the tool's commercial-use terms |
| Agents with access to systems | Only with approval | Least privilege and approval of irreversible actions |
| Decisions about people | Not alone | A human makes the final decision |
For code, the policy should say explicitly that generated code gets no special treatment. What automated review catches and misses is in AI code review. For images, the legal situation is still taking shape; see copyright and commercial use of AI images.
What should happen when something goes wrong?#
Report it fast, with no blame. A policy that only punishes makes people hide mistakes. Write the routine in advance:
- Report immediately to one named person, through one named channel.
- If a key or password was exposed, revoke and replace it at once.
- If customer data was involved, the responsible owner decides who must be notified.
- One line in the incident log: what happened, why, and what in the policy should change.
A one-page policy template#
Use this text as a starting point and adapt it to your team:
- This policy applies to all employees and project contractors.
- Approved tools: [list]. Tool owner: [name].
- Use only a company account for company work.
- Red data is never entered into any cloud AI tool.
- Yellow data only with a company account and after removing names.
- Any output that leaves the team is checked by one person before publishing.
- Generated code goes through the same review and testing.
- Connecting an AI tool to email, a code repository or a site admin panel requires the owner's approval.
- Report any mistake immediately to [name]; timely reports are not punished.
- This policy is reviewed every six months.
Writing it is half the work. Thirty minutes of training with real examples from your own team does more than ten pages of text. Put the policy next to your new-hire onboarding guide and ask the team which tools they need; a policy that makes work hard gets bypassed.
Where this is heading#
AI is moving from a separate tool to a part of everyday software: email, text editors, design tools and coding environments. So the question "which tool is allowed" gradually turns into "which feature with which data." At the same time, agents are getting more access to systems, and customers and regulators increasingly ask what companies do with their data.
To prepare:
- Write the policy around data and access, not tool names; that part ages more slowly.
- Keep a list of every connection between AI and company systems.
- Name one owner for the policy who follows up on the periodic review.
Summary#
- A total ban doesn't work; give people approved tools and clear rules.
- Whoever publishes or merges an output owns it.
- Use three data colors and make no exceptions for red.
- Agents and connections to systems need separate approval and least privilege.
- Report mistakes without blame and use them to improve the policy.
