Data Protection · AI & GDPR
Is Even One Record Accidentally Fed to AI a Data Breach?
When people hear data breach, they think of massive attacks stealing millions of passwords. Under the GDPR, though, the reality is subtler. What happens if an employee, an intermediary or a developer accidentally pastes the name and email of a single client into a chatbot like ChatGPT, or into a development tool like Claude Code? Is it a data breach? And does it change anything if we disabled model training? Let's clear this up.
The "minimum number" myth: a single record is enough
The GDPR is clear on one point: there is no minimum threshold of affected users. Under Article 4(12) of the Regulation, a "personal data breach" is any breach of security leading — even accidentally — to unauthorised access, alteration or disclosure of personal data — so even one person's data can be enough. Note, though: not every use of an AI is automatically a breach. A properly contracted and configured corporate service is different from a personal or unapproved account. It is the absence of authorisation (and the related safeguards) that triggers the breach: putting a client's data into an external, unauthorised AI is exactly that kind of unauthorised disclosure.
AI and data breach: the role of "training"
The scale of the harm and the actions to take depend largely on the privacy settings of the profile used (ChatGPT, Claude or the Claude Code CLI) — but not only: the GDPR assessment also weighs the nature and sensitivity of the data, the recipient, identifiability and the measures in place. With that caveat, the scenario splits into two typical cases.
Case 1 — Profile with training on (no opt-out)
If the data went into a consumer account with the 'help improve the model' option enabled, the AI may use that information to train its algorithms, and logs are retained for a long time.
- Long retention. In Anthropic's case, with training consent the data stays in de-identified form for up to 5 years in the training pipelines.
- The risk. The probability is low, but there is a theoretical risk that the model "learns" that record and could surface it to other users in the future.
- Internal register. Once the incident is qualified as a breach, it must be logged in the company's data-breach register: Article 33(5) GDPR requires documenting every breach, regardless of outcome and even when no notification is due.
- Notification: to assess, with two distinct tests. To the authority (within 72 hours of becoming aware) when the risk to rights is not unlikely (Art. 33); to the data subjects only if the risk is high (Art. 34). Special-category data raise the risk, but do not make both notices automatic.
- Mitigation (not a guarantee). Deleting the chat and requesting removal via the OpenAI or Anthropic form reduces exposure, but deletion from the interface does not mean immediate erasure from logs, backups or already de-identified datasets.
Case 2 — Profile with training off (opt-out) or commercial API
If you disabled training in the profile, or use the commercial APIs and products, the situation changes radically.
- No training — but check the retention. Opt-out prevents the data from being used for training, but does not amount to automatic deletion. On Anthropic, deleted chats are removed from the systems within ~30 days; on ChatGPT, disabling training does not delete normal chats (they stay in history until you delete them): the 30 days apply to temporary chats or after manual deletion. Commercial products and APIs, as a rule, do not use prompts for training and offer — by agreement and where eligible — Zero Data Retention options.
- "No training" solves only one aspect. Retention, sub-processors, abuse monitoring and possible international transfers remain: the absence of training does not equal GDPR compliance.
- The risk. Often more contained — the data does not feed models accessible to others — but not automatically negligible: it depends on the nature and sensitivity of the data, the recipient and the measures. In any case, the more immediate risk is the disclosure of the data to the provider and its systems, not a future model output.
- Internal register: always. Once qualified as a breach, the incident must go into the data-breach register (Article 33(5)) — the severity changes, not the documentation duty.
- External notification: likely not required. Not because the event "disappears", but because Article 33 exempts notification to the authority when a risk to rights and freedoms is unlikely — a plausible condition here. The assessment, however, must still be made and documented.
The difference between a potential legal disaster and a negligible hiccup is not the mistake itself, but how you configured — and can prove — the processing.
The operative principle
Good practices for development: Claude Code
The risk has recently extended to developers, with terminal tools like Claude Code (Anthropic's CLI). When the tool reads your source code or local databases to help you program, it may run into strings of real client data.
Mind the detail that slips through: if you use Claude Code on a consumer profile (Pro or Max), the tool inherits your web-account settings. If you haven't withdrawn training consent on Claude.ai, your terminal logs too may end up in training. Via API or commercial products, by contrast, prompts are not used for training.
The golden rule for companies: for professional development, using consumer accounts is a grey zone. It typically lacks the whole contractual framework of a governed corporate processing — starting with the Data Processing Agreement (DPA) that Article 28 GDPR requires when the provider acts as a processor, plus documented instructions, administrative controls and defined privacy roles. The correct path is to use Claude Code (and AI in general) through corporate API/commercial products with a DPA, which exclude data from training and allow, where eligible, Zero Data Retention options.
Quick checklist: what to do when a record is pasted into an AI
In conclusion
Human error in the AI era is around the corner, but the technology itself offers the means to limit its impact. Configuring profiles correctly — turning off training, choosing products with a DPA and defined retention — is the most effective shield a company can raise to downgrade a potential legal disaster to a thirty-day hiccup. On one condition: that the configuration is not merely an intention, but written into policy, enforced on the tools and demonstrable if audited.
Does your company use AI in a demonstrably compliant way?
Tomato Blue helps companies define AI-usage policies, choose tools with proper DPAs and retention, and build the register and evidence ready for a possible supervisory-authority audit.
Talk to us →Sources
Regulation (EU) 2016/679 (GDPR), Arts. 4(12), 28, 33 and 34; EDPB, Guidelines 9/2022 on personal data breach notification; Anthropic Privacy Center — "How long do you store my data" (privacy.claude.com): with training consent, consumer data is kept de-identified for up to 5 years, deleted chats are removed within ~30 days, and for the API standard retention is within 30 days unless a Zero Data Retention agreement applies; OpenAI — Data Controls / Enterprise Privacy: disabling training does not delete normal chats (30 days for temporary chats or after deletion), Business/Enterprise/API are not used for training by default, ZDR where supported. This article describes the general framework; specific product settings may change over time.
This article is for informational purposes only and does not constitute legal advice nor replace professional counsel tailored to the specific case. The positions expressed reflect the analysis of Tomato Blue RegTech.