Your employees are already using AI, and the more pressing question for most security teams is not whether it is happening but whether they can actually see it.
Shadow AI is the use of AI tools without IT approval: personal ChatGPT accounts, browser extensions, coding assistants, and AI-powered bots that employees adopt because they are faster and more capable than whatever the IT department has sanctioned.
Regular AI use on corporate devices tripled in a single year, from 15% to 45% of employees, according to Verizon’s 2026 Data Breach Investigations Report, and 67% of those users access AI services through non-corporate accounts. Much of that activity runs through tools that were never approved, never logged, and in most cases never known about by the security team.
The instinct is to ban it, but would that really eliminate the risk? Without an approved alternative, a ban moves usage somewhere the security team can no longer see, which makes the underlying exposure harder to address.
Key Takeaways
- Regular AI use at work tripled in a year, and two thirds of those users reach AI services through non-corporate accounts.
- It differs from shadow IT in a critical way: data entered into a public AI model cannot be deleted the way a file can, and may be retained as training data by the vendor.
- The most commonly exposed data types are customer records, source code, internal documents, and personally identifiable information.
- Banning AI tools without offering an approved alternative removes visibility while the usage continues through personal accounts.
- A mature policy covers four components: give employees approved corporate tools with privacy settings configured, publish a short list of data that never goes into any prompt, inventory real usage to build out the approved list, and train with examples from each team’s own work.
- The goal is visibility over prohibition.
What Shadow AI Is and Why It Spreads
Shadow AI is not unusual behavior. A marketing analyst pastes a campaign brief into a free chatbot to save an hour. A developer routes production code through a browser extension to debug it faster. A finance team member uploads a spreadsheet to an AI summarization tool because the internal alternative requires three approval steps and four days. None of these people think of themselves as a security risk, and most would be surprised to learn what they have actually exposed.
According to Microsoft’s 2026 Work Trend Index, employees are adopting AI faster than their organizations’ systems and norms can absorb it. The tools are free, require no installation beyond a browser tab, and often outperform sanctioned alternatives. In many organizations, no approved tool competes on speed or output quality, so employees default to whatever gets the job done.
According to Zylo’s 2026 SaaS Management Index, business units now control 81% of SaaS spend while IT directly manages just 15%, and expense-based SaaS spend jumped 267% year over year, with ChatGPT now the most expensed application across enterprise portfolios.
Why Shadow AI Is a Different Problem from Shadow IT
Shadow IT governance has a well-established playbook: find the unauthorized tool, assess the risk, repatriate the data, implement controls going forward. That playbook does not transfer cleanly to shadow AI, because the data problem is structurally different.
With shadow IT, data sits on an external server you do not control. The remediation path is clear: require deletion, revoke access, move forward. With shadow AI, data enters a model as an input, and depending on the vendor’s terms of service and training data policy, that information may be retained, used to improve the model, or incorporated into future outputs served to other users.
There is no equivalent of “require deletion” once proprietary data has potentially been absorbed into a third-party model’s weights. For sensitive data categories, this makes prevention the only viable response rather than one option among several.
What Gets Exposed
Traditional DLP (data loss prevention) tools monitor files, email, and sanctioned applications. They were not built to monitor natural language inputs to AI models, which is how sensitive data moves in a shadow AI environment. The data categories that come up most often:
Customer records and PII (personally identifiable information): Sales teams paste CRM exports into AI tools to generate outreach copy. Support teams summarize customer conversations using consumer chatbots. Each interaction containing a customer name, email, or account detail can fall under data-protection rules such as GDPR or CCPA, subject to local requirements.
Source code and technical documentation: Developers use AI coding assistants to debug, refactor, and document code. When that code contains proprietary logic or API credentials, the exposure is both an IP risk and a potential attack surface. According to IBM’s 2025 Cost of a Data Breach Report, shadow AI added USD 670,000 to the global average breach cost.
Internal strategy documents: Meeting notes, financial projections, M&A materials, and product roadmaps are regularly processed through consumer AI summarization tools by employees who assume the tool operates as a closed system.
HR and contract data: Performance reviews, employment contracts, and correspondence with counsel are among the most sensitive data an organization holds, and are routinely processed through consumer AI tools by teams trying to save time on drafting and summarization.
Mimecast’s State of Human Risk 2026 report found that 80% of organizations are concerned about sensitive data leaking through generative AI tools, while 60% are not fully prepared with specific strategies for AI-driven threats.
What We See in Practice
Sergey Martianov, CPO, ADEX, says the people behind these exposures rarely see themselves as taking a risk:
Most of the time they don’t. For them, it is ordinary daily work: an email thread with a customer, a piece of code, a spreadsheet with numbers, an internal document they needed to summarize quickly. The person is not thinking, “I am handing data to a third party.” They are thinking “I need a summary for a call in ten minutes.”
On whether retained data is a real concern, and what it means for the order of priorities:
The risk is more than real. Free and personal accounts run by default on terms that let the vendor keep the conversations and use them for training. Corporate plans and tools usually come with privacy settings that let you control when and for what purpose the provider may use the data it receives. Moving employees from personal accounts to corporate ones with privacy configured should be the first step, with policy and training coming after it, because those settings only apply to future requests. Whatever was sent before them is already there, and you cannot get it back.
Why Bans Fail
Prohibition policies and network-level blocks on known AI domains are the most common initial response to shadow AI, and neither approach eliminates the underlying behavior. When employees cannot use a tool with corporate credentials, many switch to a personal account, which leaves the organization with the same data exposure and less ability to see it.
The pattern repeats across organizations that have attempted blanket AI bans: usage continues, but through channels the security team can no longer see. Where approved alternatives have been deployed instead, unsanctioned tool use tends to fall, because the need driving the behavior is finally met.
Personal devices are often named as the main escape route. Martianov treats that as a basic access control question rather than an AI one, and says the warning signs usually come from comparing what people produce with what they were actually given:
The starting point is that there should be no way to work with corporate data on personal devices at all. That is a baseline requirement, and it does not depend on whether we are talking about AI or anything else. If it holds, the move to personal devices largely stops being a scenario.
Spotting that an employee is still using something unsanctioned is fairly straightforward. We keep a record of every corporate account and every approved provider, so we always know who has been given which tool. If an employee is clearly showing work processed with AI, presentations, texts and so on, or says so directly, and either that provider was never approved or the employee never received an account, that is the point to start looking into it: how it happened, on which device, and what data went in.
What a Mature Shadow AI Policy Looks Like
A governance program that works runs on four components, none of which is a ban. The order matters: until employees have an approved option, no restriction will hold.
Step 1: Give employees an approved tool first.
Buy corporate licenses for one or two capable services, sign a data processing agreement, and configure the privacy settings that control whether and how the provider can use the data it receives. Those settings only protect requests made after they are switched on, so moving people from personal to corporate accounts comes before policy documents and training.
The approved tools must match the consumer alternatives employees already use. A sanctioned option that cannot compete on capability will not be followed.
Step 2: Define what never goes into a prompt.
Most shadow AI policies skip this layer, and it is the most operationally important one. Keep it to one short list that applies to every AI tool and fits on one screen: passwords and API keys, database dumps, scans of identity documents, personal data, code from private repositories, data covered by attorney-client privilege, and data subject to sector-specific regulation. Everything outside the list can go into approved tools.
One security team framed the rule as: if you would not paste this into an email to a stranger, do not paste it into an AI prompt. That is not a complete policy, but it covers most of the highest-risk cases without requiring employees to consult a document.
Step 3: Inventory real usage and build out the approved list.
Next, find out how AI is actually used: which tools are in active use, by which teams, for which tasks, and what people are missing in the approved options. This requires technical visibility into browser activity, network traffic, and application usage at the endpoint level, checked against a record of which accounts and providers have been issued to whom. Asking managers will not produce an accurate picture. Organizations that run this exercise often find more tools in active use than IT estimated.
The findings work as requirements for the approved list. A practical tier structure covers three categories: fully approved tools with standard data handling, conditionally approved tools permitted for specific teams or tasks only, and prohibited tools with no compliant configuration path.
Step 4: Train with examples instead of punishment.
Employees creating shadow AI exposure are usually not acting maliciously. They are trying to work faster without enough information about what happens to the data. Using an unsanctioned tool with corporate data is still a violation and each case needs to be reviewed, but a punishment-first response drives the behavior underground.
Effective training is specific: it uses the kind of data each team handles every day and ends with the approved tool that does the same job.
For a company that has no shadow AI policy at all, Martianov puts the first moves in this order:
First, give people a proper tool. Buy corporate licenses for one or two decent services with a data processing agreement and tell people to use them. Until there is an approved option, any ban is pointless.
Second, write a short list of what must never be sent anywhere. Not forty pages of policy, ten lines: passwords and keys, database dumps, passport scans, personal data, code from private repositories. Everything else can go into approved tools. The list has to fit on one screen, otherwise nobody will read it.
Third, find out how AI is actually used in the company: which tasks people solve with it, which tools they use, and what they are missing in the approved ones. This is essentially requirements gathering. The list of approved providers is built on top of it, and that is what makes the list practical rather than formal: it contains what people really need.
–– Sergey Martianov, CPO, ADEX
On making that list stick:
The list of data that must not go into any AI tool has to be short and the same for every service, otherwise people get lost in it quickly. It is better explained through examples from a specific team’s work than in general terms: show developers code with a token inside, sales a spreadsheet with customer contacts, HR a document with personal data. That way the person recognizes their own everyday work in the rule instead of an abstract prohibition. And it is worth saying separately that whenever in doubt, they can ask security and get a quick answer. If asking is hard, people decide on their own, and not always correctly.
–– Sergey Martianov, CPO, ADEX
The Visibility Argument
Security teams that have worked through shadow AI incidents tend to arrive at the same position: a visible risk is manageable and a hidden one is not. Knowing that employees are using an unsanctioned tool gives the security team a response path, covering what data is being entered, where controls can be applied, and how to replace the tool with a sanctioned alternative. Without that knowledge, the first signal is typically a breach.
The most mature organizations treat shadow AI as a visibility problem first, building a complete picture of how AI is used across the organization so that risks can be understood, prioritized, and addressed in order of actual exposure. Violations still get reviewed, but the review starts early instead of after the damage is done.
Knowing is better, of course. Visibility does not change the fact that using an unsanctioned tool with corporate data is still a violation, and such cases need to be looked into regardless. The question is whether we learn about it right away or later, from someone else, when all that is left is to record the consequences.
That requires technical tooling that shows which AI services are actually in use in the company, and a record of what is approved and who has been given what. Without the tooling, the record is just a list on paper; without the record, there is nothing to compare the data against. And employees need a way to tell us themselves that they are using something unsanctioned or that they are missing a tool. Often that is the fastest way to find out about a problem.
–– Sergey Martianov, CPO, ADEX
FAQs about Shadow AI
What is shadow AI?
The use of AI tools by employees without IT approval or security oversight, including personal accounts on public AI platforms, browser extensions with AI capabilities, AI features embedded in SaaS tools that were not part of the original procurement decision, and AI-powered automation workflows built by business users without security review.
Why is shadow AI more dangerous than shadow IT?
Shadow IT leaves data on an external server, and the remediation path is straightforward: require deletion, revoke access. Shadow AI creates a different problem entirely. Data enters a model as an input and may be retained or incorporated into future outputs, with no reliable deletion path once it has potentially been absorbed into a third-party model.
What data is most commonly exposed?
Customer records and PII, source code and technical documentation, internal strategy and financial documents, and HR and contract data. These categories come up most often because they are what employees most frequently need to process quickly, making them the most likely to be entered into the nearest available tool.
Do AI usage bans work?
Not on their own. Without an approved alternative, usage moves to personal accounts where the organization has no visibility. Where organizations have provided approved alternatives that compete on capability, unsanctioned use tends to fall. The lever is product availability, not policy strictness.
What should a shadow AI policy include?
At minimum: approved corporate AI tools with privacy settings configured, a short list of data that never goes into any prompt, an inventory of actual AI usage that shapes the approved list, and training built on examples from each team’s own work.
Who owns shadow AI governance?
Across security, IT, compliance, and HR. Security owns detection and monitoring. IT owns tool provisioning and approved alternatives. Compliance owns data classification rules and vendor agreement review. HR owns the training program and the cultural response to incidents. Without clear ownership across all four, governance tends to stall at the policy document stage.
Final Thoughts
Shadow AI does not resolve itself over time. The surface area grows every month that visibility and governance infrastructure are not in place, and the remediation cost grows with it.
The organizations that handle this well are not the ones with the strictest AI policies. They are the ones that built an accurate picture of what was actually happening, gave employees sanctioned tools that competed on quality, and made the data classification rules simple enough to follow without consulting a lawyer. The organizations that get this right are not waiting for a breach to tell them where the problem is.