Rethinking Data Quality in the Age of AI

By Terry Dorsey, Senior Data Architect and North America’s Evangelist for Denodo

For decades, organizations have invested heavily in data quality focusing on accuracy, completeness, consistency, and timeliness. These things matter significantly, and the effort has been worthwhile. But despite real progress, many organizations still find themselves struggling when it comes to analytics, modernization, and now AI.

What if the issue isn’t that we’ve failed to improve data quality, but that we’ve been treating two very different problems as if they were one?

Conceptually and in practice, there are at least two distinct layers of quality that need to be managed separately. The first is about how well an organization represents itself in its data. The second is about how individual solutions use that representation. When these get mixed together, which happens constantly, every project ends up rebuilding the same foundation of trust from scratch.

Here’s why that distinction matters, and what it means for the AI era.

There are really two data quality problems and we keep treating them as one

Consider what has to happen before you can build anything useful — a report, an application, an AI model. First, you need to answer some fundamental questions about your own business:

• Who exactly is a “customer”?
• What counts as a “product”?
• What makes something an “order”?
• What processes produce this data—does the data accurately reflect them?
• Who is authorized to access it  and under what conditions?

These aren’t project questions.  They’re enterprise questions. And they require enterprise-level answers, validated by the people who actually run the business, not just profiled by a technical tool. 

That’s the first layer: Enterprise Information Quality. It’s about ensuring your organization has an accurate, agreed-upon representation of itself, including not just what the data means, but who is permitted to use it. Identity-based security is a core part of that foundation. Determining which individuals, roles, and systems are authorized to access which information is not a decision that should be made differently by every project. It is an enterprise decision, and it belongs at the enterprise layer.

Once that foundation exists, individual projects can focus on what they’re actually meant to do, solve a specific business problem. That’s the second layer: Solution Information Quality. It asks things like: which pieces of enterprise data do we need? Are all required fields available? Are our business rules being applied correctly? Are the right access controls being honored for the right people?

These are completely different questions. And yet, most organizations don’t treat them that way.

What happens when you blur the two together

When these layers aren’t separated, every project essentially starts from scratch.

Which customer definition do we use? Which hierarchy is right? Which source system do we trust? What are the security rules? Who is allowed to see what?

These questions get asked over and over again, by team after team, across the organization. Each project builds its own mappings, its own reconciliation logic, its own interpretation of what the data means  and too often, its own access control model. Each one effectively becomes its own data quality and security program.

The result is rising costs, inconsistent answers, fragmented governance, and growing frustration over why data remains so difficult despite years of investment. And when access controls are defined independently by each project, the risk of inconsistent enforcement, and the compliance exposure that comes with it, grows with every new initiative.

Many of what we label “data quality problems” are really symptoms of this repeated duplication.

There’s a better way: trust inheritance

What if trust were treated as an enterprise asset rather than something every project had to establish on its own?

When core entities, definitions, relationships, and policies have been validated by the people who own and use them, that trust doesn’t expire after one project. It carries forward. Other teams can inherit it.

They don’t need to re-debate what a customer is. They don’t need to reconcile competing product hierarchies. They don’t need to re-establish ownership or security policies. Those decisions have already been made.

Their responsibility becomes applying trusted information, not recreating it.

It’s a meaningful shift in how organizations think about data, with significant operational implications.

Why this matters more than ever in an AI world

For years, people served as the connective tissue holding fragmented data interpretations together. Experienced analysts knew which hierarchy to use. Veteran managers knew which reports needed additional context. Institutional knowledge quietly filled the gaps.

AI doesn’t carry that institutional knowledge.

As organizations move toward generative AI, agentic workflows, and autonomous decision-making, the data inconsistencies that humans have long compensated for become real operational problems. AI surfaces semantic confusion that has been lurking beneath the surface for years.

The challenge is no longer simply to clean your data. The question becomes: does your organization have a trusted, consistent representation of itself that AI systems can reliably consume — and does that representation include knowing who and what is authorized to access it?

The path forward: establish trust once, share it everywhere

This is where logical data management becomes critical. Rather than each project independently determining what things mean, enterprise entities, definitions, policies, and governance are established once  and exposed consistently across applications, analytics, and AI initiatives.

Critically, identity-based security is part of that delivery. Logical data management enables access controls to be defined at the enterprise level, tied to roles, attributes, identities, and data classification, and enforced consistently wherever the data is consumed. Projects don’t need to interpret or re-implement security rules. They inherit them, along with everything else the enterprise has already established.

But logical data management does more than just share what it makes available. It provides the formal processes needed to evolve the enterprise representation over time. When a new attribute is needed or when access policies need to reflect a new role, a regulatory requirement, or a change in organizational structure; there is a defined, repeatable path to introduce it. Changes are validated through governance, documented consistently, and applied across the organization without disrupting what’s already in place.

That kind of structure makes the difference between a data foundation that’s technically sound but brittle, and one that is genuinely sustainable. It can be maintained without heroic effort, adapted as the business changes, and scaled as new initiatives demand more from it.

One of the often overlooked advantages of this approach is the consistency it creates across the full development lifecycle. Because the enterprise representation — its entities, definitions, policies, access controls, and governance, is maintained as a logical layer rather than embedded within individual systems, it can be carried across every landscape, from development and testing through to production. Developers work with the same trusted definitions that operations depends on. Quality assurance validates against the same rules that will govern live systems. There are no surprises at deployment, no reconciliation between what was built and what production expects, and no drift between environments that quietly introduces errors and inconsistencies. The enterprise represents itself the same way everywhere and that consistency becomes the foundation for faster, more reliable delivery at every stage of the process.

The shift is from building trust project by project to inheriting trust organization-wide, and from managing data reactively to evolving it through a disciplined, repeatable process that includes not just what the data means, but who is authorized to use it.

That may be the most important data capability organizations need to develop right now, not just for AI, but for everything that follows.

About the Author

Terry Dorsey is a Senior Data Architect and North America’s Evangelist for Denodo, a leading provider of Logical Data Management technology powered by data virtualization.

With over 30 years of experience in Information Technology, she has played a central role in helping organizations modernize their data infrastructure to support advanced analytics, enterprise integration, and AI-driven outcomes.