When the EU’s Digital Omnibus on AI entered into force in July 2026, many organizations read the headline, a delay to high-risk AI obligations, and relaxed. That is a mistake for anyone who builds or deploys AI in areas such as hiring, credit, education, insurance or critical infrastructure. The delay moved the date, not the work. And the hardest part of that work is not writing policies; it is producing evidence about data: where training, validation and test data came from, what was done to it, and how it relates to the model in production.
That evidence is exactly what data lineage is designed to produce. This playbook explains what Article 10 of the EU AI Act asks for, how the timeline now looks, and how to build lineage that answers an auditor’s questions without a months-long archaeology project. It is written for data and AI leaders, not as legal advice; your counsel should confirm how the Act applies to your systems.
The Timeline After the Digital Omnibus
The Omnibus amendment, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, as summarized by the National Law Review. Its key timing changes for high-risk systems are:
- Stand-alone high-risk systems listed in Annex III, such as those used in employment, education, credit assessment, law enforcement and critical infrastructure, now face obligations from 2 December 2027 instead of 2 August 2026.
- High-risk AI embedded in products covered by EU product safety legislation (Annex I), such as medical devices and machinery, moves to 2 August 2028.
- Transparency obligations under Article 50 continued to apply from 2 August 2026, and general-purpose AI model obligations stayed on their original timetable.
The Omnibus also broadened the legal basis for processing special categories of personal data to detect and correct bias. According to Gibson Dunn’s analysis of the political agreement, this basis now extends beyond providers of high-risk systems to AI systems and general-purpose models more generally, subject to a strict necessity standard. That makes rigorous, documented control over such data even more important, because the permission comes with conditions you must be able to prove.
For a system that takes a year or more to design, build, document and assess, December 2027 is close. Lineage, which must be captured as pipelines run and cannot easily be reconstructed afterwards, is on the critical path.
What Article 10 Actually Requires
Article 10 applies to high-risk AI systems that are trained with data, and requires training, validation and testing datasets to be subject to data governance and management practices appropriate to the system’s intended purpose. Paragraph 2 lists what those practices must cover, which in summary are:
- Relevant design choices.
- Data collection processes and the origin of data, and for personal data, the original purpose of collection.
- Relevant data preparation operations, such as annotation, labelling, cleaning, updating, enrichment and aggregation.
- The assumptions about what the data is supposed to measure and represent.
- An assessment of the availability, quantity and suitability of the datasets needed.
- An examination for possible biases likely to affect health and safety, fundamental rights or lead to prohibited discrimination, especially where outputs influence future inputs.
- Appropriate measures to detect, prevent and mitigate those biases.
- Identification of relevant data gaps or shortcomings and how they can be addressed.
Paragraph 3 adds quality expectations: datasets should be relevant, sufficiently representative and, to the best extent possible, free of errors and complete for the intended purpose, with appropriate statistical properties for the people or groups the system is meant to be used on. Paragraph 4 requires datasets to reflect the specific geographical, contextual, behavioral or functional setting of use. Paragraph 5 sets strict conditions for processing special category personal data for bias correction, including state-of-the-art security, pseudonymization, controlled and documented access, no transfer to other parties, deletion once the bias is corrected, and records explaining why the processing was strictly necessary.
Read with an engineer’s eye, at least half of these obligations are questions about provenance and transformation: where data came from, what happened to it, who accessed it and when it was deleted. Those are lineage questions.
Article 10 does not ask for a lineage tool, but almost every question it raises about training data is a lineage question. If you cannot trace it, you cannot evidence it.
Mapping Article 10 to Lineage Capabilities
A practical way to plan is to map each requirement to the lineage capability that produces its evidence.
- Origin and collection (2b): source-level lineage that links each training dataset back to systems of record, external providers or collection campaigns, with dataset facets recording source system, collection period and the legal basis or original purpose for personal data.
- Preparation operations (2c): job-level lineage for every cleaning, labelling, enrichment and aggregation step, with the code version (for example a git SHA) and parameters captured at runtime.
- Assumptions and design choices (2a, 2d): links from datasets to the design documents, data contracts and feature definitions that state what each field is meant to represent.
- Suitability, representativeness and quality (2e, 3, 4): data quality metrics and assertions attached to dataset versions, including distribution profiles by relevant groups and geography.
- Bias examination and mitigation (2f, 2g): lineage from bias analysis jobs to the dataset versions they examined, and from mitigation steps such as reweighting or resampling to the resulting training sets.
- Special category data controls (5): column-level lineage showing exactly where sensitive attributes flow, with masking flags, access logs and lifecycle events proving deletion.
- Model linkage: lineage from final training, validation and test dataset versions to the model version and deployment, so documentation refers to what actually shipped.
Building the Lineage Foundation
Capture at runtime, using an open standard
Reconstructing lineage after the fact from notebooks and scripts is slow and unconvincing. Capture it as jobs run. OpenLineage provides a vendor-neutral event model for this: runs, jobs and datasets enriched with facets such as schema, source code location, SQL, ownership, data quality assertions and dataset versions. Its column lineage facet distinguishes direct transformations from indirect influences such as filters and joins, and flags masking operations, which is particularly useful for demonstrating how special category attributes were handled.
Version datasets, not just models
Most ML teams version models carefully and datasets casually. For Article 10 purposes, the training set is as important as the model. Use table formats with snapshots, such as Apache Iceberg or Delta Lake, or dataset versioning tools, and record the exact snapshot each training run read. A lineage event that says “trained on customers table” is far weaker than one that names a specific snapshot with its row count, profile and quality results.
Extend lineage into the ML lifecycle
Analytics lineage usually stops at the warehouse. Compliance lineage must continue through feature pipelines, labelling tools, experiment tracking, model registries and deployment. Emit lineage from training pipelines and connect experiment runs to dataset versions and registered models. Cloud platforms increasingly help: in June 2025 AWS announced an OpenLineage transport for sending lineage events into Amazon SageMaker Unified Studio, alongside expanded automated lineage for Glue and Redshift.
Attach the human context
Not everything Article 10 asks for is machine-generated. Assumptions, design choices, identified data gaps and bias assessment conclusions are human judgments. Link them to lineage nodes, for example as references to approved documents or data contract versions, so that an auditor can move from a model version to its datasets to the reasoning behind them in a few clicks.
Decide who owns the evidence
Lineage programs for compliance stall when nobody owns the result. Assign clear roles early. Data product or pipeline owners are responsible for lineage completeness and quality metadata on the datasets they produce. ML engineering owns the link from dataset versions to experiments, models and deployments. A governance or risk function owns the mapping from Article 10 requirements to evidence and runs periodic reviews. Legal confirms scope and interprets new guidance as the Commission and standardization bodies publish it. Write these responsibilities into your AI management system, so they survive team changes.
Coverage also needs a measurable definition. A simple metric, such as the share of compliance-relevant pipelines emitting complete lineage with required facets, reviewed monthly, turns an abstract goal into something teams can track and improve.
A 12-Month Implementation Plan
For an organization with one to five high-risk use cases and a December 2027 horizon, a realistic plan looks like this.
- Months 1–2: Scope and inventory. Confirm with counsel which systems are high-risk. For each, inventory data sources, pipelines, labelling processes and models, and identify where lineage already exists.
- Months 2–4: Standards and naming. Adopt an open lineage standard and dataset naming conventions; define the minimum facets required for compliance-relevant pipelines, such as source, code version, dataset version, quality results and ownership.
- Months 3–6: Instrument pipelines. Enable lineage in orchestration, Spark, SQL transformation and training pipelines; build a shared emitter library for custom code; version training datasets.
- Months 5–8: Sensitive data controls. Implement column-level lineage and masking for special category attributes, isolated processing environments for bias correction, access logging and automated deletion with lifecycle events.
- Months 7–10: Evidence assembly. Generate draft dataset documentation directly from lineage and quality metadata; link human assessments; run a mock audit on one system end to end.
- Months 10–12: Operate and improve. Make lineage completeness a release gate for model updates, monitor event coverage, and repeat the mock audit for remaining systems.
Worked Example: A Credit Scoring Model
Consider a lender retraining a credit risk model that falls under Annex III. The training data combines core banking transactions, application forms, a credit bureau feed and a labelled dataset of historical defaults. A feature pipeline aggregates transactions into behavioral features; a bias analysis checks outcomes across age bands and other protected characteristics, which the lender processes only in an isolated environment for bias detection.
With runtime lineage in place, the lender can show for the current model version that it was trained on a specific snapshot of the feature table, which was produced by a named version of the feature pipeline from defined snapshots of the three sources, with the bureau feed’s contract and collection purpose attached. Quality assertions on that snapshot passed, and profiles by region and age band are recorded. Column lineage shows that the protected attributes used for bias analysis never flowed into the training feature set, only into the isolated analysis job, where they were pseudonymized; lifecycle events show their deletion after the analysis concluded. The bias assessment and the decision to reweight one segment are linked to the training run that applied the reweighting.
When a regulator or notified body asks how the model’s data was governed, the answer is a navigable record rather than a scramble through notebooks and email threads. Just as important, when the next retraining happens, the same evidence is produced automatically.
Common Pitfalls
- Starting with documentation templates instead of instrumentation. Templates filled in by hand drift from reality; generate as much as possible from lineage and metadata.
- Stopping at the warehouse. Lineage that ends before feature engineering and training misses the steps Article 10 cares most about.
- Unversioned training data. Without snapshots, you cannot prove which data trained which model.
- Treating special category data like any other column. Paragraph 5 conditions demand isolation, access logs and proven deletion.
- Ignoring third-party data. External datasets need provenance, licensing and collection-purpose records as much as internal ones.
- One-off compliance sprints. Models are retrained; evidence must be regenerated each time, so lineage has to be part of the pipeline, not a project.
Outlook
Regulatory pressure for data provenance is spreading beyond the EU AI Act, from financial supervisors’ long-standing data aggregation expectations to management system standards for AI such as ISO/IEC 42001. At the same time, AI systems are becoming more compositional: retrieval indexes, fine-tuned models, agents and tools all have data dependencies. Expect lineage to expand to cover vector indexes and retrieval corpora, prompts and evaluation datasets, and expect auditors to ask for it. Organizations that build open, runtime lineage now will be able to answer new questions by querying a graph they already have.
Conclusion
The Digital Omnibus gave providers of high-risk AI more time, but Article 10’s substance is unchanged: you must govern and document the data behind your models, including its origin, preparation, quality, biases and gaps. Data lineage is the most efficient way to produce that evidence continuously rather than reconstructing it under deadline. Capture lineage at runtime with an open standard, version datasets, extend the graph through the ML lifecycle, handle special category data with provable controls, and generate documentation from metadata. Start now, and December 2027 becomes a checkpoint rather than a cliff.
How Hanoi Technology Can Help
Hanoi Technology helps AI and data teams build runtime lineage, dataset versioning and evidence pipelines that support EU AI Act data governance requirements.
Further Reading
- EU Digital Omnibus on AI enters into force – National Law Review
- EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes – Gibson Dunn
- Article 10: Data and data governance – Mishcon de Reya EU/UK AI Navigator
- Column Level Lineage Dataset Facet – OpenLineage Docs
- Amazon SageMaker contributes a custom transport to the OpenLineage community – AWS