A First Defensible-Use Test
A proposed public-web collection is not a free stock of content waiting for a model. It is a set of processing decisions connected across sources, actors, purposes, transformations, and outputs. The useful judgment is therefore not simply whether a page is reachable. It is whether the project can explain what it needs, who is deciding, what personal data may enter, why the processing is justified, and what evidence supports proceeding rather than narrowing or redesigning the plan.
The test below brings together the distinctions already established: public access is not consent; scraping moves through several stages; personal-data processing can occur in mixed datasets; and responsibility follows factual influence across handoffs. It is a preliminary decision model, not a universal legal safe harbour. The EDPB guidance leaves the relevant outcomes case-specific, and the supplied evidence does not settle every rule that may apply to a particular source or dataset.
Start with the proposed use, not the available web
The first question is whether the purpose is specific enough to define a collection boundary. “Build a better model” is too broad to tell a project which sites, fields, time periods, or categories of people are needed. A more useful statement connects the intended model capability to the material it requires. The EDPB gives examples of legitimate interests in developing a conversational agent, detecting fraudulent content or behaviour, or improving threat detection. It also says that a general-purpose model’s objective should be described, including whether the development is commercial, public, scientific, internal, or external.
A precise purpose does not guarantee that a collection is lawful. It does make the next questions answerable. If a project wants text in a particular language about a defined topic, it can ask whether it needs names, profile links, precise locations, or historical discussion threads. If it wants to detect fraudulent behaviour, it can ask whether collecting a wide archive of personal conversations is necessary or whether a narrower and less intrusive source would work. The purpose is a boundary-setting tool, not a slogan attached after the data have been gathered.
The second question is what processing the proposed use entails. The collection may include extraction, cleaning, structuring, storage, annotation, splitting, training, validation, testing, and model use. Some records may be non-personal, while others directly or indirectly identify people. The presence of non-personal material does not answer what happens to the personal-data portion. A project that cannot describe which operations touch personal data has not yet described the project well enough to assess it.
The third question is who makes each decision. A developer may commission a scraper and determine source categories and collection criteria. A scraper may create a dataset independently and later sell it. Two organisations may jointly set the purpose and means. These arrangements can lead to different role analyses. A project should therefore identify who chose the objective, who set the important boundaries, who could change them, and who decided to use the result for model development.
This first pass often reveals that “public web data” is too vague a description. It may conceal a targeted set of official pages, an untargeted crawl, a dataset assembled years earlier, or a mixture of sources with different audiences and restrictions. The source label should be replaced by a more concrete account of what was collected and how.
The four questions behind a defensible collection
A project can then move through four linked questions.