GDPR Article 33 gives you 72 hours from becoming aware of a personal data breach to notify your supervisory authority. Most teams know the number. Fewer have worked out what “aware” means when the thing that may have breached is an agent that made four thousand decisions overnight.
This is not a theoretical gap. It is the single most common way an AI deployment turns a contained technical problem into a regulatory one: not because the underlying incident was severe, but because nobody could establish scope inside the window.
The clock starts earlier than you think
Article 33 does not say “72 hours from confirming a breach”. It says without undue delay and, where feasible, not later than 72 hours after having become aware of it. Guidance from the European Data Protection Board is consistent on the point: awareness is a reasonable degree of certainty that a security incident occurred which led to personal data being compromised. A short investigation to establish that is acceptable. An open-ended one is not.
The practical reading: the clock starts when you have reasonable grounds to believe something happened, not when you have finished finding out what. If an engineer notices on Friday evening that an agent has been returning other customers' records, the clock is running on Friday evening.
Article 33(4) allows information to be provided in phases where it is not all available at once. This is the provision that saves people, and it is under-used. A partial notification on time beats a complete one late. Regulators have been consistent that the failure they treat harshly is silence.
What the notification actually asks for
Four things, from Article 33(3), and it is worth reading them as questions about an agent rather than about a database.
The nature of the breach, including categories and approximate number of data subjects and records. For an agent, this is the hard one. It means: which of the requests it handled involved personal data, whose, and what was exposed.
Contact point. Easy, assuming you have a DPO and their details are current.
Likely consequences. Requires knowing what was actually exposed, not what could have been.
Measures taken or proposed, including mitigation. Requires knowing when it started and when it stopped.
Three of those four are questions about scope, and scope is precisely what conventional AI logging cannot answer.
Why the usual telemetry fails
Most AI stacks log for debugging and cost control. That produces request counts, token usage, latency, error rates, and often a sampled subset of prompts.
Now try to answer the Article 33 questions from that.
Which data subjects were affected? Requires knowing which personal data was in which request. If prompts are sampled, you have a fraction. If they are not retained, you have none.
How many records? Requires a per-request record, not an aggregate.
What was exposed? Requires both the input and the output. Plenty of systems log the prompt and not the completion, which is exactly backwards for a disclosure incident.
When did it start? Requires knowing when the behaviour changed — a prompt template edit, a tool permission change, a model version bump. Configuration changes and request logs are usually in different systems with different retention.
The failure is not that teams are careless. It is that debugging telemetry and evidentiary records are different artefacts, and most stacks only have the first. You find out which one you built during the only week it matters.
Three agent-shaped incidents
Cross-session leakage. A context or cache bug means customer A's data appears in customer B's session. The scope question is which sessions overlapped, which is answerable only with per-request context provenance.
Over-broad retrieval. A permission change widens what a support agent can retrieve, and for eleven days it has been summarising documents the requester should never have seen. No system was compromised; every access was authorised by a rule that was wrong. It is still a breach, and the scope is every request in those eleven days.
Exfiltration via injection. Content in a document instructs the agent to include data in its output or send it through a tool. The scope question is which requests touched the poisoned content and what left as a result.
In all three, the technical fix is often quick. The regulatory exposure comes entirely from the days it takes to bound the impact.
“Is it even a breach?” — the question that eats the first day
Agent incidents have a particular way of stalling, and it is worth naming because it costs more hours than the technical work.
Someone asks whether a model repeating personal data back to the wrong user counts as a personal data breach at all. The argument goes: nothing was stolen, no system was compromised, the data never left our infrastructure, the model was behaving as designed.
Article 4(12) is broader than that instinct. A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Unauthorised disclosure is the operative phrase, and it does not require an attacker, an exfiltration or a boundary crossing. Showing customer A's data to customer B is disclosure to someone not authorised to receive it, whatever the mechanism.
The same applies to the over-broad retrieval case. Every access was permitted by the system. The permission was wrong. That is unauthorised access in the sense the Regulation means, and “the rule allowed it” is a description of the failure rather than a defence against it.
The practical advice is to settle this question before an incident, in writing, with your DPO. Teams that have not done so spend the first twenty-four hours debating characterisation instead of bounding scope, and the clock does not pause for the debate.
The evidence a regulator can actually use
There is a difference between records that satisfy you and records that satisfy someone who was not there.
An internal dashboard showing that the anomaly stopped at 14:20 is convincing to the team that built it. What an investigator needs is closer to: here is the decision record for every request in the window, here is the policy version in force at each point, here is the configuration change that widened the permission and when it was made, here is the integrity proof for the export, and here is the query that produced this set so it can be run again.
Two properties do most of the work.
Reproducibility. If your numbers come from a query anyone can re-run against a sealed record, the conversation is about the facts. If they come from a hand-assembled spreadsheet, the conversation becomes about your methodology, and that is a much worse conversation to be having on day three.
Coverage you can state. Being able to say “this is every request in the window, not a sample” is the sentence that ends the scoping argument. Without it, every number you give is provisional, and provisional numbers invite follow-up questions you will answer under time pressure.
What you need at hour one
A per-request, queryable record with five properties. Not for compliance theatre — because without them you cannot answer the questions in time.
Complete, not sampled. Sampling is fine for performance and useless for scope. You cannot notify about the 10% you kept.
Identity-linked. Which agent, on whose behalf, under which policy version. “An agent did it” does not bound anything.
Data-classified at the time of the call. Whether personal data was present, and of what category, decided when the request was processed. Re-deriving it afterwards from retained text is slow and disputable, and if you did not retain the text it is impossible.
Tamper-evident. A log an administrator could have edited invites the question of whether it was. Hash-chaining converts “trust our export” into “here is a record with verifiable integrity”.
Queryable along the axes you will be asked about. Time range, data subject, agent, policy, tool. If answering “which subjects were affected between Tuesday and Thursday” means a log-parsing project, you will not finish inside 72 hours.
The hour-by-hour shape
Hours 0–4. Contain: suspend the agent or narrow its permissions. Preserve: freeze the relevant records before any retention policy touches them. Start the clock formally and write down when awareness began, because you will be asked.
Hours 4–24. Bound the window and the population. Which requests, which subjects, which categories. If the record is queryable this is hours; if it is not, this is where the deadline is lost.
Hours 24–48. Assess risk to individuals, which determines whether Article 34 direct notification is triggered as well. Draft the notification.
Hours 48–72. Notify. If scope is still uncertain, notify in phases under 33(4) and say plainly what you know, what you do not, and when you will follow up.
Note that the only step whose duration you control in advance is the second one, and you control it by deciding, long before the incident, what your system records.
The part worth internalising
NIS2 adds a 24-hour early warning for essential and important entities. DORA has its own major-incident reporting path for financial entities. The EU AI Act adds serious-incident reporting for high-risk systems. The windows differ; the underlying demand does not. Every one of them asks you to bound an impact quickly and evidence it credibly.
Which makes the record the actual deliverable. Not the policy document, not the model card, not the DPIA — those are design-time artefacts and they are answering a different question. The thing that determines whether an incident stays technical or becomes regulatory is whether, at hour one, you can run a query and get an answer you would be willing to put your name on.
That capability is not something you add during the incident. It is either already there or it is not, and the 72 hours is when you find out which.