Why People Use Tools You Did Not Give Them
The reasons are consistent across organisations and none of them is defiance. Understanding them changes what the response should be.
Foundations · Analysis
Nobody sets out to create a compliance problem. The reasons people reach for unapproved tools are ordinary and they point directly at what to fix.
The recommendations in “Why People Use Tools You Did Not Give Them” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the practical checklist 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.
The reasons, in order of frequency
Nothing was provided. The commonest by far: there is no approved tool for the task.
What was provided is worse. Slower, older, more restricted, or missing the one capability that matters.
Getting approval takes too long. The task is today; the request process is weeks.
They did not know there was an approved option. Which is a communication failure wearing the clothes of a compliance failure.
And it was already there — an AI feature appearing inside a tool they already use, switched on by the supplier.
What is almost never the reason
Deliberate circumvention of a known rule for personal gain.
It happens and it is rare enough that building the whole programme around it is a mistake.
Designing for the rare case produces controls that obstruct the common one.
The time pressure point
Most shadow use is somebody trying to do their job faster.
The tool helped, and the alternative was to do it slowly or not at all.
Which means enforcement without a replacement asks people to be slower on purpose, and the request will be declined quietly.
Why it stays hidden
Not concealment, mostly. There is simply nowhere to say it.
And where there is, declaring invites a review that might end with a no, so the rational move is silence.
A declaration route that frequently results in refusal trains people not to declare. Its own note covers exceptions and why a usable yes matters more than a careful no.
The departmental pattern
Shadow use clusters: one team adopts something and it spreads by recommendation.
Which means discovery frequently finds a department rather than individuals, and that is a better unit to work with.
Ask the team what the task was. The answer is a specification for what to provide.
What this implies for the programme
Start by finding out what people are doing and why, not who.
Treat every finding as a requirement rather than an incident.
And fix the supply before tightening the rules, which the enabling section argues at length.
What to check
For each shadow tool you know about, do you know what task it was doing?
How long does approval for a new tool take in your organisation?
Is there a route to declare something, and what usually happens when somebody uses it?
And do people know what the approved option is?
The point
The reasons are ordinary: nothing was provided, what was provided is worse, approval takes too long, or the feature simply appeared in a tool they already used..
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.