
Shadow AI refers to the use of AI tools and generative AI by employees for work purposes without the approval, oversight, or governance of IT or security departments. Drafting emails, summarizing meeting minutes, analyzing data, creating documents — in many organizations, AI adoption is already spreading not from executive-level planning, but from individual employees who have simply started using it on their own.
This article is intended for those responsible for information systems, security, compliance, and management. Drawing on guidance from IBM, Microsoft, NIST, and CISA, it organizes what Shadow AI is, why it occurs, where the dangers lie, and how to address it. By the end, the goal is to shift the question from "Should we ban AI entirely?" to "How can we enable its safe use?"
Shadow AI refers to AI usage that proceeds outside an organization's awareness and control. While it may seem like a new problem, it is in fact an extension of the long-standing issue of "Shadow IT."
First, it is worth clarifying the scope of what Shadow AI refers to and how it differs from traditional Shadow IT. A clear definition of the term will make the risk structure discussed later easier to understand.
IBM defines Shadow AI as AI and generative AI tools used outside organizational control, without the approval or oversight of IT or security departments (IBM, "What is shadow AI?"). The key point lies not in "the use of AI" itself, but in "usage that is invisible to the organization."
Concretely, all of the following fall under Shadow AI:
None of these involve "formally deploying software," so they leave no trace in asset management records and remain off the IT department's radar. Because AI can be put to use in just a few clicks, a significant gap emerges between what the organization is aware of and what is actually happening on the ground.
Shadow AI is a form of Shadow IT (the use of unauthorized software and services), but the nature of the risk differs. With traditional Shadow IT, the primary concern was the introduction of unapproved tools. Shadow AI, by contrast, involves tools that not only read data, but also make judgments, produce summaries, generate text, and sometimes integrate with external data sources.
What makes Shadow AI more troublesome than Shadow IT is not only the question of where inputted data ends up, but also the fact that AI-generated output can become embedded in business operations.
| Dimension | Traditional Shadow IT | Shadow AI |
|---|---|---|
| Primary target | Unauthorized apps and SaaS | Unauthorized AI tools and AI agents |
| Primary risk | Data storage and access management | Data input + AI output + external integration |
| Data handling | Centered on storage and sharing | May be used for training, regeneration, and inference |
| Detectability | Relatively easy to detect | Difficult to detect via browser extensions or API calls |
| Scope of impact | Data leakage, costs | Leakage + misinformation entering operations + compliance |
IBM also characterizes Shadow AI as a "subset" of Shadow IT, while noting that the damage to data security, compliance, and reputation is considerably greater.
The primary reason Shadow AI spreads is that AI is "fast, accessible, and delivers results." When no official channels are provided, employees find their own tools.
Here, we examine the structure behind the emergence of Shadow AI from two angles: the motivations of frontline employees and the shortcomings on the organizational side.
There are three main reasons why Shadow AI occurs.
The first is ease of use. Many AI tools can be up and running within minutes from a browser or existing app. No installation or approval requests are required.
The second is speed of results. Once employees experience firsthand how AI can noticeably accelerate tasks like drafting emails, summarizing meeting minutes, or analyzing spreadsheets, seeking approval or checking policies starts to feel like "waiting through red tape."
The third is the absence of sanctioned alternatives. If an organization has not provided options specifying "you may use this tool for this task," people on the ground will find their own means to get the work in front of them done.
One survey cited by IBM found that while approximately 80% of U.S. office workers use AI for work, only 22% use exclusively the tools designated by their employer (IBM, "Is rising AI adoption creating shadow AI risks?"). Similarly, a 2025 IDC study reported that 56% of employees use unsanctioned AI tools at work, while only 23% use tools provided and governed by their organization. Setting aside the precise figures, the trend is clear — unless official channels for AI are established, people will create their own.
Another defining characteristic of Shadow AI is that it spreads not as an IT department "implementation project," but through the individual actions of each employee. Having AI summarize a presentation, fix code, or draft a contract — these behaviors have already become routine before anyone has granted permission.
On this situation, Microsoft notes that organizations often have no visibility into which AI apps are being used, by whom, and in what ways, and argues that the starting point for addressing the issue should be "discovery" rather than "prohibition." In fact, Microsoft has added a "Shadow AI" feature (in preview) to the Microsoft 365 admin center to help administrators identify unmanaged AI agents in use within their organization.
Conversely, many organizations begin from a state of not knowing what is happening. It is more accurate to view this not as an absence of management, but as the result of AI adoption outpacing the development of governance frameworks.
The dangers of Shadow AI are not limited to the introduction of unsanctioned tools. Risks accumulate across five layers: data leakage, lack of visibility, compliance violations, unverified AI outputs, and the expansion into shadow data and shadow models.
Let us examine each in turn.
The most immediate danger is data leakage. When employees input internal data into consumer-facing AI tools, that information moves outside the organization's sphere of control. IBM points out that financial data, trade secrets, proprietary source code, and sensitive business emails can be entered into public LLMs, where they may be retained or used for other purposes.
What is critical here is that the risk does not stop at the level of "one person misusing a tool." If customer data, financial information, or source code is leaked via an unsanctioned AI app, the impact extends to compliance obligations, contractual duties, and privacy incidents.
Indeed, IBM's research reports that data breaches involving Shadow AI carry a significantly higher average cost than those that do not, and that one in five companies has already experienced a breach related to Shadow AI (IBM, "2025 Cost of a Data Breach Report"). A single paste can prove costly in ways that remain invisible until it is too late.
Shadow AI is dangerous precisely because it operates outside the bounds of visibility. If the IT department does not know which AI apps employees are using, it cannot design access controls, data loss prevention (DLP) measures, or monitoring. The assets that need protecting are moving in places that cannot be seen.
From a compliance perspective, the problem runs deeper. Most organizations already have policies in place regarding data residency, privacy, record retention, confidentiality, and industry-specific regulations. Yet when Shadow AI takes hold, employees end up processing data through channels that fall outside the reach of those policies. Both IBM and Microsoft point out that Shadow AI directly creates compliance challenges, precisely because apps that the organization has never evaluated end up handling regulated data.
Even where controls are in place for existing SaaS and cloud applications, newer forms of AI — browser extensions, standalone agents, local model execution environments, and API wrappers — enter through gaps that traditional policies never anticipated. Unless governance is expanded to keep pace with the spread of AI, policy violations become increasingly likely.
The risks of Shadow AI are not limited to "input." They also exist in "output." When employees use AI to generate reports, contract summaries, code suggestions, customer communications, and analysis results—and then use that output without going through approved workflows or human review—AI errors slip directly into business processes.
What makes this particularly troublesome is that these errors are not recognized as "AI risks." Because there is no review layer and no record of where AI output was used in the workflow, AI errors get treated as ordinary human mistakes. The fact that the root cause lies in unauthorized AI use becomes invisible.
IBM further points out that Shadow AI does not appear in isolation. It grows alongside "shadow data" and "shadow models." Unvalidated data, third-party datasets of unknown origin, and models whose provenance no one knows can all coexist within a single workflow. At that point, the risk expands beyond individual applications to encompass data supply chains and model supply chains. It becomes a systemic risk—one that demands answers not only to "who used which app," but to "which data was used, where, and by which model."
The right response to Shadow AI is not to ban AI outright. It is to provide employees with a sanctioned path for using AI safely, while incrementally establishing visibility, control, and governance.
This section outlines where to start in practical terms.
Microsoft recommends addressing Shadow AI through a phased approach. Its guidance, "Prevent data leak to shadow AI," outlines the following four phases:
| Phase | Description |
|---|---|
| 1. Discover | Identify which AI apps are being used within the organization, by whom, and how |
| 2. Block | Restrict access to unsanctioned AI apps |
| 3. Data Protection | Use DLP and sensitivity labels to prevent sensitive data from flowing into sanctioned apps |
| 4. Govern | Continuously control the data being sent to AI |
The key point is not to start with "blocking." Prohibiting tools without first knowing what is being used will only push usage to other channels. The realistic sequence is: first discover, then categorize apps as permitted or prohibited, classify sensitive data and apply controls, and finally establish governance that operates as an ongoing practice.
The NIST AI Risk Management Framework (AI RMF) and CISA's AI security guidance also encourage organizations to treat AI not as a matter of individual applications, but as a risk to the overall system. The underlying idea is to manage trustworthiness, security, privacy, transparency, and accountability in an integrated manner. In practical terms, this means putting in place data governance, access controls, monitoring, human review, and clear accountability—together, as a set. Shadow AI cannot be solved by security tools alone; it requires policy, workflow, and change management to run in parallel.
What many organizations overlook is that "prohibition" alone will not make Shadow AI disappear. If sanctioned tools do not serve the needs of day-to-day work, employees will turn to external tools regardless. That is precisely why the core of any response must be providing a sanctioned path—a safe, approved route for using AI.
In practical terms, organizations should address at least the following four areas:
One point worth emphasizing here: Shadow AI is not a sign that employees are doing something wrong. It is a signal from the organization that the pace of AI adoption has outrun governance. The real question is how quickly the organization can provide a sanctioned path robust enough that employees no longer need to rely on external tools.
Q. What is the difference between Shadow AI and Shadow IT?
Shadow AI is a form of Shadow IT, but AI tools do more than store data—they summarize, analyze, generate text, and integrate with external services. As a result, the impact on data security, compliance, and reputation is greater than with conventional software use. IBM also characterizes Shadow AI as a subset of Shadow IT while noting that the damage it can cause is more severe.
Q. When an organization wants to rein in Shadow AI, where should it start?
The first step is "discover." Identify which AI apps are actually being used, then categorize them as sanctioned or unsanctioned, apply data controls such as DLP, and establish sanctioned workflows that employees can use. The phased approach outlined by Microsoft follows this same sequence. Jumping straight to blocking tends to push usage into channels that are even less visible.
Q. Will banning all AI solve the problem?
In most cases, no. If sanctioned tools do not fit the way people actually work, employees will continue using external tools regardless. A more effective approach is to provide sanctioned alternatives and governance that keeps pace with real-world workflows.
Shadow AI is not simply a story about "employees secretly using AI chat." It is a signal that AI adoption is outpacing organizational governance. The key risks can be organized into five categories: data leakage, lack of visibility, compliance violations, unverified AI outputs, and the expansion into shadow data and shadow models.
IBM, Microsoft, NIST, and CISA all point in the same direction — the way out is not "banning everything," but rather building visibility, policies, safe alternatives, and governance that actually works.
The right question for organizations is not "Can we ban AI?" but "How do we enable employees to use AI without taking data and risk outside the organization?" When that question can be answered clearly, Shadow AI transforms from a risk into controlled AI adoption.
References
(This article is intended for general informational purposes. Please verify the latest product specifications, statistics, and regulatory developments with each primary source. Survey figures cited are based on values published by the referenced sources.)
Chi
Majored in Information Science at the National University of Laos, where he contributed to the development of statistical software, building a practical foundation in data analysis and programming. He began his career in web and application development in 2021, and from 2023 onward gained extensive hands-on experience across both frontend and backend domains. At our company, he is responsible for the design and development of AI-powered web services, and is involved in projects that integrate natural language processing (NLP), machine learning, and generative AI and large language models (LLMs) into business systems. He has a voracious appetite for keeping up with the latest technologies and places great value on moving swiftly from technical validation to production implementation.