When an auditor, a customer, or a regulator asks “where did this model come from?”, most teams cannot answer cleanly. The AI Model Lineage Tracker builds a structured record of every model in your stack — its base model, fine-tuning sources, training-data provenance, and dependency chain — so the answer is one document away.
How it works
You add each model as a row: its name and version, the base model it builds on, any fine-tuning source and data, and the provenance of the training data (public, licensed, customer, or synthetic). You can mark dependencies — which deployed models call or build on others — and the tool renders the lineage chain.
The output is a clean, copyable lineage document. It maps onto the provenance and data-governance questions in the EU AI Act’s technical-documentation requirements and the “training data” and “model details” sections of a standard model card.
Why AI supply chain documentation has become urgent
The EU AI Act classifies AI systems by risk tier and requires technical documentation for high-risk systems, including training data descriptions and provenance records. Outside of the EU, customers in regulated industries — finance, healthcare, defence — now routinely ask suppliers for AI lineage records as part of vendor due diligence. An undocumented model is not just a compliance gap; it is a competitive disadvantage when procurement teams require written evidence before they can approve a supplier.
Independently of regulation, lineage documentation catches supply-chain risks early. A model fine-tuned on customer data that was licensed for one purpose but used for another creates liability. A model that depends on a third-party foundation model that gets deprecated or repriced creates operational risk. Tracking these relationships makes them visible while there is still time to act.
What the tool captures for each model
| Field | Why it matters |
|---|---|
| Name and version | Makes the record auditable and reproducible |
| Base model | Shows which foundation you are building on and its licensing |
| Fine-tuning source | Identifies what adapted the model and under what data rights |
| Training data provenance | Public / licensed / customer / synthetic — the most common compliance question |
| Downstream dependencies | Which of your other models or systems depend on this one |
Tips for building a useful lineage record
The highest-value field is training-data provenance — it is the one most teams cannot reconstruct after the fact, so capture it while you still can. The second is version history: record the exact version of each base and fine-tuned model, because “we use a GPT-class model” without a version number is not auditable. Treat the lineage record as living documentation and update it whenever you swap a base model, retrain, or change a data source. Everything is assembled in your browser and nothing is uploaded, so you can document internal or restricted models safely.