July 7, 2026
Most organisations now have a data quality policy. But a policy doesn’t tell you how good your data actually is right now. Policies full of aspirational language (“data should be accurate, complete, and timely”) feel like progress, but without measurable definitions of what “good enough” looks like, they’re just intentions. And, with GenAI moving rapidly from experimentation to production, that’s an urgent problem.
Data quality isn’t just one number. Saying your platform has “78% data quality” is a bit like saying a hospital is “78% healthy.” Quality only makes sense relative to the situation the data is being used for, and for many use cases, imperfect quality is good enough..
A customer email field that’s 90% complete might be perfectly fine for marketing segmentation, but if you’re using it as a key for identity resolution in your Customer 360 profiles, that same 10% gap is a serious blocker. Freshness that’s acceptable for quarterly financial reporting is useless for real-time fraud detection. The same dataset can have different quality requirements when it’s consumed by different teams for different purposes.
That’s why the impulse to demand platform-wide “quality scores” is ultimately wasteful: you’ll only generate dashboards that nobody acts on. “What’s our quality score?” isn’t a useful leadership question. “Quality for what?” is a much better thing to be able to answer. Once you tie measurement to specific use cases and data products, prioritisation becomes much clearer. You fix the issues that are actually worth addressing, not the ones that make a scorecard look red.
It helps to think of data quality as a “nutrition label” rather than a pass/fail stamp. Instead of one score, you publish a quality profile for each dataset, like completeness by field, freshness, distributions, known gaps. This visibility also grants each data consumer the agency to judge fitness for their purpose, and it forces them to take responsibility for articulating what they actually need rather than making vague data quality demands.
The quality problem is harder today than it used to be. Previously, a dashboard with a few gaps still looked like a dashboard, and a human applied judgment when reading it. GenAI use of data blows up that safety net.
When an LLM summarises records, generates recommendations, or powers an agent that takes actions, it confidently produces outputs built on potentially shaky data foundations. And because the output is fluent natural language, it feels more trustworthy than a spreadsheet with obvious holes. The blast radius of poor data quality shifts from “someone misreads a chart” to wrong answers delivered at scale, with real reputational and operational consequences.
GenAI also drags in a whole category of data that most organisations have never quality-managed at all: unstructured content. RAG pipelines pull from policy documents, wikis, Confluence pages, PDFs. The quality questions are completely different. It’s not “is this field null?” but “is this document still current? Does it contradict another document? Which version is the latest?” Most data quality programmes haven’t even begun to inventory this material, let alone measure it.
Let’s say you measured quality during a project’s build phase, and knew that a document that drives an important AI workflow was accurate when you curated it in January. But the actual business process changes in March and nobody updates the AI workflow’s document set. Now you’ve got false confidence in your data quality, which is much worse than knowing you have a problem.
The shift leaders need to make is from treating data quality as a project — a one-off assessment that produces a report — to treating quality as an ongoing part of the data product. That means continuous monitoring, clear ownership, and looking at trends rather than snapshots.
Start simple. Park ambitious measures like “contradiction detection” or “semantic accuracy” or “cross-dataset consistency” until the basics are producing actionable insights.
For structured data, start with basic dimensions that connect directly to pain:
For unstructured data feeding GenAI, start with:
None of this works if it’s launched as a compliance exercise. Instead, frame it as enablement: “we want to move faster with GenAI and analytics, and we can’t do that confidently without understanding where we are.” Start with a team or use case where data quality pain is already felt to give you an early win and a real story.
Make metrics transparent but not punitive. If a team discovers their dataset is 60% complete on a critical field, that’s not a failure! It’s the first honest conversation anyone’s had about it. Celebrate the measuring, not the score.
And watch out for Goodhart’s Law (“when a measure becomes a target, it ceases to be a good measure”). If you track null rates, someone will backfill fields with useless “N/A” strings to turn the scorecard green. Beyond simple measures, teams should tie metrics to business outcomes: state why it’s worth measuring some aspect of this dataset’s quality and what is affected by it.
Finally, resist the urge to centralise everything. Teams should own and consume their own quality metrics as operational intelligence. The CDO’s role isn’t to understand every quality score, but rather to ensure the practice is happening across the organisation and maturing over time. You’re measuring the health of the discipline, not policing the numbers.
Thorben is a data and software engineering specialist with over 18 years’ experience delivering scalable, pragmatic data and machine learning products across cloud platforms. He helps teams adopt modern data practices to rapidly build, test, and deliver value from their data.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
