What a Working Programme Looks Like

Not a maturity model. A description of a programme in an organisation of a few thousand people, a year in, that people cooperate with.

The recommendations in “What a Working Programme Looks Like” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating time tracker for projects can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.

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.

How it started

An announced discovery exercise with an explicit amnesty, which was honoured.

Asking first, technical sources second.

Four sources: destination logs, endpoint inventory, finance data, and a four-question survey.

Output: a list of tools and tasks, with no names in it.

What it found

More tools than expected, concentrated in three departments.

Browser extensions with page-reading permissions on machines used for client systems, which nobody had looked for.

AI features switched on inside two approved tools that nobody had assessed.

And a dozen people paying personally, which indicated dependence rather than casual use.

What it did first

Bought an enterprise tier of the most-used service and provisioned everybody with a plausible need, by default rather than on request.

Removed the extensions with page-reading permissions.

Published a one-page policy with three classification rules and five examples.

Published an approved list with three rows, including the embedded features.

The rules it operates

Public information: any tool. Internal: approved tools. Confidential or regulated: approved tools with an agreement, or nowhere.

Output used externally is verified by somebody accountable for it.

Five hard prohibitions, which everybody can name.

Exceptions answered in two days, granted for six months, recorded in the inventory.

What it monitors

Destination and inventory. No content inspection.

Client-side warning for defined patterns — card numbers, client identifiers — with nothing transmitted for review.

Aggregate reporting with a floor of ten; individual detail only through a named approver with a logged reason.

All of it announced before it started, with what the tooling could collect and who may change that.

What it measured

Consumer-tier traffic fell by roughly two thirds in eight weeks.

The remainder sits in two teams doing a task the approved tool cannot, which is now a procurement item rather than a compliance one.

Licence activation rate, which was low at first and prompted a second announcement.

What it accepts

Personal devices, which it cannot see.

Embedded features arriving in updates, checked twice yearly rather than continuously.

Written down, with reasons, and in the board paper.

The test

Can a colleague state the rules from memory?

Did anybody face consequences for a discovery finding?

Did consumer-tier use actually fall?

A programme that answers those three has done the work.

The point

Three tests: can a colleague state the rules, did anybody face consequences for a discovery finding, and did consumer-tier use actually fall?.

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.