Public Is Not the Same as Free to Train On
This series examines a specific use of public web data: collecting material from internet sources to build or fine-tune generative-AI models. The immediate question is not whether a person can open a page in a browser. It is whether an organisation may extract, store, transform, and use what it finds for a particular model-development purpose, involving particular people and particular risks. That distinction gives readers a practical way to judge proposed collections without treating either “public” or “AI training” as a complete legal answer.
A page can be visible to everyone and still raise questions about personal data, purpose, responsibility, expectation, and downstream control. The evidence discussed here is centred on the GDPR-focused guidance of the European Data Protection Board (EDPB) for private entities scraping external internet sources in the context of generative AI, alongside a CNIL schema showing how data collection sits inside the wider AI lifecycle. It is therefore not a universal answer to every copyright, contract, platform-policy, database-right, or non-personal-data question. It is a disciplined way to understand why public accessibility is only the starting condition.
The question hiding inside “public”
“Public” usually answers an access question: can an ordinary visitor reach the material without passing a login screen or another gate? It does not, by itself, answer a reuse question: may an organisation copy the material into a large dataset, combine it with other sources, retain it, and use it to shape a model whose outputs may be offered to millions of people?
The difference matters especially when the material contains personal data. Personal data can identify someone directly, through a name, photograph, or contact detail, or indirectly, through information that can be linked to an identifiable person using means reasonably likely to be used. A public page may contain both personal and non-personal material, but that mixture does not make the personal-data operations disappear. Under the EDPB guidance, extraction, cleaning, structuring, and storage can all be processing operations to which the GDPR applies.
That is why the important distinction is not simply public versus private. A more useful set of questions is:
- What is being collected? Is the project selecting a narrow category of material, or allowing an expanding crawler to gather whatever it discovers? Does the material include names, images, contact details, location information, financial information, data about minors, or information that reveals especially private characteristics?
- Why is it being collected? Is there a specified and legitimate purpose, or is the organisation gathering a broad reserve in the hope that a future model will find a use for it? Would synthetic or less intrusive data support the same objective?
- Who is making the decisions? Is the developer directing a scraper, buying an existing dataset, or jointly deciding collection criteria with another organisation? Responsibility follows the facts of those decisions rather than the label attached to a vendor.
- What happens after collection? Will the material be filtered, timestamped, validated, anonymised or pseudonymised where feasible, retained indefinitely, fed into training, or allowed to influence outputs that reproduce or infer information about people?
A public source can be relevant evidence in answering these questions. It is not a substitute for answering them.
The EDPB makes one point particularly clearly: the fact that people have made personal data visible online does not mean that they consented to scraping it for a specific purpose. A person may not even know that the information is publicly accessible. The absence of a robots.txt file is not consent under the GDPR either. These points do not mean that every public-data project is prohibited. They mean that access, consent, lawful basis, and reasonable expectation are different concepts and must not be collapsed into one.
Why training changes the stakes
Web scraping is not one technical event. It is a chain of decisions and transformations. The EDPB describes automated extraction and storage from sources such as registers, open-data portals, news sites, social networks, forums, and personal websites. A project may use targeted scraping, with criteria such as a domain, language, or topic, or untargeted scraping, in which a crawler follows discovered links and expands the set of pages to visit. Dynamic pages may require the scraper to render content as a browser would. Websites also change structure, which means a collection process can drift from its original assumptions unless it is monitored.
The collection itself can be understood as a sequence: define criteria and exclusions, extract material into storage, clean it, remove or transform unnecessary content, and structure what remains into a training dataset. The CNIL diagram places those activities inside a broader path. Before database constitution comes system design and an estimate of the database. Within database constitution are collection and preprocessing, including cleaning, annotation, feature extraction, and splitting the data. Learning then includes training, validation, and testing.
This wider map changes how the reuse question is understood. If someone imagines “training data” as a pile of text downloaded once, they may look for permission only at the first moment. In reality, different choices occur at every transition. A source-selection rule determines what is eligible. An extraction process determines what is copied. Cleaning may remove HTML, duplicate records, or irrelevant material, but it may also preserve personal information that seemed useful. Annotation can add labels to records. Splitting can place related information into training and test sets. Validation and testing then examine the model, not merely the original pages.
The EDPB’s point is not that every project has an identical pipeline. Its point is that processing and risk can continue through several stages. A mixed dataset may contain a great deal of ordinary text alongside a smaller amount of information about identifiable people. The scale of scraping can make it difficult to determine exactly what was collected and whose information is present. That difficulty matters for accountability: an organisation cannot easily explain or govern a dataset whose contents it has never adequately mapped.
Training also creates consequences that do not exist in the same form at the source. The EDPB identifies risks that a model may memorise and reproduce information from the training set, permit memorised information to be used for arbitrary purposes, or infer additional information about individuals from the training data and other information. These are not predictions that every model will reproduce a particular page. They are reasons to treat the model as part of the data-protection problem rather than as a clean boundary after which the original collection no longer matters.
The practical implication is simple: deleting an obvious identifier from a page is not the same as demonstrating that the whole pipeline is safe. Nor does moving data from a crawler into a cleaned database create a legal reset. The meaning of a piece of information can change as it is combined, labelled, stored, trained on, and exposed through an output.
A better way to judge the reuse
The EDPB guidance focuses on private entities acquiring personal data from external internet sources for generative-AI development. It covers organisations that scrape material themselves or commission another party to do so, as well as organisations that obtain an already-scraped dataset for model development. It does not attempt to resolve every possible data-use regime. In particular, it does not cover an organisation’s own personal data, and it does not analyse a broker whose role is only to hold a scraped dataset for others rather than train a model itself.
That scope is a strength when used honestly. It allows a precise conclusion: for the kind of personal-data processing described by the guidance, public visibility is not an automatic authorisation to collect and train. But the conclusion should not be inflated into “nothing on the public web may be reused.” The evidence supports a requirement to examine purpose, necessity, responsibility, impact, expectations, and safeguards. It does not settle every question about non-personal material or every other body of law.
The same caution applies to technical measures. An organisation may filter certain formats, exclude categories of websites, use synthetic data, anonymise or pseudonymise information where feasible, record collection dates, validate records, and publish source and rights information. Those measures can reduce exposure and improve accountability. They do not turn a vague purpose into a precise one, and they do not prove that a model cannot memorise or infer information. Their value depends on what risk they address and whether they work in the circumstances.
This is also why the people represented in the data remain part of the subject. Large-scale, indiscriminate collection can affect control over personal information, create a sense of surveillance, chill expression, expose people who intended to speak anonymously, or contribute to profiling and harmful synthetic media. The likely impact depends on context: a freely accessible blog post is not identical to a restricted social-media post, a directory that reveals contact details, or a site that expressly signals that automated collection is not allowed. A notice published after collection may improve transparency, but notice alone does not prove that every person reasonably expected every later use.
The central judgment supported by this series is therefore narrower and more useful than a blanket “yes” or “no.” Public web data are not automatically free training data because visibility addresses only one part of the situation. Before collection, a project needs a defensible purpose and a bounded scope. During collection and preparation, it needs controls that limit unnecessary personal data and preserve enough provenance to explain what happened. Before and after training, it needs to consider accuracy, rights, memorisation, outputs, and the consequences of information that cannot easily be removed once it has shaped a model.
The next step is to follow the material itself: from a visible page, through extraction and preprocessing, into a dataset and then into training, validation, testing, and model use. That lifecycle makes the central distinction concrete. It shows where a project can still narrow its choices, where responsibility moves between organisations, and where a decision that looked like a simple download becomes a continuing set of obligations.