Provenance for Training Corpora

Analytical data governance answers "who can see this and where did it come from". Training data governance has to answer a harder question: what is in this model, given that the model is a lossy compression of hundreds of millions of documents whose individual influence cannot be traced. The gap between what is asked and what can be demonstrated is why provenance for training corpora is now a first-class engineering problem rather than a legal footnote.

What a provenance record has to contain

For each source in a corpus:

Origin. Where it came from, at what URL or from which vendor, and when it was collected. A crawl date matters because a site's terms and its robots directives change.

Licence and permission. The licence the content carried at collection, or the contractual terms under which it was supplied. "Publicly accessible" is not a licence, and the distinction between accessible and permitted is exactly the one litigation turns on.

Processing history. Every filter, deduplication and transformation applied, with the code version, so a document's presence or absence in the final mixture is explainable.

Composition. How much of the final training mixture each source contributed, after weighting and epoch counts, which is what the transparency obligations increasingly ask for.

Exclusions. What was removed and why, including opt-outs honoured, personal data filtered, and content excluded for safety. Recording exclusions is what makes a later claim about them verifiable.

Why it is now required

The EU AI Act obliges providers of general-purpose AI models to draw up and make publicly available a sufficiently detailed summary of the content used for training, following a template provided by the AI Office, with those obligations applying from August 2025 for new models. That is a documentation requirement that cannot be satisfied retrospectively by a team that did not record what it ingested.

Beyond regulation, several practical obligations point the same way. Honouring opt-outs, whether robots directives, per-site machine-readable preferences, or vendor takedowns, requires knowing which documents came from which source. Responding to a takedown requires knowing whether the content was used. And excluding an individual's data from future training runs requires the corpus to be queryable by subject, which a flat pile of tokenised shards is not.

When it breaks

Provenance must be captured at collection. Reconstructing it afterwards from a processed corpus is somewhere between expensive and impossible, since the metadata that would identify a document's origin is exactly what the cleaning pipeline strips. Teams discover this when the first obligation arrives.

Licences change and the record is a snapshot. Content collected under a permissive licence that was later relicensed leaves the collector's position dependent on what was true at collection time, which is why the collection date is part of the record rather than a convenience.

Deduplication destroys the mapping. Near-duplicate removal across sources means a surviving document may have arrived from several origins, and cheap implementations keep one and drop the provenance of the rest. Keeping the full set of origins per surviving document costs storage and is what makes source-level accounting possible later.

Synthetic data inherits its parent's provenance. Data generated by a model carries whatever constraints applied to that model's training data and to its terms of use. A corpus described as synthetic and therefore unencumbered is usually asserting something about the generation step while ignoring the chain behind it.

Provenance does not answer influence. Knowing a document was in the corpus does not establish how it affected the model, and training-data attribution methods that estimate influence are expensive and approximate. Provenance answers what went in. It does not answer what came out, and conflating the two overstates what the record can support.