The European Data Protection Board's draft guidelines on web scraping for generative AI, published on July 7, 2026, reveal a pattern: teams building AI systems consistently misinterpret how the General Data Protection Regulation (GDPR) applies to training data. These aren't edge cases. They're structural mistakes that emerge when engineering timelines collide with data protection obligations.
The errors cluster around role confusion, legal basis shortcuts, and a persistent assumption that "public" means "permissible." Each mistake compounds the next, and by the time your model is in production, you're defending decisions made months earlier with incomplete compliance logic.
Why These Mistakes Keep Happening
AI development often outpaces compliance frameworks. Your data science team needs datasets immediately, while your legal team is still mapping controller relationships. The result: teams scrape first, justify later, and discover mid-project that their legal basis doesn't hold or their transparency obligations are unworkable at scale.
The EDPB guidelines don't create new obligations. They clarify existing ones in a context where the stakes are higher and the data volumes are larger than traditional GDPR scenarios. The consultation window remains open until October 30, 2026, but the compliance principles are already binding.
Mistake 1: Misidentifying Your Data Protection Role
Why it happens: Teams assume that if they hire a third-party scraper or buy a pre-scraped dataset, they're off the hook for upstream compliance. The logic goes: "We're just the processor; the scraper is the controller."
The consequence: You structure contracts and compliance programs around the wrong obligations. When a Data Subject Access Request arrives or a supervisory authority investigates, you discover you're a controller with independent responsibilities you never documented.
The fix: Map roles before you scrape. If your AI development team and the scraper jointly determine what data to collect and from which sources, you're likely joint controllers. If you acquire a pre-scraped dataset from a data broker and reuse it for model training, you're a separate controller responsible for your own processing. Document this analysis. Your contractual terms, privacy notices, and compliance measures all flow from getting this right.
Mistake 2: Defaulting to Consent as Your Legal Basis
Why it happens: Consent feels safe. It's the legal basis everyone understands, and teams assume that if data is publicly posted, the individual "consented" to its use.
The consequence: The EDPB is explicit: simply making data publicly available does not constitute consent to scraping. Consent requires a freely given, specific, informed, and unambiguous indication of the data subject's wishes. When you're scraping at scale from sources where you have no direct relationship with individuals, consent is typically unavailable. Building your compliance program on an unworkable legal basis means your entire processing activity lacks lawful grounds.
The fix: Shift to legitimate interests as your legal basis, but do it properly. You need all three limbs: identify a genuine legitimate interest, demonstrate that processing is necessary to achieve it, and document a balancing test showing your interests don't override those of data subjects. The balancing test isn't a formality. It must be tailored to your specific processing activity, account for reasonable data subject expectations, and incorporate technical and organizational measures that reduce privacy impact.
Mistake 3: Treating Data Minimisation as a Post-Collection Problem
Why it happens: Teams prioritize getting the largest possible dataset, assuming they can filter or cleanse it later. The engineering mindset is "collect everything now, decide what we need later."
The consequence: You violate the data minimisation principle from the moment of collection. The GDPR requires that personal data be adequate, relevant, and limited to what is necessary. The EDPB calls this a "major challenge" for large-scale scraping but confirms the principle applies from pre-collection through output. Post-collection cleansing doesn't cure an over-broad initial collection.
The fix: Build data minimisation into your scraping architecture before you start. Define collection criteria in advance. Implement filters to exclude sensitive data categories, high-risk websites (such as those directed at minors), and sites that explicitly prohibit scraping. Consider synthetic data as a substitute for real personal data where feasible. Your scraper configuration should reflect your documented processing purpose, not an aspirational "we might need this later" approach.
Mistake 4: Assuming Disproportionate Effort Exempts You From Transparency
Why it happens: Teams read the disproportionate effort exemption as permission to skip individual notification entirely when scraping at scale. The logic is: "We're collecting data from millions of people across thousands of sources over many years. Individual notification is impossible, so we're exempt."
The consequence: The exemption isn't a blanket pass. It requires case-by-case justification considering the number of data subjects, the age of the data, and safeguards you've adopted. Even when the exemption applies, you still need a publicly accessible privacy notice. The EDPB provides examples: large-scale collection spanning 20 years with no direct identifiers may qualify; targeted collection from 5,000 identifiable individuals over two years likely doesn't.
The fix: If you're relying on disproportionate effort, publish a detailed privacy notice that includes the sources you're scraping (to the greatest extent possible), whether those sources are publicly accessible, your crawler's characteristics, domain names and URLs of scraped pages in searchable format, the date range of collection, and contact details of originating controllers where you've purchased data. Consider conducting and publishing a data protection impact assessment. Transparency isn't optional just because it's difficult.
Mistake 5: Ignoring Special Category Personal Data Until It Surfaces in Outputs
Why it happens: Teams know they shouldn't collect special category personal data (racial or ethnic origin, political opinions, religious beliefs, health data, sexual orientation), but at web-scraping scale, filtering it out before collection seems technically impossible. The assumption is: "We'll handle it if it becomes a problem."
The consequence: Special category personal data requires an Article 9(2) condition. If you've collected it without meeting one of those conditions, your processing is unlawful. Worse, if that data makes it into your training set, your model may generate outputs that reveal or infer special categories, compounding the violation.
The fix: Implement measures across the full lifecycle. Filter at collection where possible. Delete special category personal data post-collection. Design your model to resist privacy attacks during development. Apply output filtering post-deployment with ongoing monitoring. The EDPB references a framework from GC & Others (C-136/17) that may apply where collection is genuinely incidental, difficult to detect, and accompanied by robust safeguards, but you need to document how you meet each criterion.
Mistake 6: Skipping Accuracy Validation Because "It's User-Generated Content"
Why it happens: Web-scraped data is often unreliable: outdated, user-generated, or sourced from sites with no editorial standards. Teams assume the accuracy obligation doesn't apply because they didn't create the inaccuracies.
The consequence: The accuracy principle applies to both the data you collect and the outputs your trained model produces. Inaccurate training data increases the likelihood of outputs that are factually wrong or harmful. When your model generates false information about an identifiable person, you're responsible under the GDPR regardless of where the underlying data originated.
The fix: Timestamp data at collection. Restrict scraping to credible sources where possible. Validate data before it enters training pipelines. Build accuracy checks into your model evaluation process. If you can't verify accuracy, consider whether that data source should be excluded entirely.
Prevention Checklist
Before you scrape:
- Document your data protection role (processor, controller, joint controller) with legal justification
- Identify and document your legal basis (legitimate interests with completed balancing test, not consent)
- Define collection criteria that reflect data minimisation from the outset
- Configure filters to exclude special category personal data and high-risk sources
- Draft and publish a detailed privacy notice covering sources, dates, and safeguards
- Establish accuracy validation procedures for both inputs and outputs
- Conduct a data protection impact assessment if processing is high-risk
- Set up processes for Data Subject Access Requests, deletion requests, and accuracy corrections
- Document technical and organizational measures at each stage: collection, storage, training, deployment
- Schedule compliance review before model deployment, not after
Publicly available data remains subject to the GDPR. The compliance burden falls on you before scraping begins, and shortcuts made early in the project become liabilities when supervisory authorities ask how you justified your approach.
