Shadow AI Is Already in Your Company. Here's How to Find It.
At my last bank, we ran a network traffic analysis in Q3 2024 and found 14 different AI tools hitting external APIs from employee workstations. Our official AI tool count was three. That gap, 14 versus 3, is shadow AI. And if you think your company is different, you have not looked hard enough yet.
The Scale of the Problem Is Bigger Than You Think
Gartner estimated in 2025 that 75% of employees at large enterprises had used generative AI tools not provisioned by IT. At regulated companies like banks, that number was lower but still alarming. Our internal audit found that roughly 40% of knowledge workers in risk, finance, and compliance had used ChatGPT, Claude, or Gemini through personal accounts at least once for work-related tasks.
The instinct is to clamp down. Block the URLs. Send a memo. That instinct is wrong, and I will explain why. But first, you need to understand what shadow AI actually looks like inside a large org, because it is not just people pasting data into ChatGPT.
Shadow AI has three layers. The first is the obvious one: employees using consumer AI tools through browsers. The second is more subtle: teams embedding AI APIs into spreadsheets, scripts, or internal tools without going through procurement. The third is the hardest to find: business units buying AI-enabled SaaS products where the AI component was not part of the original vendor assessment. That third layer is where the real risk hides.
A marketing team buys a content platform that added AI summarization in a product update. Nobody re-evaluated the vendor. Nobody checked where the data goes when the AI feature runs. The contract predates any AI data handling clause. This is happening in every large company right now.
Why Blocking Everything Makes It Worse
I watched a competitor bank go full lockdown in early 2024. They blocked every external AI tool, banned personal device use for work tasks, and required a 12-week approval process for any AI-related software request. Within 90 days, their top data science hire quit. Two product managers left for fintechs. The people who stayed found workarounds, using personal phones to photograph documents and upload them to AI tools. The risk got worse, not better. It just moved off the network where nobody could see it.
The lesson is straightforward. If your governance approach makes it harder to use AI through approved channels than through unapproved ones, you have built a system that rewards rule-breaking. Your best people will leave and your remaining employees will find workarounds you cannot monitor.
The goal is not zero shadow AI. The goal is visibility and risk-appropriate controls. Some shadow AI usage is low-risk and should be fast-tracked into your approved stack. Some is genuinely dangerous and needs to stop immediately. You need a system that can tell the difference.
The Discovery and Classification Framework
Here is the four-step process I have used at two different banks to get shadow AI under control without destroying morale or productivity.
Step one: Network and endpoint discovery. Work with your infrastructure team to run a 30-day analysis of outbound traffic to known AI service endpoints. This is not just openai.com. It includes API endpoints for Anthropic, Google AI, Hugging Face, Replicate, and dozens of AI-enabled SaaS products. Your CASB (Cloud Access Security Broker) should already have this capability. If it does not, that is a separate conversation with your CISO. At our bank, this 30-day scan surfaced 14 tools. Your number will be different, but it will be higher than you expect.
Step two: Procurement and vendor audit. Pull every SaaS contract renewed or signed in the last 18 months. Have someone, not a junior analyst but someone who understands AI architectures, review the product capabilities. Flag any product that has added AI features since the contract was signed. At one bank, this review found 23 vendors that had shipped AI features post-contract. Nine of those were processing customer data through AI models with no contractual data handling provisions.
Step three: Employee survey with amnesty. This is the step most security teams resist, but it is the most valuable. Send a short, anonymous survey asking employees what AI tools they use for work, what tasks they use them for, and what data they put into them. Pair it with a 60-day amnesty window. No disciplinary action for past usage. You want honest answers, not CYA responses. At our bank, the survey had a 62% response rate. It surfaced three tools the network scan missed entirely because employees were using them on personal devices off the corporate network.
Step four: Risk classification. Take everything you found in steps one through three and sort it into four buckets. Bucket A: low risk, high value. These are tools employees are using for tasks like drafting emails, summarizing public documents, or brainstorming. No sensitive data involved. Fast-track these into your approved stack. Bucket B: moderate risk, high value. These tools touch internal data but not customer PII or regulated data. They need guardrails but should not be blocked. Bucket C: high risk, any value. These involve customer data, financial data, or regulated information flowing to external AI models. These need immediate intervention, either contractual protections or replacement with approved alternatives. Bucket D: any risk, low value. Tools nobody really needs that just add surface area. Kill them.
Building the Ongoing Governance Loop
Discovery is a point-in-time exercise. If you stop there, shadow AI will regrow within 90 days. You need a standing process.
First, add AI-specific questions to your vendor intake form. Every new SaaS purchase should answer: Does this product use AI or ML models? If yes, where does the data go when the model runs? Is data used for model training? Can the AI features be disabled? This adds about five minutes to procurement and prevents the third-layer shadow AI problem I described earlier.
Second, run the network discovery scan quarterly, not annually. AI tools proliferate fast. A tool that did not exist six months ago could have 200 users in your org today. Quarterly scans keep your AI inventory current without creating a permanent surveillance apparatus.
Third, create a fast-track approval lane. At one bank, we set up a 10-business-day approval path for AI tools that fell into Bucket A or B. The old process took 12 weeks. The new one required a lightweight risk assessment, a data classification check, and sign-off from the business unit head and the CISO's delegate. Not the CISO personally. A delegate with authority to approve low and moderate risk tools. This single change cut new shadow AI adoption by roughly 60% in the first quarter because people actually used the approved path.
Fourth, publish a quarterly shadow AI report for your executive team. Not a 40-page document. A single page. Number of tools discovered. Number approved, number blocked, number pending. Top three risk findings. One or two recommendations. Executives do not need the details. They need to know the system is working and where the gaps are.
The companies that get this right treat shadow AI the same way mature organizations treated shadow IT a decade ago. Not as a crisis, but as a signal. When employees go around your systems, they are telling you your systems are too slow, too restrictive, or missing capabilities they need. Listen to that signal.
Free Resource
Want the Complete AI Leadership Playbook?
50+ pages of frameworks, scorecards, and implementation plans from 20+ years of enterprise AI adoption.
Get the Book on KindleActionable Takeaway
Run the 30-day network discovery scan this month. Just the scan. You do not need a full governance framework to start. Get the number. Find out how many AI tools are actually running in your environment. That single data point will fund every conversation you need to have with your CISO, your CRO, and your board.
This article covers a core framework from The Executive's AI Playbook. The complete playbook includes printable scorecards, additional real-world examples, and full implementation checklists.
Get the complete framework →