What a Semantic Mapping of the EU AI Act and ISO/IEC 5259 Reveals
Disclaimer: This article is provided for general informational purposes and does not constitute legal or regulatory advice. Organizations should seek appropriate professional guidance when assessing their obligations under the EU AI Act or other applicable regulations.
Executive Summary
The EU AI Act imposes binding data governance obligations on certain high-risk AI systems through Article 10. ISO/IEC 5259, a five-part international standard from ISO/IEC JTC 1/SC 42, offers a structured, technical approach to managing data quality across the analytics and machine learning lifecycle. Because both address overlapping territory — data quality, documentation, bias, lifecycle management — organizations understandably want to know whether adopting one effectively satisfies the other.
Research from Trinity College Dublin and the ADAPT Centre — specifically the paper Mapping Data Governance Requirements Between the European Union's AI Act and ISO/IEC 5259: A Semantic Analysis by Kuruvilla George Aiyankovil, Julio Hernandez, and Dave Lewis — took a rigorous, requirement-by-requirement approach to this question, using semantic web techniques rather than a high-level comparison. Their conclusion is nuanced: there is real, demonstrable overlap between the two frameworks, but also partial alignments, differences in normative strength ("shall" versus "should"), and definitional gaps that mean adherence to ISO/IEC 5259 cannot be treated as a substitute for a full Article 10 compliance assessment. This article walks through what the research found, what it means in practice, and how data governance teams can use it without overreaching.
---
1. Why AI Data Governance Is Becoming a Regulatory Issue
AI systems are only as trustworthy as the data that shapes them. A credit-scoring model trained on unrepresentative historical data, or a hiring tool built on incomplete records, does not fail because the algorithm is flawed — it fails because the data pipeline behind it was never properly governed. That is not a new insight for data professionals, but it has recently become a legal one.
The EU AI Act, formally Regulation (EU) 2024/1689, is the first comprehensive legislative attempt to regulate AI systems across sectors within the European Union. Among its many provisions, it singles out data and data governance as a specific compliance obligation — Article 10 — for high-risk AI systems that are developed using techniques involving the training of models with data. In parallel, international standards bodies have been developing technical guidance for exactly this problem space. The ISO/IEC 5259 series, published progressively from 2024, addresses data quality specifically for analytics and machine learning.
It's tempting to assume these two efforts simply describe the same thing from different angles — one as law, one as practice — and that following the standard means you've met the law. That assumption is exactly what recent academic research set out to test empirically, rather than take on faith. The central question worth asking is:
> Where do regulatory data governance requirements and international data quality standards actually align — and where do they not?
That is the question this article works through.
---
2. Understanding the EU AI Act's Data Governance Requirements
Article 10 of the EU AI Act sets out data governance obligations that apply to high-risk AI systems that make use of techniques involving the training of models with data. Where a high-risk system does not involve model training (for example, certain rule-based systems), the applicable requirements narrow to testing datasets only. This scoping matters — Article 10 is not a blanket data-quality mandate for every AI system a company builds; its force is tied to the AI Act's risk classification framework and to whether training is involved at all.
For systems within its scope, Article 10 requires that training, validation, and testing datasets be subject to data governance and management practices appropriate to the intended purpose of the system. The article specifies that these practices should address matters including:
- Data collection processes and the origin of data, including, where personal data is involved, the original purpose of collection
- Relevant data preparation processing operations, such as annotation, labelling, cleaning, updating, enrichment, and aggregation
- The formulation of assumptions related to what the data is intended to measure or represent
- An assessment of the availability, quantity, and suitability of the datasets needed
- Examination of possible biases likely to affect health, safety, or fundamental rights, or lead to discrimination, along with appropriate mitigation measures
- Identification of relevant data gaps or shortcomings and how they are addressed
The datasets themselves must be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete in view of the intended purpose, while also taking into account the specific geographical, contextual, behavioural, or functional setting in which the system will be used.
It's worth being precise here: Article 10 does not apply uniformly to every AI system, and it does not operate in isolation. It sits alongside — and is cross-referenced by — other Articles and Annexes, including the technical documentation requirements of Article 11 and Annex IV, and it intersects with existing data protection law, particularly the GDPR, especially where bias mitigation may require processing special categories of personal data. Determining exactly how Article 10 applies to a specific AI system, and what evidence is sufficient, is a legal and organizational judgment — not something this article, or any standard, can resolve in the abstract.
---
3. What Is ISO/IEC 5259?
ISO/IEC 5259 is a multi-part international standard series, developed by ISO/IEC JTC 1/SC 42, titled *Artificial intelligence — Data quality for analytics and machine learning (ML)*. It was published progressively from 2024, and its parts serve different functions:
- Part 1 — Overview, terminology, and examples, which establishes shared vocabulary and explains how the rest of the series fits together.
- Part 2 — Data quality measures, which defines a data quality model and measurable characteristics for assessing and reporting on data quality.
- Part 3 — Data quality management requirements and guidelines, the only part of the series that contains formal "requirements" in the ISO sense — specifying what an organization's data quality management system (DQMS) needs to include.
- Part 4 — Data quality process framework, which offers process-level guidance across different types of machine learning (supervised, unsupervised, semi-supervised, reinforcement) with attention to labelling, evaluation, and lifecycle management.
- Part 5 — Data quality governance framework, addressing the governance layer that sits above day-to-day data quality processes.
The series builds on existing ISO/IEC data quality work, such as ISO/IEC 25012 and ISO 8000, adapting it for the specific demands of AI and machine learning pipelines, including unstructured data types like text, images, and audio.
What matters for this discussion is what ISO/IEC 5259 is *not*: it is a technical management standard, not a law. A technical or management standard and a legal regulation serve different purposes. A standard describes a repeatable, auditable way of managing a problem area; a regulation establishes binding legal obligations, with enforcement mechanisms and penalties attached. Conformance to a standard can, in some circumstances, become legally significant — but only where that standard has been formally recognized for that purpose, which brings us to the concept of harmonized standards, discussed in Section 6.
---
4. The Research: A Semantic Approach to Comparing Requirements
Reading the EU AI Act's Article 10 next to ISO/IEC 5259's five parts, side by side, can create an impression of overlap without actually testing it. That is the gap the referenced research set out to close.
This analysis builds on and discusses research by Kuruvilla George Aiyankovil, Julio Hernandez, and Dave Lewis, who examined semantic relationships between the EU AI Act's data governance requirements and ISO/IEC 5259, published at the 1st NeXt-generation Data Governance Workshop (NXDG 2024), co-located with SEMANTiCS 2024. Rather than comparing the two documents at the level of chapters or themes, the researchers broke Article 10 down into individual, discrete requirement statements — treating each obligation within the article as its own object of analysis, complete with a source citation, a "normative level" classification (requirement, recommendation, permission, or possibility, following ISO drafting conventions), and the concepts it referenced. They did the same for the relevant provisions of ISO/IEC 5259.
They then built what they call the AI Data Governance Ontology (AIDGO), using the W3C's Simple Knowledge Organization System (SKOS) — a standard vocabulary for representing and linking concepts — to formally connect requirements across the two documents. Each connection was tagged with a mapping type, such as "completely satisfies" or "partially satisfies," along with metadata capturing differences in normative language, definitional scope, and the relative effort ("cost") of meeting the ISO/IEC 5259 provision compared with the AI Act obligation.
Why go to this trouble instead of a simpler side-by-side reading? Because two requirements can look similar on the surface while differing in scope, definitions, strength of obligation, or expected outcomes. A semantic, requirement-level mapping approach can surface those differences precisely — identifying direct alignment, partial alignment, conceptual mismatches, terminology gaps, and differences in how strongly each framework compels action — in a way that a general thematic comparison tends to smooth over.
---
5. Where the EU AI Act and ISO/IEC 5259 Appear to Align
The research identifies areas of meaningful conceptual overlap between the two frameworks. Both address, in some form, data quality characteristics and measures, documentation of data preparation processes, monitoring and improvement of data quality over time, procedures for data validation and verification, and mechanisms intended to support transparency and accountability in how data is handled.
At a broader conceptual level, the researchers found what they term "broad matches" and "narrow matches" between concepts — for instance, the AI Act's notion of "data governance practices" maps broadly onto ISO/IEC 5259's general concept of data governance, and "data management practices" in the Act corresponds broadly to the standard's treatment of data management. Similarly, "quality management system" obligations under the Act relate broadly to quality management concepts within the standard.
Several concepts appear to have meaningful overlap in intent: both frameworks care about whether data is fit for purpose, whether it has been prepared and documented in a traceable way, and whether an organization has an ongoing process — not a one-off check — for assessing and improving data quality. ISO/IEC 5259 can provide a structured framework that may support aspects of the data governance expectations set out in Article 10, particularly around building repeatable internal processes for data specification, quality measurement, and lifecycle management.
Alignment does not necessarily mean equivalence, though — and the researchers' own results illustrate why, which brings us to the more consequential part of their findings.
---
6. Where the Gaps and Differences Matter
This is arguably the most important part of the research, and the part most likely to be glossed over in a casual reading of either document.
Normative language. The researchers found that even where a concept is shared, the *strength* of the obligation frequently differs. In one of their illustrative mappings, an AI Act requirement expressed with "should" corresponds to an ISO/IEC 5259 provision expressed with "shall" — and in another, the pattern reverses, with the AI Act using "shall" against a "should" in the standard. This distinction matters practically: a "shall" is a mandatory requirement, while a "should" is a recommendation that leaves room for justified deviation. When a legal "shall" is mapped only to a standard's "should," conformance with the standard alone does not automatically demonstrate that the binding legal obligation has been met.
Definitional gaps. Terms that look identical on paper can carry different meanings depending on context. The research flagged, for example, that "transparency" as used in the AI Act and as referenced in ISO/IEC 5259's data specification provisions is not defined identically — nor is "human oversight," where the researchers identified differences in scope and implementation between the regulatory concept and the corresponding standard's quality-reporting requirements.
Partial rather than complete satisfaction. Across the specific concept pairs the researchers examined in detail — including AI system transparency, human oversight, data minimization, algorithmic bias mitigation, and explainability, each mapped against a corresponding ISO/IEC 5259 provision — the dominant finding was "partially satisfies," not "completely satisfies." That is a meaningful result: it suggests that in the specific mappings tested, conformance to the relevant ISO/IEC 5259 provision addressed part of what the AI Act requires, but not the whole of it, and that additional organizational measures were likely needed to close the remaining gap.
Scope and emphasis differences. The researchers also noted that the two frameworks differ in what they emphasize. The AI Act tends to place more weight on human oversight and transparency obligations specific to high-risk systems and their societal impact, while ISO/IEC 5259 tends to focus more heavily on technical measurement methodologies and process management for data quality itself.
Fundamental rights and broader societal concerns. A data quality framework can be an important component of responsible AI governance without necessarily covering every legal, ethical, or societal dimension addressed by regulation. Bias mitigation tied to the protection of health, safety, and fundamental rights is a legal and ethical determination as much as a technical one — and a technical data quality standard, however well constructed, is not designed to resolve that determination on its own.
---
7. Alignment Is Not the Same as Compliance
This distinction deserves its own section because it's the one most likely to be flattened in a marketing pitch or a rushed internal memo.
An organization may follow ISO/IEC 5259 closely, build a robust data quality management system aligned with Part 3, document its processes according to Part 4, and still need to independently demonstrate that it meets its specific legal obligations under Article 10. Following a standard and satisfying a law are related but distinct exercises.
| Concept | Meaning |
|---|---|
| Alignment | Two frameworks address similar concepts or requirements |
| Partial alignment | Some elements correspond, while others differ or remain uncovered |
| Conformance to a standard | Meeting the requirements of a particular standard (e.g., ISO/IEC 5259-3's DQMS requirements) |
| Regulatory compliance | Meeting applicable legal obligations under the EU AI Act |
| Harmonized standard | A standard formally adopted under EU law that, once cited in the Official Journal, gives a presumption of conformity with the corresponding legal requirement |
| Presumption of conformity | A legal effect under Article 40 of the AI Act, available only where a system conforms to a harmonized standard covering the relevant requirement |
| Evidence | Documentation or controls that may help demonstrate how a requirement is addressed, whether or not full compliance has been formally established |
It's worth being precise about harmonized standards specifically, since the term gets used loosely. Under the AI Act, high-risk AI systems that conform to harmonized standards covering the relevant requirements benefit from a presumption of conformity with those requirements. The European Commission has issued a standardisation request that includes a call for a European standard addressing data governance and quality for datasets used to build AI systems, and the underlying research paper itself identifies ISO/IEC 5259 as a candidate that European standards bodies could draw on. But being a *candidate* input into a future harmonized standard is different from *being* a harmonized standard today. As of this writing, organizations should not assume that conformance to ISO/IEC 5259 alone triggers a legal presumption of Article 10 compliance — that status depends on formal EU standardization and citation processes that are separate from, and slower than, the publication of the underlying ISO/IEC standard. Readers should verify the current status of any relevant harmonized standards directly through the European Commission and the Official Journal of the European Union before relying on this distinction operationally.
A related paper by two of the same researchers, Harmonizing AI Data Governance: Profiling ISO/IEC 5259 to Meet the Requirements of the EU AI Act, pushes this idea further by proposing a concept the authors call "qualified compliance," built on the W3C's PROV-O provenance model. The idea is to formally link specific compliance *activities* — the actual work an organization does — back to the specific legal obligations they're meant to satisfy, making the connection traceable rather than asserted. That is a useful way to think about the problem: not "did we follow the standard," but "can we show, obligation by obligation, what evidence connects our controls to what the law actually requires."
---
8. What This Means for Data Governance Teams
For Chief Data Officers, AI governance leads, and compliance functions, the practical implication is not "pick a framework and standardize on it," but rather to build a traceable chain from regulation to evidence. A reasonable, illustrative approach — not an official compliance methodology — looks like this:
Step 1: Identify applicable AI Act obligations. Determine which of the organization's AI systems fall within scope, whether they involve model training (which triggers the full Article 10 requirements) or not (which narrows the requirements to testing data), and what other Articles and Annexes interact with the data governance obligations.
Step 2: Map existing data governance controls. Inventory what already exists — data lineage, metadata management, data ownership, validation and verification procedures, bias monitoring, lifecycle documentation — regardless of what standard, if any, it was built against. This connects to Trustnoww's data governance research.
Step 3: Use standards as implementation frameworks, not compliance shortcuts. Evaluate how ISO/IEC 5259 and related standards (such as ISO/IEC 42001 for AI management systems, which several of the sources reviewed here reference in a similar context) can operationalize parts of the governance program, while treating them as tools rather than legal substitutes.
Step 4: Perform a requirement-by-requirement gap analysis. Rather than asking whether the organization "does data governance," ask which specific Article 10 obligations are addressed, partially addressed, or unaddressed by current controls — mirroring the granular approach the underlying research took.
Step 5: Maintain traceable evidence. Build and preserve the chain: regulatory requirement → governance control → operational process → evidence. This is the same connective structure the "qualified compliance" concept aims to formalize.
Step 6: Review continuously. Both the AI Act's implementing guidance and the ISO/IEC 5259 series will continue to evolve; a gap analysis performed once is a snapshot, not a permanent state.
---
9. The Bigger Opportunity: Machine-Readable AI Governance
One of the more interesting implications of this stream of research extends beyond any single mapping exercise. If regulatory requirements and technical standards can both be represented as structured, machine-readable concepts — using ontologies, SKOS, or knowledge graphs — then the relationships between them become something software can help track, rather than something a compliance team has to re-derive by hand every time a regulation or standard is updated.
Related work in this space, including knowledge-graph-based approaches to mapping EU AI Act concepts against international standards and broader research on semantic frameworks for AI Act implementation, points toward a future where regulatory requirements, technical documentation, and organizational controls are linked through reusable, queryable vocabularies rather than static spreadsheets and PDFs. This complements Trustnoww's analysis of how LLMs evaluate source authority, because machine-readable provenance and clear source relationships make governance claims easier for both people and retrieval systems to inspect.
The potential benefits are real: better traceability between legal text and internal controls, reduced manual comparison work, more consistency across teams and business units, and governance knowledge that can be reused and updated incrementally rather than rebuilt from scratch.
The limitations are equally real, and the research reviewed here is candid about them. Legal interpretation remains context-dependent and ultimately a matter of professional judgment, not automated inference. Standards and regulations both continue to evolve, sometimes independently of one another. Semantic mappings encode the assumptions of the people who built them, and those assumptions need to be revisited as frameworks change. None of this removes the need for organizational accountability — a well-built ontology can make gaps visible, but it cannot close them on its own.
---
10. Key Takeaways
1. Data governance is becoming a core component of AI governance, not a separate technical concern — Article 10 makes this explicit for high-risk AI systems within its scope. 2. ISO/IEC 5259 and the EU AI Act address overlapping but distinct objectives — one is a technical/management standard, the other a binding legal instrument. 3. Semantic, requirement-level analysis reveals both alignment and important gaps that a high-level document comparison would likely miss, particularly around normative strength and definitional scope. 4. Standards can support implementation but should not automatically be treated as proof of legal compliance — the underlying research found predominantly "partial" rather than "complete" satisfaction across the specific mappings it tested. 5. Requirement-level mapping is more rigorous than framework-level comparison, and organizations attempting their own gap analysis should work at a similarly granular level. 6. Organizations need traceability between regulations, controls, processes, and evidence — a chain that concepts like "qualified compliance" attempt to formalize. 7. Machine-readable governance frameworks may become increasingly important as both AI regulation and the underlying standards landscape continue to expand and evolve.
---
FAQ
Does ISO/IEC 5259 make an organization compliant with the EU AI Act? No. Conformance to ISO/IEC 5259 can support parts of an Article 10 compliance program, particularly around data quality measurement and management processes, but the underlying research found predominantly partial rather than complete alignment between specific provisions. A legal compliance determination requires its own assessment.
What is the role of Article 10 in AI data governance? Article 10 sets binding data governance and data quality obligations for high-risk AI systems within its scope, covering training, validation, and testing datasets, data preparation practices, bias examination and mitigation, and related documentation. Its exact application depends on the system's classification and whether model training is involved.
Why are semantic mappings useful for AI governance? Because two requirements that look similar in plain-language summaries can differ meaningfully in obligation strength, definitions, and scope. A semantic, requirement-by-requirement mapping — as opposed to a general side-by-side reading — can surface these differences precisely and keep the analysis updatable as either framework changes.
Can standards help organizations prepare for AI regulation? Yes, as implementation tools. Standards like ISO/IEC 5259 can give organizations a structured, auditable way to build data quality processes that support regulatory obligations. They are not, however, a substitute for legal analysis of what a specific regulation requires, and this article does not constitute legal advice.
---
About This Analysis
Trustnoww is an independent technology publication focused on AI trust, data governance, and authority evaluation. This article synthesizes the cited academic research and primary regulatory sources; it is an editorial analysis, not a legal opinion. See the Trustnoww editorial policy for our publishing and source-review approach.
References
Aiyankovil, Kuruvilla George; Hernandez, Julio; and Lewis, Dave. "Mapping Data Governance Requirements Between the European Union's AI Act and ISO/IEC 5259: A Semantic Analysis." Proceedings of the 1st NeXt-generation Data Governance Workshop (NXDG 2024), CEUR Workshop Proceedings.
Aiyankovil, Kuruvilla George; and Lewis, Dave. "Harmonizing AI Data Governance: Profiling ISO/IEC 5259 to Meet the Requirements of the EU AI Act." Legal Knowledge and Information Systems, IOS Press, 2024.
Holtz, Hajo Michael; and Ledendal, Jonas. "AI Data Governance – Overlaps Between the AI Act and the GDPR." Law, Innovation and Technology, 2026.
Hernandez, Julio; Golpayegani, Delaram; and Lewis, Dave. "An Open Knowledge Graph-Based Approach for Mapping Concepts and Requirements Between the EU AI Act and International Standards." AI and Ethics, 2025.
"Semantic Frameworks to Support Implementation of the EU AI Act." Computer Law & Security Review, 2026.
OECD. "A Mapping Tool for Digital Regulatory Frameworks: Including a Pilot on Efforts to Regulate AI." OECD, 2025.
European Union. "Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 10 — Data and Data Governance." Official Journal of the European Union.
International Organization for Standardization / International Electrotechnical Commission. "ISO/IEC 5259 series, Parts 1–5, *Artificial intelligence — Data quality for analytics and machine learning (ML)*." ISO/IEC JTC 1/SC 42.