Nobody Broke the AI Policy. There Wasn't One.
Shadow AI is not a story about reckless employees. It is a story about capable people solving real problems with tools that arrived faster than any review process, and about obligations — contractual, statutory, evidentiary — that attach to the data regardless of who approved the tool.
Four Liabilities, Four Different Trigger Conditions
"Shadow AI risk" is usually discussed as one undifferentiated worry. It is really four distinct exposures with different triggers, different claimants and different timelines. Sorting them is what makes the problem tractable, because only one of them is live on day one.
Where It Actually Lives
The mental image of shadow AI — someone pasting a spreadsheet into a chatbot on their phone — describes the smallest and most visible category. The larger volume sits in places that do not look like adopting a new vendor at all:
- Features inside approved software. A vendor you already reviewed ships an AI summarisation feature and enables it by default. Your original assessment covered a product that no longer exists, and no procurement event occurred to trigger a re-review.
- Browser extensions. Page-summarisers and writing assistants read the DOM of every page the employee opens, which includes your admin console, your CRM, and any customer record displayed in it.
- Meeting note-takers. They join as participants, are frequently invited by the most senior person in the room, and record conversations that include personnel matters and unreleased financials. In two-party-consent states the recording question is separate from the AI question and arrives first.
- Individually installed code assistants.Developers configure these per-machine. The relevant question is not the completion quality but whether proprietary source is transmitted and retained, and under whose account.
- Automation and agent platforms. A low-code workflow built by an operations team can move records between systems at volume under credentials nobody audited, and it does not appear in any software inventory.
Discovery That Does Not Depend on Self-Reporting
Ask people to list the AI tools they use and you will get the two everyone has heard of. This is not dishonesty — an employee who turned on a summarise button inside an approved application does not believe they adopted an AI tool. Use records you already hold instead, in roughly this order of yield:
- Corporate card lines under $50 — the individual-seat price point where most adoption happens without procurement
- Expense reimbursements categorised as software, subscriptions or professional development
- Annual charges that renewed silently after a trial someone forgot about
- App store and marketplace purchases inside your cloud or productivity suite billing
- OAuth grants and third-party app connections in your identity provider — this is the single highest-yield source
- Applications with read access to mail, files or calendar granted by individual users
- Service accounts and API keys created outside the normal request path
- Sign-ins to unfamiliar SaaS domains using company single sign-on
- Browser extension inventories from device management, filtered for anything with broad host permissions
- Locally installed developer tooling and editor plugins
- DNS and egress logs for known provider API endpoints, which catch integrations rather than web use
- Calendar invitations listing non-human participants
- Recurring meetings where a transcript document appears afterwards in shared storage
- Documents and tickets containing prompt text, which indicate a workflow rather than a one-off
- Shared links to provider conversation URLs pasted into chat
Triage: Not Everything You Find Is a Problem
An inventory with sixty entries and no ranking produces paralysis. Sort by the data that reaches the tool, not by the tool's reputation or the size of the vendor. Three questions separate the list quickly.
- Does customer content reach it? If yes, the contractual exposure is live and this is a today problem. If only internal and non-sensitive material reaches it, it is a policy and cost question, not an incident.
- Is there a contract between the provider and the company? A personal account with consumer terms means no confidentiality commitment runs to you, no service provider restriction under CCPA, and no ability to compel deletion. This distinction matters more than which provider it is.
- Is the data category regulated? Health information, financial account data, biometric identifiers and information about minors each carry their own regime with its own notice and consent mechanics. A voice note-taker in Illinois is a different conversation from a writing assistant.
The Amnesty Window
The most common failure in a shadow AI programme is enforcing before inventorying. The moment the first person who volunteered a tool gets a formal warning, disclosure stops, and every subsequent discovery has to come from logs.
A workable sequence is short and explicit: announce a fixed window in which anyone can register a tool they use with no consequence, publish the resulting approved list along with a genuinely usable path for requesting additions, and only then begin enforcing. The list has to include real approvals — a programme that answers every request with no simply relocates the behaviour rather than ending it. What people need is a sanctioned way to do the thing they were already doing, which is why the approved list matters more than the prohibition.
What the Policy Has to Say
A policy that says "use AI responsibly" is unenforceable and provides no defence. The parts that do work are specific about data rather than about tools, because the tool list changes monthly and the data categories do not:
- Named prohibited categories. Customer personal data, unreleased financials, credentials, personnel records, and anything under third-party confidentiality obligations — stated as categories, with examples.
- A company-account requirement. Where a tool is approved, use runs through a company tenant, not a personal login. This single rule converts most of the contractual and evidentiary exposure into something manageable.
- A review trigger for new features. Enabling an AI capability in existing software counts as adopting it, and requires the same check.
- A human accountability line. Output used in a customer-facing, legal or financial context is the responsibility of the person who shipped it, not the tool.
- A named owner and a real request path. Someone answers requests within a stated number of days. Without this, the rest is decorative.
Frequently Asked Questions
What actually counts as shadow AI?
Any AI tool processing company or customer data without having gone through whatever review your organisation applies to vendors. That includes the obvious consumer chatbot on a personal account, but the larger share is usually less visible: browser extensions that summarise pages, AI features switched on inside software you already license, meeting note-takers that join calls as a participant, and code assistants installed by individual developers. The defining characteristic is not that the tool is unknown, but that nobody assessed where the data goes.
Is shadow AI a security problem or a legal problem?
Both, and they fail on different timelines. The security exposure is conditional — it becomes damage if the provider is breached or retains data badly. The legal exposure is often immediate and unconditional: if your DPA promises customers a subprocessor list and an employee routed customer content to a provider not on it, you are already in breach of that contract regardless of whether anything bad happens to the data. Most organisations discover the contractual problem first because a customer asks.
Can we just block AI tools at the firewall?
Blocking domains reduces casual use of a handful of well-known sites and does almost nothing about the rest. AI features increasingly ship inside tools already on your allowlist, so the traffic is indistinguishable from sanctioned use of an approved vendor. Personal devices and personal accounts sit outside the network entirely. Blocking is worth doing for the specific providers you have decided against, but treating it as the control is how organisations end up believing they have no shadow AI.
Does an employee pasting data into a chatbot destroy trade secret protection?
It can weaken it materially. Trade secret status depends on reasonable measures to maintain secrecy, and that is assessed on what you actually did, not what your handbook said. Disclosure to a provider under enforceable confidentiality terms is defensible; disclosure through a personal consumer account with no contract between the provider and your company is much harder to characterise as a reasonable measure. The risk is not that secrecy evaporates on contact — it is that opposing counsel gets a concrete example to argue with.
How do we find shadow AI without sending a survey?
Surveys undercount badly because employees do not consider an AI feature inside an approved tool to be a separate tool. The reliable signals are financial and administrative: expense reports and corporate card lines under fifty dollars, OAuth grants and third-party app connections in your identity provider and productivity suite, browser extension inventories from device management, and calendar invitations showing unfamiliar bot participants. Each of these is a record you already hold.
Should we discipline employees we discover using unapproved tools?
Not for use that predates a clear published policy, and not as the opening move in any case. Discovery depends on cooperation, and the first enforcement action against an early discloser reliably ends voluntary reporting. The productive sequence is amnesty and inventory first, a specific and usable policy second, then enforcement against conduct that occurred after people were told. Punishing behaviour that was never prohibited also tends not to survive an employment claim.
Do we have to tell customers what we find?
It depends on what the data was and what you promised. A subprocessor notice obligation in a DPA is triggered by the addition itself, and retroactive notice with an explanation is generally better received than silence that surfaces during a later audit. A breach notification duty is a separate and higher threshold that turns on unauthorised acquisition of specific data types under the applicable statute. Assess them separately; teams frequently conflate the two and either over-notify or miss the contractual one entirely.
How does this interact with a vendor risk assessment we already run?
Shadow AI is the population your existing process never saw, so the useful move is to route discovered tools into that process rather than build a parallel one. The one adjustment worth making is adding a re-review trigger for AI features added to existing vendors, since the standard annual cycle assumes the product being assessed stays roughly constant between reviews, and that assumption no longer holds.
Start With the Contract, Not the Firewall
Of the four exposures, only the contractual one is already failing today, and it is also the cheapest to check: read your standard DPA, find what you promised about subprocessors and notice, then compare that promise against the OAuth grants list in your identity provider. That comparison takes an afternoon and tells you whether this is a governance project or an incident.
Everything else — the policy, the approved list, the enforcement posture — is easier to write once you know which it is.