XenonStack BlogData Quality Issues: Common Problems and How to Fix Them

The most common data quality issues are incomplete, inaccurate, inconsistent, stale, duplicated and invalid data. They usually start upstream, in source systems, integrations and undocumented schema changes, and they surface downstream as wrong dashboards, failed pipelines and AI systems that answer confidently from bad inputs. Gartner puts the average annual cost of poor data quality to organisations at $12.9 million.

The fix in 2026 is not a one-off cleansing project. It is an operating model: agree data contracts with producers, run automated data quality checks in every pipeline, add observability for the problems nobody predicted, and give each critical dataset a named owner. This guide maps each issue to its causes and fixes, compares the tooling, and sets out an adoption path for AI, LLM and RAG workloads.

What are the most common data quality issues?

Most data quality problems fall under six dimensions. The ISO/IEC 25012 data quality model uses a wider set of 15 characteristics, including accuracy, completeness, consistency and currentness, but the six below cover the issues enterprise teams hit most often. The table pairs each with its typical causes, the fix and an example check you can automate.

Two further problems sit across these dimensions. Orphaned data, such as orders pointing to deleted customers, is a validity and consistency failure. Dark data, collected but never catalogued or used, is a governance gap rather than a quality defect, but it often hides the issues above until someone tries to use it for analytics or AI.

What has changed in how enterprises fix data quality issues?

Earlier guidance focused on periodic audits and cleansing tools. Three shifts have changed the picture for 2026 enterprise readers:

• Prevention moved upstream. Data contracts make producers responsible for schema, semantics and service levels, so fewer issues reach consumers in the first place.
• Checks became code. Tests now live in version control next to transformations and run in CI/CD and orchestration, rather than in a separate quality tool run once a quarter.
• AI raised the stakes. Data now feeds models, retrieval pipelines and agents that act on it. Regulation such as the EU AI Act sets explicit data governance requirements for high-risk systems, and vendors such as Monte Carlo now position their products as data and AI observability.

Product names have also changed. Talend's data quality capabilities are now offered as part of Qlik Talend Cloud, and dbt renamed its tests: configuration key to data_tests: when it introduced unit tests, according to the dbt documentation.

How do data contracts prevent data quality problems?

A data contract is an agreement between the team that produces a dataset and the teams that consume it. It states the schema, the meaning of each field, the quality rules, the freshness and availability service levels, and who to contact when something breaks. When a producer wants to change any of these, the change is proposed, reviewed and versioned rather than shipped silently.

The Open Data Contract Standard (ODCS), maintained under the Bitol project, defines a YAML format with sections for schema, data quality, service-level agreement and roles, among others. Tools can then enforce the same contract: Soda Core describes itself as "a data quality and data contract verification engine" that reads contracts written in YAML.

Where should contracts start?

Start with the interfaces that break most often and cost most when they do: event streams from product teams, extracts from ERP and CRM systems, and any dataset that feeds finance reporting, regulatory submissions or a production AI system. Contracts on every internal table add overhead without much benefit.

Which data quality checks should you automate?

Automated data quality checks are assertions that run each time data moves. They should fail the pipeline, quarantine records or alert the owner depending on severity. A practical baseline for each critical dataset is: not-null and uniqueness on keys, accepted values on status and category fields, referential integrity between related tables, row-count and volume ranges, freshness against the service level, and reconciliation totals against the source.

Pick one testing framework that matches where transformations already run, rather than layering several. Most teams combine it with one observability product, not more.

How does data observability catch the issues tests miss?

Tests only catch failures someone anticipated. Observability watches freshness, volume, schema, distribution and lineage across many tables and flags anomalies against learned baselines, which is how teams find the silent upstream change or the half-empty partition nobody wrote a rule for. Our guide to the pillars of data observability explains each signal in more detail.

Lineage is what turns an alert into a fix. When a check fails, lineage shows which upstream source changed and which dashboards, models and retrieval indexes are affected, so the owner can decide whether to block, backfill or notify.

Who should own data quality and governance?

Data quality fails when everyone assumes someone else owns it. A workable model has three roles:

• Data producers own the contract and fix issues at the source.
• Dataset or data product owners, usually in the business domain, set the thresholds that matter and accept or reject exceptions.
• A platform team provides the shared testing, observability and catalogue tooling so domains do not each build their own.

Governance supplies the definitions, classification and policies those roles work within. See our overview of data governance benefits and best practices and our guide to data quality management for the wider operating model. Severity levels should be agreed in advance: a broken key in a finance table should stop the pipeline, while a small rise in nulls in a marketing attribute may only need a ticket.

Why do data quality issues matter more for AI, LLM and RAG workloads?

In analytics, a bad number is usually spotted by a person reading a report. In AI systems, bad data flows into training sets, retrieval indexes and agent actions with fewer human checkpoints. A retrieval-augmented generation (RAG) assistant that indexes an outdated policy, a duplicated contract or a document with broken access labels will return that content fluently.

For RAG and LLM workloads, extend the six dimensions to unstructured content:

• Timeliness: re-index when source documents change and retire superseded versions so the retriever cannot find them.
• Uniqueness: remove near-duplicate documents and chunks, which crowd out other relevant results.
• Validity: check that extraction and chunking produced readable text, not empty pages or table fragments.
• Accuracy and provenance: keep source, owner and version metadata on every chunk so answers can be traced.
• Access: carry permissions into the index so the assistant cannot surface content the user is not entitled to see.

Regulators now say the same in law and guidance. Article 10 of the EU AI Act requires training, validation and testing data for high-risk AI systems to be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete", with documented data origins, preparation steps and bias examination. In the US, the NIST AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1, July 2024) give voluntary guidance on managing these risks.

Which data quality metrics should leaders track?

Leaders need a small set of metrics that show whether trust in data is improving. Track them per critical dataset and roll them up by domain. Our article on data quality metrics covers calculation in more depth.

How should an enterprise fix data quality issues step by step?

1. Find the critical datasets. List the 20 to 50 datasets behind revenue reporting, regulatory output and production AI. Ignore the long tail for now.
2. Assign owners. Give each dataset a producer and a business owner with authority to set thresholds.
3. Profile and baseline. Measure current null rates, duplicates, freshness and invalid values so improvement can be shown.
4. Add baseline checks. Implement keys, accepted values, relationships, volume and freshness tests in the existing pipeline framework.
5. Introduce contracts at the riskiest interfaces. Start where upstream schema changes have caused the most incidents.
6. Add observability and lineage. Cover unknown failures and show downstream impact.
7. Extend to AI pipelines. Apply freshness, deduplication, provenance and access checks to retrieval indexes and training data.
8. Report and review. Publish the metrics above monthly and review incidents to fix root causes, not symptoms.

What are the trade-offs, and when should you not over-engineer?

• Alert fatigue: too many low-value checks train people to ignore alerts. Tie every check to an owner and a severity.
• Cost: running heavy checks on every row of very large tables adds compute cost. Sample or check incrementally where full scans add little.
• Delivery speed: contracts add review steps for producers. Reserve them for interfaces with real consumers and real risk.
• Tool sprawl: overlapping testing and observability products split ownership. Standardise on one of each where possible.
• When not to: exploratory sandboxes, short-lived prototypes and low-impact internal tables rarely justify contracts or paid observability. Basic tests are usually enough.

Frequently asked questions

What are the most common data quality issues?

Incomplete, inaccurate, inconsistent, stale, duplicated and invalid data. They map to the dimensions of completeness, accuracy, consistency, timeliness, uniqueness and validity.

How do you fix data quality issues permanently?

Fix them at the source and stop them recurring: agree data contracts with producers, automate checks in pipelines, add observability for unknown failures, and give each critical dataset a named owner.

What are data quality checks?

Automated assertions that run as data moves, such as not-null, uniqueness, accepted values, referential integrity, volume and freshness. dbt, for example, ships unique, not_null, accepted_values and relationships as built-in generic tests.

What is the difference between data quality testing and data observability?

Testing checks rules you defined in advance. Observability monitors freshness, volume, schema and distributions to detect anomalies you did not predict, and uses lineage to show impact.

How much does poor data quality cost?

Gartner estimates poor data quality costs organisations an average of $12.9 million a year.

Does the EU AI Act regulate data quality?

Yes, for high-risk AI systems. Article 10 requires training, validation and testing data to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete.