AI Act Article 10: what it actually requires from your training data

What Article 10 actually says

Article 10(3) requires that training, validation and testing datasets for high-risk AI systems be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete in view of the system's intended purpose. Article 10(2) goes further: it requires data governance and management practices covering design choices, data collection and origin, data preparation, relevant assumptions, and — critically — examination for possible biases likely to affect health, safety or fundamental rights.

None of that is prescriptive about tooling. The regulation doesn't tell you which statistical test to run. What it does require is that you can show your work: which rules you applied, what threshold you accepted, and who signed off on it. That's precisely what data quality management — the operational discipline, not the buzzword — is for.

What is data quality management

Data quality management is the set of processes, policies, roles and tools that ensure an organisation's data is accurate, complete, consistent, timely and fit for its intended use. It is not a one-off validation at the point of ingestion. It is not a quality report that someone generates once a quarter. It is a continuous process with defined metrics, thresholds agreed with the business, automatic alerts when they are breached and remediation owners with a real mandate to act.

The six dimensions of data quality

The industry reference standard, DAMA-DMBOK, defines six main dimensions for measuring data quality. Each dimension requires specific metrics and rules, and their relative importance varies by domain and use case.

1. Completeness

Measures whether all required values are present. A mandatory null field is a completeness problem. Expressed as a percentage: what proportion of records have the field filled. The acceptance threshold is defined by the business: in some fields 95% is acceptable; in training data for high-risk AI, 100% may be required.

2. Uniqueness

Measures whether there are duplicates where there shouldn't be. A customer registered twice with the same identifier, a transaction processed twice, a product with two active records. Undetected duplicates generate bias in AI models and errors in financial reports.

3. Validity

Measures whether values comply with defined format, range and domain rules. A postcode with six digits where there should be five, a future date of birth, a negative amount where only positive amounts are allowed. Validity rules are the easiest to automate and the first to implement in any data pipeline.

4. Consistency

Measures whether the same data has the same value across different systems or at different points in the pipeline. The customer who has one name in the CRM and another in the billing system. The metric that in the sales report is worth X and in the financial report is worth Y with the same definition. Consistency is the hardest dimension to measure because it requires cross-referencing sources.

5. Timeliness

Measures whether the data is available when needed. Correct data that arrives late is useless data for the decision that depended on it. Measured as delay relative to the agreed SLA: if the pipeline should complete at 8:00 and completes at 10:00, there is a timeliness problem regardless of whether the data is correct.

6. Accuracy

Measures whether the value reflects the reality it purports to represent. It is the hardest dimension to measure automatically because it requires contrasting the data with an external source of truth. A weight recorded as 75 kg when the actual weight is 82 kg is an accuracy problem that no validation rule will detect if 75 is within the acceptable range. In training data for AI, poor accuracy is the most frequent source of undetected bias.

Why the AI Act requires data quality management

Article 10 of the AI Act is explicit: training, validation and testing data for high-risk AI systems must meet quality criteria appropriate to the purpose of the system. Specifically, the Regulation requires that data be:

• Relevant, representative, free from errors and complete as far as possible.
• With appropriate statistical characteristics, including representation of the persons or groups on whom the system will operate.
• Subject to appropriate data management practices, including analysis of possible biases.

This is not a statement of principles: it is an auditable obligation. Your national market surveillance authority — in the EU, this is a designated body in each member state — may request evidence that training data meets these criteria at any point after deployment, not just at launch. Without a documented and continuous data quality management process — with metrics, thresholds, alerts and remediation records — that evidence does not exist.

How to implement data quality management step by step

Step 1: define quality rules with the business, not just the technical team

Data quality rules cannot be defined by the engineering team alone. They need business input: what values are acceptable for this field, what percentage of nulls this process tolerates, what range of values makes sense for this metric. The technical team translates those rules into code; the Data Owner validates that the rules reflect business reality; the Data Steward keeps them updated when the business changes.

Step 2: implement rules as code in the pipeline

Quality rules must live in the pipeline code, not in an external document. Tools like dbt tests, Great Expectations or Soda allow defining these rules as versioned code, integrating them into the CI/CD process and executing them automatically on each pipeline run. If a rule fails, the pipeline can stop, emit an alert or log the anomaly depending on the defined criticality.

Step 3: define acceptance thresholds and criticality levels

Not all quality rules have the same weight. A free-text comment field with 10% nulls is tolerable; a customer identifier with 1% nulls is critical. Define for each rule: the acceptance threshold (percentage of records that must comply), the criticality level (blocks the pipeline, generates an alert or only logs) and the remediation SLA (how long it should take to resolve if it fails).

Step 4: publish quality dashboards visible to Data Owners

Data quality cannot be information that only the technical team sees. Data Owners need visibility into the quality status of their domain: which rules are failing, how often, what trend they have and what impact it has on downstream systems. A quality dashboard in Power BI or in the data quality tool itself turns that information into something actionable for those with responsibility and authority to decide on the data.

Step 5: establish remediation processes with clear owners

A quality alert without a remediation process is noise. Define for each type of incident: who receives the alert, what they should do, within what timeframe and how the resolution is documented. Remediation can be automatic — correction in the pipeline — or manual — intervention by the Data Steward or the source system — but it must always have an owner and a record. That record is part of the data quality management evidence that the AI Act may require.

Data quality management tools in 2026

Data quality management in complex, multi-entity environments

Two-tier quality rules across business units or subsidiaries

In environments where several business units or subsidiaries share a single data platform, quality rules need to operate on two layers. Global rules cover the shared master domains — customer identifiers, product codes, transaction dates. These rules are identical across every entity and get applied at the integration layer. Local rules cover the specifics of each market or business unit: acceptable price ranges by region, documentation formats by country, capacity thresholds by product line. Without this distinction, global rules generate false positives on data that's locally correct, and local rules never scale to the wider group.

Wiring dbt tests into the deployment pipeline

In commercial BI projects, integrating dbt tests into the CI/CD process changes how the team treats data quality at a fundamental level. When a failing quality test blocks a model's deployment, quality stops being something reviewed after the fact and becomes a delivery requirement instead. Analysts learn to anticipate quality issues before they reach the dashboard, rather than after Data Owners report them in a meeting.

Quality dashboards as a management tool for Data Owners

In environments with critical operational data, publishing data quality status on a dashboard accessible to Data Owners changes the conversation about quality entirely. The Data Owner stops receiving reactive incident reports and gains proactive visibility instead: which fields are trending toward degradation, which rules are approaching their failure threshold, which domain has the worst completeness rate this week. That visibility creates real accountability — a Data Owner who sees their domain sitting at 88% completeness on a critical field has a clear incentive to act before it becomes a business problem.

Article 10 vs. NIST AI RMF: do you need both?

If you operate outside the EU, or alongside it, you'll run into the NIST AI Risk Management Framework — the closest US equivalent, though voluntary rather than mandatory. NIST AI RMF doesn't name "data quality" as its own category the way Article 10 does; it folds data-related risk into its four functions (Govern, Map, Measure, Manage), leaving the specific quality criteria largely up to the organization.

In practice, this means Article 10 is the more prescriptive of the two: it names the exact properties your data must have (relevant, representative, free of errors, complete) and requires bias examination as a distinct step. An organization that documents its data quality management against Article 10's criteria will, in most cases, already satisfy the data-related expectations of NIST's Measure function — the reverse isn't automatically true, since NIST leaves more room for internal judgment calls that an EU auditor won't accept without a specific reference to Article 10(2)-(5).

If you sell into both markets, build the Article 10 documentation first and map it to NIST's functions afterward, not the other way around.

Common mistakes in data quality management

• Treating data quality as a project with an end date. Data quality is perishable: a pipeline that produces correct data today can produce incorrect data tomorrow if the source system changes, the schema changes, or the business changes. Without continuous monitoring, quality degrades silently until someone catches an error in production.
• Defining quality rules without business input. Rules defined by the technical team alone tend to be incomplete or wrong for the real use case. The technical team knows which values are technically possible; the business knows which ones are operationally acceptable. Both perspectives are needed.
• Measuring quality only at ingestion, not across the whole chain. Data can enter the data lake correctly and leave the semantic model incorrect if an intermediate transformation introduces errors. Quality needs to be measured at every relevant layer of the pipeline, not just at the entry point.
• Alerts with no remediation process. An alert with no clear owner, defined process, and resolution SLA is an alert that gets ignored. 80% of the value of data quality management sits in remediation, not detection.
• Ignoring representativeness for AI training data. For AI training datasets, completeness and validity are necessary but not sufficient. Representativeness — whether the dataset adequately reflects the distribution of the population the model will operate on — is the dimension most critical to Article 10 of the AI Act, and the one most often skipped in quality processes.
• Not documenting quality results as evidence. For the AI Act, having quality rules isn't enough — you need to be able to show they run, that results are monitored, and that issues get remediated. Without historical records of quality runs, that evidence doesn't exist.

Conclusion: data quality isn't a technical KPI, it's a business SLA

Effective data quality management isn't measured by the number of rules defined or the tool chosen. It's measured by whether the data feeding business decisions — and the AI models that support those decisions — is accurate, complete, and representative enough for how it's actually used.

With the AI Act now in force, that question carries a direct regulatory dimension — and not only for organizations headquartered in the EU. The AI Act applies to any provider or deployer placing an AI system on the EU market or whose system's output is used in the EU, regardless of where the company itself is based. Organizations that already run a documented, continuous data quality management process — with metrics, alerts, remediation, and audit trails — have a real head start: Article 10 compliance becomes a natural extension of what they already do. Organizations without one should start with their most critical domains, the highest-priority rules, and the simplest tools that fit their current stack.

Checklist: operational data quality management

• Critical domains and datasets identified and prioritized for initial implementation.
• Quality rules defined per domain with input from the Data Owner and Data Steward.
• All six dimensions assessed per domain: completeness, uniqueness, validity, consistency, timeliness, and accuracy.
• Rules implemented as code in the pipeline (dbt tests, Great Expectations, or Soda).
• Acceptance thresholds defined per rule, agreed with the business, and documented.
• Criticality levels assigned: blocking, alerting, or logging, based on impact.
• Automated alerts configured with a clear owner and a defined response SLA.
• Remediation process documented with owners assigned by incident type.
• Quality dashboard published and accessible to Data Owners and the compliance team.
• Historical records of quality runs retained as auditable evidence.
• Representativeness and bias analysis documented for AI training datasets (AI Act Art. 10).
• Periodic rule-review process in place for when the business or source system changes.

Frequently asked questions about data quality management

What is data quality management?

Data quality management is the discipline of ensuring data is accurate, complete, consistent, and fit for its intended purpose, through defined roles, measurable dimensions, and ongoing monitoring — rather than a one-off cleanup project.

What are the six dimensions of data quality?

The most widely used framework defines six dimensions: accuracy, completeness, consistency, timeliness, validity, and uniqueness. Each dimension needs its own measurable threshold, since a dataset can score well on one dimension and poorly on another.

How do you measure data quality in practice?

You measure data quality by defining a specific, numeric threshold for each relevant dimension per dataset (for example, 98% completeness, zero duplicate records), then tracking the actual measured value against that threshold on a regular cadence, not just once.

Why does the AI Act require data quality management?

Article 10 of the AI Act requires that training, validation, and testing datasets for high-risk AI systems be relevant, representative, free of errors, and complete. That requirement can only be met consistently if a real data quality management practice is already in place, not assessed only when a model is built.

Does the AI Act's data quality requirement apply outside the EU?

Yes. The AI Act has extraterritorial scope: it applies to providers and deployers placing an AI system on the EU market or whose system's output is used within the EU, regardless of where the organization is headquartered — the same way GDPR applies to non-EU companies handling EU residents' data.

Do I need to comply with both Article 10 and NIST AI RMF?

If you only sell into the EU, Article 10 is the binding requirement and NIST AI RMF is optional. If you also operate in the US, documenting against Article 10's specific criteria first will typically satisfy most of NIST's data-related expectations under its Measure function, since Article 10 is more prescriptive about what counts as acceptable data quality.

What tools are used for data quality management in 2026?

Common approaches range from spreadsheet-based rule templates for smaller teams to dedicated data quality and observability platforms for larger data estates, but the tool matters less than having clear ownership, documented rules, and a repeatable measurement cycle.