BLUF: for a high-impact AI workflow, “we trained on approved data” is not enough. A release should be able to answer, from one reproducible evidence bundle: which source records and transformations produced this feature, training set or retrieval index; whether their purpose, retention and access terms still permit use; which cohorts were measured; and who approved the exception when they did not. Build that lineage before a model or index reaches production.
This is an engineering pattern, not a legal classification. Article 10 of Regulation (EU) 2024/1689 specifies data-governance requirements for training, validation and testing data for high-risk AI systems. Whether a system is high-risk, which operator role applies and what sector rules add are questions for qualified counsel. The architecture below makes facts, controls and decisions reproducible whatever that legal assessment concludes.
The operating problem: a model release has more data dependencies than its training set
Production teams often pin model weights but leave the data plane mutable. A source table refreshes; an upstream consent or retention condition changes; a feature definition moves; a document is re-chunked and re-embedded; a supplier replaces a corpus. The service still returns answers, but the team can no longer establish what evidence shaped a specific release. That is a control failure even if aggregate evaluation remains stable.
The same discipline belongs beside AI use-case intake as policy-as-code: the intake establishes purpose, affected groups and accountable ownership; the lineage system proves the actual data and artifact path that a release used. It also complements The LLM release bundle, which pins the deployable configuration.
A lineage graph that can stop a release
Use immutable IDs for every node and typed edges for every transformation. A practical minimum has DataAsset, DatasetVersion, TransformRun, FeatureDefinition, EmbeddingRun, RetrievalIndexVersion, FineTuneRun, EvaluationSuite and ReleaseBundle nodes. Edges state “derived from”, “validated by”, “approved for purpose”, “expired by”, “evaluated on” and “deployed as”. Store the source-system locator, content or snapshot digest, schema version, owner, classification, permitted purpose, retention condition, geographic boundary and evidence link on the appropriate node.
Diagram — controlled data path: Source register → contract validator → immutable dataset snapshot → transformation/feature or embedding run → cohort and quality evaluation → approval gate → signed release bundle → model or retrieval index → request trace carries release_id and index_version → monitoring event opens a re-review or rollback.
The graph is not a data catalogue with prettier arrows. It must answer reverse and forward questions in seconds: “Which live releases contain records from this source?” and “Which source-contract change can invalidate this index?” A graph database is useful at scale, but a relational implementation with immutable version tables and explicit edge records is often easier to operate first.
Contracts: make purpose, retention and quality executable
Each ingestible asset needs a versioned contract. Required fields should include permitted use (for example, fraud triage evaluation, not employee ranking), data subject or business cohort, collection basis/evidence reference where relevant, sensitivity/classification, retention or review event, producer schema, freshness expectation, quality checks, owner and exception route. The contract is checked at ingestion and again at release promotion. A contract without a technical gate becomes documentation that drifts.
This design supports the GDPR principles in Article 5—including purpose limitation, data minimisation, accuracy and storage limitation—and data-protection-by-design obligations in Article 25. It does not itself determine a lawful basis or replace a DPIA; those decisions require the controller’s facts and appropriate privacy/legal review.
Decision matrix: choose gates by release impact
| Release context | Minimum evidence gate | Stop condition | Accountable owner |
|---|---|---|---|
| Internal, non-personal knowledge assistant | source and index digests; freshness check; sampled retrieval test | unknown source or broken digest | data product owner |
| Customer-facing workflow | purpose and retention contract; cohort coverage; frozen evaluation slice; index rollback target | contract expired, critical cohort below threshold, or unresolved exception | product owner + data owner |
| Potentially high-risk or materially rights-affecting workflow | complete lineage to source; documented quality/bias assessment; independent approval; release evidence bundle | missing legal/compliance review where required, prohibited purpose, stale evidence, or failed critical cohort | accountable business owner with compliance/privacy review |
Quality and bias-control loops
Coverage must be measured against the intended population and task, not inferred from row count. Define cohorts before the evaluation run: language, region, document type, device/channel, class imbalance and rare but consequential cases. Persist the cohort definition, selection query, sample snapshot digest, metric definition, confidence or uncertainty method where applicable, reviewer notes and threshold. Compare candidate versus prior approved release on the same frozen slice.
For retrieval systems, treat the index as a data-derived release artifact. Record chunker version, embedding model revision, source document snapshot, ACL/policy filter version, corpus coverage and index build parameters. An index refresh can change what the model sees even when the model is unchanged. Require the same approval path for a material index refresh as for a model change.
NIST’s Generative AI Profile (AI 600-1) frames governance, content provenance and pre-deployment testing as primary considerations. Use its risk-management framing to decide which cohorts, tests and escalation routes are proportionate; it is not a substitute for domain-specific harm analysis.
Exceptions must be visible, time-bounded and reversible
A stale source, incomplete cohort or urgent incident should not create a shadow release process. Record an exception object linked to the failed contract or gate: reason, impact assessment, compensating control, approver, scope, expiry, monitoring signal and rollback release. The deployment service accepts only an active exception ID with a narrower release policy. On expiry, it automatically holds further promotion and creates an owner task. Never silently convert a failed gate into a warning.
Failure modes worth testing
Lineage stops at the lake: a team can name a table but not the query, transform version or snapshot. Mitigation: require content/snapshot digests and TransformRun IDs in the release bundle.
Aggregate quality hides a cohort regression: average accuracy improves while German long-form documents or a rare class degrade. Mitigation: freeze stratified cohorts, set critical floors and route near-threshold cases to human review.
A retrieval refresh bypasses model governance: re-embedding changes answers without a model deployment. Mitigation: treat index versions as promotable artifacts with evaluation and rollback.
Exception permanence: an emergency waiver has no expiry and becomes normal operation. Mitigation: machine-enforce expiry, scope, compensating control and retrospective review.
What this does not solve
Lineage can prove what happened; it cannot make a poor source representative, eliminate societal bias, establish legal compliance, or decide whether a use case is permitted. It adds storage, pipeline instrumentation and review work. Small, low-impact experiments may begin with source and transform digests plus an owner; systems that can materially affect people need stronger evidence and counsel-led legal assessment.
A practical first implementation
Start with one production feature or retrieval index. Inventory its sources, create contracts for the top three, emit immutable transform and index IDs, freeze two critical cohorts, define one release-blocking quality floor and rehearse rollback to the previous index/model bundle. If you need an architecture review that joins data contracts, release controls and operational evidence, that is a focused implementation workshop—not a paperwork exercise.
