Data quality management: what it is, how to measure it and why it matters to the AI Act

An AI model trained on incorrect data makes incorrect decisions. An executive report built on incomplete data generates wrong decisions. A scoring system that uses biased data discriminates without knowing it. In all these cases the problem is not the algorithm or the dashboard: it's the quality of the data that feeds them. Data quality management is the process that prevents these scenarios. And with the AI Act in force, it is no longer optional for high-risk systems.

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. AESIA and the AEPD may request evidence that training data meets these criteria. 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

Tool Approach Best for Cost
dbt tests Validation in transformation Teams with dbt as standard Free
Great Expectations Quality SLAs as code Python / Spark pipelines Open source / Paid cloud
Soda Quality SLAs as code Teams preferring YAML over Python Open source / Paid SaaS
Monte Carlo Data observability (anomalies) Detection without predefined rules Paid SaaS (medium-high)
Bigeye Data observability (anomalies) Teams with high table volume Paid SaaS (medium)
Collibra DQ Enterprise data quality Large corporations with Collibra High (enterprise license)

What's your Data Governance maturity?

Free assessment with your priority gaps, plus the self-assessment quiz and savings calculator on the Data Governance path.

Take the free assessment → See Data Governance templates → Calculate my savings →