The Approved List, and Keeping It Short

The approved list is the practical half of the policy. Its usefulness is inversely related to its length.

The controls in “The Approved List, and Keeping It Short” only remain useful when someone owns the reviews, exceptions and follow-up work. An organisation evaluating Monitask 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 Resource Center; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

What belongs on it

One general-purpose assistant with an enterprise agreement.

One coding assistant, if you write software.

Whatever AI features are enabled in tools you already use, listed explicitly so people know.

That is enough for most organisations and it is three rows.

Why short

People remember three and consult a document for thirty, and they will not consult the document.

A long list implies that anything absent is prohibited, which creates a steady stream of requests.

And every row carries an assessment and a review obligation, which is work that accumulates.

The embedded features row

The most-forgotten and the most important.

People do not think of a summarise button in their email client as an AI tool, and it is one.

Listing them explicitly — enabled, assessed, fine to use for internal material — removes a whole category of unintentional non-compliance.

The criteria for adding something

Does it do a task the existing approved tools cannot?

Are the terms acceptable for the classification it will handle?

Is there somebody who will own it?

Three questions. Most requests fail the first, which is a conversation about the existing tool rather than a refusal.

Removing things

Harder than adding and necessary.

A tool whose terms changed materially, whose supplier was acquired, or which nobody uses.

Removal needs notice and a migration path, because people have built habits around it.

The "tolerated" category

Tools in use, not formally approved, not worth prohibiting.

Most organisations have these and pretend otherwise.

Naming the category honestly — in use, assessed as low risk, not supported — is better than a list that claims a completeness it does not have.

Where to publish it

Somewhere people already look, not in a policy repository.

With the date and the owner.

And with the declaration route next to it, so that the natural response to "my tool is not here" is to ask rather than to proceed quietly.

What to check

How many tools are on your approved list?

Does it include AI features in tools you already use?

Has anything ever been removed from it?

And where is it published?

The point

A short approved list people remember beats a comprehensive one they consult, because they will not consult it..

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.