A data breach in an AI integration: the 72-hour clock and what to record

What actually counts as a data breach?

A data breach is not a mysterious concept in law. The GDPR calls it a personal data breach and defines it in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Three things stand out in that definition.

• It does not have to be a hack. Accidental counts just as much as malicious. An email sent to the wrong recipient is a data breach.
• It does not have to involve theft. Loss and destruction count too. If your conversation history is irretrievably gone and you needed it, that is a breach.
• It is about the security failure, not the damage. Whether something goes wrong for the customer is the next question. That question decides whether you must report, not whether it is a breach.

With an AI integration for customer contact, the risk sits in a few very concrete places. The AI assistant reads along in a shared mailbox. It hangs off your WhatsApp number. It writes conversation summaries into a CRM or a separate database. There is almost always an API key involved, and usually a connection to whoever runs the language model. Every one of those links can leak. A key that ends up in a public repository, a test environment full of real customer conversations, a chat window that shows customer A's answer to customer B: these are not exotic scenarios, they are the standard mistakes.

One point matters for everything that follows. The law places responsibility with whoever decides why and how the data is used. That is you, the business owner. Not the supplier of the AI system. Not even when the mistake was technically made at the supplier's end.

When exactly does the 72-hour clock start?

Article 33(1) GDPR says you report a breach without undue delay and, where feasible, no later than 72 hours after having become aware of it. Those last words carry the whole story. The clock does not start when the breach happens, and it does not start when your investigation is finished. It starts at the moment you can reasonably be said to know.

In practice that means the moment someone inside your organisation receives the signal. A customer calls to say the reply they got contained someone else's name. A supplier emails you about an incident. An employee notices that an export file is sitting in the wrong place. From that signal you have a reasonable period to establish whether personal data is genuinely involved — but you may not stretch that period in order to start the clock later. A short first assessment belongs in the space of hours, not weeks.

The 72 hours are calendar hours. Not working hours, not working days. A breach that reaches you at four o'clock on a Friday afternoon must in principle be reported by four o'clock on Monday afternoon. The Dutch data protection authority is outspoken about this: if you are late, you have to give a reason, and it accepts a late report only in exceptional cases. Weekend, holiday, illness or being busy are explicitly not valid reasons.

That is an organisational fact, not a legal detail. If there are five of you and only one person knows the systems, your reporting process is exactly as reliable as that person's diary. So agree in advance who looks at it when they are away, and make sure that second person can actually reach the supplier.

One more thing from the same article: where you cannot gather the information all at once, you may provide it in phases. That is the way out of the most common problem — within 72 hours you know that something happened, but not yet exactly how many customers it touches. Report what you know and add the rest later. Waiting until the investigation is complete is not an option.

Does every breach have to go to the regulator?

No. Article 33 makes one exception: reporting is not required where the breach is unlikely to result in a risk to the rights and freedoms of the people involved. That sounds like a wide escape route, but it does not work that way. The regulator puts it plainly: you have to make a risk assessment in order to decide whether or not to report the breach and whether or not to inform the people affected.

So the decision is yours, and it is a reasoned decision you must be able to show afterwards. What goes into it?

• What kind of data. A name and an email address is a different matter from a conversation in which someone describes a medical complaint in a clinic's chat.
• How many people. One customer does not automatically mean no risk, but scale counts.
• Who could reach it. A file that was open for a second on an internal network is different from an index picked up by a search engine.
• What could go wrong. Can someone use this to log in, to defraud a person, or to reveal something about a customer they did not want shared?
• What you had already arranged. If the data was encrypted and the key did not leak with it, the actual risk is lower.

The rule of thumb for a business owner short on time: when in doubt, report. A report that turns out to have been unnecessary costs you half an hour of form-filling. A missed report is a breach of Article 33 and it also creates the impression that you had no view of your risks.

Which incidents must be reported and which need not?

The table below lists situations that genuinely occur with AI-driven customer contact. Note the last column: you always record the incident, even when you do not report it. That is where Article 33(5) comes in, and there is more on that further down.

Common incidents around an AI integration for customer contact, set against whether a report to the data protection authority and a notification to the customer are required. The outcome always depends on your own risk assessment.

Incident	Report to the regulator	Inform the customer	Record in your own log
AI reply contains another customer's data and goes to one recipient	Usually yes; depends on how sensitive the content was	Only where the risk is high, for instance health or financial data	Yes
Export containing conversation history left online without protection	Yes	Yes, as soon as it poses a high risk to those involved	Yes
API key for the AI integration shared in a public environment	Yes if customer data could be reached through that key	Depends on what was accessed and by whom	Yes
Internal email with customer data sent to the wrong colleague inside the same company	Often not, if the data never left the organisation and was deleted	Usually not	Yes
Conversation database encrypted, key not leaked, backup intact	Often not; risk is then generally unlikely	Usually not	Yes
Loss of data: conversation history irretrievably gone, no backup	Yes, loss is also a breach	Depends on the consequences for the customer	Yes
Supplier notifies you of a breach in their own system	You report it, not the supplier; the assessment is yours	Where the risk is high, and then by you	Yes

The table is an aid, not a ruling. Two incidents that look the same can end differently because the data is different. So always write down why you reached your conclusion.

What has to be in the report?

Article 33(3) GDPR lists the minimum content of a report. Four elements, and all of them can be answered without a lawyer:

1. The nature of the breach. What happened, which types of data are involved, which categories of people, and approximately how many individuals and how many records. Approximately — no exact figure is required.
2. A point of contact. The name and contact details of the data protection officer, or of another point where more information can be obtained. If you have no officer, name whoever handles the file for you.
3. The likely consequences. What this could mean for the people involved.
4. The measures. What you have done or will do to close the breach and limit the consequences.

With an AI integration, point four deserves extra attention. Closing a breach there often means revoking and replacing the key, switching the integration off temporarily, having the leaked copy deleted by whoever holds it, and checking whether data you sent to a language model has been retained anywhere on that side. You can only answer that last one if you know in advance how your supplier handles data. Anyone starting that enquiry on day one of a breach will not make the 72 hours.

Cannot get it complete? Report what you have, state that the investigation is ongoing, and supply the rest in phases. The same article expressly allows this.

When do you also have to tell the customer?

Reporting to the regulator is not the same as telling your customers. Article 34 GDPR says you inform the individual yourself when the breach is likely to result in a high risk to their rights and freedoms. The threshold is higher than for the report to the regulator: there it is "a risk", here it is "a high risk".

What does that mean in day-to-day customer contact? Think of conversations in which customers say things they would not publish. An AI chat at a clinic where complaints are described. A debt adviser's WhatsApp line. A mailbox where people send copies of documents. If that content reaches an unknown third party, the chance of a high risk is considerable. If it is a list of first names and the question "what time do you open", that chance is small.

The communication to the customer must be in clear and plain language, and it contains the same core as the report: what happened, what the likely consequences are, what measures you are taking, and where they can go with questions. Article 34(3) sets out exceptions — among them where the data was encrypted and therefore unintelligible, where you have since taken measures that mean the high risk can no longer materialise, or where individual notification would involve disproportionate effort and you make a public communication instead.

A warning about those exceptions: they exist for cases where the risk has genuinely been removed, not for cases where you would rather not send an email. If you rely on an exception, write down why it applies.

Why must you record breaches you do not report?

This is the part smaller companies forget most often. Article 33(5) GDPR requires you to document all breaches: the facts relating to the breach, its effects and the remedial action taken. Not just the reported ones. Including the incident you concluded after half an hour carried no risk.

The reason is simple. Your decision not to report is itself a decision you are accountable for. Without a record it cannot be checked, and therefore it cannot be defended either. The log serves a second purpose you will notice yourself: patterns. The same kind of failure in the same integration three times a quarter is no longer an accident, it is a design problem.

Such a log need not be a system. A table will do, provided each incident carries at least the following:

• the date and time you received the signal, and from whom;
• what happened and which systems and integrations were involved;
• which types of data and which categories of people, and approximately how many;
• your risk assessment, with the reasoning behind it;
• the decision: report to the regulator or not, inform the customer or not, and why;
• what you did immediately and what you changed structurally;
• who handled it.

That fifth line is the important one. Without the reasoning it is not a file, only a logbook.

What if the breach is at your AI supplier?

This is the most likely scenario with an AI integration, because you usually do not run the technology yourself. The roles are then as follows: you are the controller, the supplier is the processor. Article 33(2) GDPR imposes one duty on the processor: to inform you without undue delay after becoming aware of a breach. The processor does not report to the regulator. You do.

There is a practical danger in that. Your 72 hours start running the moment you know. If your supplier takes three days to reach you, you are not automatically late — but you are dependent on someone else for the starting signal. Which is why this belongs in the contract.

Article 28 GDPR requires processing by a processor to be governed by a contract that binds the processor to you and that sets out, among other things, the subject matter, duration, nature, purpose and types of data. That same provision obliges the processor to assist you in meeting your obligations around breaches and security. Translate that into arrangements you can actually use on the day it goes wrong:

• a concrete deadline for notifying you, expressed in hours, not "as soon as possible";
• a fixed point of contact and a channel that also works at the weekend;
• a duty to supply you with the information Article 33(3) asks of you: nature, numbers, consequences, measures;
• a prohibition on communicating with customers or the regulator on your behalf without your instruction;
• clarity about sub-processors, because whoever runs the language model is often yet another party;
• an agreement that you receive log files showing who could reach which data and when.

Note that the Dutch data protection authority points out that the GDPR requires a processing agreement from both parties, and that both are liable if such an agreement is missing. So you cannot say the supplier should have arranged it.

How do you make 72 hours realistic before anything happens?

The 72-hour clock is not hard because the rule is complicated. It is hard because four things have to happen at once under time pressure: find out what happened, close it, assess it, report it. Everything you arrange in advance is something you do not have to invent on the day.

1. Know where the data sits. Which integrations does the AI assistant have, which systems does it write to, and who supplies them. Without that overview you cannot describe the nature or the scale.
2. Limit in advance what can leak. An assistant that only sees what it needs for the answer leaks less when something fails. That is a security measure, and it weighs in your risk assessment.
3. Set one internal reporting address. One email address or number where staff and suppliers report a suspicion. That removes any argument about when you became aware.
4. Appoint a second person. The clock does not stop for holidays or illness, so your process must not rest on one diary.
5. Walk through the form once while nothing is wrong. Whoever knows the questions collects the right things straight away during an incident.
6. Keep the log from day one. Including the small things. Reconstructing afterwards does not work.

And keep the first signals. Screenshots, emails, timestamps. When the question is "when did you become aware", your own records are the only evidence you have.

The three mistakes that cost the most

The first is starting the clock too late. Owners wait to report until they have the complete picture, while the law expressly allows phased reporting. The second is assuming the supplier reports it. They do not: they report to you, you report to the regulator. The third is failing to record what you do not report. That turns a defensible decision into an unexplained gap.

What you have read here is a general explanation of the law and not legal advice. Whether you must report in your situation depends on facts only you know. If you are unsure about a specific incident, have it assessed by someone who knows your circumstances — and let the clock keep running in your own timeline while you do.