The European Data Protection Board adopted Guidelines 03/2026 on web scraping in the context of generative AI on 07 July 2026, setting out for the first time a detailed compliance framework for companies that extract personal data from the open internet to train large language models and other generative systems. The 22-page document, published in version 1.0, is open for public consultation until 30 October 2026.

The guidelines were adopted during the same plenary session in which the EDPB also finalized its guidelines on anonymisation and its final version of guidance on blockchain technologies, according to an EDPB News announcement published on 08 July 2026. Anu Talus, Chair of the EDPB, is listed as signatory on behalf of the Board.

What the guidelines cover, and what they leave out

Web scraping, the EDPB explains, is "a commonly used technique that uses automated tools for extracting and storing information from publicly available web services, for example public registers, open-data portals, news outlets, social media, discussions' forums, and personal websites." Many of these sources, the Board notes, are likely to contain personal data, whether or not the organisation doing the scraping intended to collect it.

The scope is narrower than the general subject of AI and privacy might suggest. The guidelines apply to two scenarios: an organisation that scrapes data itself, or contracts another party to do so, to build or fine-tune a generative AI model; and an organisation that obtains a dataset already scraped by someone else. Left out entirely is the role of data brokers who scrape and hold datasets without training models themselves, as well as scraping conducted by public-sector bodies. The Board states that because web scraping for generative AI development is "mainly performed by private sector bodies," the guidelines focus only on private entities.

That framing matters. The document speaks directly to companies across the marketing technology stack: AI vendors building foundation models, ad tech firms fine-tuning models for specific verticals, and any organisation buying a training dataset rather than assembling one in-house.

Targeted versus untargeted scraping

The guidelines draw a technical distinction familiar to anyone who has built a crawler. Targeted scraping follows defined collection criteria, such as every URL ending in a particular domain, or content written in a specific language. Untargeted scraping, by contrast, uses software described in the document as "spiders" that receive open-ended instructions and continue discovering and following links with no fixed boundary. The Board warns that a short initial list of URLs "can expand significantly over time as the crawler continuously discovers and adds new URLs to its queue of pages to be visited," which increases the risk that the controller has limited knowledge of what personal data it has actually collected.

A second distinction separates static content, which sits directly in a page's HTML and can be extracted simply by fetching and parsing it, from dynamic content, which requires a scraper to render a page the way a browser would, mimicking user interaction to trigger content that loads on scroll or click. Because websites change structure frequently, scrapers require ongoing monitoring just to keep functioning.

The Board also lays out a four-step sequence common to scraping for AI training: defining data collection criteria, extraction, cleaning, and structuring and storing. The first step, according to the guidelines, is where an organisation has its best opportunity to exclude unnecessary personal data before it ever enters the pipeline.

Who is the controller when scraping is outsourced

One section carries real consequences for contract drafting: when an AI developer hires another company to do the scraping, who is legally responsible under the GDPR?

The guidelines state that the organisation actually performing the scraping "is not necessarily the controller under the GDPR." Where a scraper builds a training dataset on behalf of an AI developer, following documented instructions on sources and categories, the scraper is generally a processor and the AI developer the controller, since the developer determines the purposes and essential means of the processing. Where an AI developer instead buys or reuses a dataset another entity already scraped, the two parties are, in principle, each responsible for their own separate processing activities. The guidelines are explicit that the original scraper "is not, in principle, responsible for the re-use of the data" by a downstream buyer.

A third configuration - joint controllership - arises when two organisations jointly decide to develop a model and jointly determine the collection criteria for scraping, even if one company performs the scraping and the other trains the model. Both parties are then jointly responsible for the resulting processing because they determined the purposes and means together, even though they carried out separate operational tasks.

Transparency obligations, and when they can be relaxed

Under Article 5(1)(a) and Articles 12 to 14 of the GDPR, data subjects are ordinarily entitled to be informed when their personal data is processed. The guidelines acknowledge this becomes genuinely difficult at scraping scale: identifying and individually notifying millions of people whose blog posts, forum comments, or public profiles were swept into a training corpus is, in many cases, impossible or disproportionately burdensome.

Article 14(5)(b) of the GDPR provides a narrow exception in exactly this situation, permitting controllers to skip individual notification when it would involve impossible or disproportionate effort. The EDPB notes this exception should not be routinely invoked; it should follow a genuine balancing exercise weighing the effort involved for the controller against the impact on the person not informed, carried out with regard to the dataset as a whole rather than checked against every single data point. Relevant factors include the number of data subjects, the age of the data, and any safeguards already in place.

Where the exception does apply, a publicly available privacy policy is described as a measure the controller "must always take." That policy should specify the categories of personal data involved, the legal basis, and, where feasible, a precise indication of data sources, including whether crawler characteristics are disclosed. Where an organisation obtains an already-scraped dataset from someone else, the guidelines recommend it also link directly to the original scraper's website and explain plainly the conditions under which the data was first collected.

Two worked examples illustrate how this plays out. In one, an AI developer collects data spanning back twenty years from social media and forums where no direct identifiers appear, a scenario the Board treats as disproportionate-effort territory given the volume, age, and absence of any direct contact channel. In a second, a provider fine-tunes a model using data from a closed group of 5,000 individuals discussing a topic over the prior two years, with full names, email addresses, and participant IDs directly attached. There, the guidelines conclude the opposite: because the data is recent and the individuals are directly contactable, disproportionate effort does not apply, and the controller should inform them individually.

Data minimisation gets a concrete checklist

Perhaps the most operationally useful section for compliance teams concerns data minimisation under Article 5(1)(c). The principle, the EDPB stresses, does not prohibit training models on large volumes of data; it simply requires that controllers not process personal data that is not necessary, relevant, or adequate for the purpose.

Before collection begins, the guidelines recommend considering synthetic data as a substitute for real personal data, defining precise collection criteria, running a data mapping exercise, applying filters that exclude unnecessary categories such as bank transaction or location data where they can be sorted out, excluding categories of websites that structurally contain sensitive personal data - platforms used mainly by minors are cited as an example - and excluding sites that clearly signal opposition to scraping through robots.txt, ai.txt, or CAPTCHA. During and after collection, the guidelines recommend syntax-based filtering to catch identifiable formats such as social security or telephone numbers, replacing real data with synthetic data where feasible, and applying anonymisation or pseudonymisation.

The accuracy principle under Article 5(1)(d) receives similar concrete treatment: scrape from reliable, official sources rather than secondary aggregators; timestamp collected data to show how current it is; and validate data before it enters training, including spot-checking random samples for factual accuracy. The guidelines note this principle extends beyond collection, since a model expected to output personal data must also remain accurate in what it produces once deployed.

The legitimate interest test, condition by condition

Consent, the guidelines conclude early on, will most probably not serve as a workable legal basis for scraping. Organisations extracting data at scale from sources external to themselves typically have no direct relationship with the individuals concerned and cannot realistically obtain consent from each one before scraping. The guidelines add a pointed clarification: 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, and the mere absence of a robots.txt file does not amount to consent either.

That leaves legitimate interest under Article 6(1)(f) as the legal basis the EDPB expects private entities to rely on most often. The guidelines restate three cumulative conditions: a legitimate interest pursued by the controller or a third party; the necessity of processing personal data to achieve that interest; and a balancing test confirming the data subject's rights do not override the controller's interest.

On the first condition, the guidelines point to examples the EDPB has previously endorsed as legitimate in an AI context: developing a conversational agent to assist users, detecting fraudulent content or behaviour, and improving threat detection in an information system. For general-purpose models whose eventual use case has not yet been fixed, the guidelines recommend referencing the broader objective of development - commercial, public, or scientific research, internal or external to the organisation.

On necessity, the guidelines state that narrowing collection criteria to avoid scraping "a wide part of the internet" may be crucial to satisfying this condition, with pseudonymised or synthetic data offered as a less intrusive alternative where feasible.

What the balancing test actually weighs

The balancing test is where the guidelines spend the most analytical effort, and where the practical risk for AI developers concentrates. On one side sit the data subject's interests, fundamental rights, and freedoms - including self-determination and control over one's own data, since information originally published for one purpose is later scraped and processed for an entirely different one, often without the person's knowledge. The guidelines also flag a chilling effect: large-scale, indiscriminate collection can create a sense of surveillance that leads individuals to self-censor, particularly where a model might later be used to identify someone who intended to speak anonymously, especially if connected to a web search tool, or where a model could be used for profiling. The generation of deepfakes - images, video, or speech - is cited as adding further weight against the controller's interest, alongside potential harm to a person's dignity.

On the impact side, controllers must weigh the nature of the data - noting that highly private categories such as location or financial data, and data concerning minors, deserve particular caution even outside the special categories protected under Article 9 - alongside the practical difficulty a person faces trying to exercise their GDPR rights once scraped data has entered a trained model. On that last point, the guidelines are stark: given current technical capability, "once the model is trained, personal data cannot be easily deleted from a model."

Reasonable expectations of the data subject round out the exercise. Relevant factors include the nature of the source website, whether data was made public with restricted or open access, whether the site imposed technical measures such as CAPTCHA or ai.txt files signalling opposition to scraping, and whether the data subject is a minor or public figure. Two contrasting examples make the point concrete. Where a platform is freely accessible, does not prohibit scraping, and tells users their content might be scraped, data subjects can reasonably expect third-party scraping for AI development. Where a platform blocks scraping through robots.txt and CAPTCHA and expressly states it does not permit use of user data for AI development, the guidelines conclude the opposite: data subjects cannot reasonably expect that use, regardless of what a scraper does anyway.

Where the balance tips against the controller, mitigating measures can restore compliance: excluding particularly sensitive publications, excluding certain data categories or sources by default, limiting collection to data freely accessible without a login, imposing time-based limits, publishing updated lists of scraped sources, offering an opt-out mechanism, and applying pseudonymisation. A further category addresses the AI development phase itself, including limiting the risk that a model memorises or regurgitates training data.

Two examples close this section. An organisation collecting publicly available voice recordings to build a voice generation tool, without additional measures to protect the data or limit unlawful reuse, cannot rely on legitimate interest, according to the guidelines. By contrast, an organisation building a text-based system using only freely and publicly accessible sources where subjects manifestly made content public, excluding copyrighted content under the EU's Digital Single Market copyright directive, implementing safeguards against memorisation and regurgitation, and clearly disclosing its sources in a public privacy policy will generally satisfy the balancing test.

Special categories of data, and the search engine precedent

Article 9 of the GDPR prohibits, in principle, processing data revealing racial or ethnic origin, political opinion, health, or sexual orientation, among other special categories. Scraping such data intentionally requires both a lawful basis under Article 6 and a specific derogation under Article 9(2). The guidelines acknowledge a practical reality: it is often impossible to assess with certainty whether a scrape has picked up special category data until after the scraping has already happened.

To address that residual, unintended collection, the guidelines turn to a 2019 Court of Justice of the European Union ruling, GC and Others (C-136/17), concerning the operator of a search engine. The Court held that the prohibitions in Article 9 apply to a search engine operator "within the framework of his responsibilities, powers and capabilities," recognising that the specific features of how a search engine operates can affect the extent of the operator's obligations. The EDPB considers this reasoning can be relevant, by analogy, to the incidental and residual collection of special category data during AI training scraping - but stresses this is not a blanket exemption. It applies only where a controller's processing has relevant similarities to search-engine-style processing, involves only incidental rather than intentional collection of special category data, and where detecting such data in advance is genuinely difficult or impossible.

Where those conditions are met, the guidelines set out four stages of responsibility across the AI lifecycle: before collection, defining filters to prevent collecting special category data and excluding structurally sensitive site categories; after collection, deleting any special category data that slipped through as soon as it is identified, including on a data subject's request; during model development, testing for and preventing extraction of such data and applying output filters; and after deployment, continuously monitoring outputs and reinforcing filters if special category data appears, with machine unlearning noted as a possible future alternative to retraining.

Timeline

  • 08 October 2024 - The EDPB adopts Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR, establishing the three-condition legitimate interest test the new web scraping guidelines build on.
  • 17 December 2024 - The EDPB adopts Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, identifying examples of legitimate interest later cited in the web scraping guidelines.
  • 16 January 2025 - The EDPB adopts Guidelines 01/2025 on Pseudonymisation for public consultation, referenced in the new guidelines as a mitigating measure for scraped data.
  • 04 September 2025 - The Court of Justice of the European Union delivers its judgment in EDPS v SRB (C-413/23 P), later cited in the EDPB's related anonymisation guidelines adopted the same week as the web scraping guidance.
  • 07 July 2026 - The EDPB formally adopts Guidelines 03/2026 on web scraping in the context of generative AI, version 1.0, alongside guidelines on anonymisation and the final version of its blockchain guidelines.
  • 08 July 2026 - The EDPB publishes its news announcement summarising the newly adopted guidelines and opening them for stakeholder feedback.
  • 30 October 2026 - The public consultation period on Guidelines 03/2026 is scheduled to close.

Summary

Who: The European Data Protection Board, chaired by Anu Talus, representing the data protection authorities of the European Economic Area.

What: Adoption of Guidelines 03/2026 on web scraping in the context of generative AI, a 22-page framework setting out how the GDPR applies to organisations that scrape personal data from the internet to train or fine-tune generative AI models, including rules on controller and processor roles, transparency obligations, data minimisation, accuracy, the legitimate interest legal basis, and special categories of personal data.

When: The guidelines were adopted on 07 July 2026 and announced on 08 July 2026. Public consultation remains open until 30 October 2026.

Where: The guidelines apply across the European Economic Area, covering web scraping conducted by private entities regardless of where the scraped websites or the AI developer are physically located, so long as GDPR jurisdiction applies.

Why: Generative AI models require vast training datasets, and web scraping has become the default method for assembling them, frequently without the knowledge of the individuals whose personal data ends up in a training corpus. The guidelines give AI developers, marketing technology vendors, and any company building or buying scraped datasets a structured test for when that practice can lawfully rely on legitimate interest rather than consent, and clarify that once personal data enters a trained model, removing it is technically difficult - raising the stakes for getting the legal basis right before training begins.