A Checklist for the Whole Thing

Before anything else

Name an owner with allocated time, or do the cheap discovery and use it to argue for one.

The recommendations in “A Checklist for the Whole Thing” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating this practical resource 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 ICO guidance on AI and data protection; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Check your classification scheme exists and that people can apply it. If not, that is the first piece of work.

Read what your largest client contracts say about subprocessors.

Identify the hard constraints: regulated categories and where they cannot go.

Discovery

Announce it, with an explicit amnesty, and honour it.

Ask first: four questions, anonymous — what tools, for what tasks, what would make you switch, where was there nothing.

Then the technical sources: destination logs, endpoint inventory including browser extensions, finance data for subscriptions.

Check AI features in approved tools separately — they are invisible to everything else.

Output: tools and tasks, no names.

Assessment

For each tool: the seven clauses — training use, retention, human review, subprocessors, location, output indemnity, change of terms.

Ask which model providers sit behind it.

Classify what it is being used with, which is the column that holds the risk.

Provide before you restrict

Buy an enterprise tier of the most-used service.

Provision by default, not on request.

Approve the configuration people need, not the most restricted one.

Check it against the task list discovery produced, and name any gap.

Policy

One page. Three classification rules and an output rule.

Five examples per level, from your own work.

Say what is allowed, not only what is forbidden.

Five hard prohibitions, no more.

An approved list of three or four rows, including embedded features.

An exception route answered in two days and granted for six months.

Monitoring

Destination and inventory as standard.

Client-side warning for defined patterns rather than boundary inspection.

No content retained on non-matches.

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

Announced before it starts, including what the tooling could collect.

Afterwards

Measure whether consumer-tier traffic fell. Four weeks for a first look, three months for an answer.

Check licence activation rate.

Record incidents and what caused them; thank whoever reported.

Publish back: what was found, what was provided, what is accepted.

Twice yearly

Re-run the technical discovery.

Check approved tools for new AI features.

Check approved providers for terms changes and acquisitions.

Review the exception log for patterns that should change the approved list.

Update the register, the inventory and the policy date.

The whole thing in one line

Find out what people are doing and why, provide something good enough that they switch, write rules about information rather than tools, and monitor the destination rather than the content.

The point

Find out what people are doing and why, provide something good enough that they switch, write rules about information, and monitor the destination..

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.