On 7 July 2026 the European Data Protection Board adopted two draft guidelines that redraw where the GDPR stops applying to AI training data, and the consultation on both closes 30 October 2026. If your organization runs a training pipeline, a fine-tuning project, or a vendor whose pitch deck says "trained on publicly available data," the boundary you have been reasoning from just moved. The two documents are Guidelines 02/2026 on Anonymisation and Guidelines 03/2026 on web scraping in the context of generative AI, and the EDPB web scraping guidelines only bite once the companion anonymization test says what you are holding is personal data.
Data scraping has been on regulators' shared agenda at least since the 2023 joint statement by international privacy authorities, but that was a statement of concern. This is a test.
The two documents have to be read as a pair, in order. Guidelines 03/2026 only governs your pipeline if what you scraped or bought is personal data. Guidelines 02/2026 is the test that answers that question. Run them in the wrong order and you either apply a scraping compliance program to a dataset that never needed one, or (far more likely) you skip it because someone upstream called the data anonymous without testing that claim against a named framework. And because AI models can themselves process personal data rather than merely being trained on it, the anonymity question does not stop at the corpus.
Key Takeaways
- Anonymity is now explicitly entity-relative. The same dataset can be anonymous for one organization and personal data for another, and Guidelines 02/2026 requires the assessment to be run from each relevant entity's perspective, grounding that in the CJEU's ruling in C-413/23 P EDPS v SRB of 4 September 2025.
- The anonymization test has three criteria: No Record Isolation, No Linkage, No Inference. Pass all three and the data can be treated as anonymous; fail one and the data is not automatically personal, but you owe a deeper re-identification analysis before you can call it anonymous.
- Consent is effectively off the table for large-scale scraping, and the EDPB says the absence of a robots.txt file does not amount to consent. That leaves Article 6(1)(f) legitimate interest, with robots.txt, ai.txt, CAPTCHA, and login walls now carrying legal weight inside its balancing test.
The two 2026 EDPB guidelines at a glance
| Aspect | Guidelines 02/2026 on Anonymisation | Guidelines 03/2026 on web scraping for generative AI |
|---|---|---|
| Version and date | Version 1.0, adopted 7 July 2026 | Version 1.0, adopted 7 July 2026 |
| Core question | Is this data personal data at all, and for whom? | Given that it is personal data, what does GDPR require? |
| What it updates | The three-criteria framework in Article 29 Working Party Opinion 05/2014 | Builds on EDPB Opinion 28/2024 on AI models and Guidelines 1/2024 on legitimate interest |
| Test applied | No Record Isolation, No Linkage, No Inference (assessed per relevant entity) | Article 6(1)(f) three cumulative conditions, plus purpose limitation, transparency, minimization, accuracy |
| Scope limits | Applies to any assessment of anonymity under the GDPR | Private entities only; scraping from external sources; excludes pure data brokers who never train models |
| Consultation closes | 30 October 2026 | 30 October 2026 |
Neither document is final. That matters for how you use them: they are the clearest statement available of how European regulators will read these questions, and they are also the version you can still comment on. Treating them as binding today overstates their status; treating them as speculative understates it, because both build on positions the EDPB has already taken in Opinion 28/2024 and in its legitimate interest guidelines.
Step one: is your scraped dataset actually anonymous?
Guidelines 02/2026 replaces the framework in the Article 29 Working Party's Opinion 05/2014 — the first update to that test in over a decade. The single most consequential move in the new text is that anonymity is not a property of a dataset. It is a property of a dataset relative to a specific entity.
The EDPB's framing is that the core test asks two questions: does the information relate to a natural person, and is that person identified or identifiable. The answers may differ from one entity to another. Information can unambiguously relate to an individual while only one organization holds the additional information needed to identify them. For that organization the data is personal; for everyone else, absent particular circumstances, it is anonymous. The Board anchors this in the CJEU's judgment in C-413/23 P EDPS v SRB of 4 September 2025.
That has a practical consequence that catches teams out. If you anonymize a dataset for a recipient but retain the original yourself, you still hold personal data and still owe every GDPR obligation on it. The recipient's position does not change yours. And the Board is explicit that anonymization is itself processing: it needs an Article 6 legal basis, and an Article 9(2) exemption if the source dataset contains special category data.
EDPB Chair Anu Talus framed Guidelines 02/2026 as "a significant milestone in clarifying the notion of anonymous data" in the Board's announcement. The clarification is welcome; the operational load is real, and it lands squarely on whoever has to document the assessment.
The guidelines offer two ways to run the test. The contextual approach assesses anonymity separately for each relevant entity based on its actual capabilities. The simplified approach ignores those differences, which is more conservative, can classify data as personal even where it would genuinely be anonymous for some entities, and is easier to defend. The EDPB is clear that the simplified approach can go beyond the legal standard, and that it cannot be used by a third party to prove that data is personal.
One boundary rule quietly governs most real corpora: a dataset only counts as anonymous if anonymization is effective for every individual in it. Where a dataset holds a mix of personal and anonymous records, the entire dataset is treated as personal data in any situation where the parts are not actually handled separately. That is the rule that turns "most of this corpus is fine" into "all of this corpus is in scope."
The three criteria
| Criterion | Met when | Where it typically fails |
|---|---|---|
| No Record Isolation | The data contains no unique combination of attribute values relating to a single individual. Generally testable against the given data alone. | Records with many attributes. The EDPB notes that the larger a record and the more attributes it holds, the likelier it is unique. |
| No Linkage | Records cannot be matched to other records or external datasets relating to the same individual. Likely met where the information was not recorded elsewhere and is not correlated to similar information about the same person in other contexts. | Demographic quasi-identifiers, or any attribute set that recurs in a second dataset someone can reach. |
| No Inference | No specific and meaningful inference can be drawn. An inference is specific if it relates to one identifiable individual, and meaningful if it also relies on the given data, could not be obtained from general knowledge or population-level data, and is liable to affect the data subject's rights and interests. | Aggregate outputs, synthetic data, and models. The EDPB says specific inferences can be made by querying (or, for AI models, prompting) the given data, and cites attacks that extract data from supposedly anonymous models. |
Failing a criterion is not fatal on its own. The guidelines say that where one or more criteria is violated, you continue the analysis to assess the impact of that violation and whether the data can still be considered anonymous, for example by testing whether isolated records, possibly together with linked data, actually allow singling out.
The No Inference criterion is the one to read twice if you work on models. The EDPB's own text puts AI models and synthetic data in the frame, on the reasoning that data aggregated to represent correlations between elements of the original information can still support specific inferences when prompted with additional information. Commentators have gone further and argued that no current large language model reliably clears this bar; the guidelines themselves stop short of that conclusion. Either way, the practical instruction is the same one Giulio Coraggio of DLA Piper drew from the guidelines: anonymity now needs testing "per model and, arguably, per deployment," not once as a general policy.
If your existing documentation treats de-identified as equivalent to anonymous, that is the gap to close first. The distinction between pseudonymized and anonymized data has always mattered on paper; Guidelines 02/2026 gives regulators a named test to check it against.
Before you can document a legitimate interest assessment for a training pipeline, you need a current record of what that pipeline actually processes. Secure Privacy's Data Map & ROPA module captures purposes, legal bases, data categories, and retention periods per process and auto-calculates risk levels. That is the artifact the EDPB's data mapping and inventory expectation assumes you already hold.
Step two: what the EDPB web scraping guidelines require once data is personal
What the EDPB counts as scraping, and why crawl design is a compliance decision
The guidelines define web scraping as a commonly used technique that uses automated tools for extracting and storing information from publicly available web services, and they break the practice into four steps: defining the data collection criteria, extraction, cleaning, and structuring and storing. That sequence is worth holding onto, because most of what the document asks for attaches to the first step. The criteria you write before anything is fetched are what the necessity condition, the minimization assessment, and the exclusion lists all get judged against.
The Board then splits scraping in two. Targeted scraping applies specific collection criteria, such as URLs ending in .eu or content in particular languages. Untargeted scraping runs on an unrestricted basis, using crawlers with spiders: small programs given advance instructions to keep exploring links without strict limitation. The EDPB's stated concern is that untargeted collection may result in the exploration of a large portion of the internet and increases the risk that the controller has limited knowledge of what personal data are collected.
The guidelines do not prohibit the untargeted approach. But read that concern against the necessity condition below and the consequence is hard to avoid: a controller who cannot say what is in the corpus cannot demonstrate that collecting it was necessary, cannot filter what it did not know it held, and cannot answer a data subject who asks whether their data is in there.
Consent does not scale, and public visibility is not consent
The EDPB's position on consent is short and closes a door many organizations have been leaning on. Consent would most probably not be an applicable legal basis, because organizations scraping third-party data have no direct relationship with the data subject and cannot realistically identify and obtain consent from each person before collection.
Then the sharper point: when people publish personal data on a page anyone can reach, that does not mean they consented to it being scraped for a specific purpose. The Board goes one step further and states that the absence or non-applicability of a robots.txt file on a website does not amount to consent within the meaning of the GDPR. Silence upstream is not permission.
That leaves Article 6(1)(f). The EDPB acknowledges legitimate interest is what private bodies actually rely on here, and says the other Article 6(1) grounds will generally be less likely to apply, the same route the CNIL's guidance on AI and the GDPR had already taken at national level. If your team has been treating the choice between legitimate interest and consent as still open for training data, the guidelines effectively decide it for you — and then make the surviving option harder.
The three cumulative conditions, as the EDPB applies them to scraping
Condition 1: a legitimate interest. The interest must be lawful, clearly and precisely articulated, and real and present rather than speculative. For a general-purpose model whose end uses are not yet fixed, the EDPB recommends articulating the objective behind developing the model: commercial, public, scientific research, internal or external. Purpose limitation runs alongside this. The guidelines restate Article 5(1)(b), that personal data be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with them, and then refer back to Opinion 28/2024 rather than elaborating, so the detailed treatment of purposes in AI model development still sits in that opinion.
Condition 2: necessity. Two elements: whether the processing will actually allow the purpose to be pursued, and whether there is an equally effective but less intrusive way. This is where breadth becomes a liability. The Board says narrowing collection criteria to exclude unnecessary personal data, rather than scraping a wide part of the internet, may be crucial to meeting the necessity condition, and points to pseudonymized or synthetic data as potentially less intrusive alternatives.
Condition 3: the balancing test. Data subject interests here include self-determination and retaining control over data published for one purpose and then reused for another. The EDPB also names a chilling effect: large-scale indiscriminate collection can create a sense of surveillance, leading people to self-censor, particularly where a model could be used to identify people who intended to speak anonymously or for profiling. Deepfake generation is listed as a further impact on rights and dignity.
Two consequences carry real weight. First, the more sensitive or private the data, the more weight it gets in the balance. The EDPB names location data and financial data alongside Article 9 categories, and singles out data about minors. Second, once a model is trained, personal data cannot easily be deleted from it given the current state of the art. That permanence is an input to the balancing test, not an excuse from it, and it is the same memorization and regurgitation risk that governance teams have been tracking since Opinion 28/2024.
The Board also enumerates the mitigating measures capable of shifting the balance, as an itemized list rather than a general instruction to weigh interests. It names excluding content from publications that might carry risks for particular persons or groups, with the example of people who could face abuse, prejudice, or even physical harm if the information were released publicly; excluding personal data on sites reachable only once logged in, which the EDPB treats as not freely accessible; blocking particular data categories or sources by default; pseudonymizing direct identifiers; deleting or anonymizing unnecessary data as soon as possible; publishing the list of scraped sites; offering an opt-out; and applying output filters that limit memorization and regurgitation risk. Mitigating measures are what a balancing test weighs on the controller's side, so an assessment recording none of them is thin by construction.
What the EDPB actually enumerates on data minimization
The Board lists specific measures here rather than gesturing at proportionality, which makes this the section most likely to end up as an audit checklist. Minimization does not prohibit training on large volumes of data; it prohibits processing personal data that is not necessary, relevant, or adequate, and it requires an assessment before scraping starts.
| Stage | Measures the EDPB enumerates | Evidence a reviewer would look for |
|---|---|---|
| Before collection | Consider synthetic data instead of personal data; define precise collection criteria; undertake a data mapping and inventory process; apply filters to exclude unnecessary data categories (bank transaction data, location data) where they can be sorted out; exclude categories of websites that structurally contain sensitive or minors' data; exclude sites that clearly oppose scraping via robots authentication, robots.txt, ai.txt, or CAPTCHA | A dated pre-collection assessment, the written collection criteria, the exclusion lists, and the data map that the inventory step produced |
| During and after collection | Apply syntax-based filtering (e.g. regular expressions) during collection to strip data identifiable by format, such as social security or telephone numbers; where feasible replace real data with synthetic data; where feasible anonymize or otherwise pseudonymize, citing Guidelines 01/2025 on pseudonymisation (adopted 16 January 2025) for the technique | Filter configurations and their coverage, plus the anonymization assessment run under Guidelines 02/2026 |
| Throughout, for accuracy | Scrape from reliable, maintained sources rather than secondary or outdated aggregators; timestamp when data was scraped; validate formats and spot-check random samples for factual accuracy before training | Source provenance records, collection timestamps, sampling results |
The accuracy expectations extend past collection: where a model placed on the market is expected to produce personal data as output, that output should comply with the accuracy principle too.
Technical objection signals now carry legal weight
robots.txt, ai.txt, CAPTCHA, and login walls appear twice in Guidelines 03/2026: once as minimization measures and once inside the balancing test, as factors bearing on what data subjects can reasonably expect. The EDPB's reasoning is that if data subjects know a site implements these measures and it is scraped anyway, it is less likely they could expect their data to be processed by the scraping entity.
The Board illustrates it with two paired examples. Where a platform is freely accessible, carries no prohibition on scraping, and tells users their content may be scraped, data subjects can reasonably expect third parties to scrape it for AI development. Where a platform uses robots.txt and CAPTCHA and expressly states it does not permit its users' data to be used for AI development, they cannot. Access restrictions matter too: data behind a login is treated as not freely accessible, and the EDPB flags the case where a scraper's user agent is served more data than a normal browser as an example of data subjects not being reasonably aware.
None of this makes robots.txt a legal instrument on its own. It makes it evidence, which is why publisher-side control over AI crawlers and opt-out enforcement now sits on both sides of the same assessment.
Transparency: no individual notice, but a real public notice
Article 14(5)(b) is available. It is not a waiver.
The EDPB accepts that identifying and informing scraped data subjects is often impracticable or objectively impossible, and that a controller might therefore not have to inform them individually. But it attaches conditions. The disproportionate-effort balancing has to be carried out on the dataset as a whole rather than record by record, weighing the controller's effort against the impact on data subjects of not being informed, and taking into account the number of data subjects, the age of the data, and any safeguards adopted. The Board also warns that the exception should not be routinely relied upon by controllers who are not processing for archiving, research, or statistical purposes.
Where the exception applies, one measure is mandatory: making the information publicly available. In practice that means a published notice containing the Article 14(1)-(2) information: categories of personal data, purposes, legal basis, and a precise indication of the sources, including whether they are publicly accessible and the crawler's characteristics. Where a complete source list is impossible, list sources to the greatest extent possible and state the types of sources omitted and why. Publishing domain names and URLs in a searchable format, with collection dates, is flagged as good practice.
The EDPB lists further measures beyond the public notice: running a DPIA and publishing it, applying anonymization or pseudonymization, minimizing collection and storage periods, and implementing strong security. Its worked example of a compliant balancing test also includes a prior right to object and an opt-out list that lets people object to collection of their data on named sites before collection occurs, not only after the fact.
Where the exception does not apply, individual notice is expected. The EDPB's own counter-example is a closed group of 5,000 identifiable people whose data was collected recently: contactable, recent, so inform them.
Special category data and the "responsibilities, powers and capabilities" test
Processing Article 9 data is prohibited in principle; intended scraping of it needs an Article 9(2) derogation in addition to an Article 6 basis. The harder question is residual collection: special category data you did not intend to collect and often cannot detect until after scraping.
Here the EDPB imports the CJEU's reasoning in GC and Others (C-136/17), where the Court held that the Article 9(1) prohibition applies to a search engine operator within the framework of its responsibilities, powers and capabilities. The Board considers this can be relevant to incidental and residual collection during AI training, on a case-by-case basis, and sets four conditions: relevant similarity to the search engine processing in the judgment; only incidental and residual processing with no intentional processing; genuine difficulty or impossibility in assessing whether special category data is included; and implemented measures to prevent dissemination.
Meet those, and the guidelines spell out what "responsibilities, powers and capabilities" includes as a floor: precise criteria and filters before collection plus exclusion of website categories structurally containing such data; deletion of any special category data immediately after collection or as soon as identified, including on a data subject request that gives a plausible indication; prevention of extraction from the model during development, with output filters and state-of-the-art resistance to privacy attacks; and continuous output monitoring after deployment, with immediate remediation and, longer term, machine unlearning where it becomes reliable. The controller has to be able to demonstrate all of it, and re-verify that the measures still work. This is a materially higher bar than a generic Article 9 compliance posture, and it explicitly is not a general exemption.
If you deploy rather than train on a scraped dataset
Most organizations reading this are not scraping the web. They are buying, licensing, or fine-tuning on someone else's corpus, and Guidelines 03/2026 covers that scenario directly.
Where an AI developer trains on a dataset already scraped by another entity, the EDPB's position is that each party is in principle responsible for its own separate processing, because each determines the objectives and essential means of its own activity. The scraper is not, in principle, responsible for the reuse. That cuts both ways: their compliance work does not transfer to you, and their failures do not automatically become your liability — but your reuse is your own processing, with your own legal basis to establish. Joint controllership is possible where both parties set the purposes and means together, and where a scraper works to your documented instructions on sources and categories, it may be your processor instead.
The Board also expects you to name your upstream. For organizations obtaining already-scraped datasets, it recommends providing the means to contact the controller the data came from, linking directly to that controller's site, and explaining the conditions under which the data was collected in clear and plain language.
That turns three things into due diligence questions with a citable basis:
- Ask what anonymization test was run, and from whose perspective. "Our training data is anonymous" is now a claim testable against a named framework. Ask which of the three criteria were assessed, whether the contextual or simplified approach was used, and which entity's perspective the assessment took, because an assessment run from the vendor's perspective does not answer the question for yours.
- Ask for the legitimate interest assessment, not a summary of it. Specifically: the articulated interest, the necessity analysis including what less intrusive alternatives were rejected, the mitigating measures, and how objection signals on source sites were handled.
- Ask what happens on a deletion or objection request that reaches you. Given that personal data cannot easily be removed from a trained model, the realistic answers are output filtering, prompt restriction, or retraining, and you need to know which one your vendor can actually perform.
Coraggio's assessment of the scraping guidelines was that they are "not the obstacle some will claim" and that the direction is sound, while listing five questions the text leaves open: how wide the responsibilities, powers and capabilities door swings, whether robots.txt now has legal effect, the temporal scope, and whether the source list is workable at all. His remaining concern is worth keeping in view: the uncertainty sits exactly where a general counsel has to give a clear answer. Interaction with the AI Act and the Digital Omnibus is on that open-questions list too, which is a reason to file consultation comments rather than to wait.
Vendor answers are only useful if they are recorded somewhere a regulator can be shown. Secure Privacy's Vendor Management module keeps a central register of processors with contracts and data processing agreements, automates due diligence assessments and per-vendor risk scoring, and alerts on renewals and compliance gaps. That is where AI-supplier answers to the three questions above belong, rather than in an email thread.
Common mistakes under the EDPB web scraping guidelines
Most of the exposure these guidelines create comes from assumptions made before 7 July 2026 that still sit unexamined in a pipeline document.
| Mistake | Why it fails under the 2026 guidelines | Fix |
|---|---|---|
| Treating "de-identified" as a synonym for anonymous | Guidelines 02/2026 tests three criteria, and de-identification typically leaves record isolation or linkage intact | Run the three-criteria test on the dataset and record the outcome, including any criterion you could not clear and what you did about it |
| Running the anonymity assessment once, at dataset level | Anonymity is relative to an entity, and for a model it also depends on how that model can be queried | Reassess per entity and per model or deployment, and re-run when your capabilities or the reachable linkable datasets change |
| Accepting the vendor's anonymization assessment as your own | An assessment run from the vendor's perspective answers the question for the vendor only | Ask whose perspective was assessed and whether the contextual or simplified approach was used, then run the test from your position |
| Treating Article 14(5)(b) as a blanket exemption from notice | The EDPB warns against routine reliance outside archiving, research, and statistical purposes, and requires the balancing at dataset level | Document the dataset-level balancing (number of data subjects, age of the data, safeguards) and publish the Article 14(1)-(2) information |
| Treating an untargeted crawl as a purely engineering choice | Untargeted scraping increases the risk that the controller has limited knowledge of what personal data it holds, which weakens the necessity argument and makes filtering, deletion requests, and Article 9 detection harder to perform | Bound the crawl with written collection criteria, and record what those criteria were meant to exclude as well as include |
| Adding source exclusions after collection has already started | Minimization requires the assessment before scraping, and objection signals feed the balancing test as of collection time | Build the exclusion list into the written collection criteria and date it, so the record predates the scrape |
| Assuming a deletion request can be met by deleting from the corpus | Personal data cannot easily be removed from a trained model given the current state of the art | Decide in advance which remedy you can actually deliver: output filtering, prompt restriction, or retraining. State it in your public notice |
What to do before 30 October 2026
The consultation deadline is a useful forcing function, because everything below is work you will need regardless of how the final text lands.
- Inventory every pipeline that touches scraped or third-party web data, including fine-tuning runs and internal experiments that never got a formal project number. If your AI governance tooling already holds a system register, this is an extension of it rather than a new exercise.
- Re-test every "anonymous" dataset against the three criteria, recording which approach you used and whose perspective you assessed from. The EDPB does not expect a fresh assessment of datasets already cleared under Opinion 05/2014, but it does call periodic reassessment good practice.
- Write or rewrite the legitimate interest assessment so it addresses all three conditions as the guidelines frame them, including the alternatives you rejected on necessity.
- Audit your collection criteria against the enumerated minimization list, and document the exclusions: sensitive categories, minors' platforms, and sites signaling objection through robots.txt, ai.txt, or CAPTCHA.
- Check your public notice for the Article 14(1)-(2) elements, source specificity, crawler characteristics, and a working pre-collection objection route.
- Send your AI vendors the three due diligence questions and record the answers against each vendor.
- File consultation comments on anything your pipeline shows to be unworkable. The consultation closes 30 October 2026 at 23:59 CET.
Steps 2 through 6 are documentation exercises, which is why they tend to stall: the underlying facts live in different teams' spreadsheets. Secure Privacy's Assessments module runs DPIAs, TIAs, PIAs, LIAs, AIAs, and FRIAs from one place with templates aligned to major regulatory frameworks and approval routing, so the legitimate interest assessment in step 3 and the AI impact assessment sit against the same process records rather than in parallel documents that drift apart. The AI Governance module holds the other half: every AI system registered with its risk level, use cases, and a responsible owner, mapped to applicable regulations.
FAQ
What are the EDPB's Guidelines 03/2026 on web scraping?
Guidelines 03/2026 are draft EDPB guidelines, dated 7 July 2026, on how the GDPR applies to web scraping carried out by private entities to train generative AI models. They cover controller roles, purpose limitation, transparency, data minimization, accuracy, legal basis, and special category data, and are open for public consultation until 30 October 2026.
Is scraped public data personal data under the GDPR?
Yes, whenever it identifies someone directly or indirectly. Public visibility does not change that, and the EDPB adds that GDPR applies to mixed datasets containing both personal and non-personal data, and that publishing data online is not consent to its being scraped.
What are the three criteria in the EDPB's anonymization test?
No Record Isolation, No Linkage, and No Inference. If all three are met, the data may be regarded as anonymous; if one or more is violated, further analysis is required before concluding either way, and the data does not automatically become personal.
Can the same dataset be anonymous for one company and personal data for another?
Yes. Guidelines 02/2026 states that anonymity must be assessed from each relevant entity's perspective, because whether means of identification are reasonably likely to be used depends on that entity's capabilities. A controller who anonymizes data for a recipient but keeps the original still holds personal data.
Can we use consent as the legal basis for scraping AI training data?
Almost certainly not at scale. The EDPB says consent would most probably not be applicable because scrapers have no direct relationship with data subjects and cannot identify and obtain consent from each one, which leaves legitimate interest under Article 6(1)(f) as the realistic basis.
Does robots.txt legally prevent scraping under these guidelines?
Not directly, but it carries weight in two places: as a source-exclusion measure under data minimization, and as a factor in the legitimate interest balancing test. Where a site signals objection through robots.txt, ai.txt, or CAPTCHA and states it does not permit AI training use, the EDPB's position is that data subjects cannot reasonably expect scraping for that purpose.
Do we have to notify every person whose data we scraped?
Not necessarily. Article 14(5)(b) can excuse individual notice where it is impossible or requires disproportionate effort, but the EDPB requires the balancing to be done for the dataset as a whole and requires you to publish the Article 14 information (including purposes, legal basis, and a precise indication of sources) as a mandatory substitute measure.
Does buying a scraped dataset instead of scraping it make us responsible?
Yes, for your own processing. The EDPB treats each party as responsible for the processing whose objectives and essential means it determines, so the scraper's compliance work does not transfer to you and you need your own legal basis for the reuse.
What should we ask an AI vendor after these guidelines?
Ask which anonymization criteria were tested and from whose perspective, ask for the full legitimate interest assessment rather than a summary, and ask what the vendor can actually do when a deletion or objection request reaches a trained model. Those three answers cover the claims most likely to be load-bearing in your own documentation.
Are these guidelines final?
No. Both Guidelines 02/2026 and Guidelines 03/2026 were adopted as Version 1.0 for public consultation and remain open for comment until 30 October 2026, so the text can still change before a final version is adopted.
The work these guidelines create is documentation work: a current record of what each pipeline processes, an assessment that addresses each condition on its own terms, and a vendor file that holds the answers you were given. Secure Privacy's Privacy & AI Governance Platform covers that in one place — Data Map & ROPA for the processing record, Assessments for LIAs and AIAs, Vendor Management for supplier due diligence, and an AI Governance module that registers every AI system against applicable regulations across 60+ frameworks, with multi-entity support for groups running different postures per region. Book a demo to see how a training-data pipeline looks once the assessment, the data map, and the vendor record point at the same system.
