An identity verification system rejected a match, the customer complained, the complaint escalated and most of a year later someone asks you to explain that one decision.
Answering it means establishing five things:
- Which model version served the request.
- Which build and configuration it ran under.
- What the input and feature values were at that instant.
- Which training snapshot the model came from.
- Who approved its promotion to production.
Most teams can answer two of those with confidence. The model registry usually knows what was current, and the application logs usually retain something about the request.
The rest is archaeology: a Git commit that may not match what was deployed and a training set assembled from a query nobody saved.
The constraint is timing more than tooling, because every link had to be recorded while it was being created.
What lineage records
The chain has three segments, and teams often build one and assume they have all three.
Data lineage proper covers which sources and transformations produced which tables and columns. Table-level lineage tells you a job read one dataset and wrote another.
Column-level lineage tells you which input fields contributed to a given output field, which is the resolution you need when the disputed value is one feature instead of a whole pipeline.
Model lineage covers which dataset version, code revision, parameters and environment produced which registered model version.
MLflow’s model registry treats this as a first-class relationship: “Each registered model version is linked to the MLflow run, logged model or notebook that produced it.”
Inference lineage covers which model version, given which inputs, produced which output at which moment.
This is the segment most often missing, partly because it lives in application code instead of the ML platform, and partly because it generates a record per request instead of one per training run.
That per-request volume is the real reason teams skip it, which makes inference lineage a storage decision as much as an engineering one.
Sampling looks like the obvious compromise until you notice that the decision someone disputes a year from now is unlikely to be one you sampled.
Where full capture is impractical, keep the complete record for decisions carrying a route to appeal and sample the rest, which is at least a policy you can explain.
Stitching the three together is what OpenLineage exists for. It is “an open framework for data lineage collection and analysis” built around a standard API for lineage events, tracking metadata about datasets, jobs and runs so heterogeneous tools emit lineage in one format.
The distinction worth holding onto is that it is a standard and not a tool. Storage and graph traversal come from a metadata platform, and DataHub’s comparison of the open-source options covers that layer across DataHub Core, OpenMetadata, Apache Atlas, Marquez, Egeria and Spline.
Choosing the standard first and the store second is the cheaper order.
Where the law sets the floor
For high-risk systems none of this is discretionary. Article 10 requires training, validation and testing data to be subject to “data governance and management practices appropriate for the intended purpose,” naming “data collection processes and the origin of data” and the “data-preparation processing operations, such as annotation, labelling, cleaning” among the specifics.
Those records are the prerequisite for the dataset section of the Annex IV technical documentation Article 11 demands.
Article 12 requires the system to technically allow automatic recording of events across its lifetime, with the stated purposes covering risk identification and post-market monitoring.
Article 12(3) is the one place the Act names specific events, and it applies to remote biometric identification: the period of each use, the reference database checked, the input data that produced a match, and the identity of the people who verified the result.
Retention splits across both parties, at least six months for providers under Article 19 and the same for deployers under Article 26(6).
That floor sits below the length of most real disputes, and sector law in finance and employment routinely requires longer, so set retention against your dispute horizon and not the statutory minimum.
The dates have moved while the substance has not. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and in force from 27 July. The Council and Parliament agreement behind it set “2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products.”
The classification work and the logging design both survive the change, and only the moment they become enforceable has shifted.
What the record earns before an auditor appears
Lineage does three jobs, and the one everybody thinks of is the least frequent.
- Debugging – When accuracy drops, lineage lets you bisect the problem: which upstream table changed, or which feature started arriving null. Without it, the same investigation is a week of asking colleagues what they deployed.
- Retraining decisions – When a slice of training data turns out to be mislabelled or contaminated, lineage tells you which model versions consumed it and which downstream artefacts inherited the problem. The alternative is retraining everything on suspicion.
- Regulatory and customer response – Reconstructing one decision with the inputs and version pins that produced it, instead of describing the system in general terms and hoping that suffices.
The first two recur throughout a system’s life and the third may never arrive at all, which is the argument for building lineage as an engineering asset that happens to satisfy a regulator.
Building it so it survives the question
A few properties separate lineage that holds up from lineage that merely exists.
Records should be written at the moment of the event and committed before the response returns, so a failed or compromised process cannot suppress its own trail.
They should be tamper-evident and stored outside the pipeline they describe, because an audit trail an operator can quietly rewrite is not evidence.
Version references should be pinned instead of pointing at a moving alias, since “latest” resolves to something different every time it is read.
And the identity of whoever acted needs to travel with the record, because an unattributable event answers very little.
The uncomfortable part is that all of this is prospective. Lineage is the one governance control that cannot be retrofitted under pressure, because the evidence had to be captured while the system was running normally.
That is what separates it from the archive work at the other end of the lifecycle, where a model being retired can still be packaged if the records exist. Where those records were never written, retirement simply makes the gap permanent.
Lineage is an infrastructure decision made early, and it sits alongside the rest of the discipline covered in the guide to the AI model lifecycle and governance. Neurotechnology Cloud runs production hosting and lifecycle management on dedicated GPU infrastructure inside the EU, with monitoring and record-keeping built in from the first deployment instead of bolted on for the first audit.
If you are designing a system that will have to explain one of its own decisions a year from now, get in touch.
