Shadow AI is the use of AI tools inside an organization without security, legal or IT approval. It usually means staff pasting internal material into consumer chat products, but it also covers AI features quietly enabled inside software the organization already bought, which is the part most inventories miss.

How do we find out which AI tools employees are using?

Four signals in rough order of yield: outbound network and DNS traffic to known AI provider domains, SaaS and identity logs showing OAuth grants and single sign-on to AI products, expense and card data showing individual or team subscriptions, and a direct survey run without disciplinary framing. No single signal is complete, so use at least three.

Is shadow AI a security problem or a governance problem?

Both, and treating it as only a security problem is why remediation usually fails. The security exposure is data leaving the boundary. The governance problem is that people had an unmet need and the sanctioned path did not meet it. Blocking without providing an alternative moves the activity somewhere harder to see.

Should we block AI tools outright?

Blocking alone tends to push usage onto personal devices and personal accounts, where you have no visibility at all. The pattern that works is to provide a sanctioned tool that is genuinely good enough for the work people were doing, publish a clear acceptable use policy, and then restrict the unsanctioned paths.

What should we do with what we find?

Treat the findings as demand signal rather than misconduct. Staff who adopted an unapproved tool have already told you which problems are worth solving and demonstrated they will change behaviour to solve them. That is a stronger signal than any internal survey about desired features, and it should feed directly into use case prioritisation.

How to Detect Shadow AI on Your Network

Every large organization has shadow AI. The only question is whether you can describe it.

The useful framing is not "who is breaking the rules". It is that a group of people found a task painful enough to route around your controls, and they have told you something valuable about where the work actually hurts. Detection is worth doing for the security exposure. It is worth doing twice for the demand signal.

The four signals

No single source gives you the picture. Use at least three.

1. Network and DNS

The highest-yield technical signal. Pull outbound traffic to known AI provider domains from your egress logs, secure web gateway or DNS resolver. You are looking for volume and distribution, not individuals: how many distinct endpoints, which business units, and whether the traffic pattern looks like occasional use or a daily workflow.

Two limitations to plan around. Traffic from personal devices on guest networks or mobile data will not appear, so this undercounts. And a lot of AI usage now happens inside other products, so the destination domain may be a SaaS vendor you already approve rather than an AI provider.

2. Identity and SaaS logs

Often more revealing than network data, and consistently underused.

Look at OAuth grants in your identity provider. Every "sign in with" and every "connect your Google Drive" to an AI product leaves a record, and those grants are the ones that matter most, because they are the path by which a tool gets standing access to a corpus rather than a single pasted document.

Also check for single sign-on to AI products, and any app registrations created by non-administrators.

3. Expense and card data

Search card and expense data for AI vendor names and for recurring charges in the range individual subscriptions fall into. This surfaces team-level adoption that never touched central procurement, which is the category most likely to have become load-bearing for real work.

4. Ask people

The signal everyone skips because the results are politically awkward.

A survey works if, and only if, it is framed as service design rather than enforcement. Ask what tasks people use AI tools for, what those tools do better than the sanctioned option, and what they would need before switching. Do not ask which unapproved tools they use, because you will get a rate of honest answers that makes the whole exercise useless.

Run it anonymously, from a business owner rather than security, and publish something back to participants. That last part is what determines whether the next survey works.

The category almost everyone misses

Build your inventory around tools and you will miss the largest surface: AI features inside software you already bought.

Your CRM, your service desk, your document suite, your code hosting, your meeting recorder. Many of these have added AI features that were enabled by default or by an administrator who read it as a product update rather than a new data processing arrangement.

These are in scope for most regulatory regimes whether or not anyone made a decision to adopt them, and they typically have deeper access to your data than anything an employee pasted into a chat window. Go through your SaaS register vendor by vendor and record which AI features exist, whether they are on, what data they touch, and what the vendor's terms say about retention and training.

Reading what you find

Sort the findings into three buckets, because they need different responses.

Sanctioned-equivalent use. Someone is doing approved-looking work in an unapproved tool. The gap is provisioning, not intent. Fix by providing access to the sanctioned tool and telling people it exists.

Genuine exposure. Regulated data, privileged material or trade secrets going somewhere with unknown retention. This is an incident, and should go through incident response rather than a policy conversation.

Unmet need. A task the sanctioned tooling does not do at all. This is the valuable bucket. It belongs in your use case pipeline with a named business owner, because you have pre-validated demand for it.

What to do next

The sequence that works, in order:

Publish an acceptable use policy. Two pages, written for staff rather than lawyers. In the absence of one, people are making their own.
Provide a sanctioned tool that is actually good enough. If the approved option is materially worse than what people found on their own, the policy will lose.
Register everything in an inventory. Every AI system in use, including the embedded vendor features. You cannot govern what you cannot enumerate.
Then restrict the unsanctioned paths. Blocking first, without steps one and two, moves the activity onto personal devices where you have no visibility at all.

The order matters more than the tooling. Organizations that block first generally end up with a shadow AI problem they can no longer measure, which is strictly worse than the one they started with.

Where to go next

The governance chapter of the readiness playbook covers the policy stack and the inventory in more detail, and Shadow AI: The Hidden Risk in Your Enterprise covers why the exposure matters. For the broader picture see AI governance and compliance.