What is Shadow AI?

What Shadow AI is, in one sentence

Shadow AI is the use of artificial-intelligence tools inside an organization without the approval, knowledge or monitoring of IT, security or legal. The term descends directly from “Shadow IT”, and the mechanics are the same: the technology arrives at work through the end user’s door, not through the governance door. Shadow AI is the visibility problem; what a company governs is AI as a whole, which is the subject of the guide what is AI governance.

What differs is speed. Shadow IT took months to establish itself, because it required installing something. Shadow AI establishes itself in an afternoon, because it requires only a browser tab.

It is worth saying this early, because it changes how you treat the problem: the employee doing it is almost always trying to deliver better work, not to evade a control. Programs that start with punishment discover that nuance too late.

Why it is not just more Shadow IT

Treating the two with the same playbook is the most common mistake. Three characteristics make AI risk structurally different:

• The data entered may not come back. In classic Shadow IT, a file uploaded to the wrong Dropbox can be deleted. A contract excerpt pasted into a tool whose plan permits training on customer data may already be baked into a model’s weights. There is no delete button for that, and it is precisely the scenario a right-to-erasure provision cannot address after the fact.
• The output enters decisions with no trace. A report, a price or a clause generated by AI and pasted into an official document loses its origin marker at the first copy-paste. When the result is challenged months later, nobody can reconstruct how it was produced.
• Agents act on their own. The current generation of tools does not answer questions: it opens files, browses, calls APIs and chains tasks. A single access granted without review stops being a one-off leak and becomes an autonomous process holding credentials.

The third point is growing faster than the other two. Gartner projects that 40% of enterprise applications will carry task-specific AI agents by the end of 2026, up from under 5% in 2025, which widens the agentic surface considerably.

The size of the problem, in numbers

Shadow AI has stopped being a slide-deck hypothesis. Three independent studies measure the phenomenon from different angles, and it is worth looking at all three before sizing any program.

The first is about prevalence: how many companies already live with this, knowingly or suspecting it.

The second is about cost. In its annual breach study, IBM isolated the incidents where unapproved AI use was involved, and measured what they cost.

The third is about maturity, and explains why the first two numbers exist at all: adoption ran ahead of governance.

Read together, the three sketch the same picture: usage is near-universal, cost is already measurable, and control is the exception. That is why the right response starts with seeing, not with blocking.

The four routes it gets in through

In practice, nearly every case we see falls into one of four patterns, and only the first is the one most companies picture when they think about the problem:

The second pattern is the most underestimated. A meaningful share of AI usage in a company today did not begin with someone deciding to use AI: it began with an already-approved vendor turning on a new feature.

The consequence is subtle and expensive. The vendor inventory stays correct: the tool is there, contracted, assessed. The data processing inventory quietly stops being correct, because what the tool does with the data changed.

The risks, in order of likelihood

It is worth separating risk that is real and frequent from risk that is quoted in slide decks. In the order things actually happen:

1. Confidential data leaking through legitimate use

This is not an attack, it is routine: a contract pasted in to be “summarized”, a payroll spreadsheet uploaded to be “analyzed”, proprietary code sent off to be “refactored”. The person is working.

The data left the perimeter and, depending on the plan in use, may have entered training. IBM’s numbers show this route is also costly: 49% of incidents involving Shadow AI resulted in data loss or compromise and, in 21%, the organization reported paying a regulatory fine.

2. Losing your legal basis for processing

If a company processes personal data and sends it to a third party without that appearing in the record of processing activities, without a mapped legal basis and without a processing agreement, the irregularity is not the leak, it is the processing itself. That becomes a finding even if nothing ever leaks. See the guide on LGPD and AI tools.

3. Invisible operational dependency

Processes come to depend on a tool the company does not know it uses, did not contract and has no SLA for. When the tool changes its pricing or its policy, or goes offline, the team discovers it was infrastructure.

4. Improper use of generated content

Generated text, images or code enter commercial material with no verification of rights or accuracy. The lowest-probability risk and the highest reputational cost.

Why banning does not work

The instinctive reaction is to block the known domains at the firewall and publish an announcement. That fails for three reasons, in ascending order of seriousness:

• Usage migrates, it does not disappear. Blocked on the corporate desktop, the employee uses their personal phone. The work still gets done with AI; the company has only lost the ability to know which AI.
• The list goes stale in weeks. Blocking by domain presupposes knowing the domains. New tools appear constantly, and most real usage sits in the long tail: dozens of small tools, not the famous five.
• The company starts asserting something false. This is the worst of the three. A policy saying “AI use is prohibited” in a company where most people use AI converts a security problem into a documentation-compliance problem: there is now a signed document that contradicts actual behavior, and that document is what the auditor reads.

It is worth being explicit about something that confuses a lot of people: no governance framework (not the LGPD, not ISO/IEC 42001, not the EU AI Act) requires a company to block AI tools. All of them require it to know what is in use, to have made a conscious decision about each item, and to be able to demonstrate that.

Approving with a written policy is compliance. Prohibiting on paper while not knowing what happens in practice is the opposite, and it is where most companies sit today, without realizing it.

How to detect it: three methods and their limits

Visibility comes before policy: you cannot write rules about an environment you cannot see. There are three ways to obtain that visibility, and they are not mutually exclusive:

Each source has different blind spots, and the right mix depends on your environment. The step-by-step version, with five data sources and a seven-day plan to a first inventory, is in the guide how to find out which AI tools your employees use.

None of the three is useful without a catalog behind it: a list of domains and processes known to be AI tools, with a risk classification. Without that, the output is a traffic log, not an inventory. Our AI tool catalog is public and free to browse.

The path, in four steps

Order matters more than speed. Programs that start with the policy rather than the inventory almost always end up rewriting the policy.

• 1. Inventory. Find out what is in use, on which machines and how often. No judgment at this stage: the goal is the map, not enforcement. See how to build an AI-BOM.
• 2. Classify. Each tool becomes allowed, restricted or prohibited, with the reasoning recorded. This is where the catalog and the risk level come in.
• 3. Publish the policy. Short, specific about what kind of data may go into which category of tool, and signed. See the annotated AI usage policy template.
• 4. Monitor and remediate. A prohibited tool detected becomes a task with an owner and a deadline, not a line in a report. That is the difference between a living program and a document in a drawer.

There is a cost argument for not postponing. The same IBM study shows that a breach takes 247 days on average to identify and contain (183 to identify and 64 to contain). Without an inventory of what is in use, that clock starts later.

Frequently asked questions