Find the Shadow AI Your Team Already Uses — With Amnesty, Not a Witch Hunt

Workflow area: Policy & Governance · Tier: Core · Hands-on time: ~30 minutes

Shadow AI is not a discipline problem; it is a demand signal. An engineer paying for a tool out of pocket is telling you the approved stack has a gap worth their own money. Treat discovery as enforcement and the tools go underground where you can neither govern nor learn from them; treat it as market research with amnesty and you get the only accurate inventory you will ever collect — plus a shortlist of tools your engineers have already evaluated for you.

When to use — and when not to

• Use it before writing or revising the AI policya policy drafted against an imagined tool landscape bans things nobody uses and misses everything they do.
• Use it when the approved stack feels underusedlow official adoption alongside obviously AI-shaped output means the real usage is happening somewhere you cannot see.
• Use it on a six-month cadencethe tool landscape turns over fast enough that January's inventory is fiction by July.
• Skip it mid-crackdownif someone was just disciplined over tool use, amnesty framing will be read as a trap; repair trust first or the survey measures fear, not usage.
• Skip network-surveillance shortcutsDNS logs and browser monitoring will find tools and destroy the trust that makes the inventory honest; use spend and survey signals first, and touch traffic data only with security, works-council, and privacy sign-off.

The recipe

1. 1.

   Announce the amnesty before asking anything. One message, three commitments, in writing: nothing disclosed in this survey will be used against anyone; the goal is to approve more tools, not ban more; results will be shared back with the team. Then honor all three visibly, because you only get to run this play as many times as you keep the promises.

2. 2.

   Run a short anonymous survey. Five questions, genuinely anonymous (no "optional" name field):

   Copy

   1. Which AI tools do you use for work in a typical week — approved
      or not? (free list)
   2. For each: what task does it do better than our approved stack?
   3. What data have you needed to put into it to make it useful?
      (code / logs / customer data / internal docs / none)
   4. What are you paying out of pocket, if anything?
   5. If you could get one tool approved tomorrow, which and why?
   

   Question 3 is the risk map; question 5 is the roadmap. Expect the honest answers to arrive only if question 3's options carry no visible alarm.

3. 3.

   Pull the spend signals. Ask finance for 12 months of expense lines and SaaS-spend or card transactions matching AI vendors — and ask your IT/SSO admin which OAuth grants employees have self-approved to third-party AI apps. Spend catches what surveys miss (the tool someone forgot they expense); OAuth grants catch what spend misses (free tiers).

4. 4.

   Merge the signals into an inventory with Claude.

   Copy

   Here are anonymized survey responses [PASTE] and a vendor spend
   extract [PASTE]. Build a shadow-AI inventory table: tool / user
   count signal (survey vs spend) / tasks it serves / data exposure
   reported (from survey Q3) / monthly spend signal / overlap with
   approved stack (yes, partial, none).
   
   Then output two shortlists:
   - FAST-TRACK: high usage, low data exposure, fills a real gap.
   - RISK-FIRST: any tool where customer data, client code, or
     credentials were reported as inputs.
   Do not attempt to identify individuals from the data.
   

   Sample of the output that matters:

   Copy

   FAST-TRACK: transcript-summarizer X — 9 users, docs only, no
     approved equivalent. Candidate for pilot (pb-35).
   RISK-FIRST: free-tier chatbot Y — 6 users report pasting client
     code; consumer terms allow training on inputs. Needs an
     approved substitute BEFORE any restriction lands.
   

5. 5.

   Close the loop as policy, not punishment. Within two weeks of the survey, publish back: the inventory summary, two or three tools entering evaluation (pb-35), and for each risky tool the approved substitute plus a sunset date. The order is the whole message — substitute first, restriction second. Banning a tool while offering nothing is how you re-create shadow AI with better camouflage. Feed the data-exposure findings straight into the pb-31 leakage class and the pb-28 gates.

Make it yours

• Small team or startup: skip the formal survey; run it as a round-the-table amnesty conversation in a team meeting — "what are you actually using, and what should we just pay for?" — and write the inventory on the spot. The spend pull is one search of the company card statement.
• Large org or GCC: run the survey per org unit with results aggregated (minimum group size before reporting, per pb-38), coordinate with security so discovery and any traffic-level checks are one announced exercise rather than two surprises, and check client contracts before fast-tracking anything — a tool fine for internal code may be prohibited on client engagements (pb-33).
• Regulated environment: pre-clear the survey with privacy/works council where required, and treat any reported exposure of regulated data as a pb-31 incident to assess — under amnesty for the reporter, without exception, or this is the last honest survey you run.

Quality check

• The survey found tools spend didn't, and vice versafull overlap between the two signals means one of them is not being answered honestly.
• At least one tool got fast-trackedan inventory that produces only restrictions confirms every suspicion the amnesty message tried to defuse.
• Risky tools got substitutes before sunsetscheck the dates; restriction-first ordering is the play's one unforgivable error.
• Nobody was identifiedaudit your own process: if any step could tie a survey answer to a person, fix it before the next cycle, because someone will ask.
• The six-month repeat is calendaredand the second cycle's participation rate is your true score; it only holds if round one's promises held.