Quick answer: EU AI Act Article 10 data governance requires providers of high-risk AI systems to prove, with evidence rather than policy documents, that the datasets training, validating, and testing their systems are relevant, representative, sufficiently error-free, and actively screened for bias. Most data security tools were built to answer "where is sensitive data and who can see it?" which is a different question from "can you defend the quality and lineage of this specific training dataset on demand?" Satisfying Article 10 requires continuous, dataset-level governance, not a point-in-time scan report with a compliance label stapled to it.
If your organization's EU AI Act plan currently lives in a slide that says "Legal is reviewing," you're not behind. Most companies are in the same boat. But Article 10 is worth understanding now, because it's one of the few provisions in the Act that reaches directly into the security and data teams' territory, not just Legal's.
This piece explains what "data governance" actually means under Article 10, why the DSPM tools most security teams already own weren't built to satisfy it, and what continuous AI data readiness requires in practice.
What "Data Governance" Actually Means Under Article 10
Article 10 applies to providers of high-risk AI systems. That's the list of categories in Annex III of the Act, which includes credit scoring and creditworthiness assessment, employment and recruitment screening tools, biometric identification, and systems used in critical infrastructure, education, and law enforcement. If your company builds or deploys AI for any of those use cases, this article is written for you.
Most compliance teams hear "data governance" and picture a retention schedule and an ownership chart. Article 10 means something more specific and more testable. It requires that training, validation, and testing datasets be relevant, sufficiently representative, as free of errors as possible, complete for their intended purpose, and statistically appropriate for the population the system will affect.
To prove that, providers need documented practices covering eight areas. The design choices behind the system. Where the data came from and why it was originally collected. What was done to prepare it, including cleaning, labeling, enrichment, and aggregation. The assumptions baked into what the data is meant to represent. Whether enough of the right data actually exists. An honest examination for bias that could harm people or disadvantage groups unfairly. What is being done to catch and correct that bias. And what gaps or shortcomings remain.
Notice what's not on that list. A privacy policy, a DPA with your cloud vendor, or a checkbox confirming you "have a data governance framework." Article 10 wants evidence tied to the specific dataset behind the specific system, not an organizational commitment to governance in the abstract.
Did the Article 10 Deadline Move to 2027?
Yes, and this is worth getting right, because a lot of content on this topic is about to be stale. The high-risk AI obligations in Chapter III of the Act, including Article 10, were originally set to apply from August 2, 2026. On June 29, 2026, the Council of the EU gave final approval to the "Digital Omnibus on AI," which the European Parliament had already adopted on June 16. Once it's published in the Official Journal, expected before the original August deadline, standalone high-risk systems under Annex III get a 16-month reprieve. The new compliance date is December 2, 2027. AI embedded in regulated products under Annex I moves to August 2, 2028.
The part that matters for your planning is this: the Omnibus changes the timeline, not the substance. The eight data governance practices in Article 10 aren't watered down. Risk management, technical documentation, human oversight, and dataset traceability are all still required. The extension buys runway, not relief, and it's runway a lot of compliance teams will be tempted to spend on other fires. That would be a mistake. Building auditable data governance from scratch under deadline pressure in late 2027 is a worse position than building it now, while nobody's watching the clock.
(Separately, Article 50's transparency obligations, the AI disclosure and deepfake labeling rules, are not delayed and still take effect August 2, 2026. Different article, different clock. Worth knowing before someone on your team conflates the two in a board deck.)
Why Your DSPM Tool Stops Short of Article 10
Most data security posture management tools were built to answer a storage-layer question. Where does sensitive data live, who can access it, and is it exposed? That's genuinely useful work, and most of it was built for GDPR, CCPA, and similar frameworks that care about personal data at rest.
Article 10 asks a different question. It's not "Is there PII in this S3 bucket?" It's "can you produce documented evidence that the training dataset behind this specific high-risk model is representative, examined for bias, and free of the gaps that would make the model unreliable or discriminatory for the population it affects?" That requires connecting data classification to dataset lineage, to the specific model or pipeline it feeds, on an ongoing basis, not a quarterly scan that tells you where sensitive files sit.
Two structural gaps show up repeatedly:
Point-in-time versus continuous. A DSPM scan run last quarter can't tell you whether the dataset feeding a model retrained last week still meets the same quality bar. Article 10 is a lifecycle obligation, not a moment-in-time attestation, and agentic AI systems that continuously pull in new data make the gap worse, not better.
Sensitivity classification versus quality and lineage. Knowing a dataset contains PII doesn't tell you whether it's representative of the population the system serves, or whether known bias in it has been examined and mitigated. Those are different disciplines, and most DSPM products were never built for the second one.
None of this means DSPM is obsolete. Discovery and classification are still the foundation. It means discovery and classification alone were never designed to answer an AI-specific, evidence-generation question.
What Continuous AI Data Readiness Actually Requires
Meeting Article 10 in a way that survives an actual audit, not just a self-assessment, takes four things working together, continuously rather than periodically:
Continuous discovery and classification of the data feeding AI systems, not a periodic snapshot, so the governance record stays current as training and validation sets change.
Data hygiene before ingestion, identifying and removing redundant, obsolete, or unnecessarily sensitive data before it becomes part of a training or validation set, which directly supports the "gaps and shortcomings" and "suitability" requirements in Article 10.
Identity and access mapping that follows the data, so you can show not just who should have access to training data, but who and what (including AI agents and pipelines) actually does.
Audit-ready evidence generated automatically, tied to specific datasets, classification decisions, and access relationships, rather than assembled by hand every time a regulator or auditor asks.
That fourth point is the one compliance teams underestimate. Article 10 doesn't just want you to have good data governance. It wants you to be able to demonstrate it, on demand, for the dataset in question. If producing that evidence takes your team three weeks of spreadsheet archaeology, you don't have Article 10 compliance. You have a compliance-shaped fire drill waiting to happen.
How Sentra Supports Article 10 Data Governance by Design
Sentra is the AI Data Readiness Platform, built around a simple premise. You can't govern what AI can access if you don't continuously know what data exists, where it came from, and who or what can reach it. That maps directly onto what Article 10 asks for.
In practice, that means continuous discovery and classification across the environments where training and validation data actually lives, including cloud storage, data warehouses, and AI platforms like Databricks and Snowflake, rather than a scan you run before an audit and forget about afterward. It means identifying redundant and stale data before it enters a training pipeline, and mapping which identities and AI agents can reach sensitive datasets so access follows the data itself. And because all of this runs inside your own environment rather than a vendor-hosted copy, the evidence trail (classification decisions, access relationships, dataset lineage) is generated as a byproduct of normal operation, not manufactured under deadline pressure. That evidence is exactly what regulators expect a provider to produce for GDPR, HIPAA, and the EU AI Act alike.
Key Takeaways
- Article 10 requires dataset-specific, demonstrable data governance for high-risk AI systems, not a privacy policy or a general governance framework.
- The compliance deadline for standalone high-risk systems has moved to December 2, 2027 following the EU's June 2026 Digital Omnibus adoption, but the underlying requirements haven't changed.
- Most DSPM tools were built for point-in-time, storage-layer sensitivity classification. That's a different job from the continuous, dataset-lineage evidence Article 10 expects.
- Continuous AI data readiness means ongoing discovery, hygiene, identity-aware access mapping, and automatically generated audit evidence, not a scan report before the audit.
- The extended deadline is runway for building real infrastructure, not a reason to deprioritize the work.
The Bottom Line
Article 10 is a narrow provision with a wide blast radius for any security or compliance team whose company touches credit decisions, hiring, biometric identification, or a handful of other high-stakes categories. The deadline moved. The bar didn't. Teams that use the extra runway to build continuous, evidence-generating data governance will walk into December 2027 with a system that works, and one that happens to hold up for GDPR and HIPAA audits too. Teams that wait will be doing this exact scramble again, just with less daylight next time.
