Ask most security teams if they have an AI usage policy and the answer is yes. Ask if anyone follows it and the honest answer, most of the time, is that nobody knows — the policy exists as a document, not as anything that actually happens when someone opens ChatGPT.
That's not a criticism of the teams that wrote them. A policy document was the only tool available before there was a way to enforce anything at the point AI usage actually happens. That's changed, and it changes what a policy should look like.
The failure mode of a document-only policy
A written policy that says "do not paste confidential information into AI tools" asks employees to make a judgment call, in the moment, with no feedback loop. Most of the time nothing goes wrong, because most prompts don't contain anything sensitive — which means the policy is silently, invisibly not doing anything, and nobody finds out it failed until an incident does the finding for them.
It also asks employees to define "confidential" themselves, prompt by prompt, which is a harder problem than it sounds. Is a customer's first name confidential? A stack trace with an internal hostname in it? A snippet of code under an NDA the employee may not have fully internalised the terms of? A document written once, read maybe once, can't answer these in the moment they come up.
What a policy looks like when it's enforced, not just written
The alternative isn't a longer document — it's a smaller number of rules that a system actually checks against every prompt, before it's sent. That reframes the policy from "a set of instructions for humans to remember" to "a set of conditions a machine evaluates," which changes what it's realistic to ask for.
A workable structure, in our experience, looks like four tiers:
- Hard-block the unambiguous. Private keys, government identifiers, database credentials. Nobody argues these belong in a prompt, so blocking them outright generates no resentment and needs no judgment call from the employee.
- Redact the middle ground. Emails, phone numbers, card numbers. The employee still gets their answer; the identifier just never leaves. This is the highest-value tier and the most underused one — most policies jump straight to block or allow and skip the option that actually preserves productivity.
- Warn on genuine judgment calls. Source code is the clearest example: internal utility code is usually fine to paste, client code under an NDA usually isn't, and no detector can reliably tell the two apart from content alone. A warning puts the decision back with the person who actually has the context, instead of pretending a machine can make it for them.
- Log everything, regardless of the action taken. Even an allowed prompt should leave a record — category detected (if any), tool, timestamp, policy version in force. This is the evidence trail that makes every other tier defensible after the fact.
Start in warn mode, on purpose
The instinct when rolling this out is to go straight to blocking. Resist it for the first couple of weeks. Warn-mode-only tells you what your traffic actually contains and where your false positives are, on real data, before you make anything harder for anyone. Every organisation we've worked with has been surprised by at least one category in that first week — usually not the one they expected.
The policy is code, so treat it like code
A policy that lives as a YAML file rather than a settings-panel toggle can be versioned, diffed, and reviewed in a pull request — which matters more than it sounds like it should, because "what changed in our AI policy, and who approved it" is exactly the kind of question an auditor, or a regulator, eventually asks. A policy nobody can point to a version history for is a policy nobody can prove was actually followed.
See how PromptSec's policy engine implements this, and why blocking outright usually backfires if that's the instinct you're starting from.