Summary
- The deadline has not yet legally moved as of 2026-07-13. The amending act has completed adoption and was signed, but the Parliament’s official procedure record still states that it is awaiting Official Journal publication. The act itself provides that it enters into force on the third day after publication. Until that occurs, the existing Article 113 dates remain legally operative.
- Under the presently binding AI Act, most Annex III high-risk-system requirements apply from 2026-08-02. Article 6(1) product-related high-risk systems and their corresponding obligations have the later current date of 2027-08-02. Other portions of the AI Act already apply under earlier staged dates.
- Once the signed amendment is published and enters into force, there will be two principal revised dates, not one generic “December 2027” deadline: 2027-12-02 for Article 6(2)/Annex III systems and 2028-08-02 for Article 6(1)/Annex I product-related systems.
- “Data lineage” is not a separately defined or technology-specific AI Act obligation. Article 10, Article 11, Annex IV, Article 12, and Article 17 nevertheless require components normally supported by lineage controls: data origin, preparation operations, assumptions, bias examination and mitigation, identified data gaps, dataset provenance, validation/testing records, lifecycle changes, logging, and documented data-operation procedures.
- Article 10 compliance is primarily a provider obligation through Article 16. Deployers have distinct duties, including requirements concerning input data they control, operational monitoring, and retention of automatically generated logs. Existing systems may also benefit from Article 111 transitional treatment, depending on placement date and later significant design changes.
Issue 1 — Has the high-risk AI deadline legally moved?
Not yet, as of 2026-07-13. The revised timetable has been finally adopted and signed, but it is not legally operative until the amending regulation is published in the Official Journal and the specified three-day entry-into-force period expires.
Current Article 113 provides for general application from 2026-08-02, with Article 6(1) and its corresponding obligations applying from 2027-08-02. It separately establishes earlier dates for specified chapters.
The signed amending act provides that it enters into force on the “third day following that of its publication” in the Official Journal. Its revised timetable would apply Chapter III, Sections 1–3, to Article 6(2) systems from 2027-12-02 and to Article 6(1) systems from 2028-08-02.
Consequently:
- A regulated party cannot yet rely on 2027-12-02 or 2028-08-02 as an in-force statutory safe harbor.
- The presently binding dates remain 2026-08-02 for the relevant Annex III requirements and 2027-08-02 for Article 6(1) product systems.
- Once publication and entry into force occur, the revised dates will replace those current dates.
- The postponement concerns specified high-risk-system provisions. It is not a blanket postponement of the entire AI Act.
Issue 2 — Which systems are covered?
Article 6(1) covers AI systems that are safety components of, or themselves constitute, products governed by specified Union harmonisation legislation where third-party conformity assessment is required. Article 6(2) covers systems listed in Annex III.
For an Annex III system, Article 6(3) provides a limited route to a non-high-risk conclusion where the system does not pose a significant risk of harm and does not materially influence decision-making, provided it performs one of the specified narrow supporting or preparatory functions. Systems that perform profiling of natural persons remain high-risk. The provider must document an assessment relying on the exclusion.
Annex III includes:
- systems used to evaluate natural persons’ creditworthiness or establish a credit score, except systems used to detect financial fraud;
- recruitment and selection systems and systems used for specified employment, work-management, promotion, termination, task-allocation, monitoring, or evaluation decisions; and
- systems used for risk assessment and pricing concerning natural persons in life and health insurance.
The AI Act also has extraterritorial reach in specified circumstances, including providers outside the Union that place systems in the EU market and certain non-EU providers or deployers where system output is used in the Union. Thus, establishment outside the EU does not by itself resolve coverage.
Material classification facts include:
- the system’s documented intended purpose;
- whether it makes or materially influences a listed decision;
- whether it profiles natural persons;
- the relevant product legislation, if any;
- whether the organization is a provider, deployer, importer, or distributor; and
- where the system is placed on the market, used, and produces output.
Issue 3 — Does the AI Act require “data lineage”?
The AI Act does not prescribe a product called a “data lineage system” or an exact end-to-end technical architecture. It does impose a network of data-governance, technical-documentation, logging, and quality-management requirements for high-risk systems. A robust lineage capability is therefore a strong and often practical method of producing the evidence required by the Act, but the implementation method should not be confused with the statutory rule.
Article 10 requires applicable training, validation, and test datasets to be subject to data-governance and management practices. The operative matters include “data collection processes and the origin of data,” an “examination in view of possible biases,” appropriate bias-detection and mitigation measures, relevant assumptions, assessment of availability and suitability, and identification of data gaps or shortcomings. Article 10(3) requires datasets, to the extent appropriate, to be sufficiently representative and “to the best extent possible, free of errors and complete.”
The bias requirement is therefore not a warranty that a dataset or system is entirely bias-free. The legal structure is one of examination, risk identification, mitigation, representativeness, error control, and documented judgment.
Article 11 requires technical documentation to be prepared “before that system is placed on the market or put into service” and kept up to date.
Annex IV requires technical documentation covering development methods, design choices and assumptions, system architecture and components, training methods, datasets and their “provenance, scope and main characteristics,” selection and acquisition methods, labelling and cleaning, validation/testing procedures, relevant metrics including discriminatory effects, test reports, and lifecycle changes.
Article 12 requires automatic recording of events over the system lifetime and logging capabilities that support the “traceability of the system’s functioning,” risk identification, post-market monitoring, and operational monitoring.
Article 17 requires a documented quality-management system, including procedures concerning data acquisition, collection, analysis, labelling, storage, filtering, mining, aggregation, retention, and other data operations.
The signed amendment changes portions of Article 10 but leaves the core provenance, preparation, assumption, bias, quality, and gap requirements in paragraphs 2–4 intact.
Issue 4 — Who bears the obligations, and what remains applicable now?
The strongest Article 10 responsibility ordinarily rests on the provider. A deployer is not automatically responsible for recreating the provider’s complete training-data lineage, although it has material duties concerning controlled input data, use, monitoring, and logs.
Existing-system transitional provisions and existing GDPR obligations also prevent a uniform answer that every current AI system must satisfy the same lineage standard immediately.
Article 16 requires providers of high-risk AI systems to ensure compliance with the requirements in Chapter III, Section 2, which includes Article 10. Providers must also maintain quality-management and technical-documentation arrangements, undergo the applicable conformity assessment, and satisfy recordkeeping and related duties.
Article 26 imposes distinct deployer duties. Deployers must use the system in accordance with instructions, monitor operation, and retain logs under their control. Where the deployer controls input data, it must ensure that those data are relevant and sufficiently representative in view of the system’s intended purpose.
Accordingly:
- A provider should be able to support the complete Article 10, Annex IV, Article 11, Article 12, and Article 17 compliance case.
- A deployer should focus on input-data quality within its control, compliant operation, human oversight where applicable, monitoring, incident escalation, and log retention.
- A customer that substantially modifies or rebrands a system may acquire provider obligations, depending on the Article 25 value-chain rules and the facts.
- Contractual access to upstream evidence may be critical where a provider incorporates third-party models, datasets, or components, even though the Act does not mandate a particular contract form.
Under the current Article 111 transitional rule, many high-risk systems placed on the market or put into service before 2026-08-02 become subject to the relevant AI Act requirements only if they undergo significant changes in design after that date. Public-authority deployers have a separate 2030 compliance date.
The signed amendment aligns the significant-design-change trigger with the revised date on which the relevant Chapter III provisions apply. This means placement date and subsequent modifications can materially alter the compliance result.
The existence of this transitional rule further undermines any claim that every deployed system must immediately satisfy the same Article 10 documentation standard. It does not, however, protect a materially redesigned system, a newly placed system, or an organization subject to separate legal obligations.
GDPR interaction
The AI Act expressly preserves EU personal-data and privacy law. Where an AI system processes personal data, the GDPR continues to apply independently of the revised AI Act timetable.
The GDPR is not limited to storage and access controls. Article 5(2) requires the controller to be “responsible for, and be able to demonstrate compliance.” Article 35 requires a data-protection impact assessment where processing is likely to result in high risk, including specified forms of systematic and extensive automated evaluation. Article 22 regulates certain decisions based solely on automated processing that produce legal or similarly significant effects.
These provisions do not create a universal GDPR rule called “data lineage.” They can nevertheless require current documentation of personal-data sources, purposes, processing operations, risks, safeguards, and automated-decision arrangements.
Issue 5 — Are the potential fines €35 million or 7%?
Not for ordinary noncompliance with Article 10’s high-risk data-governance requirements. The relevant maximum tier for provider noncompliance with Article 10 through Article 16 is €15 million or 3% of worldwide annual turnover. These are statutory maxima, not automatic penalties.
Article 99 establishes materially different tiers:
- up to €35 million or 7% of worldwide annual turnover for noncompliance with the prohibited practices in Article 5;
- up to €15 million or 3% for noncompliance with specified obligations imposed on providers, deployers, and other operators, including Article 16 obligations; and
- up to €7.5 million or 1% for supplying incorrect, incomplete, or misleading information in specified circumstances.
The Act also contains SME treatment and requires enforcement to account for the circumstances and seriousness of the infringement.
Article 16 requires providers to ensure that their high-risk systems comply with Section 2, where Article 10 is located. That linkage places an ordinary provider failure to meet Article 10 within the Article 16/operator-obligation framework, rather than the Article 5 prohibited-practices tier.
