From Web Page to Training Dataset
The subject here is the path from public web material to a generative-AI training dataset and then to a tested model. The important question is what changes at each transition: what the collector knows, what information persists, what gets removed or added, and where personal-data risks can reappear. Following that path gives a reader a better way to judge a collection than treating scraping as a single technical act.
A web page is an input location, not yet a training record. Between the two lie decisions about scope, extraction, storage, cleaning, annotation, validation, and use. The European Data Protection Board (EDPB) describes these steps as a typical sequence rather than a universal template. A complementary CNIL schema places collection and preprocessing between system design and learning, then separates training, validation, and testing. Together, these sources support a lifecycle view: the meaning and risk of public material can change as it moves through the system.
Collection scope determines what can enter
Scraping begins before a crawler requests a page. It begins with a decision about which pages count as candidates. The EDPB distinguishes targeted scraping from untargeted scraping. Targeted scraping uses criteria that can be relatively restrictive—for example, a domain, a language, or a topic. Untargeted scraping gives the software a much wider instruction, such as following discovered links and continually adding them to a queue. A short starting list can therefore expand substantially as the crawler finds more links.
This difference is not merely a matter of engineering style. A targeted collection gives the organisation a clearer hypothesis about what it needs and a more manageable boundary around the source set. An untargeted collection creates a larger gap between the original instruction and the eventual contents. The collector may know where the process started while knowing much less about what it will include after repeated discovery. That gap makes it harder to predict the categories of personal data present and harder to explain why each item was needed.
The source itself can also change how the scraper works. Static content is present in the page structure and can often be extracted by fetching and parsing the page. Dynamic content appears in response to user actions, such as scrolling, and may require the scraper to render the page and imitate an interaction before the additional material becomes visible. This distinction matters because the material a person sees in an ordinary visit and the material an automated process obtains may not be identical.
Websites change structure frequently. A scraper that once selected one part of a page may later encounter a different layout or a new category of content. The EDPB notes that regular monitoring and updates may be necessary when current data are needed for a model. In lifecycle terms, the source-selection state is not permanent. A rule that was narrow at one time can become broader, less accurate, or simply wrong as the source changes.
The first transition, then, is from intended source scope to actual candidate scope. What persists is the collection rule and the set of pages reached under it. What may be lost is the original certainty that every page belongs to the same topic or contains the same kind of information. If the project does not record what it selected and when, later cleaning cannot reconstruct the assumptions that shaped the dataset.
From a response to a structured record
After selection comes extraction: material is transferred from the chosen source into a designated storage location. The result is usually raw rather than ready for training. It may contain duplicated content, irrelevant page elements, code or markup, inconsistent formats, and information that the project did not need. The EDPB describes cleaning as a step that can remove duplicate data, irrelevant HTML or code, and unnecessary information, while normalising formats such as dates and numbers. Structuring then applies further rules to refine the material and produce a usable dataset.
Each operation changes the record in a different way. Extraction preserves a copy of what the automated process received, but it can also preserve surrounding material that was not part of the intended target. Cleaning removes some noise and may remove some unnecessary personal data, yet it does not prove that the original collection was limited to what was necessary. Structuring turns heterogeneous material into fields or records that a model-development process can consume. That makes the data easier to use, but it can also make relationships between pieces of information more legible.
Consider an ordinary public discussion page. A targeted rule might select pages about a technical topic. Extraction could capture the page text, author name, timestamp, profile link, and surrounding navigation. Cleaning might remove markup and duplicate quotations. Structuring might preserve the author name and timestamp as separate fields because they appear useful for search or analysis. At each stage, the record becomes more orderly, but order is not the same as necessity. A field that survived cleaning still needs a reason to be present.
The same point applies to data quality. A page can be public and still be old, copied from another site, incorrectly attributed, or inconsistent with more reliable sources. Cleaning can standardise a date or remove a duplicate record; it cannot establish that the underlying statement is true. The EDPB therefore treats accuracy as a continuing concern and recommends reliable sources, timestamps, and validation before training. The lifecycle must preserve enough information about origin and time to make those checks possible.
Personal data can also persist through transformations that make the record look less like its source. A name may become a field in a structured record. A face in an image may become an annotated label. A set of posts may become examples in a training corpus. The format changes, but the processing question does not disappear merely because a human reader no longer sees the original page layout. The EDPB’s GDPR analysis expressly includes extraction, cleaning, structuring, and storage when personal data are involved.
The second transition is from raw captured material to usable training records. What persists is selected content, its provenance, and any personal information that the cleaning rules did not remove. What may be lost is page context: how a statement was presented, who could see it, whether it was current, and what restrictions accompanied it. A smaller, cleaner record can therefore be more useful for a model while being less self-explanatory to a later reviewer.
Database constitution is the middle of the lifecycle
The CNIL schema is useful because it places database constitution between system conception and learning. On the design side are the choice of system architecture and an estimate or pilot for the database. In the database-constitution stage are data collection and preprocessing. The diagram groups cleaning, annotation, feature extraction, and data splitting under preprocessing. Learning then contains training, validation, and test.
This structure prevents a common misunderstanding: the dataset is not a passive container waiting for a model. It is constituted through choices. A team decides what kinds of material to collect, which records to clean, which features or labels to retain, and how to divide the data for later evaluation. Those choices can affect what the model learns and what the team is able to detect.
Annotation is a good example. The source schema names annotation but does not explain a particular method or quality standard. That limitation matters. We can safely say that annotation is a distinct preprocessing activity in the depicted lifecycle. We cannot infer from the diagram which labels are used, who supplies them, or how reliable they are. Likewise, the diagram identifies feature extraction and data splitting as stages, but it does not establish a particular algorithm or model architecture.
The same discipline applies to the boundary between database constitution and learning. Training uses the prepared data to adjust a model. Validation and testing examine how the resulting system performs under their respective arrangements. They do not erase the history of how the records were obtained. If an unnecessary personal detail entered the database during collection, the fact that the model later passes a test does not make the earlier collection necessary. If a stale statement is embedded in the training material, a successful technical test does not automatically establish factual accuracy in the world.
A lifecycle also reveals where information is lost. A raw page may contain publication time, surrounding links, edits, access conditions, and the distinction between an author's words and quoted material. Cleaning may discard some of those signals. Structuring may preserve only the text and a few fields. Splitting may distribute related examples across different evaluation sets. These transformations can be entirely ordinary, but each one changes what a later operator can know about the original context.
What persists is not only the cleaned text. It includes the effects of selection rules, transformation choices, labels, and data partitions. What may be lost is the context needed to interpret a record or respond to a person who asks where it came from. This is why provenance and timestamps are not administrative decoration. They help connect a model-development record back to the source conditions under which it was created.
The loop in the diagram is a practical interpretation of the lifecycle, not a claim that the sources prescribe one software architecture. Model outputs provide a point at which accuracy, memorisation, or unexpected disclosure may become visible. Those observations can change the next collection or filtering decision. A lifecycle that ends at training misses this feedback; a lifecycle that includes outputs can ask whether the original choices still support the system's actual behaviour.
Mixed material, persistent consequences
Public web collections often contain mixtures: ordinary factual material, creative expression, metadata, comments, images, and information about identifiable people. The EDPB’s point is not that the entire collection has one uniform character. It is that GDPR obligations apply to the processing of personal data within a mixed dataset. The label “web content,” “open data,” or “training corpus” does not settle which operations involve people.
Scale makes this harder. A large collection may contain information about thousands or millions of individuals, including material the collector did not intentionally seek. The organisation may not be able to tell quickly which records identify whom, especially when identification is indirect. That uncertainty is itself a governance problem: if the contents are not mapped, it becomes harder to state what was collected, explain the purpose, validate accuracy, respond to rights requests, or remove unnecessary material.
The model can extend the consequences further. The EDPB identifies the possibility that a model memorises and reproduces information from its training data or infers additional information about individuals using the training data and other information. These are risks, not a measured prediction for every model. The evidence does not support saying that every model will repeat a page or that every training record remains recoverable. It does support treating model development as connected to the earlier data lifecycle, because later outputs may expose failures that were invisible in the raw dataset.
This connection also explains why “we cleaned it” is an incomplete answer. Cleaning may improve consistency and remove some unnecessary content. It cannot, by itself, establish that the collection scope was justified, that the source was reliable, that context was preserved, or that the resulting model will not reveal information in an unexpected form. Those are different questions assigned to different transitions.
A useful lifecycle analysis therefore asks four things at every stage: what enters, what changes, what context is lost, and what evidence remains. The answers are different for a crawler queue, a raw response, a cleaned record, a split dataset, a trained model, and an output. Keeping those states distinct is the first step toward deciding who must control them and explain them.
The next question follows directly from these handoffs. When one organisation selects sources, another performs scraping, a third supplies an existing dataset, and a developer trains the model, who is making the decisions that matter? The answer cannot be read from the pipeline diagram alone; it depends on who determines the purposes and essential means at each stage.