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.

Short Answer

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

Machine-enforced
~45%
Needs a named approval
~25%
Unmeasurable guidance
~30%

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.

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.

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.