Who Is Making the Decision to Use the Data?
This chapter focuses on responsibility inside a public-web-to-generative-AI pipeline. A scraper may fetch pages, a dataset provider may package the results, and an AI developer may train a model, but the important question is who decided why the processing would happen and how it would be organised. Readers can use that question to distinguish a commissioned service, a reused dataset, and a genuinely shared decision without assuming that a contract or job title settles the issue.
The distinction matters because the pipeline described earlier is rarely controlled by one pair of hands. The person whose information appears on a page, the website or service hosting it, the organisation operating a crawler, the organisation supplying a dataset, and the model developer may all be connected to the same material. Their activities can be related without being the same processing activity. Responsibility therefore has to be mapped across the handoffs.
Responsibility follows factual influence
The EDPB says that the roles of controller, joint controller, and processor must be analysed case by case. The analysis should look at the factual organisation of the processing: who determines the purpose, who determines the essential means, whose instructions govern the collection, and how the parties actually arrange the work. These terms are useful because they describe different kinds of influence, not because they provide convenient labels for outsourcing.
A controller is the organisation that determines why personal data are processed and the essential choices about how that processing is organised. A processor performs processing on behalf of a controller and follows the controller’s documented instructions. Joint controllers arise where organisations determine the purposes and means together. These are general role concepts; the EDPB’s web-scraping guidance applies them to the facts of a particular AI-data pipeline rather than offering a one-line classification for every vendor relationship.
Imagine a developer that wants to train a model for a stated purpose and hires a scraping company. The developer gives documented instructions about the sources to use and the categories of information to collect. The scraper operates the collection process within those instructions and prepares the dataset for the developer. In that arrangement, the scraper may be a processor, while the developer will generally be the controller because the developer determines the purpose and essential means of the scraping.
The important fact is not merely that one organisation sent an invoice to another. It is that one organisation determined the reason for collection and the significant boundaries around it. Instructions about source types and data categories can be evidence of that influence. So can decisions about how broad the crawl should be, which personal-data categories are necessary, and what the resulting dataset is meant to support.
The relationship can look different when the scraper makes the key decisions independently. If the scraper chooses its own purpose and essential means, its processing may be separate from the developer’s later use. The EDPB does not say that the organisation operating the scraper is automatically the controller for every subsequent activity, nor that the developer can avoid analysing its own processing by pointing to the scraper. Each activity must be connected to the party that actually determines it.
This factual approach also prevents a common mistake: treating the word “processor” as a way to transfer all responsibility away from the organisation that wants the model. If the developer decides what the dataset should contain and why it is needed, a service agreement does not change the developer’s influence merely because another party performs the extraction. Conversely, a scraper is not automatically acting only on instructions because the customer later buys or uses the resulting dataset.
Three handoffs, three kinds of accountability
The first handoff is between the person or source context and the scraping activity. The person may have published information for a particular audience or purpose, while the scraper may be deciding to collect it for model development. The relevant question is not whether the source is visible in isolation, but which organisation decided to make that visibility part of a new processing activity and what constraints it placed around the collection.
The second handoff is between scraping and dataset construction. A scraper may extract material and clean it, while another organisation receives the result and structures it for training. At this point, provenance matters. The receiving organisation needs to know what was collected, from which sources, under what conditions, and when. The EDPB recommends that information made publicly available to data subjects include source details, categories of personal data, the purposes and legal basis, and—where possible—domains or URLs and collection dates. It also recommends a way to contact the controller from whom an already-scraped dataset was obtained.
These are not merely record-keeping preferences. They allow the next organisation to assess whether the dataset fits its own purpose and whether the collection conditions are compatible with the planned reuse. A package described only as “public web data” hides the decisions that made it. Without source and date information, the developer may be unable to distinguish freely accessible material from content subject to access restrictions, old material from current material, or a narrow collection from a crawl that expanded beyond its initial scope.
The third handoff is between dataset use and model development. If an AI developer trains a model using a dataset already scraped by another entity, the EDPB says the scraper and the developer are, in principle, responsible for their own separate processing activities. The scraper is not, in principle, responsible for the developer’s reuse merely because it created the dataset. The developer still has to analyse the processing involved in obtaining and using that dataset: its own purpose, the types of personal data it contains, its lawful basis, and the safeguards needed for model development.
This is why “the data were already collected” is not a complete answer. Reuse is another decision. A dataset can be suitable for one stated purpose and unsuitable for another. A collection that was narrowly described at the source can be combined with new data or used to train a model with different capabilities. The new user must examine the facts of the new processing rather than inherit a blanket permission from the earlier handoff.
Joint responsibility is a third possibility. The EDPB gives the example of two organisations that agree to develop an AI model together, with one performing the scraping and the other developing the model, while both determine the collection criteria. They may be jointly responsible because they jointly determine the purposes and means of the processing, even though they carry out different operational tasks. Physical separation of the work does not prevent shared decision-making.
The dividing line is therefore decision authority, not physical proximity to the server or dataset. One organisation can collect while another decides what should be collected. One organisation can train while another has jointly set the purpose and criteria. A useful analysis asks, for each activity: who chose the objective, who set the important boundaries, who could change them, and whose instructions or choices shaped the result?
The diagram shows relationships, not a universal organisational arrangement. In some projects the scraper and dataset provider are the same entity. In others, the developer receives a dataset directly from a scraper. The point is to make the decision crossings visible: instructions can travel from developer to scraper, provenance can travel with the dataset, and rights information must remain intelligible to people affected by the processing.
What should remain visible across the handoffs?
A defensible pipeline needs more than a list of companies. It needs an account of the decisions that connected them. At minimum, the public explanation should make the purpose and legal basis understandable, identify the categories of personal data concerned, describe the source or sources precisely where possible, and explain whether the sources were publicly accessible. For online scraping, the EDPB also points to crawler characteristics and, where possible, searchable domains or URLs and collection dates.
The same information helps the organisations involved reason about their own roles. A developer that receives a dataset can ask whether the sources match the intended purpose, whether the collection was targeted or expansive, whether the data are recent enough, and whether categories of information were gathered that the model does not need. A scraper can compare its actual process with the documented instructions rather than assuming that a customer’s broad objective authorises every page discovered by the crawler.
Rights information should travel with the explanation as well. The EDPB says data subjects should be told what rights they have and how to exercise them, in information that is easy to find and understand. When an organisation obtains an already-scraped dataset, a contact route to the original controller and a clear account of the conditions under which the data were collected can help make that right meaningful. The guidance recognises that individual notification may sometimes be impossible or require disproportionate effort at large scale, but it does not treat that difficulty as permission to make the source and purpose unknowable.
It helps to think of provenance as a decision chain rather than a file label. At the collection end, the chain records what the scraper was told to seek, which categories were excluded, and which source boundaries applied. At the dataset end, it explains what was retained, when it was obtained, and what transformations were performed. At the model end, it identifies the purpose for which the developer chose to use the material and the channel through which affected people can ask questions or exercise rights. The EDPB does not prescribe one particular record format, but its transparency recommendations point to the information that must remain intelligible across the handoff.
This chain also helps separate two questions that are often confused. The first is whether the scraper followed the collection instructions. The second is whether the developer may use the resulting dataset for its own model purpose. A scraper can comply with a narrow instruction while the developer later chooses a different use. Conversely, a developer can state a narrow purpose while the actual crawler reaches sources or categories outside that purpose. Evidence about one handoff cannot automatically answer the other.
Consider a dataset assembled from public discussion pages. If the developer asked for material about a topic and the scraper captured only the relevant text, the collection may be closer to the documented scope than if it also retained profile identifiers and unrelated pages. But even the narrower result still needs a role analysis: who chose the topic, who chose the fields, who could change those choices, and who decided to train a model on the result? The example does not decide the legal outcome; it shows why the facts of the workflow matter more than the description “public discussion data.”
A second example shows why reuse cannot be treated as a passive transfer. A dataset supplier may have collected material for one model-development purpose and passed it to a developer pursuing another. The developer must examine its own purpose and the data it received rather than assume that the supplier’s earlier decision covers the new processing. Source URLs, dates, category descriptions, and a contact route make that examination possible. Without them, a buyer may not know whether the collection was targeted, whether the material was subject to access restrictions, or whether the dataset contains information that the new model does not need.
This evidence trail also exposes disagreements between the intended and actual pipeline. Suppose a developer instructs a scraper to collect pages about a specific topic, but the crawler follows links into forums with a different audience or begins capturing profile details that were not needed. The label “topic dataset” does not resolve the mismatch. The actual collection criteria, crawler behaviour, source categories, and later cleaning decisions determine what happened. A role analysis that ignores those facts may assign responsibility to the wrong party and miss the point at which the scope expanded.
The evidence is strong for this general role-analysis framework, but it is not a substitute for reviewing a real workflow, agreement, or decision record. The EDPB expressly makes the classification case-specific. Nor does a public description of roles settle other legal questions, such as copyright or platform terms, which require additional authority. The useful conclusion is narrower: the organisation that wants to use public web data cannot treat organisational distance as a substitute for justification, and the organisation that performs scraping cannot assume that its customer’s later use is automatically part of its own responsibility.
Once the actors and handoffs are visible, the next judgment becomes possible. A proposed collection can be tested not only for whether a page is reachable, but for whether the purpose is precise, the people and data are understood, the relevant actors are identified, and the project has evidence for its choices. Public accessibility remains one fact in that analysis. It never replaces the analysis itself.