Most AI usage policies fail the same way. Someone writes three pages of prohibitions, posts it in the company wiki, announces it once in Slack, and six weeks later half the team is pasting customer support tickets into a chat window anyway.
The document usually isn't wrong. It's unusable at the moment the decision gets made — the two seconds where an engineer stares at a stack trace containing a production connection string and decides whether pasting it is fine. Nobody opens a wiki page to answer that. They guess.
A policy people follow has a different shape. It's short enough to hold in your head, written about data rather than product names, backed by a compliant path that's faster than the workaround, and stored somewhere the team already has open. Four sections below, in the order you should write them.
Classify data, not tools
The most common structural mistake is writing the policy against a list of approved products. That list is stale the week you publish it. A new model ships, your IDE turns on an agent mode by default, a designer's plugin starts calling a hosted API, someone's terminal gets an assistant. The policy is now either being violated constantly or quietly ignored — and those look identical from the outside.
Write the rules against data classes instead. Three tiers cover most teams:
- Public — anything already on your marketing site, public docs, open-source repos, published API references. No restrictions. Say this explicitly, because people over-restrict here out of caution.
- Internal — private repo source, architecture notes, roadmaps, aggregate metrics, internal runbooks. Allowed in tools your company holds a contract with (zero-retention or no-training terms in writing). Not allowed in personal accounts, ever.
- Restricted — customer PII, credentials and secrets, anything covered by a customer confidentiality clause, health and payment data. Not pasted anywhere, including approved tools, unless there's a written exception with a named owner.
The payoff: when a new tool appears, you don't rewrite the policy. You answer one question — which tier does this clear? — and add a row to the tool table. The rules themselves stay stable across model generations.
Check the plan, not the brand. The consumer and business tiers of the same product frequently have different retention and training defaults, and the consumer default is usually the permissive one. "We use [Vendor], they don't train on our data" is a claim about a contract, not about a company. Get the tier and the terms in writing before you list a tool as approved for Internal data.
Make the compliant path the shortest one
Policy compliance is mostly a convenience problem. If the approved assistant requires a VPN, a ticket, and a two-day wait, people will use their phone — and now the data is somewhere you can't audit at all. Every friction step you add to the approved path is a push toward the shadow one.
Three things to fund before you publish:
- Seats that already exist. If your policy says "use the approved coding assistant," the seat should be provisioned on day one for everyone in scope, not requested. A pending license request is an invitation to open a personal account.
- SSO on the chat interface. Single sign-on is what makes "use the work account" a default rather than a chore, and it's what gives you an offboarding story.
- A tool request path with a stated turnaround. Name the owner, name the target — a week is a reasonable commitment for most teams — and publish the queue. An approval process with no SLA is a denial process with extra steps.
Then give explicit permission for the boring majority of use. List the things that are unambiguously fine: drafting and rewriting your own text, naming things, regex, test scaffolding, explaining unfamiliar code from a public repo, summarizing a public RFC. Teams that only publish prohibitions get a predictable failure pattern — people over-comply where it's visible and under-comply where it isn't. The visible caution costs you productivity; the invisible non-compliance is the one that ends up in an incident review.
Replace disclosure theater with one accountability rule
Disclosure is where policies turn vague, usually because the drafters are trying to cover code review, published writing, and hiring in one sentence. Split it.
For code, skip per-line attribution. It's unenforceable, it decays within a sprint, and once a checkbox exists reviewers start trusting the checkbox instead of the diff. Write one rule instead:
You are accountable for every line you merge, regardless of what wrote it. "The agent generated it" is not a defense in a post-incident review.
That sentence does more work than any disclosure field. It tells reviewers nothing changed about their job, and it tells authors that generated code carries the same burden of understanding as typed code.
For published and customer-facing work, disclosure is warranted, because a reader's trust genuinely depends on provenance. One honest line at the top of the artifact is enough — this site marks AI-assisted articles for exactly that reason. For hiring and evaluation, state the rule per-stage rather than globally; a take-home and a live pairing session have different answers, and pretending otherwise means candidates guess.
A useful test before publishing: hand the draft to someone who wasn't in the room and ask them to answer three questions from it — "Can I paste this stack trace?", "Can I use my personal account on the train?", "Do I have to tell my reviewer?" If they can't answer all three in under a minute, the policy is a reference document, not a policy.
Version it like code, and log the exceptions
Treat the document as a living artifact with the same hygiene as a config file: a version and date at the top, a named human owner (a person, not "Legal" or "Security"), a review cadence, and a visible change history so people can see what moved and when.
The part teams skip is the exceptions log — a running list of the cases you approved, who asked, what data was involved, and why you said yes. That log is where the next version comes from. After a quarter, the patterns in it tell you which restriction was too tight and which approval you'd like back. Without it you're rewriting the policy from memory and vibes.
A one-page structure that covers the ground:
| Section | Contents |
|---|---|
| Scope | Who this applies to, and what counts as an AI tool here |
| Data tiers | Public / Internal / Restricted, with concrete examples from your product |
| Approved tools | Table of tool, tier cleared, account type required |
| Accountability | The one-sentence merge rule |
| Disclosure | Per-context: code, published work, hiring |
| Exceptions | How to request, who decides, target turnaround |
| Metadata | Version, date, owner, next review |
Wherever it lives, it needs page history and search — the two features that decide whether anyone can tell what the rule was in March. A wiki page with no history is how you end up arguing about what the policy said during an incident.
If your team already lives in a repo, a markdown file with PR-based review works just as well and gives you review-by-default. The failure mode isn't the tool — it's a policy with no owner and no history, which nobody can update and everyone can reinterpret.
The measure of a policy isn't whether it's comprehensive — it's whether someone under deadline pressure, at 6pm, with a stack trace on their screen, can recall what it says. Optimize for that and most of the length falls away on its own.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)