Shadow AI is a requirements document

The security teams sounding the alarm about shadow AI have their facts straight, and it is worth saying so plainly before saying anything else. People are pasting customer lists, draft contract language, unreleased financials and half-formed strategy into tools nobody vetted. There is no data-residency guarantee. There is no audit trail. There is no retention control, no way to answer a regulator's question about where a particular document went, and frequently no contract at all beyond a checkbox somebody clicked on a laptop on a Sunday evening. The surveys everyone is quoting keep finding the same thing — most employees are using AI their employer never sanctioned, and a meaningful share of them are feeding it material the company would never knowingly release.

The instinct that follows is not stupid. Inventory the usage. Block what you can block. Write a policy, train against it, enforce it, and put a name on the enforcement. That is the playbook that handled shadow IT for two decades, and it was broadly correct then. We would not tell a client to shrug at unapproved AI tools any more than we would tell them to shrug at an unmanaged spreadsheet holding customer records on a personal drive.

But the response is answering only half of what is in front of it. Shadow AI is a governance failure, and it is also something else — something worth more than the failure costs. It is a requirements document, written involuntarily, by the people closest to the work. The standard response reads the first and shreds the second.

The exposure is real

We want to be unambiguous here, because the argument that follows is easy to misread as permission. The data problem is not theoretical and it is not small. A consumer chatbot with a permissive retention default is, functionally, an uncontrolled copy of whatever gets typed into it. Once a pricing model or a candidate's file or a description of an unannounced acquisition has been pasted in, there is no recall, no expiry you control, and no honest answer to give a client who asks where their information lives. Some of these tools train on what they receive. Some retain indefinitely by default. Most of them were designed for individuals, and the individual on the other end of the account is not the enterprise.

None of that is in dispute. What is in dispute is the theory of the case — the belief that this is fundamentally an incident to be contained, and that containment is therefore the whole job. Containment is part of the job. It happens to be the part that destroys the evidence.

Shadow IT was procurement friction

The reason the old playbook feels right is that it worked, and the reason it worked is worth stating precisely, because the precision is where the analogy breaks.

Shadow IT was a purchasing problem wearing a security costume. A team wanted a file-sharing service or a project tracker or a survey tool. The company hadn't bought one, or had bought a worse one, or had bought a fine one that took eleven weeks and three approvals to provision. So somebody put it on a personal card and expensed it. The gap being routed around was a gap in the catalogue. The fix, correspondingly, was catalogue work: find out what people were buying, buy a governed version centrally, negotiate the contract, turn on single sign-on, and the shadow usage collapsed — not because anyone was policed into compliance, but because the sanctioned path became the path of least resistance. Procurement friction is a solvable friction, and solving it genuinely solves the behaviour.

That is why security leaders reach for the same move now. It is a good move. It is a good move against a different problem.

Shadow AI is judgment friction

What an employee routes around when they open an unapproved AI tool is almost never a purchase order. It is a decision — one the sanctioned system is making, and making badly or slowly or in the wrong place.

Watch what the usage actually looks like. An analyst has a sanctioned assistant available, inside the approved environment, cleared by legal. She uses something else anyway. Not because the approved one doesn't exist but because it takes forty seconds to return anything, because everything is routed through the most capable model on the roster whether or not the task needs it — a choice we have argued elsewhere is rarely the right default — because it refuses a class of request that is plainly benign, because it cannot see the document she is working on, because it lives in a portal and her work lives in her inbox. Every one of those is a judgment somebody made when the sanctioned system was designed. She is not evading procurement. She is overruling a design decision, silently, at her desk, several dozen times a week.

That is the whole difference, and conflating the two is the error that produces every subsequent mistake. Procurement friction says we don't have that. Judgment friction says we have it and it is wrong about something. The first is a gap in a catalogue. The second is a defect in a system already in production, being discovered continuously by the only people positioned to discover it, and reported through the only channel available to them — their behaviour.

Consider what that channel is actually worth. Organisations spend real money trying to learn which internal workflows are too slow, too rigid, or too far from where the work happens. They run surveys that people answer politely. They run process reviews that surface what is safe to say in front of a manager. They commission maturity assessments that produce a heat map nobody acts on. Shadow AI produces the same finding with none of the distortion, because nobody is performing when they open a browser tab at eleven at night to get something finished. Revealed preference is expensive to gather and this arrives free. And the first thing most organisations do with it is make it stop being visible.

A ban buys invisibility

Here is the mechanism, and it is not subtle once you look at it directly.

Blocking a tool at the network edge does not reduce the demand that produced the usage. The analyst still has the deadline, still has the document, still has the forty-second wait on the sanctioned path. What changes is the route. She uses her phone. She uses a personal laptop on the guest network. She emails herself the paragraph and handles it at home. She finds the tool that isn't on the block list yet. The behaviour persists at something close to its original volume and moves entirely outside anything you can observe.

So the trade is not usage for safety. The trade is a measurable problem for an unmeasurable one. Before the ban you had a rough map — expense lines, browser telemetry, the tools people mentioned in meetings without thinking about it. After the ban you have a policy, a compliance attestation, and no map. The exposure is roughly what it was. Your knowledge of it is worse.

We have made this argument in another register about automation that self-heals instead of failing loudly, and the shape is identical. A failure you can see is not more dangerous than one you cannot; it is less dangerous, because it is the only one you can act on. Rule-based bots broke in your face and everyone hated it, and the hatred obscured that the breakage was doing unpaid work — telling you the moment reality diverged from your model of it. A visible shadow AI problem is doing exactly that job. Banning it does not fix the divergence. It turns off the alarm.

The approved list answers the wrong question

The more sophisticated response — and it is more sophisticated — is the approved-tool list. Vet a set of vendors, negotiate enterprise terms, publish the roster, and give people a legitimate destination. This is better than a ban and we recommend it often. It is also, on its own, an answer to the wrong question.

The approved list answers is this tool safe. It never asks why was the sanctioned path insufficient. And because it never asks, the pressure that produced the shadow usage is still there, unrelieved, pushing against whatever the newly approved tool also fails to do. Six months later there is a new set of unapproved tools in the expense reports, the security team is genuinely puzzled — we gave them something — and the cycle restarts one vendor further along. Each round costs a procurement exercise and buys a quarter or two of quiet.

This is what a governance posture looks like when it has substituted a list for a way of deciding. We have written about that substitution as it appears at the strategy level, where an organisation produces a document instead of a repeatable method for making the call. Tool approval is the same failure at operational scale: an artefact that satisfies the question as asked, and leaves the question underneath it untouched.

Blanket policy, blanket disregard

There is a second cost, and it compounds.

Pasting a segmented customer list into a consumer chatbot and using an unapproved transcription tool for an internal standup are not the same act. They differ in what leaves the building, how sensitive it is, whether it identifies anyone, whether it is recoverable, and what a regulator would make of it. Any competent security professional knows this. Most shadow AI policies are written as though they don't, because a policy that draws distinctions is harder to write, harder to train, and harder to enforce uniformly.

The employee reads the uniform policy and learns something the authors did not intend to teach: this policy has not been calibrated. It treats a trivial act and a serious one as one offence. And once someone concludes the policy isn't calibrated, they stop calibrating too — not out of malice, but because the policy has told them their own judgment is not part of the system. They now sort every AI-related decision into one bucket labelled technically against the rules, and having decided the rules are indiscriminate, they discriminate less, not more. The person who would have hesitated before the customer list no longer hesitates differently than before the transcription tool, because the organisation told them there is no difference. Blanket policies produce blanket disregard, and the disregard lands hardest exactly where you most needed the hesitation.

Preference or finding

We should be honest about the limit of the argument, because it has one, and treating every instance of unapproved usage as a valuable signal would be its own kind of foolishness.

Some shadow AI is pure exposure with nothing in it. Someone tried a tool because it was in the news. Someone prefers a particular interface for reasons that generalise to no one. Someone was careless. There is no requirement hiding underneath and no design decision being overruled — there is just risk, and it should be handled as risk, with no strategic reading attached.

The test is clustering, and it is cruder and more reliable than most of what gets used in its place. A tool one person uses is a preference. A tool forty people found independently, without coordinating, in different functions, is a finding — and the finding is not about the tool. It is about the shape of the gap all forty were trying to close. When the same category of usage shows up across teams that have no reason to talk to each other, something in the sanctioned environment is failing in a way that is structural rather than personal, and the specific tool they converged on tells you which capability is missing. Cluster size is the difference between a security ticket and a roadmap item, and almost nobody is looking at it, because the inventory is being compiled to support enforcement rather than to be read.

Amnesty beats audit

What we would do instead is unglamorous, and it starts by pulling the two questions apart, because they have been fused into one and they have different answers.

The data-exposure question is real, urgent, and separately solvable. Solve it at the data layer rather than the tool layer. Classify what actually cannot leave, instrument where it moves, and control the movement — which is a different discipline from maintaining a list of blessed applications, and a more durable one, since it survives the arrival of the next tool. It is the same principle we have argued for machine access, where every connector is a grant of authority that should be scoped to the data and the action rather than to the vendor's name. Govern the data, not the tool. A policy built that way can be calibrated, because it is drawing the distinction that matters — what left, and how sensitive it was — rather than the one that is easy to enforce.

The demand-signal question is strategic, and currently being thrown away. Make declaring usage cheaper than hiding it. That means amnesty with teeth removed: a genuine, credible, publicly honoured commitment that telling us what you are using carries no penalty, paired with the only thing that makes such a commitment believable — visible action on what gets declared. Then read the resulting map for what it is. Not a list of violations. A prioritised backlog of the places your sanctioned systems are losing to a free tool, ranked by how many people independently reached the same conclusion.

Measure it accordingly. The number worth watching is not incidents detected or policies acknowledged. It is the share of AI usage you can see, and the time between a cluster appearing in that map and a change in the sanctioned system that answers it. An organisation where declared usage is rising and shadow usage is falling is winning. An organisation where both appear to be falling has usually just stopped being able to tell.

What the clean policy costs

The exposure is real, the urgency is real, and nothing here argues for tolerating an uncontrolled copy of your customer data on someone's personal account. Handle that. Handle it at the data layer, where it can be handled without pretending a customer list and a meeting transcript are the same thing.

But be clear about the second thing you are deciding, because most organisations are deciding it without noticing. You can have a clean shadow AI policy or an accurate picture of where your operations are failing. The clean policy is legible, defensible in a board meeting, and easy to attest to. The accurate picture is messy, arrives as a list of things your own systems are doing badly, and requires you to act on it in order to keep receiving it. Almost everyone takes the first. Very few of them know they gave up the second — which is the tell, because the whole value of the signal was that it came from people who never meant to send it.