Why Blanket Bans Do Not Work

The instinctive response to shadow AI is to block it. The effect is well documented in adjacent areas and is consistent: use continues and the organisation stops being able to see it.

The recommendations in “Why Blanket Bans Do Not Work” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the official explanation 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 OECD AI Principles; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

What a ban actually changes

Corporate network and device access, which is what the controls cover.

It does not change: personal phones, home machines, personal accounts accessed from anywhere, or tethering.

Which means the ban moves the activity to channels with no logging, no data loss controls and no enterprise terms.

The risk increases and the visibility goes to zero.

The predictable sequence

Block announced.

Use drops on managed devices.

Within weeks it resumes on personal ones.

Nobody reports it, because reporting means admitting a breach.

And the organisation now believes it has solved the problem, which is the most dangerous state of the three.

Why people comply with some rules and not this one

Rules get followed when the cost of compliance is low or the reason is evident.

Here the cost is doing the job slower, and the stated reason — data risk — does not obviously apply to drafting an internal email.

A rule that is clearly overbroad for the common case gets ignored for all cases, including the ones where it was right.

Where a ban is correct

Specific tools with genuinely unacceptable terms.

Specific data categories: regulated, client-confidential, personal data of others.

Specific contexts: an agent with access to production systems.

Narrow, explicable, enforceable. Its own note covers what to prohibit outright, and the list is short.

What works instead

Provide something good enough that the approved route is the easy one.

Classify data so the rule can be "not this kind of information" rather than "not this tool".

Make declaring a tool safe and quick.

And accept that some use will happen outside your view, which is true of every control and is better managed than denied.

The honest trade

Enabling means accepting more use overall, with better terms and visibility.

Banning means less recorded use, unknown actual use, and worse terms on whatever is happening.

Stated that way, most organisations choose enabling, and the ones that do not usually have a specific regulatory reason.

What to check

If you have a ban, do you know whether use actually stopped?

Could somebody comply with your policy and still do their job at normal speed?

Is there an approved option, and do people know about it?

And would somebody report shadow use here without fearing consequences?

The point

A ban moves the activity to personal devices and personal accounts, where there are no logs, no controls and no enterprise terms.

The risk rises and the visibility goes to zero.

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.