Shadow AI: Which Controls Actually Fit Your Company Size

A shadow AI policy written in 2023 assumed the exposure was an employee opening ChatGPT in a browser tab and pasting in a customer list. That is still real, but it is no longer the largest or the fastest-growing vector, and a policy that only addresses it leaves the other three uncovered.

AI features silently switched on inside SaaS tools the company already pays for is the vector most policies miss entirely. Note-taking add-ons, CRM "smart" fields, help-desk summarization, and productivity-suite copilots are frequently enabled by default or auto-enabled on a vendor update, sending data to a model the security team never evaluated — without any new tool being installed and without appearing on a shadow IT inventory built from network egress or new-app-signup detection. Because nothing new was "installed," most inventories miss this vector entirely.

The other three vectors matter too, in roughly descending order of how well existing controls tend to cover them:

Blocking AI domains at the network firewall is the first control most companies reach for, and it fails for three structural reasons that apply regardless of company size.

Answer the questions below to get a starting risk tier and a matched set of controls. This runs entirely in your browser — nothing is submitted anywhere.

Detection tooling falls into four broad categories, and most mid-sized organizations end up combining at least two rather than relying on a single tool.

Vendors in this space are typically grouped by which detection category above they lead with, though most have expanded across categories over time. This is a general orientation, not a benchmarked comparison — evaluate any vendor against your own environment and current pricing before purchasing, since packaging and coverage change frequently in this market.

Detection tooling answers "is this happening?" It does not answer "what should an employee do instead?" — and that second question is the one that actually changes behavior.

An employee who finds a genuine productivity benefit in an AI tool and has it blocked or flagged, with no sanctioned alternative offered, has three realistic options: stop getting that benefit, find a way around the block, or keep using the tool and hope it is not noticed. In practice, a meaningful share of employees choose the second or third option — which is exactly why detection-only programs tend to show a shrinking count of *detected* incidents without a corresponding drop in the underlying unsanctioned usage.

A sanctioned internal deployment — most durably, a self-hosted or locally-run model the security team controls end to end — closes that gap because it gives employees a legitimate answer to "so what do I use instead?" on day one of a new policy, rather than leaving them to route around a rule that offers no replacement. This is the natural bridge between a shadow AI policy and the broader local-LLM deployment literature: see local LLMs vs. cloud APIs for the underlying trade-offs, and on-prem / air-gapped local LLM deployment for what a sanctioned internal deployment actually involves.

An Acceptable Use Policy that only says "do not use unapproved AI tools" is not enforceable in practice, because it gives employees no positive guidance. A workable AUP typically covers the following clauses:

A sanctioned local or self-hosted deployment is a genuinely durable control for one specific problem: giving employees a legitimate alternative to unapproved consumer AI tools. It is not a complete answer to shadow AI, and treating it as one creates a false sense of coverage.

Local deployment does not address AI features already embedded inside SaaS tools the organization does not control. If a CRM vendor enables an AI summarization feature server-side, running your own model in parallel does not change what that vendor's AI feature does with the data already inside their system — that requires a vendor-contract and DPA-level control, not a deployment decision.

Local deployment does not, by itself, satisfy notice or disclosure obligations to employees or regulators. Running a model on-premises changes where inference happens; it does not automatically create the internal AI-literacy training, the works-council or employee consultation, or the regulatory filing that some jurisdictions require regardless of where the model runs — see the Jurisdiction Notes section below for concrete examples where this distinction matters in practice.

In the United States, shadow AI is not governed by a single dedicated federal statute. It falls under the existing data-security and vendor-risk-management framework: state data breach notification laws, sector-specific rules where applicable (HIPAA for health data, GLBA for financial institutions), and the FTC's general unfairness and deception authority where AI-driven data handling causes consumer harm. This is a practical consequence of how the exposure is legally characterized in the US — as a data-security and third-party-risk problem rather than an AI-specific one — not an exhaustive list of every law that could apply to a specific company's facts.

A secondary consideration for US-headquartered companies with EU operations or EU customer data: the EU points below apply in parallel, and the works-council sequencing issue is easy to miss for a US-based security team building a rollout plan on a US timeline.

This section is general orientation, not legal advice — confirm applicability with counsel for your specific jurisdiction, industry, and data types before finalizing a policy.