Ask a CEO how many AI tools are in use across the company and you’ll usually hear about the ones on the invoice. Ask the team anonymously and the list gets longer: free chatbot accounts, browser extensions, meeting notetakers, and AI features switched on inside software you already pay for. The difference between the two lists is what nobody approved.
That gap is what people mean by shadow AI. It isn’t a story about rule breaking. It’s a story about a team that found a faster way to finish and didn’t think to ask, because nothing in the company told them asking was required.
Why the list is always longer than leadership thinks
Three things drive the gap, and none of them involve bad intent.
- The tools stopped being separate products. AI features now ship inside software your company already licenses. A summarize button in the help desk, a reply drafter in the support inbox, a notetaker that joins every customer call. Nobody experiences using those as adopting an AI tool.
- Adoption spreads sideways, not downward. One person finds something useful and shares it in the team channel. Before long it’s how that team works, and it’s invisible from the leadership channel.
- Asking has a cost and using doesn’t. Someone who asks permission risks a no, a delay, or a security review. Someone who just uses the tool faces none of that. The incentives are doing exactly what you’d predict.
The exposure isn't created by the tools. It's created by the fact that nobody can name them.
What’s actually at risk
For a SaaS or AI company the risk is rarely the tool itself. It’s the category of data that moved into it, and the obligations attached to that category.
Most of your customer data is covered by something you signed. Your contracts and DPAs say where it can go and who may process it, and your subprocessor list is often part of the deal. A support transcript pasted into a free chatbot, an account record run through a browser extension, or a customer contract uploaded for a quick summary can put that data with a vendor none of those documents mention. Source code has its own version of the problem: whatever an engineer pastes in to debug a function goes wherever the tool sends it.
Then the question comes back to you. Enterprise security questionnaires have started asking which AI tools touch customer data and what policy governs them. And in SOC 2 terms, an unapproved tool holding customer data is a vendor that never went through your vendor review. “None” is an easy answer to type. It’s a hard one to stand behind when the honest answer is “we don’t know.”
The wider data points the same way. In IBM’s 2026 Cost of a Data Breach Report, 68% of breached organizations lacked the governance to manage AI or detect shadow AI, up from 63% the year before. That isn’t a prediction for your company. It’s an indication of what the insurance market has started pricing.
Why blocking doesn’t solve it
The instinct is to have IT block the domains. It’s a reasonable first move and it’s roughly a third of an answer.
Blocking covers managed devices. It doesn’t cover personal phones, home machines, browser extensions, or the AI features embedded in software you deliberately pay for. More important, it does nothing about the reason the tool was reached for in the first place. The pressure that drove someone to paste a customer’s ticket thread into a free tool at nine at night doesn’t disappear because the domain stopped resolving. It relocates.
Technical controls and process controls solve different halves of this problem. Most companies have one of them and believe they have both.
The map, in four moves
What replaces the guessing is a short, specific exercise. It takes about ninety minutes of leadership time.
1. Ask leadership what they believe
Write it down before you look. Which tools do you think are in use, who approved them, what data do you believe touches them. This becomes the comparison point, and the gap between this answer and the next one is the finding.
2. Ask the team anonymously
Five questions, two minutes, genuinely anonymous, sent under the CEO’s name. Anonymity isn’t a courtesy here, it’s the mechanism. People don’t tell their manager’s manager that they pasted a customer’s data export into a chatbot. They’ll tell a form that can’t identify them, and they do.
3. Map data, not tools
A list of tools isn’t exposure. Exposure is which categories of information moved into which service, under whose account, and whether that vendor trains on what it receives. Customer personal data, support transcripts, account and billing records, contracts, source code, internal working documents. Each one gets a row.
4. Separate this week from this quarter
Every review of this kind turns up a few things you can fix this week at no cost, and at least one that needs real ownership. Naming which is which is most of the value, because the easy ones get done and the hard one stops being ignored on the grounds that everything looks equally large.
The uncomfortable part. The exercise usually surfaces at least one thing leadership would rather not have learned. That's the point of running it now rather than hearing it from an enterprise customer's security team, your SOC 2 auditor, or an underwriter, none of whom will present it as neutrally.
What good looks like ninety days later
Not zero AI use. A SaaS company with zero AI use in 2026 has either a very unusual team or a reporting problem.
What good looks like is a named list of sanctioned tools, a written rule about which data may enter them, a signed acknowledgment from everyone on the team, and a person whose job includes revisiting the list when it goes stale. That’s the whole of it. It’s a smaller piece of work than the anxiety around it suggests, and it turns a question you’ve been avoiding into a document you can hand to anyone who asks, including the next security questionnaire.