shadow AI is the fastest-growing shadow IT in history

In February 2025, a product manager at a B2B SaaS company pasted a customer interview transcript into ChatGPT and asked it to summarize the key insights. The interview was with a major customer, covering their current pain points, internal politics, and planned evaluation of competitors. The summary was excellent and went into the PM’s next product planning doc.

In March 2025, a sales rep uploaded a copy of the quarterly pipeline forecast to Claude to generate analysis of trends. The forecast included deal amounts, probability weighting, and named accounts with competitive positioning notes.

In April 2025, an engineer pasted a stack trace and relevant code snippets from a production service into Cursor to get debugging help. The code snippets included internal API keys that the engineer didn’t notice.

In each case, the employee’s intent was reasonable. Each of them was trying to get work done faster with a tool that was obviously useful for their task. None of them was trying to exfiltrate data. None of them was acting maliciously.

In each case, sensitive corporate data left the company’s environment and was transmitted to a third-party AI service. In each case, the transmission happened outside any of the company’s DLP tools, sanctioned integrations, or acceptable-use policies. In each case, the data now exists in the AI provider’s logs, subject to the provider’s retention and usage policies, which may or may not include training on the data.

This is shadow AI. It is shadow IT with a specific architecture that makes it faster-moving, harder to detect, and more consequential than the shadow IT patterns of the last decade.

This essay is about why shadow AI is the fastest-growing shadow IT category in history, and what to do about it.

the frictionless path

Shadow IT historically required at least some friction. To sign up for a new SaaS tool, an employee had to create an account, configure it, often integrate it with existing systems, and maintain awareness of the tool as a separate thing they were using. Each of those steps was small, but cumulatively they meant that shadow IT adoption happened over weeks, not minutes.

AI assistants have compressed the friction to near zero. The employee opens a tab. Types or pastes a query. Gets an answer. No account creation required for most services, or a single sign-in for the rest. No configuration. No integration. No maintenance. The tool is used for one query and then the tab is closed.

The friction compression has a specific effect on the shadow IT pattern. In the historical model, a shadow IT tool became part of someone’s workflow over time. Today’s shadow AI becomes part of someone’s workflow the first time they use it. The adoption curve, from “I haven’t tried this” to “I use this daily,” is measured in a single work session.

The second effect is on the data that flows. Historical shadow IT exposed data gradually, the employee would put a few records into the new CRM, then more records, then eventually migrate their workflow. The data exposure was incremental. Today’s shadow AI exposure is blunt, the employee pastes a complete document into a chat window in one interaction. The entire exposure happens in seconds.

The third effect is on detection. Historical shadow IT was detectable by the data it accumulated. A shadow tool that held data was discoverable by finding the data, the account, or the subscription. Today’s shadow AI often holds no durable account. The query is made, the response is returned, the conversation is closed. The only trace is in the AI provider’s logs, which are not available to the employer.

where AI touches company data

• the sanctioned enterprise AIunder contract, with controls
• public chatbotswhere people paste text
• AI features inside SaaSswitched on by default in tools you already use
• browser extensionswith access to every page
• meeting note-takersjoining calls and keeping transcripts
• AI coding assistantsoften licensed, sometimes not

outside the contractusually handled

the enterprise account doesn’t solve it

The common enterprise response to shadow AI has been to negotiate an enterprise license with a major AI provider, OpenAI’s enterprise tier, Anthropic’s Claude for Work, Microsoft Copilot for Enterprise. The enterprise version provides SSO integration, data residency guarantees, no-training-on-your-data commitments, and admin controls.

This is a useful step. It gives the enterprise a sanctioned channel that can be monitored, audited, and governed. The enterprise version of a given AI service solves the compliance problem for that service.

It does not solve the shadow AI problem.

The reason is that AI is not a single category. An employee who needs AI for a specific task will pick the AI tool that best serves that task. The enterprise’s sanctioned AI is one option. The non-sanctioned AIs, a specialized coding assistant, a research tool that uses a different model, a marketing tool with AI features, a note-taking app with AI summarization, a transcription service that uses AI transcription, are dozens of other options.

A typical knowledge worker, in 2026, interacts with AI features through many different products. Some of those interactions are with the sanctioned enterprise AI. Many of them are with AI features embedded in other products the employee uses for other purposes. The embedded AI features are often enabled by default in the product.

Shadow AI includes all of those interactions outside the sanctioned channel. The enterprise AI contract covers only part of the AI use in the company, and nobody knows how large that part is.

the features no one opts into

A specific pattern that accelerates shadow AI: the embedded AI feature that gets enabled automatically.

Salesforce launches Einstein features. Slack launches AI Summary. Notion launches Notion AI. Microsoft launches Copilot features across Office. Zoom launches meeting summarization. Each of these is added to an existing product the company already uses. Each of them is gated by admin-level feature flags that default to “on” in many cases, or that users can enable themselves.

An employee using Zoom notices a new “AI summary” option. They enable it for a meeting. The meeting recording is processed by Zoom’s AI service. The summary is generated. The employee gets a useful artifact.

The data flow that just happened: the meeting audio, which includes whatever was said during the meeting (potentially confidential), was sent to Zoom’s AI processing infrastructure. Depending on the Zoom plan and admin settings, the audio and transcript may be stored in Zoom’s systems for some retention period. The training-on-customer-data policy depends on the plan tier and admin controls.

The employee enabled a feature. The enablement was a single click. The data exposure was the entire meeting’s worth of audio. The admin did not explicitly consent to the feature being used, because the feature was available in the product and the employee simply used it.

This pattern scales. Every major SaaS tool the company uses is progressively adding AI features. The features are enabled, sometimes by admin default and sometimes by user-level controls, and each enabling action is a potential data flow to the AI provider’s infrastructure. Tracking the cumulative exposure across dozens of products is beyond what any mid-market company’s IT team is currently staffed to do.

the paste is the hard one to detect

The category of shadow AI that is genuinely hard to detect is the paste-into-public-tool pattern. An employee copies data from a corporate system. Pastes it into a public AI service. Gets a response.

The data has left the corporate perimeter. DLP tools, if configured comprehensively, can catch some of this, outbound text pattern matching on copy-paste events, browser extensions that scan for sensitive data before transmission, endpoint DLP that looks for specific data signatures. In practice, DLP at mid-market companies is configured for email and file transfer, not for general web interactions.

An employee pasting a customer contract into ChatGPT is moving text through a web form. The endpoint is a general-purpose chat interface. The pattern is identical to pasting text into any other web form. Distinguishing sensitive corporate text from benign text, at the moment of paste, requires either deep content inspection that slows everything down or specific tooling designed for this exact use case.

Specific tooling has emerged, Harmonic Security, Netskope’s AI product, Obsidian Security’s AI monitoring, but the deployment is new, uneven, and rarely comprehensive. Most mid-market companies do not have any of this deployed in 2026, which means the paste-into-public-tool flow is effectively invisible to them.

What companies do have is awareness. A growing acknowledgment that this is happening. Ask any team whether people use AI tools the company never approved, and the honest answer is yes. The companies know it’s happening, even if they can’t see the specific instances.

the consent problem

A specific subcategory: the AI feature that processes data without the user understanding the data flow.

A recruiter uses LinkedIn Recruiter. LinkedIn has added AI-powered candidate matching. The recruiter doesn’t know, because they haven’t read the updated terms, that their searches and candidate interactions are being used to train LinkedIn’s AI models, or that the matching algorithm is running against data that flows through LinkedIn’s AI infrastructure.

A marketer uses HubSpot. HubSpot adds AI-powered email writing. The marketer’s draft emails are being processed by AI models that may or may not be trained on the data.

A salesperson uses Gong. Gong processes every call recording with AI. The call data includes customer conversations, internal strategies, and sensitive revenue discussions.

In each of these cases, the employee is using a sanctioned product. The data flow to AI processing is a feature of the sanctioned product. The IT and security teams may not have explicitly evaluated the AI processing aspect of the product, because the product was approved before it had AI features and the features were added through updates.

The specific consent problem is that the AI feature is not always clearly indicated to the user. Users don’t read terms of service updates. Users don’t know when a new feature is added. The data flows start happening, and the users don’t notice because nothing visible has changed in their workflow.

Detecting this requires reviewing every sanctioned SaaS product for new AI features, reading the updated terms, and making explicit decisions about whether to allow the feature. Few companies have the capacity to do this continuously. Fewer still are doing it for every product in their stack.

the governance that actually works

The governance patterns that have emerged for shadow AI look different from traditional shadow IT governance.

Historical shadow IT governance relied on blocking and approval. Block the tool at the network layer. Require approval before use. If blocked, the user escalates and either gets approval or uses an alternative.

Shadow AI governance cannot rely on blocking, because the tools are too many, too interchangeable, and too easily accessed from personal devices. Blocking ChatGPT at the corporate network just pushes the use to the employee’s phone. The data exposure continues, just through a different network path.

The patterns that work focus on providing acceptable alternatives, setting clear use policies, and building monitoring specifically for AI interactions.

A sanctioned enterprise AI tool, with SSO, data handling guarantees, and broad capability, provides most employees with a legitimate option. If the sanctioned tool is good enough for most tasks, the majority of usage flows through it instead of through shadow channels.

A clear policy on what data can and cannot be used with AI, including public AI, embedded AI in SaaS tools, and internal AI, gives employees a decision rule. The policy is usually simple: customer data, employee data, and intellectual property must stay in sanctioned channels. Everything else can go through public AI if useful.

Monitoring designed for AI interactions, either network-level filtering of AI service domains, endpoint DLP tuned for paste events, or dedicated AI monitoring products, provides visibility into the actual usage. The monitoring doesn’t have to be perfect. It has to be good enough to catch the clear policy violations and generate teaching moments.

Training for employees on what AI does and doesn’t do with their data. Most employees don’t know that free-tier public AI services may retain or train on their data. Most of them will behave differently if they understand the data handling.

None of these is glamorous. All of them are more sustainable than the blanket-block approach, which fails because users route around it.

governance that people follow

1. 1one-page policyWhat data may go where, in plain words.
2. 2acknowledgementEveryone confirms they read it.
3. 3an approved path that's easierIf the sanctioned tool is slower, people route around it.
4. 4quarterly auditCheck which AI tools and features are in use, and update the policy.

the quarterly AI audit

Here’s the specific exercise for running shadow AI governance.

Pick the top twenty SaaS tools in your company by usage or spend. For each tool, open the admin console and look for AI features. They might be under “beta features,” “labs,” “AI settings,” or embedded in specific feature pages.

For each AI feature, answer: is it enabled? Who enabled it? What data does it process? Where does the processing happen? Does the vendor train on customer data by default?

For each AI feature you find enabled, decide: should it be enabled? If yes, document the decision. If no, disable it.

Do this quarterly. The list of AI features grows quarterly. The policy decisions need to track.

For the public AI services, check: does the company have an enterprise account? If yes, is it being used (or is usage flowing elsewhere)? If no, is there a plan to get one?

Pull any AI-specific monitoring data you have. Review the top destinations of AI-related traffic. Compare to the sanctioned list. Investigate the delta.

The goal is not to catch every instance of shadow AI. The goal is to see the shape of it, understand where it’s happening, and push users toward sanctioned alternatives while the unsanctioned tools continue to exist.

the specific thing to do this week

Write a one-page AI use policy. The policy should specify what data is allowed in public AI services (approved use cases, no customer data, no employee data, no IP), what the sanctioned enterprise AI is for (broader use), and what happens if employees violate the policy (teaching, then escalation).

Distribute the policy. Require acknowledgment.

This alone will reduce the most egregious shadow AI behavior in your company, because employees who paste customer contracts into public AI are usually doing it without realizing the implications. Most of them will stop once the implications are named.

The harder tier, the employees who keep doing it after the policy is clear, or the AI features embedded in products you don’t know about, requires the continuous audit discipline.

Shadow AI is the fastest-growing shadow IT category because the AI tools are the most valuable new technology for knowledge workers in a generation. The tools are here. The usage is real. The governance has to be designed for adoption.

Write the policy. Name the sanctioned tool. Audit the embedded features. Monitor what you can. Accept that some exposure will happen and focus your controls on the high-risk categories.

The alternative is to pretend the tools don’t exist, which is what most companies are still doing, and which is why most companies have a shadow AI exposure they haven’t measured.