Policy, the Register, and Incidents

Policy comes last in this guide deliberately. Written first, it is a document produced by people imagining risks, and it gets routed around within a quarter. Written after you have run a few things, it describes decisions you already made and can defend.

You should be able to hand someone three artifacts. A policy that says what is allowed, a register that says what is running, and a procedure for what happens when something goes wrong. Most companies have none of these and a slide deck instead.

Write it to permit

The first sentence sets the tone for how the whole thing gets treated. A policy that opens with prohibitions gets read as an obstacle and routed around by people who are trying to do their jobs. One that opens with what is encouraged, and reserves its restrictions for the genuinely risky, gets followed.

The practical form: name the approved tools for everyday work and say plainly that people should use them. Then say what must not go into them, using the tiers from chapter six. Then say which situations need a conversation first. Three sections, two pages, written in the language people actually use.

If your policy is longer than two pages, it is a document for auditors rather than for employees, and you will need the employee version anyway.

Classify the data, not the tools

The rule that keeps a policy from expiring. Tool lists go stale in weeks. The three tiers from chapter six stay true, and a person can apply them from memory: public, internal, restricted. Give two or three real examples of each from your own company. Real examples are what makes it usable, and they are the part most policies skip.

Keep the approval path short

Two questions, not one, and they deserve different paths:

• Can I use this tool for my own work? Should be answered by the policy itself, with no approval needed for internal-tier material in an approved tool. Requiring a ticket for this is how you create shadow usage.
• Can I put this system in front of others, or let it act on its own? This one needs a person, and it should be one named person with a short list of what they are checking. Blast radius, data tier, who owns it, and how you would know it went wrong.

A review that takes three weeks does not produce safety. It produces a workaround.

The pilot lane

Add an explicit path for trying something new without the full conversation. Internal-tier data only, no writes to shared systems, one team, thirty days. It goes in the register on day one. Then it either graduates through the real review or it stops.

The pilot lane is the highest-return paragraph in an AI policy. Without it, every experiment is either forbidden or hidden, and hidden is what you get.

Keep a register

One table. Every automation that touches company data, whether it was approved, built by IT, or made by someone in sales on a Tuesday. Columns:

• What it does, in one sentence a non-technical person understands
• Who owns it
• What it can read, and what it can change
• Data tier
• What happens if it is wrong, and who would notice
• Date of last review

Getting the first version populated is the hard part, and the way to do it is amnesty. Say clearly that anything declared in the next month is fine and nobody is in trouble. You will find more than you expect, and most of it will be useful.

Put the rules in the machinery

The rules that survive are the ones that are not rules. A tier that cannot be reached by a system has better properties than a tier a system is told to avoid. An approval gate in the flow is worth more than an approval step in a document. A spending cap set at the vendor is worth more than a paragraph about responsible use.

Every time you write a rule, ask whether it could be a configuration instead. Most can, and each one that moves is a rule that cannot be forgotten under deadline pressure.

Incidents, and saying so

Decide now, in the quiet, what counts as an incident and who gets told. A useful threshold. Restricted data reached a system it should not have. Output went outside the company and was wrong in a way that matters. A system acted without its required approval. Spend exceeded its cap by a defined multiple.

For each: one named person, informed within the hour, and a written note within the week covering what happened, what it touched, and what changed as a result. Practice it once on something trivial, because the first time should not be the real time.

Then review the register quarterly and retire what is not being used. Governance that only ever adds becomes an archive. The most useful thing a review meeting can produce is turning something off.