Writing a Policy People Will Follow

A policy that nobody can state from memory is not operating. The test is whether a colleague asked at their desk could tell you the rule.

The controls in “Writing a Policy People Will Follow” only remain useful when someone owns the reviews, exceptions and follow-up work. An organisation evaluating this project guide can attach time and responsibility to those recurring governance tasks, but the platform should support the policy rather than decide whether an AI use case is acceptable.

For an independent benchmark, compare the local approach with NIST AI RMF Playbook; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

The shape that works

One page.

Three or four rules, tied to data classification rather than to tool names.

Examples from your own work.

A named route for questions and for declaring a new tool.

That is the whole document. Longer versions exist to protect their authors rather than to guide anybody.

The core rules

Public information: any tool.

Internal information: approved tools only.

Confidential or regulated: approved tools with an agreement, or not at all.

Output used externally or in a decision is checked by a person accountable for it.

Four lines, and they cover most of the real cases.

What to leave out

Definitions of artificial intelligence, which date immediately and help nobody.

Lists of specific tools in the body, which go stale — put the approved list somewhere it can be updated without reissuing the policy.

General exhortations to be careful.

And anything that cannot be followed while doing the job at normal speed, which the bans note covers.

Examples beat definitions

"A client contract is confidential. A draft internal email is internal. Our published prices are public."

Five examples per level, from your own work.

People apply examples and argue with definitions.

Say what is allowed

Most policies are a list of prohibitions, which leaves people guessing about the common case.

State positively that drafting, summarising public material, explaining errors and rewriting internal text are fine with approved tools.

This removes the fear that drives ordinary use into hiding, and it is the single change that most improves compliance.

The declaration route

One line: if you find something useful, tell us here, and we will usually say yes.

Then honour it — quickly.

A route that takes six weeks and usually refuses teaches people not to use it.

Reviewing it

Twice yearly at minimum, and whenever a major tool changes materially.

With a visible date on the document.

A policy dated two years ago in this field is read as not applying.

What to check

Could a colleague state your rules from memory?

Is the policy one page?

Does it say what is allowed, or only what is forbidden?

And when was it last dated?

The point

The test of a policy is whether a colleague asked at their desk could state the rule.

One page, four rules, five examples.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.