Quick answerFine-tuning an open-source model in-house shifts provenance and audit responsibility from the vendor to you, permanently. Track four things from the first training run onward: the exact base model version and checkpoint, the full training dataset composition with source and consent basis for every subset, the hyperparameters and training code version used for each fine-tune run, and a versioned mapping from each deployed model artifact back to the run that produced it. Without that mapping, you cannot answer "what data influenced this model's behavior" months later, which is the question an auditor, a regulator, or your own legal team will eventually ask.
This is a different question than choosing to build in-house
The decision to fine-tune your own model rather than use a vendor-hosted one is a build-versus-buy platform choice covered elsewhere in this series. Provenance and audit obligations are what comes after that decision is made and the fine-tune is already running in production: an ongoing record-keeping discipline, not a one-time evaluation. A company can make the right build decision and still fail an audit six months later because nobody kept the paper trail the decision implied.
Why provenance breaks down faster than teams expect
A vendor-hosted model comes with the vendor's own documentation of what it was trained on, at least at a high level, and the vendor absorbs much of the burden of answering provenance questions. Once you fine-tune your own checkpoint on your own data, that burden transfers to you entirely, and it transfers at the exact moment you have the least infrastructure built for it: a small ML team iterating quickly, retraining on updated data, and not yet thinking about what a future audit will need. By the time the question actually comes, from a customer's legal team, an enterprise security review, or a regulator, the training runs that matter may already be six iterations in the past.
The minimum viable audit trail
Four records, kept from the first fine-tune run: the base model's exact version and checkpoint hash, since "we fine-tuned Llama" is not an answerable provenance claim without the specific release; the training dataset's composition, broken into named subsets with the source and consent or licensing basis for each subset, not just a total row count; the hyperparameters, training code version, and infrastructure config for every run, versioned the same way you would version application code; and a lookup table mapping each model artifact that actually gets deployed back to the exact training run that produced it, since a model that gets promoted to production three iterations after the run that trained it is useless to audit if nothing links the deployed artifact to its actual training history.
What this buys you when a hard question arrives
When a customer's enterprise security team asks whether their data ever influenced a model shared with other customers, or a regulator asks whether a specific category of data was used in training, the answer needs to be a lookup against a maintained record, not a best-effort reconstruction from engineers' memory and old commit history. The cost of building this discipline is small relative to the cost of not being able to answer that question credibly when it counts, which is also when your credibility with that customer or regulator is most on the line.
Treat model retirement the same way
Provenance obligations do not end when a model version is retired from production. Keep the training records and lineage mapping for retired checkpoints for as long as any customer conversation that model served could plausibly still be referenced in a dispute, support ticket, or legal request. Deleting the audit trail the moment a model is decommissioned just moves the unanswerable-question problem to a worse time: after the system that could answer it is already gone.
FAQ
Does this apply if we only fine-tune with LoRA or adapters, not a full fine-tune?
Yes. The provenance obligation is about what data shaped the model's behavior, not the specific fine-tuning technique. A LoRA adapter trained on customer data needs the same dataset-composition and lineage record as a full fine-tune.
Who should own this record-keeping, ML or legal?
ML engineering should own the mechanics of capturing the records at training time, since that is where the information exists, but legal and compliance should define what the record needs to contain, since they know what questions will eventually be asked of it.
Is this different from model versioning for rollback purposes?
Related but not the same. Versioning for rollback is about being able to revert to a prior model artifact; provenance is about being able to explain what went into any given artifact, including ones you are not planning to roll back to.