EU AI Act Provisions on Data Governance and Their Enforcement Limits
National enforcement gaps and supply chain opacity limit how much regulators can verify.
The EU AI Act’s data governance rules demand more than clean datasets and written assurances. Article 10 sets substantive requirements, but national enforcement gaps, opaque supply chains and the limits of auditing a trained model restrict what regulators can verify. An organisation must therefore both document compliance and make design choices that leave that documentation open to meaningful scrutiny.
What Article 10 actually requires of high-risk AI system providers
Article 10 applies to the datasets used for training, validation and testing in high-risk AI systems that use machine learning techniques. Providers must record and use governance practices that cover the relevant design choices, how the data was collected and its data origin, including why personal data was first collected. They must also account for preparation operations, including annotation, labelling, cleaning, updating, enrichment and aggregation. The obligation begins with how the data became usable.
Article 10 requires providers to formulate assumptions about what their data measures and to assess the availability, quantity and suitability of datasets. Providers must examine biases likely to affect health and safety, fundamental rights or prohibited discrimination, especially when outputs become inputs later. They must take appropriate steps to detect, prevent and mitigate the biases they find. The eighth practice concerns identifying gaps or shortcomings that prevent compliance and explaining how those gaps will be addressed.
Quality is also tied to intended use. Datasets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete, with appropriate statistical properties for the persons or groups targeted. They must account for the geographic, contextual, behavioural or functional setting in which the system will operate. Article 10(5) originally allowed special-category personal data to be processed in exceptional cases for bias detection and correction, if six strict conditions were met. These included technical re-use limitations, state-of-the-art security and privacy-preserving measures including pseudonymisation, deletion once bias is corrected, and a prohibition on third-party transfer.
The interlocking articles that make Article 10 operational — and verifiable in theory
Article 11 turns these governance practices into a technical record. Providers must maintain documentation covering design choices related to training data, the datasets used and their intended purpose, and make it available to national competent authorities on request. That gives an authority something specific to inspect.
Articles 12 and 13 extend that record into operation and downstream use. Article 12 requires high-risk systems to have built-in capabilities that automatically log events that help identify risks and material modifications for as long as the system is in use. Article 13 requires providers to give deployers enough information to understand the training data used and its limitations. A deployer acquiring a high-risk system from a third party has a right to that information.
Documentation establishes the development record, logging provides the operational trail, and disclosure extends accountability to the organisation using the system. What connects those duties to market access? A high-risk system must pass a conformity assessment before being placed on the EU market, and data governance documentation is a prerequisite.
How the Digital Omnibus reshaped both the timeline and the scope of Article 10's reach
The Digital Omnibus, in force in late July 2026, changed when much of this verification architecture applies without weakening Article 10’s substance. For Annex III high-risk systems, including hiring and credit scoring applications, the deadline moved from 2 August 2026 to 2 December 2027. The new deadline applies to the requirements for data governance, technical documentation, logging, conformity assessments and registration. For Annex I product-safety systems, which include medical devices, the duties under the AI Act apply from 2 August 2028.
The Omnibus also broadened a specific data-processing permission. It moved the special-category personal data permission for bias detection and correction from Article 10(5) into a new Article 4a. That permission now extends beyond providers of high-risk systems to all AI systems and models, including general-purpose AI models, and to deployers. This change of scope should not be confused with an extension of every Article 10 obligation to every AI system.
Other duties were not postponed by the Omnibus. GPAI obligations concerning training-data transparency, copyright policy compliance and publication of training data summaries have applied since 2 August 2025. Article 50 transparency duties, including chatbot disclosure, deepfake labelling and synthetic content marking, took effect on 2 August 2026. For the delayed high-risk obligations, however, the shift creates a longer interval before the corresponding governance and verification requirements apply.
Why enforcement of data governance obligations lands primarily on national authorities that are not yet ready
The AI Act divides enforcement between national and central institutions. National competent authorities enforce the risk-based obligations for AI systems, with help from central bodies that include the European Commission. The Commission exclusively supervises and enforces Chapter V GPAI rules, entrusting implementation to the AI Office, which also has exclusive competence over certain GPAI-based systems under amended Article 75. That central role does not displace the national pattern. Oversight of the most substantive high-risk data governance duties remains predominantly decentralised.
The European Parliament’s research briefing recorded that 8 of 27 member states had notified a single point of contact as of March 2026. The Future of Life Institute’s national implementation tracker recorded that 9 of 27 had designated both a market surveillance authority and a notifying authority as of 17 June 2026. Roughly half showed only partial designation, and several had neither.
Finland provides the clearest operational contrast. It became the first EU member state with operational AI Act enforcement, with Traficom designated as the single point of contact and sector market surveillance authorities operating under legislation in force since 1 January 2026. Italy enacted a dedicated national AI law on 10 October 2025, designating the National Cybersecurity Agency as market surveillance authority and single point of contact. Germany’s federal cabinet adopted the KI-MIG draft on 11 February 2026, naming the Bundesnetzagentur as both market surveillance and notifying authority, with DAkkS as the accreditation body. The draft had not cleared the Bundestag and Bundesrat by mid-2026.
France remained without formally designated authorities as of 17 August 2026, a year after the Article 70 designation deadline. CNIL served in practice as the reference authority for systems involving personal data and other Annex III domains, but it had to wait for the National Assembly to adopt the DDADUE bill before it could have formal AI Act authority. The Senate had passed it on 18 February 2026. A system deployed across member states faces different enforcement in practice because each country has its own bodies in charge.
How opaque supply chains make Article 10 obligations difficult to trace even when authorities are ready
When a high-risk application is built on a third-party foundation model, the system provider has duties under Article 10, while the upstream model supplier often controls the training data. An enterprise acting as the high-risk system provider cannot discharge that responsibility simply by pointing to its model vendor’s practices. Yet it may be unable to get the underlying training data, bias examination records and data origin documentation. Article 11 can therefore require a record that the responsible party cannot fully assemble.
GPAI transparency duties provide some visibility into that upstream layer. The European Commission published a mandatory training-content summary template on 24 July 2025, requiring general characteristics, lists of large publicly available datasets, and yes/no indications with general descriptions for licensed and third-party sources. Its approach is deliberately aggregated and narrative-style to avoid over-disclosure. A summary is not the underlying dataset. How far can it support a system provider’s account of dataset suitability, bias or contextual fit?
Meta publicly announced its refusal to sign the GPAI Code of Practice, illustrating that major providers may contest those expectations. Refusal to sign a voluntary code should not itself be confused with breach of a legal duty. It does, however, test the reach of a framework in which the Code and mandatory summary template are the main transparency tools for the GPAI layer.
When an EU enterprise uses a non-EU LLM provider for a high-risk application, it must meet both the AI Act data governance obligations and the GDPR Chapter V transfer requirements. A Standard Contractual Clause does not establish the training-data provenance that AI Act documentation requires. Systems designed so that user data and inference remain within a controlled environment reduce one layer of this complexity. They do not, by that fact alone, explain an upstream model’s training history.
Why training data cannot be meaningfully audited after a model is deployed
The deployed model offers weights and behaviour. Verifying the practices covered by Article 10(2)(b)–(h) requires evidence about data used before deployment, which may no longer be retained and was never in the regulator’s possession. Technical limits prevent model outputs from reconstructing that evidence.
Where original datasets and records remain accessible, they can support scrutiny, but deployment does not itself preserve them in an auditable form. Article 12 logging serves a different purpose. It records operational events relevant to risks and material modifications during the system’s lifetime, rather than recreating the provenance or quality of pre-deployment training data. A strong operational trail cannot substitute for a missing development record.
Within Annex III, third-party assessment by notified bodies is required only for biometric identification systems, and only where harmonised standards or common specifications have not been fully applied. Providers use self-assessment for the broad range of other Annex III high-risk applications. Their documentation is therefore assessed primarily on its face rather than independently checked against the underlying data.
Civil society organisations also lack access to the data and documentation needed for independent audits of high-risk systems. The GPAI Code’s development process has faced criticism for privileging industry access over civil society participation, further exposing the limits of external scrutiny. Who, then, can test a provider’s account against actual practice? The framework relies heavily on what providers report about themselves and what they choose to disclose. Its documentation layer is demanding, but its data layer remains difficult to verify after training.
What the gap between Article 10's demands and enforcement's reach means for organisations building or deploying high-risk AI
Limited verification does not make Article 10 optional. Breaches of high-risk and transparency obligations carry large penalties, though these are below the maximum of €35 million or 7% of global annual turnover for prohibited AI practices. The delayed Annex III deadline provides preparation time. Because self-assessment dominates for most Annex III systems, internal documentation is central to compliance posture. Organisations cannot assume an independent pre-deployment check will identify their gaps.
The practical response begins with assigning responsibility before evidence becomes difficult to recover. Organisations should inventory AI systems sufficiently to classify them by risk, a step most have not completed, and give an internal owner authority to generate and maintain Article 11 documentation. Vendor contracts should make training-data provenance and bias examination records easy to find and understand. Logging needs to be built in before deployment. Dataset-level bias examination should document identified gaps and how they are addressed.
Timing makes those preparations more pressing. CEN and CENELEC harmonised technical standards are targeted for the end of 2026, promising a clearer conformity path but leaving less time before December 2027. Providers using third-party foundation models must either obtain sufficient provenance documentation or design deployments to reduce exposure to undocumented upstream practices. The provider must make that choice, which determines how much of its legal account rests on evidence it can actually obtain.
Privacy-by-architecture offers a partial structural response by keeping user data and inference within a controlled environment, reducing chain-of-custody complexity, but it does not establish dataset representativeness, correct bias or reconstruct missing training evidence. The deeper implication is that more inspectors alone cannot close the enforcement gap. Design choices made before training and deployment determine how much evidence remains available when an authority eventually asks.
