Shadow AI is unsanctioned use of models and agents under the company’s authority. Staff paste contracts into a consumer chatbot. A team wires an API key into a spreadsheet. A department buys a “copilot” that reads the CRM. None of this is exotic. It is how every other class of shadow IT arrived.

The legal name is already in the EU AI Act. Article 3(4) defines the deployer as the person using an AI system under their authority, except for purely personal use. If the work happens on your time, your devices, your data, or your customers, you are the deployer. A policy that says “don’t” does not change Article 3.

This is not a product brochure for a census appliance. It is how to find the use, decide what stays, and put a control on what stays — without pretending you have seen everything.

Why is discovery the first control?

Because classification, Article 50, DPDP, and every customer contract assume you know what is running.

You cannot mark synthetic output (Article 50(2)) on a tool you do not know exists. You cannot assign human oversight (Article 26, when it applies) to a hiring bot HR bought on a card. You cannot tell a Data Principal, under DPDP section 5, the purpose of processing if the purpose lives in a browser plugin. You cannot hash weights you never saw.

ISO/IEC 42001 starts from context: the systems you develop, provide, or use. NIST’s Map function is the same instruction. An AIMS or an RMF programme with no discovery step is a binder.

Shadow use is also how prompt injection and data leakage skip the security review. The consumer chatbot has no tool budget, no retention, and no contract. LLM01 and LLM02 apply anyway.

What should you look for?

Four classes. Hunt all four or you will congratulate yourself on the first.

1. Consumer and unsanctioned SaaS. Personal ChatGPT, Claude, Gemini, Copilot personal, and the long tail of “AI email” extensions. Signal: outbound HTTPS to known inference hosts, browser extensions, SaaS spend on virtual cards, DLP hits on paste of source code or contracts.

2. Sanctioned platforms used off-label. The enterprise tenant is approved. The use is not. Staff load privilege-marked files into a general copilot, or turn on a connector the security review never saw. Signal: connector audit logs, unexpected retrieval corpora, sharing settings.

3. Embedded models in line-of-business tools. CRM, service desk, HRIS, and coding tools now ship assistants by default. Procurement bought the suite. Nobody listed the assistant as an AI system. Signal: vendor release notes, new API scopes, “AI features” checkboxes in admin consoles.

4. Agents and scripts. Internal automations that call a model and then call a tool — send, write, ticket, deploy. These are the high-impact class (LLM06; ASI01–ASI03). Signal: new service accounts, OAuth grants with mail.send, CI jobs with model keys, “agent” repositories.

A fifth class exists and is easy to miss: models on laptops. A 7B GGUF on an engineer’s Mac is an AI system if it is used under your authority for work. It is also a weight you do not hash and a corpus you do not retain.

How do you discover without a theatre census?

Use the sensors you already paid for. Add one human process.

Network and DNS. Resolve known inference endpoints and the vendors your CASB already classes as generative AI. This finds (1) and some of (2). It will not find an internal agent.

IdP and OAuth grants. List applications with mail, files, and CRM scopes issued in the last year. Anything named “assistant,” “agent,” or “copilot” is in the inventory until proven otherwise.

Cloud and key stores. Search for API keys whose prefixes belong to model vendors. A key in a repo or a serverless function is a system.

Procurement and expense. Unapproved SaaS is still a purchase order or a card. Ask finance for the last two quarters of “AI,” “GPT,” and “copilot” vendors.

Admin consoles of suites you already own. Microsoft, Google, Salesforce, ServiceNow, Atlassian, GitHub. Turn on the usage report. The assistant is often already on.

Ask the departments, in writing. A two-page return: what you use, for what purpose, what data, what tools, who paid. Treat a blank return from a high-risk department (HR, legal, finance, clinical, customer operations) as a finding, not as “none.”

Do not run a credential-stuffing exercise against staff personal accounts. Do not scrape consumer chat histories. Discovery that creates its own DPDP or GDPR incident is not control.

What do you do with a finding?

Three bins. Write the rule down before you hunt, or every finding becomes an argument.

Retire. Consumer tools on regulated data; agents with send/pay and no owner; anything that looks like an Article 5 prohibited practice. Cut the key. Write the date.

Replace. The use is real, the channel is wrong. Move it to an approved tenant, or to a stack you hold, with a tool budget and a log. Give a date. Shadow use that has no replacement will return tomorrow.

Record. The use is acceptable on the current channel. Add it to the inventory: owner, deployer/provider, data classes, tools, Article 50 status, next legal date. Accept residual risk in a sentence. This is how shadow use stops being shadow. It becomes governed use.

A fourth bin — “ignore” — is how you get the incident. If you cannot staff replace, retire or record. Do not leave a known agent in limbo.

What control is enough for what you keep?

Minimum, for any system that stays:

  • a named executive owner
  • a written purpose and data class
  • Article 50 disclosure if it talks to people, unless the interaction is obvious
  • no send/write/pay without a human and a downstream policy (LLM06)
  • logs you can replay
  • a contract or an equivalent custody story (weights you hash, or an API you treat as a service)
  • DPDP/GDPR processor terms if personal data is involved

For uses that fail the leak / swap / outage tests — privileged files, replayable decisions, core processes — sanctioned SaaS is often still the wrong bin. Those belong on hardware you own, with models you hold and hash. That is what a Sovereign Stack is for. It is not required for every summariser.

ASIS is the governance add-on that detects, contains, and proves what a governed stack did. It is not a substitute for the hunt across SaaS and laptops. Do not describe it as a shadow-AI census. Describe it as proof on the systems you have already taken into custody.

What do you tell staff?

A short rule beats a long policy.

“Work data stays in approved systems. Approved systems are on this page. If you need a new one, here is the form. Pasting work into a consumer model is a data-handling breach, same as emailing it to yourself. If you already did, tell us this week — you will not be punished for the report.”

Amnesty for the first inventory is how you learn. Punishment for the first inventory is how you learn later, from a journalist.

Literacy is already an Article 4 duty where the Act applies. Training that only says “AI is powerful” is not literacy. Show the approved list and the three bins.

What do you tell the board?

A count, a trend, and the top five by authority.

“We found 22 unsanctioned uses. 8 retired, 9 being replaced by [date], 5 recorded as approved. Two had mail.send. Those keys are revoked. Next hunt in 90 days.”

No percentage of “employees using AI.” You do not have the denominator. Inventing one is a lie.

If you cannot hunt quarterly, say so and fund it. Shadow AI is not a one-time project. Vendors ship new assistants inside tools you already bought.

What to do next

Turn on the suite usage reports this week. Pull OAuth grants and model-vendor keys. Send the department return. Bin every finding as retire / replace / record. Put send/write/pay on a human gate. Schedule the next hunt.

If the replace bin is full of uses that cannot leave the perimeter, map them in an Architecture Review. That session is for the estate you will take into custody, not for a slide about culture.