An AI usage policy your team will actually follow

Most teams using AI in 2026 fall into one of two camps. Either they have no policy at all, meaning everyone is improvising and hoping nothing goes wrong, or they have a policy that nobody reads, filed somewhere in a shared drive between the 2023 expense guidelines and an outdated org chart. Neither position is acceptable when the stakes include data leaks, hallucinated analysis landing in board decks, and regulatory exposure under frameworks like the EU AI Act.

The reason policies fail is almost never the content. It is the process that created them. A document written by Legal in isolation, reviewed by IT, and emailed to staff as a PDF is not a policy. It is an artifact. What you need is a short, usable document that people helped shape, that answers the questions they actually have, and that gets updated when reality changes.

Building a policy that works: the sequence

Start with a usage audit, not a blank template

Before writing a single rule, spend two weeks mapping what your team is already doing with AI. Run a short anonymous survey. Ask which tools people use, for which tasks, and what they are pasting into prompts. You will almost certainly find that some employees are running client data through consumer-grade ChatGPT accounts, that others have built quiet workarounds with tools like Notion AI or Copilot, and that your official stance has no relationship to actual behavior.

This audit is not a gotcha exercise. It is the foundation of a policy grounded in reality. At Klarna, internal data from 2024 showed AI assistants handling tasks across customer service, legal drafting, and financial reporting simultaneously, long before a formal policy caught up. Getting the honest picture early prevents you from writing a policy that bans what half the company already depends on.

Write for use cases, not abstract principles

Generic rules like "use AI responsibly" produce nothing. Organize your policy around the actual jobs your team does. For each major use case (drafting client communications, summarizing research, writing code, analyzing data), answer four questions: which tools are approved, what data can go in, who reviews the output before it is used, and what gets logged.

Keep the full document under three pages. If it is longer, you are writing policy for lawyers, not practitioners. Anthropic's internal responsible scaling policy is a useful structural reference, though it is designed for an AI lab, not a typical business function. Strip it down to fit your context.

Define data categories explicitly

The most common and most costly failure in AI governance is unclear data handling. You need at minimum three tiers: information that is public or internal-only and can go into any approved tool; data that is confidential (employee records, unreleased financials, client PII) that requires enterprise-grade tools with data processing agreements; and information that cannot go into any AI system at all (trade secrets under NDA, regulated health data, anything subject to litigation hold).

MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → your tools to these tiers. Microsoft 365 Copilot with a signed enterprise agreement sits in a different category than a personal Claude.ai account. Make this explicit. People will not figure it out on their own, and they should not have to guess.

Run a 30-minute onboarding, not a training module

Mandatory e-learning courses get clicked through at 2x speed on a Friday afternoon. Instead, schedule a single 30-minute team session where you walk through three real examples from the audit: one that was fine, one that was borderline, one that was clearly wrong. Let people ask questions. The conversation that happens in those 30 minutes does more to set norms than any written document.

Designate one person per team as the first point of contact for AI questions. Not a gatekeeper, just someone who knows the policy well and can give a fast answer. This removes the activation energy barrier that causes people to skip the policy entirely and just do whatever feels reasonable.

Build in a revision cycle

Set a calendar reminder for 90 days out. At that point, collect questions people have asked, incidents that occurred, and tools that have been adopted since launch. Update the policy accordingly. A policy that was accurate in January 2026 may be meaningfully wrong by October given the pace of model and tool releases.

Where this goes wrong

The most common failure mode is writing a policy that reflects what leadership wants to be true rather than what the team actually does. If you ban tools that are already embedded in workflows without offering a sanctioned alternative, you will simply drive behavior underground.

A second failure: making approval processes so slow that they become a tax on productivity. If every new AI use case requires a committee review and a two-week wait, people will stop asking. Build a lightweight fast-track for low-risk use cases, something a team lead can approve in 24 hours.

Watch out for the policy that is only enforced after an incident. Waiting for a data breach or a hallucinated legal citation to appear in a client deliverable before enforcing your rules signals that the policy was never real. Light, consistent reinforcement during normal operations is what makes a policy credible.

Finally, do not outsource this entirely to IT or Legal. Those functions need to be involved, but the policy should be owned by the people doing the work, with functional managers accountable for adoption.

Quick wins to start this week

• Run a five-question anonymous survey asking which AI tools your team uses and for what tasks. Block two hours to read the results before writing anything.
• List every AI tool currently in use and flag which ones have a signed data processing agreement with your organization. The gaps will surprise you.
• Identify one concrete incident (a near-miss, an awkward output, a question that had no clear answer) and use it as the anchor example for your onboarding session.
• Pick a policy owner. Not a committee. One person who will answer questions and manage the revision cycle.

A policy succeeds when people reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for it the moment they are unsure, rather than when they are caught doing something wrong. That only happens if the policy was built with their actual questions in mind. Start there.