Loading…
An operational guide for AI data leaks. GDPR Article 33 timing, containment, evidence preservation, notification templates, three worked incident walkthroughs, and the regulator differences that catch teams off guard.
The detection signal arrives from somewhere unexpected. A customer screenshots a chatbot reply that contains another customer's name. An external researcher emails your security@ mailbox at 11pm with a screenshot of an exposed vector store. Your dashboard shows a 4xx spike on a retrieval endpoint. Your support team finds an internal prompt history in a reply suggestion.
Whatever the trigger, your AI feature just leaked something it should not have leaked. The next 72 hours are governed by GDPR Article 33, a regulator clock, and a thousand small decisions you will be asked to defend later. This is the operational walkthrough — what to do when, what to write down, which template to pull, and which trap to avoid.
The DeepSeek case from January 2025 is the canonical recent example of a misconfiguration-class AI leak. A ClickHouse database exposed roughly one million log entries including plaintext chat histories, API keys, and backend tokens. Wiz Research disclosed it on 29 January 2025. DeepSeek closed the database within an hour. The Italian Garante banned the service the following day. Later in this guide I walk that incident plus two others — OpenAI's March 2023 Redis bug (a code defect in the provider) and Microsoft 365 Copilot's EchoLeak (a prompt-injection exfiltration chain) — all the way through the 72-hour timeline, because the three root-cause classes have genuinely different response shapes.
The single best predictor of how an AI incident actually goes is what the team had prepared before it started. Most of the mistakes I see during the first 24 hours are not intelligence failures — they are logistics failures. Nobody knows the DPO's phone number. Nobody has a working filing credential for the relevant supervisory authority. Nobody has a breach log template. The incident commander spends ninety minutes assembling the first page of a document that should have existed on day one.
The minimum readiness set, scoped to AI features specifically:
None of this is expensive to build. All of it saves you hours when the clock is running.
The clock does not start when the breach happens. It starts when you become "aware" of it. This distinction has saved companies and sunk them.
EDPB Guidelines 9/2022 define awareness as "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." That is a lower bar than most teams assume. You do not need to know exactly which records, exactly how many, or exactly which individuals. The French CNIL's published guidance adopts the same line almost verbatim, and the UK ICO's breach guide is written the same way. There is no significant divergence between the major supervisory authorities on the awareness trigger.
The practical translation. If a researcher emails you a screenshot of your exposed vector store, you are aware. If a customer reports seeing another user's data in a chatbot reply and you reproduce it once, you are aware. If your alert fires on a retrieval endpoint and a five-minute check confirms a real misconfiguration, you are aware. Start the timer.
I think the biggest single mistake I see at this stage is teams arguing themselves out of starting the clock. "We are not sure yet whether personal data was actually accessed" is the most common phrasing of that mistake. The EDPB's answer is explicit: confirmed unauthorized access is not required. What is required is reasonable certainty that the incident has led to personal data being compromised. If you are writing paragraphs explaining why the clock has not started, you are probably already past hour zero.
Write down the timestamp. Write down who confirmed it. Write down what they saw. This is the first line of the breach log.
"We are not sure if personal data was actually accessed, so the clock has not started." The EDPB, the CNIL, and the ICO have all rejected this reading. Awareness requires reasonable certainty that a security incident has compromised personal data — it does not require confirmed unauthorized access. If you are arguing yourself out of starting the clock, you are probably already past hour zero, and that will be visible to a regulator later when they reconstruct the timeline from your logs.
You have started the clock. In the first hour, you do three things in parallel. None of them are optional.
Declare the incident formally. Even if you are one person at a ten-person startup, write down the declaration. Start the breach log. Pick an incident commander — probably you. Pick a note-taker. Pick a communications lead, even if it is a single line in the log that says "external comms deferred to hour 4." Structure beats improvisation during the first hour.
Notify your DPO. The DPO needs to know inside the first hour. If the DPO is external, call the mobile number. Voicemail is not good enough. You need an acknowledgment in the breach log with a timestamp.
Brief leadership. Your CEO needs to know within hour 4; your head of engineering or CTO within hour 1. The breach log captures each notification with a timestamp and an acknowledgment.
The timing on these three matters because regulators reconstruct the timeline after the fact. "Detection at 22:05, DPO notified at 22:18, incident commander on call at 22:25, containment started at 22:42" reads as a competent team under pressure. "Detection at 22:05, first log entry at 03:40 the next morning" reads as a team that lost hours.
Containment comes before investigation. Stop the bleeding, then ask why. For a typical AI feature, contain means:
Disable the leaking endpoint at the gateway, not at the model. If you only "turn off the model," upstream caches, retries, and queued jobs keep producing leaked output. Block at the edge, drain the queues, and confirm in the access log that requests are no longer hitting the backend.
Rotate every credential the affected component touches. The model provider's API key, vector store credentials, embedding service credentials, database credentials for any data source feeding the prompt, and any service accounts the agent was using. Assume each credential is compromised until proven otherwise.
Pull retrieval permissions. For RAG, revoke the vector store credentials and suspend the index. For agents, disable tool access. If your vector store contains personal data — and it almost certainly does — this step is not optional.
Snapshot logs before you rotate. Rotation invalidates session-bound logs at some providers; at others it does not, but you do not want to discover the difference at hour 3. Save what you have first, then rotate.
For prompt-injection-driven incidents, disable user input passthrough on the affected route until you have a filter you trust. Classifier bypass research from 2025 (see the prompt injection elevation for the arXiv citations) is a reminder that a "guardrail" is not the same thing as a filter you trust.
If your AI feature touches multiple tenants, decide whether to disable it for everyone or only for the affected tenants. The default for GDPR-sensitive features is "everyone," because tenant boundaries are rarely as airtight as architects believe and the cost of being wrong about that is being back in the breach log four hours later.
Snapshot before you rotate. Always. Rotating credentials or wiping caches without first exporting the state is the most common self-inflicted wound in AI incident response. An hour of extra work preserving evidence at hour 2 is worth ten hours at hour 48 when the regulator's questions arrive. The snapshot list for AI features should include: vector store contents, retrieval query logs, prompt and completion history, tool-call traces, guardrail hit logs, model response caches, and any fine-tuning state. Your existing IR playbook probably does not name these explicitly. Add them now, not after the incident.
Now the questions Article 33(3) will require you to answer. None of them need complete forensics in 24 hours. All of them need a defensible estimate range and a clear method.
"Approximately" is the operative word. Regulators understand that 24-hour estimates are ranges. They do not understand silence at hour 72 because a team is still waiting for perfect numbers.
Evidence preservation matters as much as the investigation itself. Three rules.
Do not delete logs to "clean up." Destroying evidence makes notification harder, not easier. If a regulator later asks for your access logs from the incident window, "we rotated the bucket to be safe" is a worse answer than "they were exposed for 11 hours." The regulator reads the first answer as obstruction.
Snapshot the AI-specific state. Vector store contents, prompt history, output history, retrieval logs, tool-call traces, guardrail and classifier hit logs, and any cached responses. Move them to a write-once location with a clear chain of custody. This is the material your post-incident review will care about and the material a regulator may request.
Request your provider's audit logs immediately. OpenAI, Anthropic, Azure OpenAI, and Vertex AI all retain request logs but the retention windows are short (seven to thirty days is typical) and the request process is not instant. Get the request in flight before hour 24 or you may lose the evidence window. Your DPA should specify the timeline on this; if it does not, push anyway.
An honest uncertainty to flag during scoping: whether a model output containing another user's data — a chatbot reply that inadvertently exposed personal information — counts as a notifiable breach under Article 4(12). The academic reading is yes, and the EDPB's broad framing of "personal data breach" supports that reading. I have not seen a regulator make this exact argument in a published enforcement action yet. The defensible move is to assume yes, treat the output as a breach, and argue the point later if needed — notifying when you did not have to is a smaller regulatory problem than not notifying when you should have.
Article 33 requires four things from your filing:
Article 33(4) explicitly allows phased reporting. If you do not yet have all four pieces, file what you have and update. The ICO, CNIL, Garante, Dutch AP, and Irish DPC all accept this. What you cannot do is wait silently past 72 hours and hope to file a complete report on day four. That is the behaviour that triggers aggressive enforcement.
A working template for the initial filing. Fill it as you go, not at hour 71.
## Personal data breach notification (initial filing)
Controller: [legal entity]
DPO contact: [name, email, phone]
Filing time: [ISO 8601]
Awareness time: [ISO 8601, the moment from hour 0]
Reason for any delay past 72h: [if applicable]
### 1. Nature of the breach
- AI feature affected: [name, route, version]
- Underlying cause (working hypothesis): [misconfig | injection | model hallucination | sub-processor incident | code bug | unknown]
- Time window of exposure: [start - end, or "under investigation, current estimate: X"]
- Affected data sources: [model logs | vector store | prompt history | retrieval index | output cache | tool call traces]
### 2. Personal data categories affected
- Categories: [identifiers, contact data, content of communications, special category, etc.]
- Approximate number of data subjects: [range, methodology]
- Approximate number of records: [range, methodology]
### 3. Likely consequences
- Risks to data subjects: [identity theft, reputational harm, fraud, exposure of sensitive context]
- Specific to AI: [exposure of prompt history may reveal sensitive context never intended for the AI]
### 4. Measures taken or proposed
- Containment: [endpoint disabled, credentials rotated, index suspended — timestamps]
- Investigation: [scope, owner, ETA for full report]
- Mitigation: [what changes are in flight]
- Notification: [internal stakeholders notified, Article 34 decision and reasoning]
If you used phased reporting, schedule the follow-up filings now. Day 5, day 14, and day 30 are common cadences. Put them on the calendar so they do not slip — a follow-up filing that arrives a week late is almost as bad as a late initial filing.
Article 34 requires notification to data subjects "without undue delay" when the breach is likely to result in a high risk to their rights and freedoms. Article 33 and Article 34 have different thresholds, and teams that confuse them notify customers prematurely or, more commonly, miss the notification entirely.
For AI incidents, the default is usually high risk. Chat history reveals sensitive context even when no special category data is involved. A leak of prompt logs can expose health questions, legal concerns, financial details, and family situations the user never intended to share with a chatbot, let alone with another customer. Treat Article 34 as triggered unless you can point to a specific reason it is not.
A customer notification template, plain-language, AI-adapted:
Subject: Important security notice about [product/feature name]
[Date]
Dear [customer],
We are writing to tell you about a security incident that affected [product/feature name] and may have involved some of your personal data.
### What happened
[Two to three sentences, plain language. Name the feature, the time window, and the root cause in one clear sentence. Do not minimise. Do not use words like "sophisticated," "unprecedented," or "unauthorized third party" unless they are technically precise.]
### What information was involved
[Specific categories. "Your name and email address" is better than "your account data." If you are not sure, say so: "We are still investigating and will update you by [date]."]
### What we have done
[Containment actions in order. Date-stamped.]
### What we are asking you to do
[Specific actions: rotate a password, review recent activity, watch for phishing that references your account. If there is nothing the customer can do, say so explicitly: "You do not need to take any action at this time."]
### Who to contact
[A real email address and, ideally, a real phone number. Not a help-center link. This matters — regulators read the communication and notice if the contact is a dead end.]
We are sorry. [Product/feature name] is now operating normally, and we have reviewed [specific measures] to prevent a recurrence.
[Named signatory — ideally the DPO or the CEO, not "The [Company] Team."]
Draft the text in plain language. Regulators and journalists will read your customer notification side-by-side with your forensics, and the gap between them is the story. Do not minimise and do not use corporate hedging — both look worse than the underlying facts.
Post-incident review (PIR) scaffolding. A guide-tier runbook needs one. Schedule the PIR for day 14 at the latest. The PIR has three outputs: a factual timeline reconstructed from the breach log and the evidence snapshots, a list of changes to process and architecture, and a written answer to the regulator's eventual follow-up question — what changed? The PIR document becomes an appendix to your final Article 33 follow-up filing. It is also the document your next enterprise customer's procurement team will ask for when they hear about the incident.
Update three artefacts in the PIR: your DPIA (specifically the risk assessment section — which risk materialised and why was it assessed lower), your vendor risk register (if a sub-processor was in the causal chain), and your incident response runbook itself (what was missing from this document that would have helped).
If your AI provider caused the breach, you still notify your regulator and your customers. You do not get to wait for your provider to file. Your DPA with the provider likely requires them to notify you without undue delay, and you should escalate hard if they do not, but the controller obligation under Article 33 stays with you. The companion article What to do when your AI provider gets breached covers the broader posture.
The practical escalation protocol when the cause is upstream:
If the DPA's notification SLA is longer than your 72-hour clock allows — some providers commit to "without undue delay" without a specific number, and others quietly stretch it — that is a contract problem you should fix before the next incident. Add a concrete hour-level commitment to your next DPA renewal.
GDPR is a regulation, so the Article 33 and Article 34 text is identical everywhere. What differs is the supervisory authority's interpretation of "reasonable certainty," the portal you file through, and how aggressively they pursue delay-past-72-hours cases.
There is no significant divergence on the 72-hour clock itself. The divergence is in enforcement appetite and in the degree of procedural sympathy a DPA will show for a team that filed phased and kept the regulator informed.
The 72-hour clock is in proposed revision, but not yet in force. The Commission's Digital Omnibus proposal, in trilogue as of April 2026, would extend the Article 33 supervisory-authority notification window from 72 to 96 hours and would raise the notification threshold to align with the Article 34 "likely to result in a high risk" standard. The Council adopted its general approach on 13 March 2026 and IMCO/LIBE approved a joint report on 18 March 2026. Trilogue closure is expected in late spring 2026. Until then, plan against the 72-hour clock; the proposed 96-hour window is not law and a regulator will not accept it as a defence for a late filing in an incident that started before the trilogue closes. When the package does pass, the operational shift is smaller than it sounds: the 24 extra hours buy you scoping time, not silence time, and the higher Article 33 threshold pushes the notify-or-not decision toward the same logic Article 34 already uses. Update your runbook the day the final text is in the OJEU, not before.
The three root-cause classes for AI data leaks — misconfiguration, code bug in the provider, prompt injection — have genuinely different response shapes. Walking each from detection to notification makes the shape visible.
Incident 1: DeepSeek ClickHouse exposure (January 2025). A misconfigured ClickHouse database exposed roughly one million log entries including plaintext chat histories, API keys, and backend tokens. Wiz Research disclosed the exposure on 29 January 2025. DeepSeek closed the database within an hour. The Italian Garante banned the service on 30 January 2025. The shape of the response: hour 0 was the disclosure email from Wiz. Hour 0-1 was containment (database closed). Hours 1-24 were scoping — which records were in the exposed database, which users they mapped to. Hours 24-72 were notification drafting, regulatory outreach, and public communication. The Garante's action on day 2 shortened the window for everything that followed.
Incident 2: OpenAI March 2023 Redis bug. At 1am PT on 20 March 2023, a bug in the redis-py library caused some ChatGPT users to briefly see the titles of other users' conversation histories and the first messages of a new conversation (OpenAI postmortem). The bug also exposed payment information for about 1.2% of ChatGPT Plus subscribers active during a nine-hour window: name, email, payment address, last four digits of a credit card number, and expiration date. OpenAI took ChatGPT offline, patched the bug, and published a detailed postmortem. The shape of the response: hour 0 was internal detection via monitoring; containment was a full service shutdown; evidence preservation was built-in because the bug's effects were in the model's own logs. The interesting contrast with DeepSeek is that OpenAI was the provider and not the deployer — every team running on OpenAI's API at the time had to decide, very quickly, whether their own Article 33 clock had also started.
Incident 3: Microsoft 365 Copilot EchoLeak (June 2025). A crafted email triggered a full data exfiltration chain from Copilot without any user interaction (Aim Security; CVE-2025-32711). The shape of the response is different again: the incident was discovered by external researchers, disclosed to Microsoft's Security Response Center under coordinated disclosure, and patched before public disclosure. Every Microsoft 365 tenant with Copilot enabled during the vulnerability window had to consider whether their own Article 33 clock had started — the answer in most cases was yes, but the exposure window was genuinely difficult to bound without Microsoft's help. The contrast with DeepSeek and the March 2023 Redis bug is that the cause was neither infrastructure misconfiguration nor a code bug — it was an architectural property of the LLM trust boundary.
The three cases cover the three classes. Most teams will face the first class more often than the other two. All three classes still resolve into the same 72-hour shape if the pre-incident readiness is in place.
The three incidents above span the full root-cause matrix for AI data leaks and are all publicly documented with primary sources. When building internal incident response training, walk the three timelines with your team before the first real incident. The muscle memory — "this is the misconfig pattern, this is the code-bug pattern, this is the injection pattern" — is what makes hour 0 calm instead of chaotic.
Notifying late without an explanation. Article 33 allows late notification but requires you to state the reason for the delay. "We were investigating" is not a reason. "Initial detection at 22:05; cross-team confirmation at 04:30; first regulator filing at 09:15 after legal review" is a reason.
Confusing Article 33 with Article 34. They have different thresholds. Article 33 (notify the regulator) triggers on any non-trivial breach with a risk to rights and freedoms. Article 34 (notify the people) triggers only on high risk. Decide both questions, document both decisions, and do not let one answer drive the other.
Cross-border one-stop-shop confusion. If the controller is established outside the EU and only has an Article 27 representative, the one-stop-shop mechanism does not apply — you may need to file with multiple national authorities. Confirm your lead supervisory authority before the incident, not during it.
Destroying evidence to "be safe." Rotating logs, wiping caches, or deleting prompt history during containment is the most common self-inflicted wound. Snapshot first. Always.
Treating a sub-processor breach as not your problem. The controller obligation stays with you. Your DPA gives you recourse against the provider; it does not relocate the Article 33 clock.
The incidents that end well are not the ones with the shortest exposure or the fastest forensics. They are the ones where the pre-incident readiness was in place: a breach log template, a named DPO with a working phone number, pre-registered filing credentials, a sub-processor escalation sheet, and a written Article 33 vs Article 34 decision tree. Every hour you spend on that sheet before an incident is worth ten hours during one. The time to build it is this week, while nothing is on fire.
Downstream incident runbook for the moment your AI vendor's breach email arrives. The 72-hour clock from your awareness, scoping with API logs only, and the three real 2025-2026 cases.
Between January 2025 and February 2026, 20 documented AI app breaches exposed hundreds of millions of records. Four configuration mistakes explain nearly all of them.
What EchoLeak actually showed, what the lethal trifecta actually is, and how your defense posture should change by architecture tier. Grounded in 2025 Microsoft, Google, and OWASP research.