Cybercoria / Regulation

Generative AI: can you trace where a data point came from after ingestion?

Between a web page and an AI model, data can be copied, filtered, transformed and incorporated into multiple artefacts. Provenance helps reconstruct that path.

Key takeaways · 1 minute

Between a web page and an AI model, data can be copied, filtered, transformed and incorporated into multiple artefacts. Provenance helps reconstruct that path.

Action: identify the assets, dependencies and evidence involved before treating the topic as an isolated requirement.

A company collects millions of public web pages to feed an artificial-intelligence system.

Six months later, an individual asks which data about them was used. The team knows the model, the dataset and the training pipeline. But can it answer a simpler question: where exactly did this data come from?

Web scraping for generative AI is not only a legal issue. It is also a data traceability problem.

In July 2026, the European Data Protection Board published Guidelines 03/2026 on web scraping in the context of generative AI. As of 21 September 2026, the text remains open for feedback, with consultation running until 30 October 2026.1

This is an opportunity to examine scraping through system architecture, because data can undergo a long sequence of transformations between a web page and a model.

“We used public data” does not describe a pipeline

A training path may look like:

web source → crawler → raw storage → filtering → cleaning → deduplication → dataset → training → model

A RAG system may instead involve:

source → collection → transformation → embeddings → vector database → retrieval → prompt → model → response

At every stage, data may be transformed, copied, enriched or combined. Knowing the final dataset does not necessarily mean knowing its origin.

Provenance is a relationship, not just a field

Adding a source column can help, but usable provenance may need to reconstruct:

data → source document → URL → collection date → collection method → transformations → dataset → consuming system

The same information can appear in several sources; pages change; data can be normalised or inferred. Provenance describes the history of data within the system.

Public web data is not outside GDPR

Public availability does not automatically mean information stops being personal data. Guidelines 03/2026 examine GDPR principles in the context of scraping for generative AI.1

The EDPB's Opinion 28/2024 had already addressed several data-protection questions concerning AI models.2

Technical teams therefore need to ask not only “Were we allowed to collect this source?” but also “What happened to the information after collection?”

Map the data pipeline

A useful representation begins before the model:

source → collection → raw storage → transformation → dataset → model → application → use

Each stage can carry attributes such as data type, purpose, owner, system, location, retention, transformation and downstream systems.

This helps answer: if data becomes problematic at the source, where must we intervene downstream?

The case of an individual request

Consider a company that collects public professional profiles, company websites and forums for a specialist assistant.

A person believes the service contains information about them. The team must investigate: was the data present in collected sources? Does the raw source still exist? Which transformed datasets contain it? Were those datasets used for training, fine-tuning, indexing or RAG? Which applications still use those artefacts?

Without traceability, each question becomes a separate investigation.

A dataset is only one node in the system

Several versions may exist:

raw dataset → cleaned dataset → filtered dataset → training dataset → evaluation dataset

Add snapshots, backups, caches, indexes, embeddings, exports and provider copies. Information removed from the primary dataset may still exist elsewhere.

RAG and training create different traceability problems

In RAG, documents or their representations generally remain connected to a retrieval mechanism, so a response may sometimes be linked to retrieved documents.

In a model trained or fine-tuned on a corpus, the relationship between source information and model behaviour becomes much less direct.

The question is therefore not only “Which model do we use?” but “How does data enter this system?”

Provenance should survive transformations

Useful traceability does not require keeping all data indefinitely. It requires deciding what information is needed to reconstruct origin and movement for an appropriate period.

Batch identifiers, collection metadata, dataset versions, pipeline logs and relationships between artefacts can help.

The principle is simple: a transformation should not necessarily break the provenance chain.

Provenance also supports cybersecurity

If a collected source is later found compromised, a dataset poisoned or a data supplier reports an error, the immediate question is: which systems were affected by this data?

Provenance enables an impact path:

compromised source → affected datasets → affected models/indexes → affected applications → exposed users

AI-BOM and provenance answer different questions

An AI-BOM helps identify models, libraries, services and applications. Provenance asks where information came from, how it was transformed, which artefacts incorporated it and where it is used now.

AI-BOM: what does my AI system depend on?

Data lineage: where did its data come from and where did it go?

Seven relationships to reconstruct

  1. Source → collection: which sources fed each batch?
  2. Collection → raw data: what was actually retrieved?
  3. Raw data → transformation: which filters and processing steps were applied?
  4. Transformation → dataset: which versions were produced?
  5. Dataset → model or index: which AI artefacts used which versions?
  6. Model or index → application: which services expose those artefacts?
  7. Upstream change → downstream impact: which components must be reviewed?

If several relationships cannot be reconstructed, the organisation may know its AI architecture better than the history of the data flowing through it.

Map before you need to trace backwards

Web scraping for generative AI raises complex legal questions that Guidelines 03/2026 seek to address. But compliance also depends on practical capabilities.

The problem rarely appears on collection day. It appears months later when the path must be reconstructed.

The design question is therefore: “If we had to find this data in a year, could we trace it back to its source?”

REFERENCES

Sources verified September 21, 2026 · 3 sources

  1. [1] Official sourceEDPB — Guidelines 03/2026 on web scraping in the context of generative AI
  2. [2] Official sourceEDPB — Opinion 28/2024 on certain data protection aspects related to AI models
  3. [3] Official textEUR-Lex — Regulation (EU) 2016/679 (GDPR)

References are shown so readers can verify the underlying material. Citing an official source does not mean Cybercoria attributes a conclusion to that source that it does not make.