Every organization I’ve watched try to solve shadow AI has run the same play. Publish a policy. Add a training module. Block a handful of domains at the proxy. And announce it during the last 5 minutes of an all-hands with a slide about data protection.
It works for roughly 6 weeks during the slow internal news cycle. Then usage recovers. Except now it’s harder to see because the people who continued are the ones who found the routes your proxy doesn’t cover.
The conclusion most leadership teams draw from this is that employees don’t take the policy seriously. That’s the comfortable conclusion since it puts the failure somewhere other than your own process. But as I’m sure you guessed, it’s the wrong conclusion.
This isn’t a discipline problem with a policy solution. It’s a latency problem with a procurement solution. And until the arithmetic changes the behaviour won’t. Do I sound crazy? Well stick around a few more paragraphs. You’ll see this idea may be so crazy, it just might work.
Why shadow AI numbers don’t reveal a compliance failure
Verizon's 2026 Data Breach Investigations Report found that employee use of unapproved AI tripled to 45% of employees now considered regular AI users on corporate devices. Shadow AI has become the third most common non-malicious insider action when it comes to data about data loss prevention. Which is a 4x increase in a single year.
The phrase worth pausing on in Verizon's categorization is "non-malicious." This isn’t exfiltration. These are people trying to finish their work.
The data type ranking makes the same point from another angle. The most common category of material submitted to external models is source code. That isn’t someone leaking a customer list. That’s an engineer debugging a function at 11pm, pasting it into whatever was available and getting an answer as quickly as possible.
When a behavior is exhibited by 45% of a population that spans industries and geographies, and consists overwhelmingly of people doing their jobs, you aren’t looking at a compliance failure. You’re looking at a process that the organization has routed around because it wasn’t working.
How long does AI approval actually take?
Most teams can’t answer that without going to look. That’s the first finding. And when they find it, the number is almost never measured in days. Drawing on more than 30 billion dollars of processed spend, Vertice put the average procurement cycle at 72 days in 2026. Even new purchases, which move faster than renewals, averaged 40 days.
Add a security review, a data processing agreement, and a vendor risk questionnaire, and your buying path for a new AI tool will easily be measured months. The unsanctioned path takes about 12 seconds. Open a browser, sign in with a personal account, paste the thing. That’s the whole mechanism.
You’re asking someone to accept a delay of two to three months in exchange for a benefit that accrues to the organization rather than to them. And on a task they’ve been asked to complete this week. Policy doesn’t change that trade, nor does training. The only thing that changes that equation is making the sanctioned path comparably faster.
Is the failure model behind your AI policy wrong?
In most cases, yes. When it comes to enterprise governance, the assumed failure model is that someone would do the wrong thing unless told not to. That model fits both fraud and negligence. It doesn’t fit shadow AI, where the person understands the rule, agrees with the reasoning, and breaks it anyway because the alternative is missing a deadline.
The people setting the rules appear to know this. Survey work through 2026 has repeatedly found senior leaders among the heaviest users of unapproved tools. And a substantial share of executives are comfortable with the trade because speed is what they are being measured on. When the rule is being broken at the top for rational reasons, it quickly becomes clear that the rule isn’t the control you think it is.
The productive reframe is to stop asking why employees ignore the policy and start asking what the policy is competing against. Unapproved tooling wins because it’s available. Any response that doesn’t address availability is decorative.
What does a faster sanctioned path look like in practice?
It looks unglamorous. Most of the work sits in procurement design rather than security engineering. Which is probably why it so rarely gets done.
Start by tiering on data class instead of on tool. Most organizations run one approval process for everything, which means a summarization tool touching public marketing copy waits behind the same review as a system touching customer records. Splitting the path by what data the tool will see lets low risk usage clear in days and concentrates scrutiny where it delivers ROI.
Then pre-clear a real catalogue and keep it current. Surprisingly enough, a list of three approved tools published 18-months ago is honestly worse than nothing. Why? Because it tells everyone that the sanctioned route isn't being maintained. The catalogue has to move at the pace of the category.
Default deny on data rather than on tools. Blocking domains starts an arms race you'll lose because more AI tools appear each month than your proxy list can track. Controlling which data can leave, through classification and egress inspection, holds regardless of which tool arrives next.
Then track the delay and report it. The metric that matters isn't policy violations detected. It's median time from request to approved access, measured against how long the equivalent unsanctioned option takes. That number is the actual driver. It's trackable and it turns a security conversation into an operations one.
What happens when the next wave of AI tools arrives?
The same latency dynamic will reappear. Which is why this reframing matters beyond today’s tooling. Agents, embedded copilots, and vendor shipped automation will all present the same choice between a fast unofficial route and a slow official one. Organizations that treat the gap as the control point will absorb those waves. Organizations that treat each one as a fresh policy problem will keep publishing rules that describe an organization they don’t have.
So the question for your next security review isn’t how many shadow AI violations were detected last quarter. Ask instead how long it takes, today, for an employee with a legitimate need to get access to an approved AI tool.
If nobody in the room knows the number, that’s the finding. And if the number is measured in months, you have not been running a governance program. You’ve been running an incentive scheme. And it has been working exactly as designed. If this is you, it’s time for redesign.
FAQs
What is shadow AI?
Shadow AI is the use of AI tools within an organisation without formal approval or oversight. It covers everything from an employee using a personal account on a public chatbot to teams adopting AI features in products that never went through vendor review. It is the AI equivalent of shadow IT, but adoption is faster because there is nothing to install.
Why don't policies and training reduce shadow AI?
Because they address motive rather than friction. Most shadow AI use is not defiant; people understand the policy and break it anyway because the approved path takes months and the unapproved one takes seconds. Until that gap closes, a policy documents the rule without changing the underlying incentive.
How do you actually reduce shadow AI?
Shorten the sanctioned path and control data rather than tools. Tier approvals by data class so low risk requests clear quickly, maintain a current catalogue of pre-cleared tools, apply egress controls based on data classification rather than domain blocking, and track median time to approved access as your primary metric.
What is the biggest risk from shadow AI?
Intellectual property loss rather than regulated data exposure. Verizon's 2026 DBIR found source code to be the most common category of data submitted to external AI models, ahead of images and structured data. Most early shadow AI discussion focused on personal data, but the dominant exposure in the breach data is proprietary technical material.
.png)
.svg)