The term "shadow AI" frames the issue as a behavior problem, as though employees are doing something they know is wrong. Most of them are not. They found a tool that makes them faster, it is available in the browser, and no one told them not to use it. The behavior is rational. The risk is real regardless of intent, and it lands on security teams who were not consulted before the tool appeared in the browser history.
What security teams actually need is not a way to characterize employee behavior. It is a framework for identifying which teams and workflows carry the highest concentration of data risk, before an incident makes the mapping for you.
Why Usage Surveys Undercount by a Significant Margin
When organizations survey employees about AI tool usage, the results typically reflect tools people recognize as AI tools: ChatGPT, Claude, Copilot. They undercount browser extensions with embedded AI assistants, AI-integrated features inside approved SaaS tools, and any tool employees access from a personal device or personal account during work hours.
A more reliable approach is to audit outbound DNS queries and proxy logs for AI provider domains. The list of active AI service destinations in a 200-person company consistently surprises security teams. The common pattern is a handful of known, org-approved tools accounting for the majority of volume, and a longer tail of five to fifteen unapproved services accounting for a minority of requests but containing disproportionate surface area for sensitive data exposure.
The tail services matter because they frequently lack the data handling agreements, no-training commitments, and usage logging that security teams use to scope AI vendor risk. A customer support rep using a niche AI writing assistant to draft ticket responses may be transmitting customer PII to a vendor that has never been evaluated, has no security review on file, and processes data under default consumer terms.
Mapping by Team, Not by Headcount
Not all employees carry equivalent prompt-data risk. The risk concentration varies substantially by function, and the distribution matters more than the total headcount.
Customer support teams are consistently the highest-risk cohort in the organizations we work with. Their core workflow involves ingesting customer data and generating responses, which maps directly to the pattern of pasting context into an AI tool for drafting assistance. A support agent at a company handling healthcare billing questions can put PHI into a prompt without recognizing it as protected data. The data type and the regulatory exposure are real regardless of the agent's intent or knowledge.
Software development teams carry different but equally serious risks. The dominant pattern is developers using AI assistants for code generation, debugging, and documentation. What gets transmitted is often not just the code being debugged but the surrounding context: imported libraries with version pins, configuration stubs that include environment variable references, and internal API patterns that constitute IP even if no secrets are directly embedded.
Sales and account management teams generate CRM-related exposure. The workflow involves translating structured CRM data into communications: call prep notes, email drafts, account summaries. Each of these involves pasting structured customer data into a prompt. A CRM record has enough personal data fields to trigger GDPR obligations under the third-party processor model, and the AI tool is operating as an uncontracted processor in most configurations.
Finance and HR teams have lower prompt volume but higher sensitivity per prompt. A finance analyst asking an AI to summarize a revenue report may paste figures that are material non-public information. An HR team member asking for help drafting a performance note may include employee data that is regulated under different legal frameworks depending on jurisdiction.
The Risk Matrix You Need Before Your Next Board Update
A practical shadow AI risk map plots two dimensions: prompt volume and data sensitivity. Teams with high prompt volume and high data sensitivity (typically customer support, sales, development) need detection controls first. Teams with low volume and lower sensitivity can be addressed through policy communication.
Populating this matrix does not require surveying employees. Proxy logs and DNS telemetry give you volume by department. Your existing data classification policies tell you which teams handle which data categories. The intersection of those two data sets produces a risk heat map that is more defensible in an audit than a usage survey.
The practical sequence: pull AI provider destination traffic from your proxy or CASB for the last 90 days, aggregate by user or organizational unit, and classify each team against your data sensitivity tiers. Flag any team in the top quartile of AI tool usage that also handles regulated data categories. That intersection is your immediate governance priority.
Shadow Tools vs. Shadow Usage on Approved Tools
It is worth distinguishing two distinct sub-problems that often get conflated under "shadow AI."
Shadow AI tools are unapproved applications: tools that have not been evaluated, procured, or contracted by IT or security. These are the easiest to enumerate via traffic analysis and carry the most straightforward governance action: evaluate, approve with controls, or block.
Shadow usage on approved tools is harder to address and often larger in volume. When an organization approves ChatGPT Enterprise but does not specify which data categories are permissible in prompts, employees are using an approved tool in ways that were never evaluated. The tool is visible in your approved application inventory. The specific usage pattern, pasting customer records for drafting assistance, may never have been assessed when the tool was approved.
Addressing shadow usage on approved tools requires prompt-level visibility, not just application-level approval decisions. An approved tool designation does not tell you what goes into the prompt. That visibility requires a layer that operates on prompt content directly.
What a Reasonable Governance Posture Looks Like at 100-300 Employees
At the size range where this problem is most acute, a governance posture does not need to be comprehensive on day one. The goal is proportionate coverage: controls that address the highest-concentration risk in the time available.
Start with detection before policy. It is genuinely hard to write a prompt-data policy without knowing what employees are currently sending. A detection pass that classifies prompt content over 30 days gives you the data to write a policy that matches actual behavior rather than hypothetical risks. Policy written without this data tends to either over-restrict in ways that generate friction, or under-restrict by missing the categories that are actually flowing.
Address the high-risk cohorts explicitly. Customer support and development teams need prompt-level controls sooner than most other functions. A targeted rollout of inline inspection for those teams, before you have visibility across the full organization, creates meaningful risk reduction while keeping the governance program tractable.
Build the inventory continuously, not as a one-time project. New AI tools appear on a rolling basis. A point-in-time shadow AI audit is stale within weeks at the current pace of AI tool proliferation. Continuous DNS and proxy monitoring, with alerting on first-appearance of new AI service destinations, is more durable than any periodic survey.
The Assessment Is Not the Hard Part
Most security teams, once they run the traffic analysis and build the risk matrix, find the assessment easier than expected. The destination list, the volume distribution, and the team-level data sensitivity map are all available from existing infrastructure. The hard part is not identifying the risk concentration. It is having the detection layer in place that tells you what is actually in the prompts, rather than inferring it from who is sending them.
We are not claiming that prompt content inspection is sufficient by itself. Risk mapping at the team and workflow level is necessary context for making detection policy decisions that are calibrated rather than blanket. The two work together: team-level risk mapping tells you where to prioritize, prompt-level inspection tells you what is actually happening. Neither one alone closes the gap.