The short answer
At its July 2026 plenary the European Data Protection Board (EDPB) adopted Guidelines 03/2026 on web scraping in the context of generative AI — the first pan-EU framework confirming that the GDPR applies in full to personal data scraped to train AI models, with no carve-out for AI. The draft is open for public consultation until 30 October 2026, but it already tells you where enforcement is heading.
The headline shifts are concrete: consent is unlikely to be a valid legal basis for scraping, legitimate interest only survives a documented three-part test, sensitive data carries a near-prohibition, and — critically — once a model is trained, personal data cannot be easily deleted from it. That turns AI data governance into an upstream engineering problem, and a live GDPR question you have to answer before training, not after launch.
What did the EDPB actually publish?
The EDPB — the body that coordinates national data-protection authorities across the EU — adopted Guidelines 03/2026 on web scraping in the context of generative AI at its July 2026 plenary in Brussels, releasing version 1.0 for public consultation. It is the first time the Board has addressed, in one document, the specific practice at the heart of modern AI: extracting personal data from the open internet to train large language models and other generative systems.
The core finding is deceptively simple. The GDPR applies whenever web scraping involves personal data processing operations — "collection, storage, organisation and retrieval" — and there is no special exemption because the purpose is AI training. For years, some labs treated the open web as a free-for-all input. The guidelines close that door: if the pages you scrape contain personal data of people in the EU, every one of those processing steps is regulated, whether you are OpenAI-scale or a startup fine-tuning an open model on a domain corpus.
This did not arrive in a vacuum. Italian, Irish, Dutch and French authorities had already taken enforcement action against AI companies — fining providers, blocking a chatbot from training on EU posts, and pursuing smaller developers for scraping without a lawful basis — but each acted under its own reading of the law. Guidelines 03/2026 hands all 27 national regulators a single rulebook, which is exactly what makes it matter for teams that build or commission AI and data products: the standard is now consistent across the bloc.
Why doesn't consent work for scraping?
The most consequential clarification is about legal basis. Under the GDPR, any processing of personal data needs one of six lawful bases, and for scraping the two candidates are consent and legitimate interest. The EDPB is direct that consent "will most probably not serve as a workable legal basis for scraping." The reasoning is practical: a controller scraping millions of pages has no direct relationship with the individuals behind that data, and cannot realistically obtain valid, informed, freely given consent from each of them.
The Board also shuts down a convenient assumption. As it puts it, "a person making their data available on an openly accessible web page has not thereby consented to that data being scraped for a specific purpose such as AI training." Public visibility is not permission. That single sentence dismantles the informal justification a lot of early datasets relied on — "it was on the open web, so it was fair game" — and it applies equally to a frontier lab and to a team assembling a retrieval corpus from scraped pages.
With consent effectively off the table for large-scale scraping, legitimate interest becomes the realistic basis. But it is not a free pass — it comes with a test you have to pass and document.
Legitimate interest and its three-part test
The guidelines frame legitimate interest as a three-condition test, and all three must hold. First, there must be a legitimate interest pursued by the controller or a third party — the EDPB gives examples such as developing conversational agents, detecting fraudulent content and improving threat detection. Second, the processing must be necessary to achieve that interest, meaning you cannot reach the same goal with less personal data. Third, a balancing test must confirm that the data subjects' rights and freedoms do not override the controller's interest.
For engineering and product teams, the operational word is documented. A legitimate-interest assessment (LIA) is not something you reconstruct after a complaint; it has to exist before scraping begins, and it has to show your working — what interest, why this data, what alternatives you rejected, what safeguards you added, and how the balance tilts in favour of proceeding. Necessity, in particular, pushes toward data minimisation: collecting narrowly for a defined purpose is easier to defend than hoovering up everything "in case it's useful later," which is also a red flag under the purpose-limitation principle the guidelines emphasise.
Transparency sits alongside this. The Board recognises that individually notifying every scraped person may be impossible or require disproportionate effort — but where that exemption applies, a publicly available privacy notice is described as a measure the controller "must always take," setting out the categories of data, the legal basis and the sources. In other words, the exemption from personal notice is not an exemption from transparency.
What about health and financial data?
Large-scale scraping inevitably sweeps up sensitive material, and here the guidelines are strict. Special categories of data — including health data and data revealing other protected attributes — are generally prohibited from processing under Article 9, and lifting that prohibition requires both a lawful basis under Article 6 and a specific Article 9(2) exception. For open-web scraping, few of those exceptions realistically apply, which makes indiscriminate collection of sensitive data very hard to justify.
Drawing on the Court of Justice's reasoning in GC and Others (C‑136/17), the EDPB accepts that some incidental or residual collection of special-category data may be tolerated where a controller genuinely cannot detect it in advance — but only if appropriate safeguards are in place and the data is deleted once identified. The obligation, in practice, is engineering work: classifiers and filters that screen sensitive content out of a training set, plus a deletion path for anything that slips through. For regulated domains such as HealthTech and FinTech, "it was publicly available" is nowhere near a defence — the presumption runs the other way, and you are expected to actively keep this data out.
Why "delete my data" breaks after training
The most technically significant point for builders is about erasure. The EDPB observes that once a model has been trained, personal data cannot be easily deleted from it. Weights are not a database row you can drop; a person's information, once learned, is diffused across parameters in ways that resist targeted removal. That collides head-on with GDPR rights such as erasure and rectification, which assume data can be located and acted upon after the fact.
The compliance consequence is unavoidable: you cannot fix a training-data problem after the model ships, so governance has to move upstream. Curate, minimise and document the dataset before the training run, because the alternatives — retraining from a clean corpus, or defending a model you cannot cleanly remediate — are expensive and slow. This is where compliance stops being a legal formality and becomes an architectural decision, and it ties directly into the risk-management and documentation duties teams already face under the EU AI Act. The two regimes are converging on the same demand: know what went into your model, and be able to prove it.
What it means for US & EU software teams
Strip away the legal detail and three practical signals remain. First, scope is broad and extraterritorial: if you build or commission generative AI that touches the personal data of people in the EU — including US companies serving EU users — these expectations reach you, regardless of where your servers sit. "We scraped it in the US" does not put an EU-facing dataset outside the GDPR.
Second, the work is now upstream and documentary. Before a training or fine-tuning run, you need a recorded lawful basis (in practice, a legitimate-interest assessment), a data-minimisation rationale, a public transparency notice, and filters that keep special-category data out with a deletion path for what slips through. None of that is exotic — it is the same "know your data" discipline good AI and data engineering already values — but it now has to be evidenced, not assumed. Teams that treat a scraped corpus as a black box will struggle; teams that can produce a dataset lineage will not.
Third, this is the direction of travel even though it is a draft. Consultation runs to 30 October 2026 and wording may shift, but the core positions — GDPR applies, consent rarely works, legitimate interest needs a test, sensitive data is near-prohibited, models can't be un-trained — are consistent with how European regulators have already been acting. The pragmatic move is to build for them now rather than wait for a final text, so a "future rule" doesn't become a launch blocker. Match the dataset to a defensible basis, keep the lineage, and make compliance a design input rather than an audit surprise — the same principle we apply to LLM fine-tuning engagements.
A practical compliance checklist
Nothing here is a new statutory deadline. It is the work that turns a fast-moving AI-data landscape into a routine review rather than a surprise at audit:
- Pick and document a lawful basis. For scraped data, run and record a legitimate-interest assessment — interest, necessity, balancing — before collection starts. Don't rely on consent.
- Minimise at the source. Collect narrowly for a defined purpose; broad "just in case" scraping fails the necessity and purpose-limitation tests.
- Filter out special-category data. Add classifiers to screen health, financial and other sensitive content, plus a deletion path for anything detected later.
- Publish a transparency notice. Where individual notice is impractical, a public privacy notice listing data categories, legal basis and sources is still mandatory.
- Record dataset lineage. Track what was collected, from where, when and under which basis — timestamps and validation included — so you can answer an auditor without re-deriving it.
- Govern before you train. Assume you cannot delete a person from a trained model; get the corpus right upfront and keep the ability to retrain from a clean, documented dataset.
This is not legal advice, and the right approach depends on your data, your markets and your model. But the signal from Guidelines 03/2026 is clear: the era of scraping the open web as an unregulated input is ending in Europe, and the teams that will move fastest are the ones who make their training data defensible by design.
Frequently asked questions
What did the EDPB publish on web scraping for AI?
At its July 2026 plenary the European Data Protection Board adopted Guidelines 03/2026 on web scraping in the context of generative AI, version 1.0. It is the first pan-EU framework that addresses collecting personal data from the open web to train AI models directly, and it confirms that the GDPR applies in full whenever scraping involves personal data of EU residents, with no carve-out for AI training. The draft is open for public consultation until 30 October 2026.
Can we rely on consent to scrape public web data for AI training?
In most cases, no. The EDPB concludes that consent will most probably not serve as a workable legal basis for scraping, because a controller has no direct relationship with the people whose data appears on public pages, and someone making their data available on an open web page has not thereby consented to it being scraped for a purpose such as AI training. Legitimate interest is the more realistic basis, but only after a documented three-part test.
What is the three-part legitimate interest test?
First, identify a legitimate interest pursued by the controller or a third party, such as developing a conversational agent or improving threat detection. Second, show the processing is necessary to achieve that interest and cannot be met with less data. Third, run a balancing test confirming the data subjects' rights and freedoms do not override that interest. The assessment must be documented before scraping begins, not reconstructed after an incident.
How do the rules treat health and financial data in scraped datasets?
Special categories of data such as health or data revealing financial or other sensitive attributes are generally prohibited from processing and require both a lawful basis under Article 6 and an exception under Article 9(2). The EDPB accepts that incidental or residual collection of such data during large-scale scraping may be tolerated only where detection is genuinely difficult and the controller applies safeguards and deletes the data on discovery. For HealthTech and FinTech teams, that means active filtering and deletion pipelines, not a blanket assumption that public means usable.
If a person asks to be removed, can we delete their data from a trained model?
Not easily. The EDPB notes that once a model is trained, personal data cannot be easily deleted from it, which is a real limit on GDPR rights such as erasure after deployment. The practical consequence is that data governance has to happen upstream: filter, minimise and document your training data before training, because retrofitting compliance into a trained model is far harder than getting the dataset right in the first place.
Sources
EDPB — EDPB sheds light on anonymisation and web scraping for generative AI (July 2026)
EDPB — Guidelines 03/2026 on web scraping in the context of generative AI (public consultation to 30 October 2026)
PPC Land — EDPB blocks AI firms from using consent as an excuse to scrape