Building an AI Usage Policy for Your Company

Most internal AI policies are written to be defensible rather than to be followed, and they produce the outcome they were meant to prevent: people use the tools anyway, on personal accounts, invisibly. A policy that is short, specific and permissive about the safe cases is a better control than a strict one nobody reads.

This is an engineering and operations template, not legal advice. Have it reviewed by whoever handles your employment and data obligations before publishing it, particularly the monitoring section, which is regulated differently in different places.

The failure mode to design against

Shadow usage is the thing to prevent, and it is caused by policy, not by disobedience. A blanket prohibition means work moves to personal accounts, where you have no contract, no retention control, no audit trail and no idea what was sent. That is strictly worse than sanctioned usage with rules, and the second-order effect is worse still: once people are hiding the tool, they stop asking questions about it.

So the design goal is a policy where the compliant path is also the easy path. In practice this means naming the approved tools, being explicit that ordinary work is fine, and reserving the friction for the categories that genuinely need it.

The template

AI USAGE POLICY — <company>            v1.0 · owner: <name>
Applies to: all staff and contractors.  Review: every 6 months.

1. APPROVED TOOLS
   Use these for work:  <tool A>, <tool B>, <tool C>
   Access them through your company account only. Personal
   accounts are not approved for company work of any kind.
   Want something not on the list? Ask <channel>. We say yes
   more often than no, and the review takes about a week.

2. WHAT YOU MAY SEND — GREEN
   Public information, your own drafts, internal documents that
   are not confidential, code from public repositories, general
   questions. No approval needed. This is most of your work.

3. WHAT NEEDS CARE — AMBER
   Internal confidential material, customer names, non-public
   financials, unreleased plans, source code from private repos.
   Allowed in approved tools, provided you remove identifying
   details you do not need. Ask if unsure.

4. WHAT MUST NOT BE SENT — RED
   - Credentials, keys, tokens, certificates
   - Personal data of customers or staff beyond the minimum
     needed, and never special-category data
   - Anything under a contract that forbids third-party
     disclosure  (check before, not after)
   - Regulated data outside the approved path: <named path>

5. BEFORE YOU RELY ON THE OUTPUT
   You are responsible for what you send on. Check facts,
   figures, citations and code. Do not paste generated code
   into production without reading it. Do not send generated
   text to a customer or a regulator without reading it.

6. WHEN TO SAY IT WAS AI
   Tell people when they are talking to a system rather than a
   person. Say so if AI drafted something you send externally
   under your name. See <disclosure standard> for specifics.

7. DECISIONS ABOUT PEOPLE
   Do not use AI as the deciding factor in hiring, performance,
   discipline, pricing to an individual, or access to a service.
   Assistance is fine; the decision is a person's, and that
   person's reasoning must stand up without the tool.

8. IF SOMETHING GOES WRONG
   Sent something you should not have? Tell <channel> the same
   day. No blame for reporting; we need to know to act on it.

9. WHAT WE MONITOR
   We record which approved tools are used and by which team,
   for cost and capacity. <State precisely what else, if
   anything, is logged, and check this section locally.>

The reasoning, clause by clause

• Approved tools, with a fast path to add one. The list is what makes everything else enforceable, and the fast path is what stops the list from being routed around. A one-week review that usually says yes is a functioning control; a six-week review that usually says no is a fiction.
• Green before amber before red. Leading with what is allowed is not softness, it is accuracy — the large majority of what people want to do is genuinely fine, and a policy that opens with prohibitions trains readers to assume the answer is no and stop reading.
• Credentials at the top of red. The most common real incident, and the one with the fastest consequence. It also generalises: if a secret goes into a prompt, treat it as leaked and rotate it, the same as any other exposure.
• Responsibility for output. The single most important clause, because it prevents the failure where a person forwards something wrong on the basis that a tool produced it. State it in terms of what the person sends on, not in terms of the tool.
• Decisions about people, called out separately. This is where regulatory exposure concentrates, and where an individually reasonable shortcut does the most harm. It is worth its own numbered section so nobody can claim it was buried.
• A no-blame reporting route. You will only ever hear about the incidents people are not afraid to report. This clause is what turns the policy from a rule set into a source of information.
• Monitoring, stated honestly. Say exactly what you record. Vagueness here destroys trust in the whole document, and in several jurisdictions workplace monitoring carries its own requirements — this is the section to have reviewed locally.

Enforcement that is not theatre

A policy is enforced by defaults, not by a signature at induction. What actually moves behaviour: company accounts provisioned so the approved tools are the frictionless ones; secret scanning that catches credentials before they reach a prompt as well as before they reach a commit; a redaction layer in company-built tools, so the amber rule is partly automatic; and a short, specific onboarding note with real examples from your own business rather than generic warnings.

Deliberately not on that list: blocking domains at the firewall as the primary control. It moves the work to phones, teaches people to route around security, and produces confident statements about usage that are simply untrue.

Keeping it alive

Put an owner and a review date on it, and re-read it whenever the tool list changes, which will be more often than every six months. Two questions at each review: what did people ask about that the policy did not answer, and what did people do that the policy did not contemplate. Both are answers to a document that is out of date, and both are cheap to collect if the reporting channel from clause eight is real.