Case Study: Turning a 40-Page AI Policy Into an Operating Habit

The best-written AI policy we have ever reviewed belonged to an organisation with one of the worst Judgment & risk scores we have ever measured¹. That is not a paradox. It is the pattern.1A composite case, anonymised from several Fellow engagements. Numbers are representative of the pattern, not one client's audited results.

The situation

A manufacturing group of about 1,200 people had commissioned a thorough AI usage policy: forty pages, legally reviewed, covering data classes, approved tools, escalation paths. It had been distributed by email, twice, with a mandatory acknowledgement click.

The readiness assessment then asked their people a simpler question: does a data policy exist, and could you describe it? The gap was stark — the overwhelming majority had acknowledged a policy they could not state a single rule from^◦.By the numbers92% vs 9%had formally acknowledged the policy, versus could describe any rule in it when asked

Meanwhile, output verification — the behaviour the policy mandated most carefully — depended entirely on which individual happened to be doing the work.

Why paper does not change behaviour

A policy is a description of intended behaviour, not a mechanism for producing it^◦. Reading is not rehearsal: people do not consult documents mid-task, they follow habits and copy colleagues. A rule that is not present at the moment of work does not exist at the moment of work.DefinitionPolicy theatre Controls that exist to be shown — to auditors, boards, clients — rather than to be used, creating the impression of safety without the behaviour

The forty pages also carried a quieter cost: because the official rules were unusable, teams had each improvised their own informal ones — twelve different local versions of "be careful", none of them the written one.

What we did

1. Cut the policy to one page. Three categories — never leaves approved tools; allowed with care; freely allowed — with the five most common data types of each named explicitly. The legal team kept the forty pages as an annex; the page became the interface.
2. Taught it in ninety-minute working sessions, using each team's real deliverables. Every session ended with the team classifying ten of their own recent AI uses against the page — disagreement was the point, and settling it was the training^◦.FigureThe moment that changes behaviour is applying the rule to your own work, not reading it
3. Moved verification into the workflow. For the three deliverable types where an error would reach a customer, a named checker and a five-line checklist — in the template itself, not in a separate document.
4. Made the rule the reflex. Team leads opened week meetings for a month with one classification question. Sixty seconds each time; that repetition, not the email, is what installed the rule.

What changed

At re-assessment one quarter later, the described-the-policy number moved from single digits to a strong majority, and verification on customer-facing deliverables was structural rather than personal^◦. The incident that eventually tested it — a supplier document pasted toward an unapproved tool — was caught by a colleague quoting the rule from memory, which is the only place a rule ever works.By the numbers9% → 78%respondents able to state the core data rule unprompted, one quarter after the rewrite

What to steal

1. This week: ask ten people to state your AI data policy from memory. Their answers are your real policy.
2. This month: compress the written policy to one page someone could apply mid-task; keep the long version as an annex.
3. This month: teach the page against your teams' own recent work — classification arguments included.
4. This quarter: move verification into templates and workflows for the deliverables where errors travel furthest.

A policy that lives only on paper scores as risk, not protection, in a readiness assessment — and in reality^◦. If this is your flagged pattern, the one-page rewrite is the highest-leverage week you can spend.RelatedThe wider pattern: when usage outruns control