Shadow AI: How to Find It, Govern It and Stop Data Leaving
Shadow AI is the use of AI tools, apps and browser extensions that your organisation has not approved, reviewed or logged. This guide explains why bans rarely work and how to bring shadow AI under control with discovery, approved alternatives, policy, technical enforcement and evidence.
What is shadow AI?
Shadow AI is any use of artificial intelligence at work that sits outside the organisation's approved tooling and oversight. It covers an employee pasting a contract into a public chatbot, a team connecting a spreadsheet to a model through a personal API key, a browser extension that summarises pages, or an AI feature quietly switched on inside a SaaS product. Some people call this shadow artificial intelligence, and a single unapproved tool is often called a shadow AI app.
The idea mirrors shadow IT, but the exposure is different. A forgotten file share stores data. A chatbot receives it, may retain it depending on the provider and plan, and returns output that people then act on. That makes the shadow AI risk a mix of data leakage, unreliable outputs, missing records and unclear accountability.
Why shadow AI is a real risk
Most shadow AI use is well intentioned. People want to draft faster, summarise longer documents or debug code. The problems come from what travels with the request and what the organisation can later prove.
- Personal data and confidential material leave the perimeter without a lawful basis check, a contract with the provider or a record of the transfer. Under the GDPR, a controller remains responsible for processing carried out on its behalf (Regulation (EU) 2016/679).
- Unreviewed outputs enter customer communications, code and decisions with no human checkpoint.
- Missing evidence means that when a regulator, auditor or customer asks which AI systems touch which data, nobody can answer.
- Regulatory exposure grows as AI rules mature. The EU AI Act, Regulation (EU) 2024/1689, places duties on deployers as well as providers, and it applies in stages, so check the current official text for dates (EUR-Lex).
Why bans on AI tools fail
The first reaction to shadow AI is often a blanket ban. It is easy to announce and almost impossible to enforce, for three reasons.
First, the tools are one browser tab away and work on personal devices. A ban on the corporate network simply moves the activity to a phone or home laptop, where you have no visibility at all. Second, the productivity gain is real, so people who are measured on output will find a way. Third, a ban teaches staff to hide their use, which removes the honest conversations you need to learn what the business actually wants from AI.
A more durable approach treats shadow AI as a signal. It tells you which tasks people want help with. Your job is to meet that demand with something safer, then make the safe route the easy one.
How do you discover shadow AI?
You cannot govern what you cannot see, so start with an honest inventory. No single source is complete, so combine several.
- Network and DNS logs. Look for traffic to known AI services and API endpoints, and measure volume rather than just presence.
- Identity and SaaS logs. Review OAuth grants, single sign-on activity and browser extension installs for AI related applications.
- Expense and procurement data. Small subscriptions paid on corporate cards often reveal tools nobody registered.
- Surveys and amnesty conversations. Ask teams what they use and why, and make clear that disclosure will not be punished. Self-reported use is often the richest source.
- Vendor reviews. Ask existing SaaS suppliers which AI features and sub-processors they have added.
Record each finding in an AI inventory with an owner, the data involved, the purpose and a risk rating. The inventory then feeds the wider governance process described in our guide to the AI governance framework.
What approved alternatives should you offer?
People stop reaching for unapproved tools when a sanctioned option is at least as convenient. That usually means one or more enterprise grade assistants or an internal model endpoint, a short list of approved use cases, and a fast route to request something new.
Be specific about what is allowed with which data class. A simple three tier model works well in practice: public information may go to approved external tools, internal information only to tools under contract with suitable data terms, and restricted or regulated data only to tools you host or that pass a formal review. Publish the list where people work and keep the approval process measured in days, not months.
Policy plus technical control
A written policy sets expectations, but it does not stop a rushed copy and paste. Pair it with controls that act at the point where data leaves.
The policy should state approved tools, prohibited data classes, who owns each AI use case, how exceptions are requested and what happens when something goes wrong. Keep it short enough that people read it, and train staff with realistic examples from their own roles.
The technical layer then enforces the same rules in two places.
- The API layer. Applications and agents send model requests through a governed gateway, so every call is checked against policy, redacted where needed, logged and attributed.
- The browser layer. Much shadow AI happens in a chat window, not through an API. A control inside the browser session can apply the same policy to what staff type into tools such as ChatGPT, Gemini, Claude and Microsoft Copilot.
Using one policy across both layers matters. Otherwise people simply move from the monitored path to the unmonitored one.
How do we stop staff pasting data into ChatGPT?
No single measure stops it entirely, but layered controls reduce it sharply. Work through them in this order.
- Classify the data people handle, so rules can refer to concrete categories such as customer identifiers, health data, source code and contracts.
- Offer an approved assistant so the legitimate need has a legitimate outlet.
- Intercept before the prompt leaves. A browser session control can inspect typed input and either redact sensitive values or block the interaction before the prompt reaches the model.
- Apply the same rules to API traffic so scripts, plugins and integrations cannot bypass the browser control.
- Give the user feedback. A clear message explaining why a prompt was blocked or redacted teaches better than silent filtering.
- Review the telemetry and adjust the policy where legitimate work is being blocked.
Training and clear consequences support this, but the interception step is what turns policy into a control rather than a hope.
Redaction and its failure mode
Redaction is often the most practical control, because it lets work continue while removing the sensitive part. A prompt that mentions a customer can still be summarised once the name and account number are masked. Detection is never perfect, so the failure mode matters as much as the detection method. If the redaction layer errors or times out, should the request go through unredacted or stop? Our article on fail-closed PII redaction strategies covers that decision and the four redaction operations in depth.
Audit and evidence
Governance that cannot be shown does not count in an audit. For each governed interaction you want a record of who acted, which tool and model were involved, what policy decided, whether data was redacted or blocked, and when. Records should be append-only and tamper evident, so that later edits or deletions can be detected.
Aggregate this into a small set of measures: the number of AI tools in use against the number approved, blocked and redacted interactions over time, and the most common data types intercepted. NIST's AI Risk Management Framework and OWASP's Top 10 for LLM applications are useful references when deciding what to measure and which threats to cover.
How Krasper helps
Krasper Raigate is a self-hosted AI governance firewall. It applies one allow, block or approve policy across API traffic and the browser session for ChatGPT, Gemini, Claude and Microsoft Copilot, redacts PII before prompts reach the model, and records governed requests as audit evidence. Raigate supports your evidence; it does not certify compliance.
If you first need to understand where shadow AI sits in your organisation and what policy to write, our AI governance consulting team can help you build the inventory, the policy and the control plan.
корпоративную инфраструктуру?
Запишитесь на технический брифинг. Без продаж, только архитекторы и ваша команда.