An AI policy is only as good as what it can see

A policy that runs to fifteen pages is a policy nobody reads to the end. These six are the ones that change behaviour, and the rest is usually restatement.

Each one should be written so that a person can tell, without asking anybody, whether what they are about to do is allowed.

The instinct is to list the tools people may not use. That list is incomplete the week it is published: new products launch constantly, and an assistant added inside a tool you already approved is not a new domain at all.

An allow list has the opposite property. It is shorter, it is yours to control, and anything outside it is covered by one sentence rather than by a list somebody has to keep.

The second common failure is writing the policy before anybody knows what staff are actually using. A rule written against a guess is either too strict, in which case it is routed around, or too loose, in which case it changes nothing. Finding out first is a week of work that saves the policy.

Every clause in the six above can be enforced at the moment of the send, on the device, rather than audited afterwards. That is the difference between a policy and a statement of intent.

The ordering matters. Watch first, then warn, then block, and only where the data class justifies it. Most organisations spend the first two months on the first of those, which is also what makes the consultation conversation straightforward: you are describing what you observed rather than what you assumed.

This is the clause that decides whether the policy is usable, and the common failure is writing it from scratch in language that exists nowhere else in the organisation.

You almost certainly already have data classes defined, in a classification policy, a records schedule or the scoping document for whichever audit you last went through. Use those words. A person deciding whether they may paste something should be able to recognise the category from the label on the system they took it out of, and a reviewer should be able to map a detection back to the rule that makes it a problem.

Write the clause by class and then give one concrete example per class, because the class makes it complete and the example makes it understood. What to avoid is a list of examples with no class behind it, which is the shape most of these clauses take and which leaves everybody arguing about whether the thing in front of them is sufficiently like the example.

Policies in this area go stale faster than most, because the ground underneath them moves without telling anybody.

Three things change on their own: provider terms, which vary on notice and quietly invalidate an assessment; the tools in use, which grow every quarter and grow fastest inside software you already approved; and the regulatory picture, which is moving in several jurisdictions at once. A policy that does not name who re-reads these and when is describing a moment that has passed.

What a named owner and a review date are worth is mostly that somebody notices. The review itself is usually short: has the approved list changed, have any provider terms changed, has anything appeared in discovery that nobody has assessed. Two of those three questions can be answered from a report rather than from a meeting, which is the argument for measuring usage continuously rather than surveying it annually.