Traceability under the EU AI Act operates on two dimensions: technical traceability identifies what produced a given output, while business traceability assesses whether outcomes align with stated intent. This page covers both dimensions, how to bridge them, and the five artefact categories that must be versioned to maintain an auditable compliance record.
Traceability under the EU AI Act requires two complementary dimensions serving different audiences and purposes. Technical traceability answers what produced a given output, identifying the exact model version by hash, code version by Git commit SHA, data versions for training and features, infrastructure state including container images, and specific input data from the logging layer. This chain enables reproduction of any historical inference and root cause diagnosis. Business traceability answers whether the system achieves its intended outcomes, tracking five dimensions: outcome alignment with the documented purpose, affected person experience including transparency and redress, deployer satisfaction, override and intervention patterns revealing alignment with human judgement, and complaint volumes. A translation layer between technical metrics and business outcomes is essential because a technical metric change has business significance only in context. The model registry serves as the central navigation index, with composite version identifiers embedded in every inference log entry enabling single-lookup provenance retrieval. Four implementation practices make traceability robust: version tagging at execution time, cryptographic hash verification at model load, shared transformation code between training and serving, and an immutable deployment ledger. Five artefact categories (source code, model artefacts, datasets, configuration, documentation) must be versioned with specific tooling and evidence requirements.
For a given system output, technical traceability must identify the exact model version, code version, data versions, infrastructure state, and input data that produced it.
For a given system output, technical traceability must identify the exact model version, code version, data versions, infrastructure state, and input data that produced it. Each element is referenced by a deterministic identifier: model artefact hash, Git commit SHA, DVC data version, container image digest, and logged input record. This traceability chain enables the engineering team to reproduce any historical inference, diagnose root causes of unexpected outputs, and demonstrate to a technical auditor that the system's behaviour is deterministic and traceable.
The model registry, code repository, data versioning system, container registry, and logging infrastructure must all be integrated so that a single query against the composite version identifier retrieves the complete provenance chain. The serving infrastructure tags every inference request with the composite system version at the point of execution, embedded in the log record and immutable after the fact.
Business traceability answers a different question from technical traceability: is the system achieving the outcomes it was designed to achieve, and are those outcomes aligned with the organisation's stated intent.
Business traceability answers a different question from technical traceability: is the system achieving the outcomes it was designed to achieve, and are those outcomes aligned with the organisation's stated intent. This dimension is owned by product management and business stakeholders rather than the engineering team, requiring different metrics, cadences, and reporting formats.
The product manager tracks five dimensions. Outcome alignment assesses whether the system's actual deployment outcomes are consistent with the intended purpose documented in Module 1. Affected person experience assesses whether individuals are receiving the transparency, explanations, and redress pathways documented in Module 8. Deployer satisfaction assesses whether deployer organisations find the system useful, trustworthy, and aligned with their compliance obligations.
The model registry is the central index that makes the traceability chain navigable.
The model registry is the central index that makes the traceability chain navigable. Without it, the links between code, data, and model artefacts may exist in principle but are impractical to follow. With a properly configured registry, any authorised person can start from a model version and trace backwards to the exact experiment, training run, dataset version, code commit, and pipeline execution that produced it.
The registry structure follows a lifecycle model. MLflow uses four stages: None for initial registration, Staging for models under validation, Production for deployed models, and Archived for retired models. Stage transitions must be governed: promotion from Staging to Production requires approval from the AI Governance Lead or delegate, and the approval event is logged with the approver's identity and timestamp. This approval log is Module 10 evidence demonstrating that no model reaches production without governance sign-off.
Technical traceability proves what produced an output; business traceability proves the output serves its intended purpose. A system can have perfect technical traceability while failing to achieve its documented business outcomes.
Take an inference ID, extract the composite version from the log, query the model registry for metadata, and traverse links to data version, code commit, and evaluation report. OpenLineage with Marquez or a custom script chaining Git, DVC, and MLflow lookups.
The model transitions to Archived stage with cryptographic signature verification. The registry records decommission date, trigger, and archive location. All artefacts remain retrievable for ten years to support retrospective regulatory inquiries.
Technical traceability identifies what produced a given output (model, code, data, infrastructure). Business traceability assesses whether outcomes align with stated intent and stakeholder expectations.
Five elements: exact model version, code version, data versions, infrastructure state, and input data, all linked through the composite version identifier for single-query provenance retrieval.
Five dimensions: outcome alignment with intended purpose, affected person experience, deployer satisfaction, override and intervention patterns, and complaint and escalation volumes.
Composite indicators translate technical metrics into business significance, enabling both audiences to detect alignment drift. The model registry provides the central navigation index.
Source code (Git), model artefacts (registry), datasets (DVC/Delta Lake), configuration (Git YAML/JSON), and documentation (version-controlled document management).
Model artefacts are stored with a cryptographic hash of their contents, verified at model load time to ensure the served model is identical to the one tested and approved. Feature transformation code is shared between training and serving pipelines, not duplicated, eliminating training-serving skew as a source of traceability breaks. Deployment events are recorded in an immutable deployment ledger capturing the before-state, after-state, the authorising person, and the evidence reviewed.
Override and intervention patterns track the proportion of recommendations modified by human operators and what the modification pattern reveals about alignment with human judgement. Complaint and escalation volumes track whether affected persons are raising concerns and whether those concerns are resolved.
The organisation needs a translation layer between technical metrics and business outcomes. A small drop in accuracy is a technical fact; its business significance depends on whether it causes more qualified candidates to be wrongly excluded, disproportionately affects certain groups, or triggers deployer complaints. The monitoring system should include composite indicators bridging both dimensions, enabling technical and business stakeholders to detect alignment drift from their own perspectives.
When a system reaches end-of-life, the production model transitions to Archived. The AI System Assessor verifies the artefact's cryptographic signature one final time before archival. The model registry records the decommission date, the end-of-life trigger, and the archive storage location as structured metadata. The archived model must remain retrievable for the ten-year retention period under Article 18.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Transparency and Information
Technical Documentation Contents
