If you've been asked to write an AI usage policy for your company, you've probably noticed there's no shortage of advice out there. Most of it falls into one of two camps: either it's a high-level overview that doesn't actually tell you what to write, or it's a 50-page enterprise framework you don't have time to read.

This post is the practical middle. Eight rules every AI usage policy needs, with sample policy language for each. So you can copy what works, adapt the rest, and have something usable by the end of the day.

This isn't legal language (that's a lawyer's job). These are the behavioral rules. The actual things your team needs to know about how to use AI at work.

Why an AI usage policy matters

Most companies don't have an AI usage policy. Their employees use AI anyway. That's the gap.

When the rules aren't written down, every person on your team is quietly making up their own. One marketer uses ChatGPT to draft customer emails. Someone in sales pastes deal terms into Claude. An engineer drops production code into Cursor. None of them are doing anything wrong, exactly. They just don't have any rules to point to.

A written usage policy fixes this. It puts everyone on the same page about what's OK, what isn't, and what to do when something goes sideways.

The policy doesn't have to be long. It does have to be specific. Eight rules, each one clearly stated, will do more for your team than a 30-page framework nobody reads.

The 8 things every AI usage policy needs (quick list)

Here's the structure. Each section is explained below.

  1. State what AI is FOR: the affirmative section that names acceptable use cases up front.
  2. List your approved tools: and define how a new tool gets onto the list.
  3. Define the data that can never go in: the categories that are off-limits no matter what.
  4. Require human review of outputs: before anything goes external, public, or into production.
  5. Set disclosure rules: the test for when AI assistance has to be acknowledged.
  6. Draw account boundaries: company accounts only for company work, no personal accounts.
  7. Define incident reporting: what counts as an incident, where to report, how fast.
  8. Name an owner and a review cadence: the human who keeps it current and the schedule for updates.

1. State what AI is FOR

Start by stating what AI is for at your company. This is the affirmative side of the policy: the green light. Most policies skip this and jump straight into restrictions, which is why they read like a list of "don'ts."

Lead with the "do."

People follow rules better when they understand the goal. If your team knows AI is welcome for drafting, summarizing, brainstorming, code suggestions, and research, they don't have to wonder if every use is risky.

Sample policy language

Employees may use approved AI tools to draft written content, summarize information, brainstorm ideas, generate code suggestions, translate text, and assist with research. AI use should make the work better, not replace your judgment about whether the work is right.

Keep this section short. A line or two about acceptable categories is enough. The point is permission, not instruction.

2. List your approved tools

Name the tools your team is allowed to use. Update the list when new tools come in.

Without an approved list, two things happen: people sign up for whatever they want with their personal accounts (shadow AI), or they don't use anything because they don't know what's allowed. Both create problems.

Sample policy language

Employees may use the AI tools listed in the Approved Tools Register (Appendix A). To request a new tool, submit a request to [contact email] with the tool name, the intended use case, and the data categories involved. Approval will be confirmed within ten business days.

Don't put the tool list inside the policy itself. Put it in a separate register that gets updated as tools change. Otherwise the policy is out of date the day a new model launches.

3. Define the data that can never go in

This is the most important section in your policy. If only one section gets read closely, this should be it.

The single most common AI incident is the wrong data going into the wrong tool. Customer PII, source code, financial records, anything regulated. Once it's been pasted into a third-party model, you can't pull it back. The OWASP Top 10 for LLM Applications puts sensitive information disclosure near the top of the list for a reason: it's the failure mode that shows up most often, and it's almost always caused by a person pasting data they shouldn't have.

Sample policy language

The following categories of data may not be entered into any AI tool unless that tool has been specifically approved for that category: customer personally identifiable information (PII), employee data, source code, financial records, legal correspondence, anything covered by an NDA, and anything subject to regulation (HIPAA, PCI, SOC 2 scope). When in doubt, do not enter the data. Ask first.

This list should be visible and short. If it runs to two pages, nobody will remember it. Keep it to the categories your team will actually encounter.

One more rule worth writing down: an AI output that contains restricted inputs is itself restricted. If you summarized a customer list and the summary still has names in it, that summary is now a restricted document. Treat it the same way.

4. Require human review of outputs

AI output goes to a human before it goes anywhere else. That's the rule.

AI tools confidently produce things that are wrong. Sometimes subtly wrong, sometimes embarrassingly wrong. The output looks polished even when the content has errors. A 30-second human review catches most of it.

Sample policy language

AI-generated content must be reviewed by an employee before it is sent externally, published, used to make a business decision, or executed as code. The reviewer is responsible for the accuracy and appropriateness of the final output, not the AI tool that produced it.

This is the rule that gets violated most often when teams are in a hurry. State it clearly. Repeat it in onboarding. Reinforce it the first time someone ships unreviewed AI output and gets corrected.

5. Set disclosure rules

Sometimes AI assistance has to be acknowledged. Other times it doesn't. The policy needs to say which is which.

Customers, regulators, and partners have started asking whether content was AI-generated. If your team has been disclosing inconsistently (or not disclosing at all), you're going to have an awkward conversation eventually. HBR's research on AI in business keeps coming back to the same finding: buyer trust hinges on clear, consistent disclosure. Hide the AI and you risk damaging the relationship more than the AI use itself ever would have.

Sample policy language

AI assistance must be disclosed when AI generated the structural draft, the substantive content, or the final form of work going to a customer, partner, regulator, or the public. Disclosure can be a footnote, a metadata tag, or a brief note in a methodology section. Routine productivity use (spell-check, summary suggestions, light rewriting) does not need to be disclosed.

The test is simple: did AI do the substantive work? If yes, disclose. If no, you're fine. Train your team on the test, not on memorizing a list of cases.

6. Draw account boundaries

Use company-issued accounts for company work. Don't paste company information into a personal ChatGPT account. That's the line.

Personal accounts route data to vendors under terms you didn't approve. They're often set to train on your inputs by default. They don't sit inside your security perimeter. Using a personal account for work data is a small action with a big footprint.

Sample policy language

Company information (including customer data, internal communications, financial information, and proprietary content) may only be entered into AI tools through company-managed accounts. Personal accounts (whether free or paid) may not be used for any work involving company data, even on personal devices.

This rule stops the majority of accidental data leaks. Make it loud. Repeat it in onboarding. Repeat it again whenever someone asks if "their personal Claude" counts.

7. Define incident reporting

Things will go wrong. The policy needs to say what to do when they do.

Most AI incidents stay private because nobody knows where to report them. By the time they surface, they've grown into something harder to fix. Make reporting fast and protected. MIT Sloan's research on AI deployment consistently finds that incident response is the function teams underinvest in until they have an actual incident, which is the wrong order to figure it out.

Sample policy language

Suspected AI incidents (including data exposure through an AI tool, harmful or incorrect output that has affected someone, the discovery of unauthorized tool use, or a vendor security disclosure affecting an approved tool) must be reported within 24 hours of discovery to [single reporting email]. Reporting in good faith is protected: an employee who reports promptly will not be disciplined for the underlying issue.

Pick a single reporting address. Don't make people figure out who to email in the moment. The 24-hour window from discovery is the standard most teams use, and it's short enough that incidents don't drift but long enough that people aren't punished for waiting until morning.

8. Name an owner and a review cadence

Name the person responsible for the policy. Set a review schedule. Do not skip this.

Policies without owners go stale fast. AI capabilities shift every few months. A policy written last year that lists specific tools by name is already out of date.

Sample policy language

This policy is owned by [name and title]. It will be reviewed every six months at minimum, plus any time a new category of AI capability becomes broadly available, a regulation changes, or an incident reveals a gap in the current rules. The Approved Tools Register may be updated more frequently as new tools are evaluated.

Six months is the floor. Three months is fine if your industry is moving fast or if you're early in your AI rollout. The owner doesn't have to be senior. They just have to be named, reachable, and accountable.

Common pitfalls

A few patterns that show up when companies try to write an AI usage policy from scratch:

  • Starting with 30 pages of definitions. Nobody finishes those. Keep the rules at the top of the document. Definitions go in an appendix, not in front of them.
  • Listing specific tools by name in the policy itself. Six months later, half are dead products. Use a separate register that updates without touching the policy.
  • Skipping the "what AI is FOR" section. Without it, the policy reads like a list of complaints. Lead with permission.
  • No incident reporting deadline. Without a number, incidents drift. 24 hours from discovery is the standard.
  • No named owner. A policy without an owner is a wishlist, not a policy.
  • Treating personal-account use as a gray area. It's not. Make it a clear, named line in the policy.
  • Skipping legal review. Even a strong template should go past your counsel before it gets rolled out. The structure can be standard. The wording often needs to fit your jurisdiction.

FAQ

How long should an AI usage policy be? +

Three to five pages of policy, plus appendices for the approved tools register and any defined terms. Anything longer doesn't get read by the people who need to follow it.

Do we need a separate AI policy or can it go inside our existing acceptable use policy? +

Either works. For most companies under 5,000 people, a standalone AI usage policy is easier to find and easier to keep current. Larger companies with mature policy frameworks can fold it into the existing acceptable use policy as a new section.

Should this be reviewed by a lawyer? +

Yes. The structure can be standard, but the wording often needs to fit your jurisdiction, industry, and any contracts you have with customers. A short legal review is usually 1 to 2 hours of attorney time if you start from a solid template.

How do we get employees to actually read it? +

Three things help. Keep it short (under 5 pages). Cover it in onboarding within the first 30 days. Send a one-line refresh whenever the policy changes so the team knows what's new.

What if our policy is already out of date? +

Update the parts that need updating. Don't wait for a full rewrite. Most updates are one or two changes (a new approved tool, an added restricted data category, a clarification on disclosure language). Date the update and send a one-line note to the team.

The bottom line

You can write this policy from scratch. It'll take 10 to 20 hours of work, plus a round of legal review. The result will probably look a lot like the eight sections above, because there isn't a secret eleventh thing nobody else has thought of.

Or you can start from a template that already has the structure and the language, and customize it to your company. That's literally what I built the AI Policy Template for. Word doc and Notion, lawyer-approved, $29, 7-day money-back guarantee.

Either way, the eight rules above need to be in there. Once they are, your team has something to point to. Which is the whole goal.

That's it. Now go write your policy.