Key takeaway: Data provenance is not paperwork. It is the precondition for answering every substantive question anyone will ask about a model’s behaviour or legality.
The Questions That Arrive Later
A model ships. Then the questions come: does it reproduce copyrighted text, why does it underperform for a particular group, was personal data used without a lawful basis, can a specific individual’s records be removed.
Every one of those requires knowing what the training set contained. A team that scraped, merged and filtered without recording sources cannot answer any of them, and cannot fix problems it cannot locate.
What a Usable Record Contains
| Field | Why it matters |
|---|---|
| Source and acquisition date | Establishes what terms applied at the time |
| Licence or legal basis | Determines permitted use |
| Content type and volume | Supports composition analysis |
| Filtering and dedup applied | Explains what was excluded and why |
| Known limitations | Documents recognised gaps |
| Consent status for personal data | Required under privacy law |
The acquisition date matters more than people expect. Terms of service change, and a dataset collected under one licence may be redistributed under another. Without a timestamp, the applicable terms are unknowable retrospectively.
Deletion Is the Hard Constraint
Several privacy frameworks grant individuals a right to erasure. For a database that is a delete statement. For a trained model it is genuinely difficult — the information is distributed across weights with no addressable location.
The available responses are all imperfect. Retraining without the data is correct and expensive. Machine unlearning techniques are an active research area with limited guarantees. Output filtering suppresses symptoms rather than removing information.
The practical mitigation is architectural: keep personal data in a retrieval layer rather than in training data wherever the use case permits. Deleting a document from a corpus is trivial; deleting it from weights is not. That single design choice converts an intractable compliance problem into a routine one.
Documenting Composition
Aggregate description is achievable even for large corpora and answers most questions. Report the proportion by source type, by language, by time period and by domain.
Composition explains behaviour. A model trained overwhelmingly on English web text will perform worse in other languages, reflect the demographics of who writes online, and encode the time period of its corpus. None of that is surprising once composition is known, and all of it is mysterious when it is not.
Model cards and dataset documentation exist for this purpose. Their value is that they force explicit statements about intended use, known weaknesses and evaluated populations — which is precisely the information a downstream deployer needs and rarely receives.
Inherited Risk
Most teams fine-tune rather than pretrain, which means inheriting a base model’s provenance without visibility into it. That risk is real and largely unavoidable, but it can be managed: record which base model and version you used, retain the licence terms, and document your own added data thoroughly. When a question arises about the base model, you can at least establish the boundary of your own contribution.
The Bottom Line
Record source, date, licence and filtering for every dataset as you acquire it, because reconstructing it later is impossible. Keep personal data in retrieval rather than training where you can, and document corpus composition so that model behaviour is explicable.
