Shadow AI Governance

Shadow AI is AI tool use inside an organization that IT, Legal, or Risk have not approved and often do not know exists. It is the AI-era successor to shadow IT, but it arrives through more channels than an employee just signing up for a free chatbot. Three distinct vectors produce it: individual adoption of external tools (an employee pasting text into a consumer AI app, a team wiring an AI browser extension into its workflow), AI features that a SaaS vendor quietly enables inside a tool the organization already approved (Microsoft 365 Copilot, Salesforce Einstein, and similar additions to existing procurement agreements), and client-side AI scripts embedded in a vendor's web application that run in the user's browser without ever touching the organization's own network. Only the first vector looks like a policy violation. The other two happen to compliant employees using approved tools.

Shadow IT required an employee to install something, request a budget line, or ask IT for access, each a friction point where the activity could surface. Shadow AI mostly does not. A browser-based AI tool needs no installation and no admin rights. A vendor turning on a new AI feature inside software already running in production requires no action from the customer at all, and no new procurement review gets triggered because nothing was newly procured. The result is that a meaningful share of shadow AI exposure is not rule-breaking by employees; it is AI capability arriving through the software supply chain the organization already trusted, exactly the vector the PRC-014 shadow AI control exists to catch.

The structural risk comes first: you cannot classify, monitor, or report on an AI system you do not know exists, which makes shadow AI the gap underneath every other control. A data governance program built on an incomplete inventory has an unmeasured hole in it by definition, and an incident response plan has a blind spot exactly where an incident is most likely to originate. The data-handling risk is more immediate: consumer-grade AI tools generally carry none of the contractual data-handling terms an enterprise vendor agreement would require, so sensitive input pasted into one has no enforceable retention, training-use, or deletion guarantee. The embedded-feature vector adds a third risk that is easy to miss: when a SaaS vendor's AI feature processes personal data, that AI subsystem is functioning as a data processor under GDPR and CCPA, which means an existing vendor agreement that predates the AI feature may no longer have adequate data-processing terms, and nobody re-reviewed it because nothing about the vendor relationship appeared to change.

No single method surfaces all three vectors, so effective detection combines three. A vendor contract and feature-announcement review catches the embedded-feature vector: assume vendors in the productivity, communication, and CRM categories have added AI capabilities unless confirmed otherwise, and request AI feature disclosure as part of the annual vendor review. An employee survey that offers amnesty for undisclosed tool use, paired with a clear path to get a tool formally approved, catches individual adoption more reliably than a policy memo does, since the goal is visibility, not enforcement, at the discovery stage. Endpoint and network monitoring catches the rest: endpoint management tooling can inventory browser extensions across managed devices and flag ones with broad site-data or clipboard permissions, while content-security-policy or web-application-firewall logging surfaces client-side scripts loading from AI-associated domains. The AI system inventory and risk classification playbook walks through running these in parallel rather than sequentially, since each method finds systems the others miss.

A blanket ban is the least effective response, because the tools that created shadow AI in the first place require no IT involvement to keep using quietly; a ban mostly removes the organization's visibility into usage it was already struggling to see. The more durable response is the same one applied to any newly discovered AI system: run it through risk classification based on data sensitivity, decision impact, and regulatory exposure, then route high-value shadow tools into a fast-track approval path instead of leaving employees to choose between an unapproved tool and no tool at all. For the embedded-feature and browser-extension vectors specifically, that means the PRC-014 control's maturity model: an allowlist and blocklist for AI-capable browser extensions, a review of vendor agreements for adequate data-processing terms once an embedded AI feature is confirmed, and a cadence for repeating the scan as vendors keep shipping new AI features into tools already in production.

An AI system being unauthorized does not create a compliance exemption for it. GDPR and CCPA data-processor obligations attach to personal data processing regardless of whether Legal ever approved the tool doing the processing. The EU AI Act's risk-tier obligations attach to what a system does, not to how it was procured, so a high-risk use case does not become lower-risk because it arrived through an employee's personal account instead of a signed vendor contract. Sector-specific rules carry the same logic forward: a financial institution's model risk framework or a healthcare organization's clinical AI oversight requirements do not carve out systems just because they were adopted informally. Shadow AI shifts when an organization discovers its obligations, not whether it has them.