What to Prohibit Outright

A policy of mostly guidance needs a small number of hard prohibitions. Their power comes from being few, specific and obviously justified.

The controls in “What to Prohibit Outright” only remain useful when someone owns the reviews, exceptions and follow-up work. An organisation evaluating daily work tracking 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 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.

The list

Regulated and client-confidential data in any tool without an agreement covering it.

Credentials, keys and tokens in any prompt, ever.

Personal data of others — customers, patients, colleagues — in unapproved tools.

Unattended automations against unassessed services.

Output filed externally or used in a regulated decision without human verification.

Five items. Most organisations can stop there.

Why each is on it

The first two have caused real, documented damage and have no legitimate counter-case.

The third is a legal exposure in most jurisdictions.

The fourth turns a judgement call into a continuous unsupervised flow.

The fifth is where the organisation's own accountability is unavoidable.

Why the list must stay short

Every addition dilutes the others.

A prohibition list of twenty items is read as a wish list and applied selectively.

Five items that everybody can name are enforceable; twenty that nobody can are not.

The credentials item specifically

Worth singling out because it happens more than people expect.

Debugging a connection string, asking about an error containing a token, pasting a configuration file.

It is rarely malicious and it is always serious, because the credential is now in somebody else's logs.

Train it explicitly and pair it with a rotation process that is easy to invoke.

What should not be on the list

Specific named tools, which change.

General categories like "do not use AI for important work", which nobody can apply.

Anything whose violation you cannot detect or would not act on, because an unenforced prohibition weakens the enforced ones.

Consequences

State what happens: for most of these, a conversation and a correction.

Reserve formal process for deliberate repeated breach, which is rare.

And say that reporting your own mistake leads to help rather than punishment, which is the only thing that produces early reporting of an incident.

Reviewing it

The list should shrink as tooling improves — client-side blocking can make the credentials item largely automatic.

Review annually and remove anything a control now handles.

What to check

How many hard prohibitions does your policy have?

Could a colleague name them?

Is there a quick credential rotation route when somebody pastes one?

And what happens to somebody who reports their own mistake?

The point

Five hard prohibitions, no more.

Every addition dilutes the others, and twenty that nobody can name are not enforceable.

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.