Scraping the whole internet is the easy case. Your small, targeted scrape is not.

Say your team fine-tuned a model this spring. Nobody ran a crawler: someone found a public dataset, a few thousand forum posts from exactly your domain, downloaded it, cleaned it, and trained over a quiet week. If anyone owes the people in that dataset anything, surely it is whoever scraped it. Surely the real exposure sits with the companies ingesting the whole internet.

The EDPB, the board where the EU's data protection authorities coordinate, has just published draft guidelines on web scraping for generative AI, and its worked examples sort the easy cases from the hard ones in exactly the opposite direction 1. A crawl over millions of people going back twenty years: publish a notice, drop the pages where people are directly identifiable, carry on. A fine-tune over five thousand named people from the last two years: go and tell them, individually.

Guidelines 03/2026 are a version 1.0, adopted on 7 July 2026 in the same plenary as the anonymisation guidelines I wrote about separately 3, and open for consultation 2 until 30 October 2026. Draft or not, they are the Board's first full statement of how the GDPR reaches scraped training data, and two of its choices land directly on ordinary SaaS teams: the guidelines cover fine-tuning, and they cover re-use.

Do these apply if we never ran a crawler?

This is the part I would check first, because the answer is yes and the reasoning is short.

The guidelines cover personal data acquired from sources external to the organisation (your own production database is a different conversation), and they say scraped datasets "may be employed not only to train new generative AI models but also to fine-tune existing models for specific use cases" 1. That is the sentence that moves the document from their problem to ours.

The Board lists two typical situations: an organisation scraping itself (or contracting it out), and an organisation that "obtains and reuses a dataset that has already been scraped by another organisation (data broker)" 1. Both are in scope. The one role not covered is the broker itself, where it only holds datasets for others (paragraph 4), which is precisely the party you might have assumed was carrying this. But exclusion from the guidelines is not exclusion from data protection law, as the Board itself notes 1.

Running the crawler also does not decide who the controller is, the GDPR's word for the organisation that decides why and how personal data is used: a scraper working to an AI developer's documented instructions may be a mere processor, with the developer as controller 1. And where the dataset already exists and you pick it up, each of you answers for your own processing: "the scraper is not, in principle, responsible for the re-use of the data" 1 (paragraph 19). The operative line puts collection and re-use on the same footing: before "carrying out scraping operations involving the collection of personal data or re-use of scraped data, the controller must identify a lawful basis to the processing" 1 (paragraph 43).

So the team in the opening scenario is a controller for that re-use, needs its own legal basis under Article 6 of the GDPR, and owes the people in the dataset its own transparency. None of that is waiting upstream.

Why is a small scrape the hard case?

Because the escape hatch on transparency is not sized by how much data you took. It is sized by how easily you could go and tell people, and a targeted scrape is precisely the one where you can.

Where personal data was not collected from the person directly, Article 14 of the GDPR requires the controller to inform them anyway, unless that "proves impossible or would involve a disproportionate effort", the let-out in Article 14(5)(b). The Board accepts that this is often the position when scraping at scale, but not as a default: the exception "should not be routinely relied upon" by controllers outside archiving, research and statistical purposes 1.

The test itself is a comparison. A controller "should assess the effort involved for the controller to provide the information to the data subject against the impact and effects on the data subject if they were not provided with the information" (paragraph 28), judged on the dataset as a whole, taking in three inputs: the number of data subjects, the age of the data, and any safeguards adopted 1.

The two worked examples show which input actually decides. In the first, a developer crawls social media pages and forums going back twenty years, no direct identifiers, possibly millions of individuals. Disproportionate effort applies, on all three inputs: "there is no direct link between the scraper and the data subject that enables the communications", the data is old, and the dataset is very large. Publish a notice, and exclude pages where people are directly identifiable 1.

In the second, a provider fine-tunes a model on data from a closed group of five thousand people discussing a specific topic over the last two years, directly identifiable by full name, email address and participant ID. The conclusion is flat: "Given the fact that there are means to contact the data subjects and that the data has been published or collected in the recent years, it would not involve disproportionate effort", so the controller "should inform the data subjects individually about the scraping" 1.

Five thousand sits in that example's facts and nowhere in its reasoning. What decides it is contactability, with recency behind it. So the honest rule is not that small datasets lose the exemption; it is that datasets you could email lose it, and targeting a scrape usually means targeting people you can name. A small, recent, directly identifiable dataset is not exotic; it is what a targeted fine-tune looks like.

The squeeze this creates, and where it does not

On the necessity limb of legitimate interest (more on that basis below), the Board says that "narrowing the collection criteria to exclude unnecessary collection of personal data, rather than scraping a wide part of the internet may be crucial to ensure the necessity condition is met" 1 (paragraph 52). Narrow by picking a smaller set of nameable people, and you have improved your Article 6 position while walking into individual notification under Article 14. That is not a contradiction, just two tests pulling on the same design decision from opposite ends.

The same sentence offers a second route, and that one does not squeeze at all: "using pseudonymised personal data, or synthetic data, may be another less intrusive way of pursuing this purpose" 1, and safeguards like pseudonymisation and minimisation also count in your favour in the Article 14 balance 1. The trade bites on who and how many, not on how much detail you hold per person, so make that call deliberately, before the dataset exists.

What does our public notice have to carry?

If you do land on disproportionate effort, one measure is not optional: the controller "must always" make the information publicly available, for instance through a privacy policy or a specific notice on the website 1.

The contents are more specific than a standard privacy-policy block: the categories of personal data, the purposes and the legal basis (the draft's own wording here is garbled, the sort of thing a consultation exists to catch), "a precise indication of the source(s) of the data", including whether the sources are publicly accessible, and, for crawled sources, information that "should include crawler's characteristics" 1. Where a complete source list is impossible, list what you can and say what is missing and why; as good practice the Board wants domain names and URLs, searchable, with the collection period 1. If the dataset came from someone else, it recommends giving people a way to contact the controller you got it from, which is a third-party dependency sitting in your published legal text 1.

None of that is a paragraph you write once. Change the crawler's user agent, add a source, re-scope the collection window, and the published description is stale. That is a deployment event with a documentation consequence, and no calendar review catches it.

Can we still lean on legitimate interest?

Legitimate interest, the Article 6(1)(f) basis that does not require a relationship with the people concerned, is the route the Board expects: it "is often relied on" for scraping in generative AI development, and the other Article 6(1) grounds "will generally be less likely to apply" 1 (paragraph 43). Consent "would most probably not be an applicable legal basis": publishing something publicly is not consent to it being scraped for a specific purpose, and, in a line worth pinning above a few engineers' desks, "the absence or non-applicability of a robots.txt file on a web site does not amount to consent within the meaning of the GDPR" 1 (paragraph 45).

Legitimate interest needs an interest, necessity, and a balancing test against the rights of the people concerned 1. The balancing is where the technical detail of your crawler becomes a legal fact: people's reasonable expectations turn on the nature of the source websites, how public the publication really was, and "the restrictions imposed by the scraped website", naming robots.txt, ai.txt and CAPTCHA 1. Ignoring a robots.txt is not a separate regulatory offence; it is evidence inside your own balancing test, and it is evidence against you.

Two of the Board's mitigating measures are more engineering than drafting. One is a "discretionary and prior right to object", an opt-out list people can join "including before the data collection occurs" 1: a piece of software with a public endpoint and a matching problem, not a clause. And its worked example of a scrape that passes the balancing test leans on source selection, limits on memorisation and regurgitation, and output restrictions as much as on any document 1.

What if we did not build the model at all?

Then the relevant document is the earlier Opinion 28/2024, which covers a model developed on unlawfully processed personal data and then deployed by someone else 4. Each controller has to ensure and demonstrate the lawfulness of its own processing, so authorities should assess the deployer too, and in doing so should take into account whether it "conducted an appropriate assessment, as part of its accountability obligations", to establish that the model was not built that way, looking at criteria such as the source of the data and whether an authority or court has already found an infringement 4 (paragraph 129). The depth expected of you "may vary depending on diverse factors", case by case 4, and where your own deployment runs on legitimate interest, unlawfulness upstream "should be taken into account as part of the legitimate interest assessment" 4.

I do not read that as a duty to audit OpenAI. I read it as a duty to have written something down about why you picked the model you picked, before a regulator asks what you knew.

So what would I actually do about it?

Four things, and only one of them is a document.

Write down which of the two situations you are in. Scraping yourself, or re-using someone else's dataset. The obligations differ, and the second one is the one teams assume they are exempt from.

Decide the Article 14 route before you fix the collection criteria, not after. The number of people, the age of the data and whether they are directly identifiable are design parameters, and they determine whether your obligation is a public notice or a mail merge.

Treat the published source description as generated output. Categories, purposes, basis, sources, crawler characteristics, collection period: every one of those is a value your pipeline knows and your privacy policy asserts. When they drift apart, it is a release that did it, not a legal change.

Keep a note on every model you did not train. Where the weights came from, what you checked about the training data, and when. It is a short file, and Opinion 28/2024 puts it among the things an authority is told to take into account if the model's origins ever do turn out to be a problem 4. Nobody is asking you to prove a negative. They are asking whether you looked.

One caveat over all of it. This is version 1.0 of a draft, and the consultation 2 is open until 30 October 2026. If you disagree with where the Board has drawn the line on small datasets, that window is the moment it can still move. And if you are reading this afterwards, check whether a version 2 has landed before you quote a paragraph number from it, including mine.