Knowing what you trained on: provenance, lineage and lawful reuse

A team assembles a fine-tuning corpus from three places: pages scraped from the public web, a dataset bought from a data broker, and several years of internal support tickets. The three are cleaned, deduplicated, shuffled and tokenised into one flat file. Six months later the broker discloses that part of its dataset was collected without a valid basis. Counsel asks a simple question: which of our training examples came from that source, and what happens if we remove them? If the pipeline kept no per-record trace, there is no answer. The only honest options are to keep using a corpus you can no longer justify, or to throw the whole thing away and retrain from scratch.

That is the practical argument for provenance. It is not a documentation exercise. It is the difference between a surgical removal and a total loss, and it is the capability that determines whether you can answer scope questions at all. A signed licence review covering each source at dataset level tells you that somebody once believed the sources were acceptable. It tells you nothing about which individual records survived deduplication, which were augmented, or which were merged into a synthetic rewrite. A checksum of the final training file proves only that the file has not changed since you hashed it. A model card naming three source categories is a disclosure artefact, not a lookup index.

Provenance

The recorded origin of a piece of data: where it came from, when, under what terms, and who supplied it.

Lineage

The recorded chain of transformations a record passed through, so that any item in the final corpus can be traced back to its origin and forward to every artefact derived from it.

Purpose limitation

The principle that data collected for one stated purpose may only be used for that purpose or for a further purpose compatible with it.

Legal basis

The specific justification relied on for processing personal data. It attaches to a purpose, not to a dataset, so a new purpose may need a new basis.

What a lineage record has to carry

Useful lineage travels with the record and survives every transformation. At minimum it identifies the source system or acquisition, the collection date, the terms or legal basis under which the data was obtained, the jurisdiction of collection, the data subject category, and the identifier of the transformation job that produced the current form. When two near-duplicate records are collapsed into one, the surviving record inherits the union of their provenance, not the provenance of whichever copy happened to sort first. Teams routinely lose lineage precisely at the deduplication and augmentation steps, because those steps are written as throwaway scripts by people who are not thinking about a legal request eighteen months out.

{
  "example_id": "corp-2f19c8",
  "text_hash": "sha256:9c2f...",
  "source": {
    "acquisition_id": "vendor-set-b",
    "collected_on": "2024-11-03",
    "jurisdiction": "EU",
    "terms": "licence-b-v3",
    "lawful_basis": "contract"
  },
  "subject_class": "customer",
  "contains_personal_data": true,
  "derived_from": ["raw-114923", "raw-114927"],
  "transforms": ["pii-scan-v2", "dedupe-v5", "chunk-1024"],
  "eligible_for": ["finetune-support", "eval-internal"]
}

Reuse is a new decision, not a continuation of an old one

The second place provenance earns its keep is reuse. Support transcripts are collected so that agents can resolve customer issues. A product team now wants to train a general assistant from that archive and sell it to other customers. The question that governs this is compatibility: is the new purpose compatible with the purpose the data was collected for, judged on the relationship between the two purposes, the context in which the data was collected, the nature of the data, the likely consequences for the people involved, and the safeguards applied. Where the new purpose is not compatible, you need a fresh basis and, ordinarily, fresh notice.

Three arguments come up constantly and none of them work. The first is ownership: we hold the archive, so we may use it. Ownership of a database is not a permission to process the personal data inside it. The second is that de-identification makes any downstream purpose permissible. De-identification is a safeguard that weighs in the compatibility assessment and can help, but the next module shows how rarely it reaches true anonymity, and a safeguard does not by itself convert an incompatible purpose into a compatible one. The third is that customers accepted terms of service at the time of the support interaction. Consent to a support relationship is not consent to become training material for a commercial product sold to third parties, and a general terms clause is unlikely to carry that weight.