Shadow AI in the Enterprise: Discover and Manage Unapproved AI Usage

Shadow AI is AI used for work without the organisation knowing or approving it: a personal chatbot account for drafting customer emails, a free website that summarises PDFs, a browser extension that rewrites everything you type, a note-taker that joins meetings. It's the same story as shadow IT ten years ago, with one difference that makes it more urgent: what people paste into these tools is often the most sensitive data the company has.

Shadow AI is rarely bad intent. People use these tools because they help, and because the approved option is missing, slow to get, or not as good. So blocking everything doesn't work. Usage moves to phones and home laptops, where you can see even less.

This post sets out a governance approach in six steps, and tests two pieces of it:

• Discovery from network logs, run on a synthetic month of logs for a fictional company.
• Sensitive-data detection, run on 30 labelled sample prompts, to see what pattern-based data loss prevention (DLP) actually catches.

The Approach at a Glance

The order matters. If you start with blocking (step 5) before steps 1 to 4, you'll block the wrong things, and people will route around you.

Step 1: Discover What's Actually in Use

You can't govern what you can't see. Useful sources, roughly in order of how much they show:

• Web proxy, secure web gateway or firewall logs: which AI domains are contacted, by whom, and how much data is uploaded.
• A cloud app security tool (a CASB, such as Microsoft Defender for Cloud Apps), which keeps a catalog of thousands of apps, including a generative AI category, with risk scores.
• OAuth consents in your identity provider: AI apps employees have connected to their work mailbox, calendar or files.
• Browser extension inventory from your endpoint management: AI writing extensions read everything typed into web pages.
• Expense reports and card statements: personal AI subscriptions claimed back.
• Simply asking. An anonymous survey ("which AI tools help you, and for what?") finds use cases logs can't.

We wrote a short discovery script that maps log lines to a catalog of known AI apps and adds up users, departments and uploaded data per app. Run on the synthetic month, it produced:

App                            Tier Users   Uploaded  Top departments
Microsoft 365 Copilot             1   199       34 MB  Engineering 44, Sales 41, Support 37
GitHub Copilot Business           1    84       15 MB  Engineering 70, IT 14
ChatGPT (personal account)        2   147       27 MB  Sales 40, Marketing 26, Support 24
Claude (personal account)         2    30        6 MB  Engineering 11, Support 6, Sales 4
Gemini (personal account)         2    29        5 MB  Sales 7, Engineering 6, Support 4
Perplexity (personal account)     2    28        5 MB  Support 8, Engineering 7, Sales 4
AI grammar extension              3    41        8 MB  Sales 10, Engineering 7, Support 7
AI slide generator                3    35      201 MB  Marketing 17, Sales 9, Engineering 4
AI meeting note-taker             4    21     7320 MB  Sales 10, Marketing 3, Finance 3
AI PDF chat site                  4    14      248 MB  Legal 6, Finance 5, Sales 1
 
Not in the catalog:
  translatedocs.example        users  10  uploaded    146 MB  NOT flagged: nothing in the name says AI
  summarize-ai.example         users  10  uploaded     85 MB  flagged as likely AI by name

The exact numbers come from our generator, but two lessons hold for any real report:

• Rank by data, not by users. The most popular unapproved tool was a personal chatbot, used by 147 people. But the meeting note-taker, with 21 users, uploaded about 7.3 GB, far more than everything else together, because it uploads meeting recordings. The PDF chat site had only 14 users, mostly in Legal and Finance, uploading whole documents. A report sorted by headcount puts the riskiest tools at the bottom.
• Name-based discovery misses things. Our simple "does the domain look like AI?" check caught summarize-ai.example but missed translatedocs.example, which received 146 MB, about two thirds of it from HR and Legal. Use a maintained app catalog, and review the top unknown domains by upload volume, not just the ones with "AI" in the name.

Step 2: Classify the Data, Not Just the Tools

A tool isn't risky on its own. It's risky for a kind of data. Most organisations already have data classes; if yours doesn't, four are enough:

The core of an AI policy is a simple matrix of which data class may go into which tool tier:

Employees can remember one rule: if it isn't public, it only goes into an approved tool.

Step 3: Put Every AI Tool in a Risk Tier

Each app in the catalog gets a tier based on a few facts you can check. In our catalog, each entry records them:

    "AI meeting note-taker": {"domains": ["meetingnotes-ai.example"], "contract": False, "work_sign_in": False,
                              "trains_on_data": None, "uploads_files": True, "tier": 4,
                              "alternative": "Teams meeting recap (licensed)"},

The questions behind a tier:

Our four tiers:

Every tier 2, 3 and 4 entry has an approved alternative. That's what makes the policy workable. When a tool is proposed for tier 1, review it like any other supplier, including its licence terms: AI Model Supply Chain shows how easily a licence restriction is missed.

Step 4: Build the Paved Road

The most effective shadow AI control isn't technical. It's making the approved way the easy way. For each common task found in discovery, name the approved tool:

Then make the rest easy too:

• A request process for new AI tools: one short form, a named reviewer, and an answer within a set time, for example ten working days. If approval takes three months, shadow AI is the rational choice.
• A one-page guide: the data rule, the approved tools, and how to request a new one.
• Short, practical training. Use real examples of what not to paste, and why. In the EU, the AI Act already expects organisations to ensure staff using AI have a sufficient level of AI literacy.
• A no-blame amnesty when you launch: tell people which tools you found, offer the alternative, and set a date after which tier 4 gets blocked.

Step 5: Guardrails, and What Pattern Detection Can Really Do

For the riskiest cases, add technical controls. The obvious one is DLP: check what's being pasted or uploaded, and warn or block when it looks sensitive.

We tested how much pattern-based detection can see. We wrote six detectors, with checksum validation so a random number doesn't count as a bank account:

DETECTORS = {
    "IBAN":        (re.compile(r"\b[A-Z]{2}\d{2}(?: ?[A-Z0-9]{4}){3,7}(?: ?[A-Z0-9]{1,3})?\b"), iban_ok),
    "BSN":         (re.compile(r"\b\d{9}\b"), bsn_ok),
    "Card number": (re.compile(r"\b(?:\d[ -]?){13,19}\b"), lambda s: luhn_ok(re.sub(r"\D", "", s))),
    "Email":       (re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]+\b"), None),
    "API key":     (re.compile(r"\b(?:sk|pk|api|key)[-_][A-Za-z0-9_-]{16,}\b"), None),
    "Label":       (re.compile(r"\b(?:highly )?confidential\b|\binternal only\b", re.I), None),
}

The BSN check is the Dutch citizen service number's "11-proof", the IBAN check is the standard mod-97 test, and card numbers use the Luhn check. So 123456782 (a valid BSN format) is flagged, while the order number 123456789 isn't.

We ran them on 30 labelled prompts of three kinds:

The ten it missed are exactly the leaks that matter most:

• "Write a renewal email to Contoso Retail; their contract is EUR 1.2M and we will offer 12% discount."
• "Make a table of salaries: Emma Bakker 74k, Daan Smit 68k, Sofie de Jong 91k."
• "Improve this text: Q3 revenue fell 8% to EUR 41M; we announce it to the market on 4 November."
• "Summarise our plan to acquire Fabrikam Logistics before the announcement in January."
• "Help me write to my manager that Lisa from Support is on sick leave for burn-out until March."
• A database connection string with a production server name, a firewall rule for the finance database, unreleased pricing, a customer list with overdue invoices, and a candidate's background check.

And the two false alarms: "How do I mark a Word document as confidential?" (the word "confidential") and a public support email address in an FAQ answer.

Mapping the guardrails to Microsoft tools

If you run Microsoft 365, most of this maps onto tools you may already license. Names and features change often, so check current documentation for your licences.

Step 6: Monitor Trends, Not Individuals

Governance needs a few numbers you track every month:

Report these by department and app, not by person, except where a specific incident needs investigating under your normal HR and security processes. Monitoring employees' use of tools has legal and trust implications. In the Netherlands, for example, introducing a system that monitors employee behaviour generally needs the works council's consent. Involve HR, legal and employee representatives early.

Finally, keep the catalog alive. New AI features appear inside tools you already approved: an existing SaaS product adds an AI assistant overnight. Review the catalog every quarter, and make "does this product now include AI?" part of every software renewal.

A 90-Day Rollout

Checklist

• Discovery from proxy logs, the app catalog, OAuth consents, browser extensions and a staff survey.
• Results ranked by data uploaded, not just users; unknown domains reviewed by volume.
• Data classes defined, with one simple rule: non-public data only goes into approved tools.
• Every AI tool in a tier, with the facts behind it (contract, sign-in, training, retention, location, uploads).
• Every non-approved tool has a named approved alternative.
• A fast request process with a named reviewer and a target time.
• DLP for structured identifiers, in warn mode first; sensitivity labels for what patterns can't see.
• Tier 4 blocked, with a message saying why and what to use instead.
• Monthly trend metrics by app and department; works council and legal involved.
• The catalog reviewed every quarter, including AI features added to approved products.

The Short Version

Shadow AI shows you what your employees need. Find out what they're using and why, give them a safe way to do it, and protect the data that matters with more than pattern matching.