EU AI Act Article 10: What Data Governance Requires of Your Document Corpus
The EU Council formally adopted the Digital Omnibus on 29 June 2026. Article 10 on data governance is untouched: what it requires of an enterprise RAG corpus.
On 29 June 2026, the Council of the European Union gave its final, formal green light to the Digital Omnibus on AI, two weeks after the European Parliament adopted the text on 16 June (423 votes in favour, 57 against, 174 abstentions) (NicFab, Licentium). The text locks in the deferral of high-risk obligations for stand-alone Annex III systems to 2 December 2027, and for Annex I systems embedded in regulated products to 2 August 2028. Publication in the Official Journal is expected within weeks, ahead of the 2 August 2026 deadline.
This green light closes three months of institutional back-and-forth. It leaves entirely untouched an article that most Digital Omnibus coverage barely mentions: Article 10, on governance of training, validation and testing data. Neither the Annex III deferral nor the Annex I deferral changes its content. And contrary to a common assumption among teams running RAG systems rather than internally trained models, this article does not leave them entirely out of scope.
What 29 June Changes — and What It Doesn’t
The Digital Omnibus settles a calendar question, not a substantive one. The obligations of Chapter III, Section 2 of the AI Act — risk management (Article 9), data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency toward deployers (Article 13), human oversight (Article 14), accuracy and cybersecurity (Article 15) — are not rewritten. What moves is the date by which a system classified as high-risk under Annex III must comply: from 2 August 2026 to 2 December 2027.
K-AI already covered, in a 1 June note, what remains due on 2 August 2026 for high-risk systems already in service — Annex IV, Article 12, Article 26 (read the article) — and, on 24 June, what Article 50 transparency specifically requires of internal chatbots (read the article). Article 10 is a third, distinct block: it is not about documenting the system (Annex IV) or informing the end user (Article 50), but about the data itself — how it’s collected, prepared, how representative it is, what biases it carries. It’s ground that neither generalist legal coverage nor the 26 DKP and enterprise search vendors we reviewed this week name explicitly.
What Article 10 Actually Requires of Your Datasets
The official text of Article 10 requires that training, validation and testing datasets for a high-risk system be subject to data governance practices covering eight specific points (official text — Article 10): design choices, data collection processes and the origin of the data, data-preparation operations (annotation, labelling, cleaning, updating, enrichment, aggregation), the assumptions made about what the data is meant to measure, an assessment of the availability and suitability of the datasets, an examination of possible biases affecting health, safety or fundamental rights, measures to correct those biases, and the identification of gaps or shortcomings preventing compliance.
Translated into document-governance terms, what Article 10 asks for looks a great deal like a corpus audit: where do the documents feeding the system come from, how were they cleaned or normalized before ingestion, what assumptions were made about their freshness and completeness, which segments of the corpus are over- or under-represented, and which gaps were identified but never closed. Article 10(3) adds a substantive requirement: datasets must be “relevant, sufficiently representative and, to the best extent possible, free of errors and complete” for their intended purpose. An enterprise document corpus riddled with diverging duplicates, outdated policies that were never flagged as such, or entire business areas left uncovered does not meet this bar — regardless of how well the system built on top of it appears to perform.
The Unsettled Question: Is Your RAG Actually in Scope?
This is where the most useful question sits for a CIO or CTO running a RAG system rather than an internally trained model. Article 10(6) sets out a distinct regime: “for the development of high-risk AI systems not using techniques involving the training of AI models, paragraphs 2 to 5 apply only to the testing data sets” (official text — Article 10(6)).
Most enterprise RAG deployments run on a pre-trained foundation model, not fine-tuned on the internal corpus. On paper, that narrows Article 10’s reach: points (a) through (h) don’t apply to the entire document corpus used at generation time, only to the dataset used to test the system’s performance before deployment and at each significant update. In practice, the dividing line is far from trivial to draw. If the document corpus also serves to evaluate retrieval accuracy, measure the rate of correctly sourced answers, or qualify the system ahead of a version change, it effectively becomes a testing dataset under Article 10(6) — and falls back under the representativeness, error-free and bias-detection requirements of paragraphs 2 to 5. None of the 26 DKP, enterprise search and data governance vendors we reviewed this week — Glean, Sinequa, Squirro, Unstructured.io, Collibra and Atlan included — formalizes this distinction between generation-time corpus and testing dataset under Article 10(6).
What a Review of 26 Market Players Reveals
Squirro published a detailed piece on 22 June on regulatory defensibility for AI deployments, focused on tracing permissions, retrieved documents and human decisions at every query (Squirro — AI Audit Trails) — adjacent ground, but centered on production-time traceability rather than upstream data governance. Structured-data governance vendors — Collibra, Alation, Atlan — publish AI compliance guides that address the question at model level (registries, model cards, risk classification) or structured dataset level (lineage, quality, provenance), but none descends to the level of the individual unstructured document — a PDF, a Confluence page, an archived email — that constitutes the raw material of an enterprise RAG system.
That gap isn’t an isolated oversight; it reflects a persistent market segmentation between model governance, structured-data governance, and RAG production tooling. Article 10’s text makes none of these distinctions — it refers to “datasets,” a term broad enough to cover an unstructured document corpus whenever it serves, even partially, to train, validate or test a high-risk system.
From Training Data to Proof of Compliance
A document corpus audit, to satisfy Article 10, needs to produce specific, dated evidence — not a general impression of quality. Concretely: a map of document provenance (author, source of truth, validation date), an inventory of preparation operations applied (deduplication, normalization, chunking, annotation), an assessment of representativeness by business unit or geography, a log of identified biases — an HR corpus that over-represents one entity, an internal policy that exists only in an outdated version in one language and a current one in another — and a register of documented gaps, even unresolved ones.
K-AI has already published the operational detail of this approach in two earlier notes: the six-axis audit method from 15 May (internal inconsistencies, cross-document conflicts, diverging duplicates, unflagged obsolescence, traceability, freshness — read the article) and the rapid diagnostic scorecard from 29 June for prioritizing effort (read the article). Both methods cover the ground Article 10 requires documenting; what changes with this week’s reading of the article is the precise regulatory framing that turns it, for a high-risk system, into an obligation rather than a best practice.
Why the Deferred Calendar Doesn’t Change the Urgency to Start
Pushing Annex III to December 2027 removes immediate pressure on risk classification, not on preparation. A RAG system that will fall into high-risk scope by that deadline — hiring, scoring, access to essential services — will need to present a governance history, not a one-off exercise performed the week before the compliance audit. Article 10(2) asks organizations to document processes, not a snapshot: how data was collected, prepared and corrected over time. A document corpus tidied up in thirty days ahead of a deadline doesn’t produce that history; a corpus under continuous monitoring for eighteen months does, naturally.
Penalties remain unchanged by the Digital Omnibus: non-compliance with providers’ obligations under Article 16 — which includes compliance with Article 10 — is subject to an administrative fine of up to €15 million or 3% of total worldwide annual turnover, whichever is higher (official text — Article 99(4)). SMEs and start-ups benefit from a cap at the lower of the two thresholds.
Frequently Asked Questions
What must the documentation required under AI Act Article 10 contain for a high-risk AI system?
Article 10(2) requires documenting eight elements for each training, validation and testing dataset: design choices, data collection processes and origin, preparation operations (annotation, cleaning, updating, enrichment), the assumptions made about what the data represents, an assessment of availability and suitability, an examination of possible biases, bias-correction measures, and the identification of gaps preventing compliance. Article 10(3) adds a substantive requirement: data must be relevant, representative, as free of errors as possible, and complete for the intended purpose.
Is a RAG document corpus (SharePoint, Confluence, DMS) covered by Article 10 if it doesn’t train a model?
Partially, under Article 10(6). If the high-risk system doesn’t train a model on that corpus, the governance requirements of paragraphs 2 to 5 apply only to the dataset used to test the system. In practice, once the corpus is also used to evaluate retrieval accuracy or to qualify a new version before deployment, it falls within scope of that testing obligation — which covers a large share of real-world enterprise RAG usage.
What’s the difference between Article 10 obligations and Annex IV requirements?
Article 10 governs the data itself: collection, preparation, representativeness, bias. Annex IV, referenced by Article 11, governs the technical documentation of the system as a whole — general description, design specifications, risk management, post-market monitoring. A system can have complete Annex IV documentation without the underlying data governance required by Article 10 being demonstrated: these are complementary obligations, not interchangeable ones.
Does the Digital Omnibus adopted on 29 June 2026 also delay Article 10?
No. The Digital Omnibus defers the compliance deadline for systems classified as high-risk under Annex III (2 December 2027) and Annex I (2 August 2028). It does not change the text or content of Article 10: once a system falls within high-risk scope, whenever that happens, the data governance obligations apply in full.
What penalties apply for non-compliance with Article 10?
Non-compliance with providers’ obligations under Article 16 of the AI Act — which covers compliance with Article 10 on data governance — is subject, under Article 99(4), to an administrative fine of up to €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. SMEs and start-ups are subject to the lower of the two thresholds.
Where to Go From Here
Article 10 shifts documentary compliance from a good-faith exercise into a dated, verifiable governance obligation. To assess where your document corpus stands against these eight points — collection, preparation, representativeness, bias, gaps — the K-AI team is available for an initial diagnostic conversation. Contact: contact@k-ai.ai.
K-AI already works with CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies and CEVA Logistics. Partners: AWS, Snowflake, Microsoft, Wavestone, Devoteam.
Related Reading
- EU AI Act August 2026: What the Digital Omnibus Didn’t Postpone — and the 60-Day Corpus Plan
- AI Act August 2: The Article 50 Your Legal Team Underestimated
- Auditing a Document Corpus for AI — the K-AI Six-Axis Method
Sources Cited
- EU AI Act — Article 10: Data and Data Governance, official text. https://artificialintelligenceact.eu/article/10/
- EU AI Act — Article 99: Penalties, official text. https://artificialintelligenceact.eu/article/99/
- NicFab Blog — Digital Omnibus on AI: the European Parliament Approves the Agreed Text, 17 June 2026. https://www.nicfab.eu/en/posts/digital-omnibus-ai-final-approval/
- Licentium — EU Council Formally Adopts AI Omnibus Amending EU AI Act, 29 June 2026, 3 July 2026. https://www.licentium.io/post/eu-council-formally-adopts-ai-omnibus-amending-eu-ai-act-29-june-2026
- Gibson Dunn — EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes, 27 May 2026. https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
- Squirro — AI Audit Trails: What Happens When the Regulator Calls, 22 June 2026. https://squirro.com/squirro-blog/ai-audit-trails-what-happens-when-the-regulator-calls
