GUIDE
Building an enforceable AI usage policy
A clause that doesn't know where it gets checked isn't a rule. This guide re-engineers policy from the enforcement point back to the text: clause triage, an exception path, a candor page, a review cadence.
An enforceable policy is built backwards, from the checkpoint to the text: gather existing rules, triage every clause (machine-enforceable / needs approval / guidance), turn the enforceable into request-time settings, build a fast named exception path, show the rules to those they govern, and review quarterly on register numbers.
THE PROBLEM
The problem: a policy written to be read
Most AI policies die the day they are signed. Written in general language ("sharing sensitive data with AI tools is prohibited"), emailed, acknowledged by all, and then the text never meets a single actual request again.
The problem is engineering, not intent: nobody specified where each clause gets checked, who owns the exception and within what window, or how compliance is even measured. So the organization lives with two policies: one on paper, one in reality.
An enforceable policy is written in the opposite direction, from the checkpoint to the text: every clause knows its gate before it knows its final wording.
A clause that doesn't know where it is checked is not a rule; it is a wish in official wording.
THE PRINCIPLES
The principles
- Every clause is a switch, an approval, or guidance. Triage every line into one of three, and whatever resists classification, rewrite until it complies.
- Name the approver, fix the window. An exception without a name and a window is the gap discovered at the worst time.
- Show the policy to those it governs. Employees see the same rules applied to them: a declared rule earns respect; a hidden one invites testing.
- Updating is part of the text. Put the review date inside the policy itself; a document that doesn't move with reality gets bypassed by it.
THE STEPS
The six steps
The steps start from your existing documents, not a blank page.
- Gather what you have. The infosec policy, data classification, earlier circulars: the new policy builds on this inheritance and references it; it does not repeat it.
- Triage every clause. Three separate lists: machine-enforceable (sources, roles, balance limits) (needs human approval) awareness guidance. These lists are the real policy.
- Turn the first list into settings. Every machine clause becomes an enablement or a limit checked at request time, the real enforceability test: a clause that finds no switch goes back for rewriting.
- Build the exception path. A short request form, a named approver, a maximum response window, an automatic register entry: a good exception is faster than the workaround, or the workaround wins.
- Publish the candor page. What gets recorded, what is never collected, who sees what, in employee language, not contract language. Candor here is a real compliance control, not a PR touch.
- Set the review cadence. Quarterly: what did the gate stop? Which clauses attract constant exceptions? A clause that is always excepted was written wrong, and the register exposes it numerically.
ILLUSTRATIVE
WHERE A TYPICAL POLICY'S CLAUSES LAND: ILLUSTRATIVE
An illustrative split: the guidance third isn't a flaw, the flaw is treating it as if it were enforceable.
EVALUATION
Evaluation questions
- Take three random clauses: where is each checked? If the answer needs a meeting, the policy is a document, not a system.
- How many exceptions were granted last month, and to whom? If the answer isn't an entry readable in a minute, the exception path isn't working.
- Can a new employee learn their boundaries in five minutes? The candor page is tested on a real employee, not only in legal review.
Bring your current policy.
One working session: we triage twenty clauses of your actual text into switches, approvals, and guidance, and you see for yourselves how many find their gate.
EVALUATION QUESTIONS
Questions raised in every evaluation.
Do we write a new policy or repair the existing one?
Repair the existing one: the three-way triage runs on your current text, and two-thirds usually survives rewording, what's genuinely new is the exception path and the candor page.
Who writes the candor page?
Drafted with internal comms and reviewed by legal, but its acceptance test is an employee reading it and answering: what is recorded about me? If they hesitate, redraft.
What do we do with the guidance clauses?
They stay, under their true name: awareness to be trained, not rules to be enforced. Confusing the two is what costs the policy all its authority.
CLOSE
Closing: the text needs an arm
Nobody proposes abolishing the document: it is the formal basis and the reference. The proposal is simpler and harder: stop leaving it alone. Every clause deserves a gate that enforces it, every exception a name, every quarter an honest read of the compliance numbers.
How text becomes switches, on the product page:
Clause to switch. Text to system.
Print the guide and run the three-way triage on one page of your policy, then bring the result, and together we turn it into working settings.
This page prints cleanly: its chart split is illustrative.