A recruiter has forty CVs to screen before Thursday. The approved applicant tracking system has an AI assist button that takes its time and returns summaries written in the voice of a nervous lawyer. So she opens a tab on her personal laptop, pastes in the job description and the first CV, and gets something usable almost instantly. By lunch she has a shortlist. By Friday, three colleagues are doing the same thing, and none of them has mentioned it to anyone.
When IT finds out, the conversation tends to go one way. Personal data left the building. Nobody signed a processing agreement. There is no audit log. All of that is true, and in an earlier piece on shadow AI we went through the security risks in detail. We are not walking any of them back. But if the only response is a policy memo and a blocked domain, the organisation has mistaken the smoke alarm for the fire.
Employees are telling you something
Nobody routes around an official tool for fun. Finding an alternative takes effort, using it takes a little nerve, and keeping it quiet brings a constant low hum of worry about being caught. People pay that cost only when the official path costs more. Shadow AI is what happens when an employee's judgement about how the work should be done outruns the organisation's ability to supply the tools for it.
Read that way, every unapproved tab is a free piece of user research. It tells you which task is painful, how painful, and what good enough looks like to the person actually doing it. Companies pay consultants handsomely to produce that information. Here it arrives unprompted, and the standard reflex is to punish the people who supplied it.
Urban planners have a name for the dirt track worn across a lawn, a few metres from the paved path the architect drew: a desire line. The sensible ones pave the track. The others put up a fence, and then a second fence when people start walking around the first.
Why the official tool keeps losing
The approved tool usually loses for reasons that have little to do with technology. It was chosen a year or two ago by a committee that weighed vendor stability, contract terms, single sign-on and a reference call with somebody else's CIO. Those are reasonable criteria. None of them is "does this help a sales rep write a follow-up in the four minutes between two calls".
Then it gets configured. Every department that touched the rollout added a safeguard: a disclaimer, a mandatory field, a restricted data source, a content filter tuned for the worst imaginable case. Each one made sense on its own. Stacked together, they produce a tool that is technically available and practically avoided. Nobody owns the total friction, because everybody owns a slice of it.
Meanwhile the consumer version on someone's phone has no committee. It is quick, it remembers what you said five minutes ago, and it does not ask you to classify your prompt before answering. The gap between the two is obvious to anyone who uses both, and invisible to the people who chose one and use neither.
What a crackdown actually achieves
Picture the marketing team the week after the memo. The domain is blocked on the corporate network. Usage drops on the dashboard, and someone tells the board that shadow AI has been contained. What actually happened is that the work moved to phones and home broadband, where it is now invisible as well as unapproved. The campaign briefs and customer segments still leave the building. You have simply lost the ability to watch them go.
The second effect is quieter and worse. The people most likely to experiment are usually the ones closest to the work and least patient with waste. A crackdown teaches them that initiative is a disciplinary risk. Some will stop. The best of them will carry on and stop telling you, which is the precise opposite of the culture every AI strategy deck claims to want.
This is Goodhart's law in miniature. Once "unapproved tool usage" becomes the number that gets reported, it gets managed. The need that produced it does not move an inch.
Treat it as a signal and work backwards
None of this means waving the risk away. It means changing the order of operations: find out what people are doing before deciding what to forbid. That sounds soft. In practice it is a fairly hard-nosed exercise.
Start with an amnesty that is actually an amnesty. Ask teams, with no consequences attached, which tools they use and for what. The first round of answers will be partial, because trust takes a couple of rounds to build. They will still be more accurate than any network log, because they include the reason.
Then sort what you hear. Some uses are low risk and could be approved this month with one sensible data rule: rewriting your own emails, summarising public documents, drafting code that goes through review anyway. Some are genuinely dangerous, usually the ones touching customer records or contracts, and those need a real alternative quickly rather than a ban with nothing behind it. A few will expose a workflow so broken that the right move is to fix the workflow, at which point the AI question quietly disappears.
Then publish the result, quickly and in plain language. A one-page list of approved uses, with the data rule beside each, does more than a forty-page acceptable-use policy nobody finishes. Revisit it every month, because the shadow tools will keep moving and so will the work. Owning up to a workaround should earn people a better official option and nothing worse.
Finally, judge the official tool against the shadow one on the shadow one's terms. How long to a useful answer. How many clicks. How many fields to fill before anything happens. If the sanctioned option cannot get within shouting distance, you do not have a compliance problem. You have a product problem with a compliance symptom.
A better job description for security
Security teams often hear this argument as an accusation, which is unfair to them. They are judged on breaches. Nobody measures them on how long a recruiter spends on a shortlist, so naturally they optimise for fewer doors. It is the principal–agent problem in a sentence: the person writing the rules does not bear the cost of the friction, and the person bearing the friction does not answer for the breach.
The remedy is to make both costs visible to the same people. A security lead who spends a morning beside the sales team, watching what the approved tool does to a twenty-minute task, makes different decisions afterwards. So does a sales manager who sits through one incident review. Neither visit takes long, and neither appears in any governance framework we have read.
The best security teams we have worked alongside describe their job as making the safe path the easy path. That framing turns shadow AI from an enemy into a backlog. Every unapproved tool is a feature request with an unusually clear specification, written by someone who cared enough about the work to bend a rule for it.
So the next time someone forwards a list of unapproved AI domains spotted on the network, resist the urge to sort it by risk. Sort it by team, then go and ask the heaviest users what they were trying to get done. Bring a notebook and leave the policy on your desk. The recruiter with forty CVs has already written the requirements for your next internal tool, and she did it without being asked.
