I wanted to understand how GDPR and other EU data rules influence data preparation and logging for LLM training and inference.
Below is my understanding, written in the form I would want to read as an AI researcher and engineer. Most of the rules make sense to me. They largely ask teams to know their data, limit unnecessary collection, test whether models expose personal information, and keep evidence of the decisions they make.
This is an engineer’s reading of the current framework, not legal advice.
Takeaway 1: Know what is in your data, and do not train on what you cannot defend
As an engineer, I want provenance anyway: which sources, which crawl, which filters, and which snapshot. It turns out that this is close to what the law wants too.
The location of a data center does not decide whether GDPR applies. Article 3 of the GDPR covers processing connected to an EU establishment regardless of where the processing occurs. It can also cover organisations outside the EU when their processing relates to offering goods or services to people in the EU, or monitoring their behaviour there.
For model builders, EDPB Opinion 28/2024 says legitimate interest may provide a legal basis for developing or deploying an AI model. It is not a blanket permission. The controller must identify a legitimate interest, show that the processing is necessary for it, and balance that interest against the rights and freedoms of the people concerned. The assessment depends on the purpose, data, sources, safeguards, and reasonable expectations in each case.
That sounds like paperwork, but much of the evidence should already exist in a well-run data pipeline. Source manifests, crawl dates, filters, dataset versions, and decisions to exclude sources make the assessment reviewable. The EDPB’s 2026 web-scraping guidance also recommends reliable sources, timestamps, validation before training, and measures that limit the personal data collected.
Europe does not ban AI training. It asks you to show your work. Clearview AI is the cautionary example for teams tempted to scrape first and ask questions later. Several European authorities found its face-data processing unlawful, and the Dutch authority imposed a EUR 30.5 million fine.
A “canary string” acts as an early warning system for data leakage. These are harmless, easily identifiable strings embedded in the training data. If your deployed model does not reproduce the canaries during membership inference tests, you have the legal and engineering evidence needed to demonstrate that your AI system is ready to protect sensitive user data and support GDPR compliance.
Takeaway 2: Models memorise, so deduplicate and scrub before training
Every practitioner knows that memorisation grows with duplication, and that a model fine-tuned on raw support tickets may recite them. We therefore deduplicate aggressively and remove names, email addresses, account numbers, and other identifiers at ingestion. This can improve the dataset while reducing the attack surface.
The law arrives at the same problem from another direction. Opinion 28/2024 says that a trained model is not automatically anonymous. Anonymity must be assessed case by case. The relevant questions include whether someone can be identified from the model and whether personal data can be extracted through queries. Both outcomes must be very unlikely before a controller can treat the model as anonymous.
The engineering translation is straightforward. Insert canary strings before training. Run extraction probes and membership-inference tests after it. Record the test setup, model version, results, and limitations. For fine-tuning on sensitive records, prefer synthetic rewrites or carefully de-identified examples over raw logs. Small datasets can memorise hard.
You would want these tests for model quality and security anyway. Keep the results, because they also become part of the evidence supporting your data-protection assessment.
Takeaway 3: A deletion request is a data-lineage problem
My naive expectation was that one deletion request might force a full retraining run or the withdrawal of an API. The real answer is more conditional.
Article 17 of the GDPR gives people a right to erasure in specified circumstances, with exceptions. Opinion 28/2024 then asks whether the trained model itself still contains personal data or can be treated as anonymous. It does not establish one universal procedure for every model and every request.
A practical engineering response should still cover three layers. Remove the person’s data from retained datasets and snapshots where erasure is required. Add the relevant identifiers or source records to an exclusion mechanism so later training runs do not reintroduce them. Then test the deployed model for extraction or regurgitation connected to the request.
Those steps are only possible if the infrastructure exists: versioned dataset snapshots, per-source or per-shard provenance, a working rights-request channel, and repeatable memorisation tests. Output filters can reduce immediate exposure, but they do not by themselves answer whether personal data remains in the model. If testing shows that the model exposes personal data, the controller needs a case-specific remediation plan and legal assessment.
The practical lesson is not that checkpoints are exempt. It is that deletion has to be designed into the training system before the first request arrives.
Takeaway 4: Log metadata, not payloads
For inference, billing needs token counts, timestamps, model IDs, status codes, and latency. It usually does not need prompts and completions.
The sensible default is therefore to minimise payload retention, make debug logging time-limited and explicit, and avoid training on API inputs unless the customer has agreed. Major commercial APIs have moved in this direction. OpenAI and Anthropic say that business or commercial API inputs and outputs are not used for training by default. Mistral documents separate controls for API training and retention.
No training, zero retention, and EU data residency are different controls. No training governs whether customer content improves the provider’s models. Zero retention governs whether supported inputs and outputs are stored after processing. Residency concerns where data is stored or processed. Buyers often conflate the three, so state them separately and precisely.
What you never store does not need to be secured, searched, produced, or deleted later. Data minimisation is one of the rare cases where privacy, security, and operating simplicity all point in the same direction.
The difficult question: residency, transfers, and jurisdiction
One thing my engineer’s intuition got wrong was the idea that an EU-region checkbox settles the location question. It does not.
Preprocessing personal data is already processing. Depending on how a pipeline is designed, collection, remote access, or disclosure to a separate organisation in a third country may trigger the GDPR’s international-transfer rules. At the same time, storing data in an EU region does not remove every jurisdictional issue around the provider that operates the infrastructure.
The EDPB and EDPS analysis of the US CLOUD Act describes possible conflicts between US disclosure orders and EU data-protection law. That does not mean every EU workload on a US-owned cloud is automatically an unlawful transfer. It does mean that residency, corporate control, government-access exposure, encryption, subprocessors, and contractual safeguards must be evaluated separately.
This is the decision that is hardest to retrofit. Source filtering, memorisation tests, and retention controls can be improved over time. Changing the legal and operational boundary around an established data pipeline is much harder.
Does the EU enforce this?
Yes, through national data-protection authorities, coordinated through the EDPB, and through the courts that review regulatory decisions.
Italy’s Garante temporarily restricted ChatGPT in 2023. In 2024 it imposed a EUR 15 million fine on OpenAI, including findings about legal basis and transparency. The same Garante page now records that the Court of Rome upheld OpenAI’s appeal in a judgment published on March 18, 2026, and the authority temporarily removed the decision.
That cuts both ways. Regulators can intervene, and courts can check them. A multi-year dispute is still expensive evidence that teams should build the paperwork and technical controls before a conflict starts.
The proposed Digital Omnibus, published in November 2025, would make the AI-training position more explicit. The Commission proposal says legitimate interest may support AI development and operation under the existing balancing test and other GDPR duties. It also proposes safeguards including data minimisation, protection against retained-data disclosure, greater transparency, and an unconditional right to object. It remains a proposal, not current law.
It makes sense on paper
Most of what EU data law asks from a model builder is engineering you would want anyway: provenance manifests, deduplication, personal-data filtering, memorisation tests, snapshot versioning, and restrained logging. Compliance evidence should fall out of the pipeline, not out of a lawyer’s drawer.
The less obvious addition is jurisdictional. Decide who operates the machines, which entities can access the data, which laws can compel them, and which safeguards apply from the first crawl to the last inference token.
Whether the framework works in practice depends on how it is enforced. When regulators publish the reasoning, not just the fine, the community can learn from it and enforcement becomes education. That is the version I would like to see: regulators educating builders and the public first, instead of making them spend years in court to discover what the rules meant.
The Garante and OpenAI dispute shows how much clarity is still being produced the expensive way. How it develops from here, we will see.