Ask a room of compliance officers whether web scraping for AI training is legal in Europe, and you'll get a range of confident answers. Most rest on assumptions that don't hold up under the GDPR text. These myths persist because the practice has moved faster than guidance, and because "publicly available" sounds like a legal category when it isn't.
EPIC's recent comments to the European Data Protection Board (EDPB) on its draft Guidelines on Web Scraping to Train Generative AI highlight the issue. They argue the draft doesn't go far enough, and the gaps they identify align with the myths below. If you advise a business that builds, buys, or fine-tunes models, here's where your assumptions may be wrong.
Myth 1: "If data is publicly accessible, we can scrape it"
Reality: Public availability is about access, not legality. The GDPR requires a lawful basis under Article 6 for any processing of personal data, regardless of where the data is found.
EPIC's analysis concludes that the only plausible basis for large-scale scraping is legitimate interest. This requires a balancing test: the controller's interest weighed against the risk to individuals' rights and freedoms. EPIC argues developers will likely fail this test for three reasons. Generative systems incorporate training data into the model itself. AI can draw inferences and re-identify de-identified individuals. And hardly anyone posted their data publicly expecting it to be used to train a model.
Treat "it was public" as one weak input to the balancing test, not as a shortcut around it.
Myth 2: "We're not covered because we didn't scrape this for AI"
Reality: This is the loophole EPIC flags in the draft Guidelines. The current scope excludes scrapers who create data sets not explicitly intended for AI training initially.
This exclusion leaves out data brokers, who often assemble massive scraped data sets and sell them for multiple purposes. If a broker's data set is out of scope, the pre-scraping steps the Guidelines recommend never apply: defining a data scope, establishing a legal basis, performing a risk assessment. Those obligations don't disappear for you. When you buy or license a data set that later feeds a model, you're a controller (or joint controller) for what you do with it.
Don't rely on a vendor's statement of original purpose. Ask where the data came from, what legal basis supported collection, and whether you can document it. Your supply chain diligence should treat purchased data sets like any third-party component with unknown origins.
Myth 3: "A notice on our website satisfies transparency"
Reality: The draft Guidelines acknowledge that notifying individuals may be impossible or burdensome, suggesting a notice on the company's website. EPIC's objection is hard to rebut. An individual would have to suspect their data was scraped, identify which companies used it for training, find the notice, and then contact the company to exercise their rights. This chain doesn't work in practice.
Transparency under the GDPR exists so people can exercise their rights. A notice nobody can realistically discover fails that purpose. If your compliance relies on a website banner as your transparency measure, treat it as a known weakness, not a defense. Regulators are being urged to reject this approach.
Myth 4: "We can honor deletion and correction requests after training"
Reality: Data subject rights are the practical pressure point. EPIC notes that once a system has been trained on personal data, individuals will find it nearly impossible to get it corrected or deleted. Training data becomes embedded in model parameters, so there's no row to delete.
This matters for your Data Protection Impact Assessment. If you can't describe how an erasure or rectification request would be fulfilled for a trained model, the assessment should say so, and the residual risk should be rated accordingly. Retraining on a filtered data set, output filtering, and unlearning techniques each have limits you should document honestly.
Myth 5: "Data minimization is satisfied by cleaning the data afterward"
Reality: Minimization is a collection-stage principle. EPIC's position is that mass scraping is inherently against data minimization: you can't collect everything and then claim you only needed a fraction. Post-hoc filtering reduces exposure but doesn't justify the collection retroactively.
EPIC recommends more concrete requirements for cleaning scraped data sets before training, but as a harm-reduction measure, not a cure. The sequence matters. Define scope first, collect only what that scope justifies, then clean.
What to do instead
You don't need to wait for the final Guidelines to tighten your posture. EPIC's recommendations point to the direction of travel, and they're a useful stress test for your program:
- Inventory data provenance. For every training and fine-tuning data set, record the source, collection method, and legal basis. Include purchased and licensed sets.
- Document the legitimate interest assessment. Write the balancing test honestly, including inference and re-identification risk, and be prepared for it to fail.
- Default to no scraping without permission signals. Treat pages as off-limits unless an indicator like robots.txt affirmatively permits scraping for AI training. Adopting this as internal policy puts you ahead of the likely trajectory.
- Plan for rights requests before training. Decide how access, correction, and erasure will work for a trained model, and record the limits.
- Expect transparency to get stricter. EPIC recommends a public registry of companies using scraped data for AI training, covering what was scraped, from what sources, for what purpose, and how to exercise rights. Building that information now costs little compared with reconstructing it later.
The industry is betting that regulators will defer to innovation arguments. That's a bet on enforcement behavior, not a compliance strategy. Build your program on what the GDPR says.
