Breach Notification Timelines When an AI System Leaks Personal Data

You are reading a message that says something like “we have identified an issue that may have resulted in a small number of users seeing content belonging to other accounts”, or you are looking at a support ticket where your assistant quoted a customer’s address to a different customer. The first question is not what went wrong. It is what time the clock started, because Article 33 gives you 72 hours from a moment that has probably already passed.

Is this a personal data breach at all

Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Three categories follow from that definition and all three occur in AI systems: confidentiality breaches, where data is disclosed to or accessed by someone unauthorised; integrity breaches, where data is altered; and availability breaches, where data is lost or made inaccessible.

Two consequences matter here. First, nobody has to have attacked you. A caching bug that shows one user another user’s conversation is a confidentiality breach with no attacker in it. Second, a model producing personal data about someone to a person who should not have it is a disclosure, whether the data came from a leaked context, from a mis-scoped retrieval index, or from the weights. The absence of an intruder does not take the incident out of Article 4(12).

Article 33(1) requires notification to the supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That is a low bar for the exemption to clear against — “unlikely”, and any risk, not high risk. If you are unsure, the structure of the provision points towards notifying. Article 33(5) requires you to document every breach regardless, including the facts, effects and remedial action, so that the authority can verify compliance — which means the incidents you decide not to notify still generate a record.

When the 72 hours start

Article 33(1) requires notification without undue delay and, where feasible, not later than 72 hours after having become aware of the breach. Where notification is later than 72 hours, it must be accompanied by reasons for the delay.

“Aware” is the operative word and it has a settled meaning in guidance. The Article 29 Working Party guidelines on personal data breach notification, WP250 rev.01, endorsed by the European Data Protection Board and superseded in part by EDPB Guidelines 9/2022 — both available from the EDPB’s document register — take the position that a controller is aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. A short initial period of investigation to establish that is permitted, and the clock runs from the end of that initial phase rather than from the end of the full forensic investigation. What is not permitted is stretching the initial phase to delay the start.

Three timing rules follow that decide most real cases:

• A credible report from outside starts the clock quickly. A customer emailing screenshots of someone else’s data is a report with a high degree of certainty attached. The investigation establishes scope, not whether something happened.
• Your processor’s awareness is not automatically yours. Article 33(2) obliges the processor to notify the controller without undue delay after becoming aware. In practice your clock starts when the vendor tells you — which is why a contractual vendor notice window of 72 hours makes your own 72 hours unachievable, and why that number is the one to negotiate. See DPA clauses specific to AI sub-processing.
• Awareness by anyone in the organisation counts. An engineer who spots cross-tenant data in a log and files a ticket has given the controller knowledge. Whether it reached the DPO is an internal process failure, not a defence.

Four AI fact patterns

Cross-tenant leakage from a caching or session bug. The clearest case. A request-scoped cache keyed incorrectly, a conversation list rendered from a stale session, a vector index queried without a tenant filter. This is a confidentiality breach from the moment the first user saw the wrong data, and awareness dates from the credible report or from the engineering observation, whichever came first. The scoping work is unusually hard because the disclosure is read-only and often leaves no record of who saw what, which is itself something to say in the notification.

Prompt-injection exfiltration. Content in a document, web page or email that the model processes contains instructions causing the system to send data to an attacker — classically by rendering a link or image to an attacker-controlled URL with data in the query string, or by calling a tool with the wrong recipient. This is unauthorised disclosure and it is a breach. The awkward analytical point is that nothing was compromised in the traditional sense: the system did exactly what it was built to do with untrusted input. That is a design failure under Article 25 and a breach under Article 33 at the same time.

Prompts in logs reaching the wrong audience. Application logs, traces or error reports containing prompt bodies, shipped to an observability vendor, retained beyond the stated window, or accessible to a broader internal group than the data justified. This is the most common and least dramatic pattern, and the one most likely to be discovered during an unrelated audit. Whether it is notifiable turns on who could access it and for how long.

A model producing personal data it should not have. Either regurgitation of training data, or retrieval from an index the user should not reach. Distinguish these carefully before notifying, because they have different scopes: a retrieval scoping failure has a determinable set of affected records, and a regurgitation claim requires you to establish whether the output was real data or a plausible fabrication. A fabricated address that happens to resemble a real one is an accuracy problem under Article 5(1)(d), not a breach — and telling the two apart is the first job.

What to file when you do not know yet

Article 33(3) sets the minimum content: the nature of the breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; the name and contact details of the data protection officer or other contact point; the likely consequences; and the measures taken or proposed, including where appropriate measures to mitigate possible adverse effects.

The escape valve for an incomplete picture is Article 33(4): where and in so far as it is not possible to provide the information at the same time, it may be provided in phases without undue further delay. This is the provision to use. Notifying within 72 hours with approximate numbers and a stated intention to supplement is compliant; waiting a week for certainty is not, and the reasons-for-delay requirement in Article 33(1) means the delay itself becomes something you have to justify in writing.

1. Fix the exposure first if it is ongoing. Containment is not delay, and an authority reading a notification will look for the containment timestamp.
2. Record the awareness moment and who held the knowledge, in writing, immediately. Reconstructing it later is unconvincing.
3. Identify the competent supervisory authority. If you have a main establishment in the Union, that is your lead authority under Article 56. If you are not established in the Union, the one-stop shop is not available to you and notification may be owed in each member state where affected individuals are — a point EDPB Guidelines 9/2022 made explicitly.
4. File on the authority’s own form within 72 hours, using ranges and stating what is still under investigation.
5. Assess Article 34 separately. It is a different test with a different deadline.
6. Supplement under Article 33(4) as the scope firms up, and close the Article 33(5) internal record with the final facts.

Telling the individuals

Article 34(1) requires communication to the data subject without undue delay where the breach is likely to result in a high risk to their rights and freedoms — a higher threshold than the notification duty, and with no 72-hour figure attached. Article 34(2) requires the communication to describe in clear and plain language the nature of the breach and to contain at least the same information as points (b), (c) and (d) of Article 33(3).

Article 34(3) provides three exemptions: the data were rendered unintelligible to unauthorised persons, for instance by encryption; subsequent measures ensure the high risk is no longer likely to materialise; or communication would involve disproportionate effort, in which case a public communication or similar equally effective measure is required instead. The encryption exemption is worth noting precisely because it so rarely applies to AI incidents: the data disclosed by a model or a mis-scoped index was plaintext by construction.

After the incident closes, the finding that matters is usually a design one. Cross-tenant leaks trace back to a filter applied at the wrong layer; injection exfiltration traces back to a system that could reach the network on behalf of untrusted content; log exposure traces back to a default that captured prompt bodies. Each of those is an Article 25 question that could have been asked before shipping — see privacy by design applied to an AI feature. For what enforcement in this area has actually looked like, see notable GDPR fines involving AI.