Customer data in an AI tool: what to do now

It has happened: somebody has pasted a customer list, a job application or a meeting transcript into a public AI tool. This is not a catastrophe and in most cases it is manageable — but a clock is running. This page is written as a set of instructions, not as an essay.

By Patrick de Kathen, Founder of KlarComply · Reviewed on 2 August 2026

Step 1: is this a notifiable breach at all?

Not every mistaken entry is a personal data breach. Work through two questions in order.

Question A: were personal data involved?

If only an anonymised calculation or a product description went in, there is no personal data breach. What may remain is the trade secrets question — see trade secrets and AI tools — but the 72-hour clock is not running.

Question B: is there a breach within the meaning of Article 4(12) GDPR?

That provision covers any breach of security leading to unauthorised disclosure of, or access to, personal data. Where customer data are entered into a tool for which there is no sound legal basis and no processor contract, that is normally an unauthorised disclosure to the provider. A breach therefore exists — even if nobody read the data.

Step 2: assess the risk

Article 33(1) GDPR requires notification to the supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Note the structure: notification is the rule, refraining from it is the exception, and it is the exception you have to justify.

Factor	Raises the risk	Lowers the risk
Type of data	health, finances, job applications, special categories under Art. 9	a name and a business address with nothing further
Volume	a complete customer list, many data subjects	a single individual, a single data point
Contractual position	personal account, no agreement	business agreement with processor contract, training use disabled
Where the data now sit	history cannot be deleted, retention unclear	history deleted, deletion confirmed, short retention period
Identifiability	real names with contact details	pseudonyms or placeholders, no route back to a person

Record the reasoning in five to ten sentences. In any later review that reasoning matters more than the outcome, because it shows that you assessed rather than guessed.

Step 3: the 72 hours

Article 33(1) GDPR: notification is made without undue delay and, where feasible, not later than 72 hours after having become aware of the breach. Four points are regularly misunderstood:

• The clock starts on awareness, not on the incident. If the entry happens on Friday and the management learns of it on Tuesday, the clock starts on Tuesday. “Awareness” means that of the controller, meaning the company — not that of the individual employee.
• The period runs on calendar time. Weekends and public holidays count. Awareness on Thursday afternoon means Sunday afternoon.
• 72 hours is the ceiling, not the target. The provision says without undue delay. If you know everything after four hours, you do not wait until day three.
• A late notification is better than none. Under Article 33(1), where notification is not made within 72 hours it shall be accompanied by reasons for the delay. That route is expressly provided for.

What goes into the notification (Article 33(3))

1. A description of the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned
2. The name and contact details of the data protection officer or other contact point
3. A description of the likely consequences
4. A description of the measures taken or proposed to address the breach and mitigate its effects

Where not all the information is available, notify on time with what you have and supply the rest later — Article 33(4) expressly allows that. Supervisory authorities provide online forms for this. Which authority is competent depends on where you are established, and in several member states on the region as well; if you operate across borders, identify your lead supervisory authority before you need it, not on the day.

Step 4: do the data subjects have to be told?

Article 34 GDPR requires communication to the data subjects where the breach is likely to result in a high risk to their rights and freedoms. The threshold is therefore higher than for notifying the authority.

It falls away, among other cases, where the data are unintelligible to unauthorised persons through appropriate measures such as encryption, where subsequent measures ensure the high risk is no longer likely to materialise, or where individual communication would involve disproportionate effort — in which case a public communication takes its place.

For a typical mistaken entry of individual customer details into an AI tool, a high risk can often be ruled out — often, not always. With health data, application documents or financial data the assessment looks different. If you are unsure, speak to the supervisory authority; it can order communication under Article 34(4) in any event.

Step 5: clean up at the provider

Technical damage limitation runs in parallel with the legal assessment. Four steps, in this order:

1. Delete the conversation or chat history — after you have secured the evidence.
2. Switch off the use of inputs for model improvement, if it was active. That has no retrospective effect, but it stops the position getting worse.
3. Request deletion from the provider, through their data protection contact. Ask for written confirmation — it is a strong point in the notification and in the record.
4. Document the response, including where none comes. The attempt counts in the assessment.

Step 6: document it — even if you do not notify

Article 33(5) GDPR requires you to document all personal data breaches, comprising the facts, their effects and the remedial action taken. That applies whether or not you notified. The documentation must enable the supervisory authority to verify compliance.

In practice: an incident register with one line per case, and a file per case. The most common failing in reviews is not the missing notification. It is the missing documentation of the cases where you decided against notifying.

Further duties that can arise

• Contractual notification duties. Check customer contracts and non-disclosure agreements — many contain their own deadline, and it can be shorter than 72 hours.
• Your role as processor. If you are yourself a processor for the customer, Article 33(2) GDPR applies: you notify the controller without undue delay, not the authority.
• Employee representatives. Where employee data were affected, informing the representative body is normally appropriate, and in some jurisdictions required.
• The AI Act. There is no general incident reporting duty for deployers. The serious incident reporting duty in Article 73 concerns providers of high-risk systems. For the case described here it is normally not engaged.
• Sector rules. Financial services, health and providers of essential services carry their own incident reporting regimes with their own, often shorter, deadlines. Those run independently of the GDPR clock.

Three variants and how they typically assess

So that the abstract test becomes usable — without this classification replacing your own assessment:

Facts	Typical assessment
A single customer name with a company address, entered into a tool with a business agreement and training use disabled	Breach doubtful, or risk very low; document it, notification usually unnecessary — record the reasoning
A customer list of fifty names, email addresses and turnover figures in a personal free account	A breach has occurred and risk cannot be excluded; notification under Article 33 is normally indicated
A complete job application with CV in a personal account	A breach has occurred; risk elevated because of the type of data, and communication under Article 34 should be seriously considered

The boundaries are fluid, and supervisory authorities do not assess identically. If you are wavering, notify. A notification that later proves unnecessary carries no sanction. An omitted one that was necessary does.

Afterwards: the actual value of the incident

Every reported incident exposes a gap nobody could see beforehand. Four questions, a week later:

1. Why was this tool being used? Is an approved alternative missing? Then the incident is a procurement matter, not a discipline matter — see shadow AI in the workplace.
2. Was the rule known and comprehensible? “No sensitive data” is not a rule, it is a mood. Specific examples work.
3. Was there a permitted route? If the placeholder approach was not known, the training was too abstract.
4. How long did the report take? From the entry to the management becoming aware. Anything over a day suggests the reporting route is not perceived as consequence-free.

Feed the result into the AI policy and into the training. An incident that turns into a rule has paid for itself.

Whether that reporting route exists in your organisation is one of the points in the free quick check. If you are reviewing your external channels in the same session, the free AI labels cover the disclosures for chat windows and AI images.

Frequently asked questions

An employee entered customer data into ChatGPT — what comes first?

Record the facts in writing, secure evidence with screenshots, stop further entries, involve the data protection officer and note the time you became aware. The Article 33 GDPR clock runs from that awareness. Do not sanction anyone, or the next case will not be reported.

When do the 72 hours start?

From the point at which the controller becomes aware of the breach, not from the incident itself. The period runs on calendar time, so weekends and public holidays count. 72 hours is the ceiling; the provision requires notification without undue delay.

Do we always have to notify?

Notification is the rule. It falls away under Article 33(1) GDPR only where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. You have to reason and document that assessment — and in a review the reasoning matters more than the outcome.

Do we have to inform the affected customers?

Only where a high risk is likely, under Article 34 GDPR. The threshold is higher than for notifying the authority. For individual contact details a high risk can often be ruled out; for health, application or financial data, less so. The supervisory authority can order communication in any event.

Is deleting the chat history enough?

It is a necessary step but not a complete remedy. Request deletion from the provider as well and obtain written confirmation. Never assure anyone of complete removal from a model that has already been trained — that generally cannot be assured.

Do we have to document the incident even if we do not notify?

Yes. Article 33(5) GDPR requires documentation of all breaches with the facts, their effects and the remedial action, independently of notification. The most common failing in reviews is not the missing notification but the missing documentation of cases where notification was deliberately not made.

Does the incident trigger a reporting duty under the AI Act?

Normally not. The serious incident reporting duty in Article 73 of the AI Act is addressed to providers of high-risk systems. For a deploying company in the situation described here it is not engaged; Articles 33 and 34 GDPR are what govern.

Which supervisory authority do we notify?

The one competent for you, which depends on where you are established and in several member states on the region as well. If you process across borders, identify your lead supervisory authority in advance rather than on the day. Check your customer contracts too — many contain their own notification deadline, sometimes shorter than 72 hours.