---
title: "Shadow AI is a data-breach risk under the GDPR"
canonical: "https://nordvec.com/blog/shadow-ai-is-a-breach-risk"
lang: "en"
claims: "https://nordvec.com/api/trust/claims"
---

# Shadow AI is a data-breach risk under the GDPR

Source: https://nordvec.com/blog/shadow-ai-is-a-breach-risk

This file is rendered from the same message catalogue as the page, at request time; the HTML page is the canonical document. Statements about the processing chain are bound to the claim record at https://nordvec.com/api/trust/claims, which says which of them the register currently supports.

Rasmus Kjær Damgaard, Founder · Published August 3, 2026 · Updated September 27, 2026

This article was produced with AI assistance, and no review of it by a person is on record.

Digital source type (IPTC): https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia

The EU's data protection supervisor treats unmanaged AI use as a breach risk. Unapproved tools are unvetted processors, and an approved-tools register is the fix.

**TL;DR:** The European Data Protection Supervisor's 2026 essay "Managing
Shadow AI's Hidden Data Breach Risk" treats unmanaged AI use as a breach
vector. The mechanism is simple: an unapproved AI tool is an unvetted
processor with no contract, no logs and no data map, which means an
unanswerable Art. 33 notification when something leaks. The fix is a
maintained approved-tools register with per-tool data limits, a protective
reporting path and an approved alternative. Generate the register and the
rules with our free [AI policy generator](/tools/ai-policy-generator).

## The mechanism, stated plainly [#the-mechanism-stated-plainly]

When an employee pastes customer information into a private AI account,
three GDPR facts become true at once:

1. **Processing has occurred** with the company as controller, whether or not
   anyone approved it.
2. **No processor agreement exists** (Art. 28), so there is no contractual
   basis governing what the tool's vendor does with the data, including
   whether it trains on it.
3. **The company cannot scope a breach.** If the tool leaks, mistrains or is
   compromised, the 72-hour notification duty (Art. 33) attaches to an
   incident with no logs, no inventory and no data map. You cannot notify
   precisely about data flows you never knew existed.

None of this requires the AI to malfunction. The breach risk is
architectural: data left the controlled environment the moment it was
pasted.

## Why bans fail and registers work [#why-bans-fail-and-registers-work]

Blocking consumer AI tools at the network edge moves usage to phones and
home machines, where visibility drops from partial to zero. Governance keeps
the use in view:

| Control | What it does |
|---|---|
| Approved-tools register | Names the tools that may be used, each with an approval state and the highest data tier it may receive |
| Data classification | A traffic-light model anyone can apply in seconds, plus a prohibited-input list |
| Protective reporting duty | Whoever finds an unapproved tool reports it; the response is migration to an approved alternative, not discipline |
| A sanctioned alternative | The decisive control: shadow use drops when the approved path is better |

The register does the heavy lifting because it converts an unbounded problem
("employees might be using anything") into a bounded one ("these tools,
these limits, this process for adding more").

## Where we stand in this [#where-we-stand-in-this]

Nordvec exists because of this problem: an EU-hosted service where your
documents answer questions with citations and become reports you export, with
an audit trail and a data processing agreement, in place of consumer tools
nobody can audit. That is our interest in the topic, stated
openly. The tools below are free and useful whether or not you ever become a
customer:

- [AI policy generator](/tools/ai-policy-generator): the register, the data
  tiers, the reporting duty and the rest of the policy, assembled from
  structured answers with the legal citation behind every section.
- [Article 50 checker](/tools/article-50-checker): which transparency duties
  your AI use triggers, with an evidence record.

## Sources [#sources]

- [EDPS: "Managing Shadow AI's Hidden Data Breach Risk" (W. Wiewiórowski, 15 June 2026)](https://www.edps.europa.eu/press-publications/press-news/blog/managing-shadow-ais-hidden-data-breach-risk_en)
- [Regulation (EU) 2016/679, Art. 28 (processors)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679#art_28)
- [Regulation (EU) 2016/679, Art. 33 (breach notification)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679#art_33)
- [Our guide to Article 50's transparency duties](/blog/eu-ai-act-article-50)


## Frequently asked questions

### What is shadow AI?

Employees using AI tools for work without IT's knowledge or approval: private ChatGPT accounts, browser extensions, free-tier assistants. The organisation has no processor agreement, no data-flow visibility, and no way to answer a supervisory authority's questions about where the data went.

### Why is shadow AI a GDPR problem and not just an IT policy problem?

Because pasting personal data into an AI tool is processing. Without a processor agreement (Art. 28) the transfer is unmanaged, and if the tool trains on inputs or leaks them, the company faces a personal-data breach it cannot even scope, with the 72-hour notification clock (Art. 33) running on an incident it has no logs for.

### Should we just block AI tools at the firewall?

Bans push usage to personal devices, where the company sees none of it. Govern the use instead: an approved-tools register with per-tool data limits, a protective reporting duty, and a sanctioned tool good enough to prefer.

### How do we find the shadow AI already in use?

Ask department by department, protectively: which tools, for what tasks, with what data. Amnesty first, register second. The point of the exercise is an accurate register and moved usage, not punishment.

[All articles](/blog)