Data Quality Management: A Framework for Business

2026-09-07 · Tommaso Maria Ricci

Gartner surveyed 248 data management leaders in the third quarter of 2024 and found that 63% of organizations either lack the right data management practices for AI or do not know whether they have them. The prediction attached to that finding is the number executives should be reading twice: through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data. Learning how to measure data quality before AI adoption is therefore not a technical housekeeping exercise. It is the single filter that separates the AI budgets that produce something from the ones that produce a postmortem.

I want to be precise about what this article is and is not. It is not a survey of data quality tools. It is a method for measuring the state of your data in numbers, deciding what to fix in what order, and knowing when to stop. I have used this method inside companies with 30 employees and inside groups with eleven legal entities, and the sequence does not change much. What changes is how long each step takes.

The financial case is older than the AI wave and more durable. Writing in MIT Sloan Management Review, Thomas Redman put the cost of bad data at 15% to 25% of revenue for most companies, and argued that roughly two thirds of that spend can be identified and permanently removed by attacking the root causes of errors rather than the symptoms. That article is from 2017, which matters: the cost of bad data was already structural before anyone was budgeting for AI. What generative AI did was remove the option of ignoring it, because a model trained or grounded on inconsistent records does not degrade gracefully. It produces confident, specific, wrong answers.

There is a companion finding worth holding next to it. In Harvard Business Review, Tadhg Nagle, Thomas Redman and David Sammon reported that only 3% of companies' data met basic quality standards when measured record by record. Their method was deliberately crude: take 100 recently created data records, work through each one, count how many are error free. I still use that exact test as the opening move of every assessment, because it takes an afternoon and it ends the argument about whether there is a problem.

Why data quality became the binding constraint

For twenty years, data quality was a back office concern with a weak business case. It stayed that way because the systems consuming the data were tolerant. A slightly wrong address produced a slightly late delivery. A duplicate customer record produced a marginally inflated count in a monthly report that nobody audited. The errors were absorbed by people, who noticed them and quietly corrected for them.

Three things changed that.

The first is automation. When a process runs without a human in the loop, there is nobody left to absorb the error. An automated dunning sequence sends invoices to the wrong contact at scale and quickly. The tolerance that used to live in the process disappears the moment the process stops passing through a person.

The second is the shift from reporting to prediction. Reporting on bad data produces a wrong number, which someone eventually questions. Predicting on bad data produces a model that has learned the wrong relationships, and nobody questions it because the output looks like every other output. The error is not visible in the artifact.

The third is grounding. Retrieval systems and AI assistants read directly from operational stores. If those stores contain three versions of a customer, four spellings of a supplier, and a pricing table that was superseded eighteen months ago but never archived, the assistant retrieves all of it and reconciles none of it. This is the mechanism behind most of the enterprise AI pilots that impress in demo and fail in production. The demo runs on a curated slice. Production runs on the actual store.

McKinsey's global State of AI survey, fielded from late June to late July 2025 with 1,993 respondents across 105 countries, describes the resulting gap plainly. 88% of organizations report using AI in at least one business function, but only around 6% qualify as high performers attributing more than 5% of EBIT to AI, and data quality sits among the named blockers to scaling alongside workflow rigidity and measurement gaps. Adoption is universal. Value is rare. The difference is mostly upstream of the model.

If your organization is deciding where to spend its next AI budget, the sequencing argument is laid out in more detail in the enterprise AI adoption framework, and the honest version of it is that data work usually has to come first even though it never demos well.

Data quality is not data governance

These two get conflated in almost every conversation I have, and the conflation is expensive because it sends the work to the wrong team.

Governance answers questions of authority. Who owns this data domain. Who is allowed to change a customer record. What is the retention policy. What happens when two departments disagree on a definition. Governance is a decision rights problem, and it is solved with structure, policy and named accountability. I have written the practical version of that separately in the data governance framework guide.

Data quality answers questions of state. How wrong is this data right now. Wrong in what dimension. Wrong in which systems. Getting worse or better. Quality is a measurement problem, and it is solved with instrumentation and remediation.

The relationship between them is directional. Governance without quality measurement is a policy nobody can verify. Quality measurement without governance produces dashboards showing decay that nobody has the authority to stop. You need both, but they are not the same project, they do not require the same skills, and running them as one initiative is the most common way I see both fail.

There is a third thing that also gets folded in, wrongly: master data management. MDM is the architectural answer to the specific question of where the authoritative version of an entity lives. It is a heavy solution and it is the right one less often than vendors suggest. The circumstances where it genuinely pays are covered in the master data management strategy guide. For most mid sized companies, disciplined quality measurement plus clear ownership solves 80% of what MDM is sold to solve, at a fraction of the cost.

The six dimensions, and what to actually measure in each

The academic literature offers between four and sixteen dimensions of data quality depending on which framework you read. Six are enough to run a business on, and each one needs a measurable definition rather than an adjective.

Completeness. The percentage of records where required fields are populated. Measurable immediately. The trap is defining "required" by the database schema rather than by the process. A field can be nullable in the schema and mandatory in reality, and those are the fields that break things.

Accuracy. The percentage of records that correctly describe the real world object. This is the expensive one, because it cannot be measured inside the system. It requires an external reference: a phone call, a physical count, a third party registry. Because it is expensive, measure it on samples, not populations.

Consistency. The percentage of entities that agree across systems. Take 200 customers that exist in both the CRM and the billing system, and compare the fields that should match. In my experience the disagreement rate on a first measurement in a company that has never done this sits between 10% and 30%, and the number reliably shocks the people who own both systems.

Timeliness. The lag between an event in the world and its representation in the system. Measure it in hours or days per data domain, not as a general property. Inventory that is four hours stale and a customer address that is four hours stale are entirely different risks.

Uniqueness. The duplicate rate per entity type. Straightforward to measure with fuzzy matching, and consistently worse than anyone expects. Duplicates are the single most common reason a retrieval system returns contradictory answers about the same customer.

Validity. The percentage of values conforming to their defined format or allowed range. Cheap to measure, cheap to enforce going forward, and the dimension where prevention beats remediation most decisively.

The discipline that makes this list useful rather than decorative is that each dimension gets a number, a measurement method written down, and a cadence. A dimension without a number is an opinion.

How to measure data quality before AI adoption: the four week assessment

Here is the sequence I run. Four weeks, one part time analyst, no software purchase required.

Week one: scope and the manual baseline.

Pick between three and five data domains that matter to the decisions you actually make. Customers, products, suppliers, transactions, employees. Do not attempt the whole estate. An assessment that tries to cover everything produces a document nobody reads.

Then run the HBR test on each domain, by hand. Pull the 100 most recently created records. Go through each one, field by field, and mark it error free or not. Count. This gives you a baseline that is defensible in a board meeting precisely because it involved no tooling and no methodology anyone can dispute.

Record two numbers per domain: the percentage of clean records, and the distribution of error types. The second number is more useful than the first, because it tells you where to aim.

Week two: automated profiling.

Now go wide. Profile the full tables: null rates per column, cardinality, format violations, value distributions, outliers, referential integrity failures. Any modern data platform does this, and for a first pass a few hundred lines of Python against a database connection is entirely sufficient.

Compare the automated profile against the manual baseline. Where the automated numbers look better than the manual ones, your automated checks are too permissive, and that gap is itself a finding worth documenting.

Week three: cross system consistency.

This is the week that produces the uncomfortable slide. Take the entities that exist in more than one system and compare them. Customers in CRM against customers in billing. Products in the ERP against products on the website. Employees in HR against accounts in the identity provider.

Report three numbers per pair: entities present in one system and absent in the other, entities present in both with conflicting values, and entities present in both and in agreement. In most organizations the third number is smaller than leadership expects, and it is the number that best predicts whether an AI assistant grounded on those stores will contradict itself.

Week four: cost attribution and the readiness verdict.

Convert findings into money, because a percentage does not get funded. Three components, all countable.

Rework cost: hours per month spent correcting data downstream, times loaded hourly cost. Ask the teams, then verify with a two week time log rather than trusting the estimate.

Error cost: incidents traceable to bad data over the past twelve months, times their direct cost. Wrong shipments, credit notes, duplicate payments, missed renewals.

Opportunity cost: decisions delayed or made blind because the data was not trusted. Harder to quantify, so state it as a range and label it as an estimate rather than dressing it up as precision.

Then write the readiness verdict per use case, not per company. "Our data is not AI ready" is not actionable. "The customer domain is ready for a retrieval assistant scoped to support tickets, and is not ready for automated pricing" is.

If you run this assessment and find that the gap between your current state and your AI ambitions is wider than one internal team can close in a quarter, that is worth a structured outside conversation before the budget is committed rather than after the pilot has stalled. A four week assessment that reprioritizes an eighteen month roadmap pays for itself several times over, and the right moment to have it is while the roadmap is still a draft.

The data quality scorecard

Score one point per yes. This is the version I leave with clients.

Measurement

You can state the completeness rate of your primary customer records as a number, measured within the last quarter.
You measure duplicate rates on at least your customer and supplier domains.
You measure consistency across at least two systems that hold the same entities.
Quality metrics are recomputed on a schedule, not when someone asks.
Metric definitions are written down somewhere other than in one analyst's head.

Ownership

Every primary data domain has a single named owner who is accountable, not a committee.
There is a defined path for reporting a data error that is not a message to a colleague.
Reported errors are tracked to closure with a visible backlog.
Data quality appears in at least one operational review each month.

Prevention

Validation happens at entry, not only in downstream reporting.
Duplicate prevention is enforced at creation time.
Integrations fail loudly on schema or contract violations instead of silently dropping records.
There is a documented process for retiring or archiving superseded records.

AI readiness

You know which data stores your AI systems can read from, and that list is current.
Superseded documents, old price lists and obsolete policies are archived out of the retrieval corpus.
You have measured quality specifically on the subset of data an AI system consumes, not just overall.

Reading the score. 14 to 16: you are ready to scale AI on this data, and remaining work is maintenance. 10 to 13: ready for narrowly scoped, well bounded use cases; be explicit about the boundary. 6 to 9: run targeted remediation on one or two domains before any AI project touches them. Below 6: any AI initiative built on this data is a coin flip, and the honest recommendation is to spend the next two quarters on foundations.

The 30, 60, 90 day remediation roadmap

Assessment without remediation is an expensive way to feel informed. This is the execution sequence.

Days 1 to 30: stop the bleeding.

Fix intake before fixing history. Every hour spent cleaning records while the pipeline that creates them is unchanged is an hour that will be spent again next quarter. Add validation at the point of entry for the three or four fields that generate the most downstream errors, and enforce duplicate prevention at creation.

Name the owners. One human being per domain, with the authority to decide what a correct record looks like. Not a working group. A person.

Instrument the metrics you defined in the assessment so they recompute automatically and land somewhere visible.

Days 31 to 60: remediate what pays.

Rank domains by cost of error multiplied by volume, and work the top of the list only. In most companies this means customer and supplier data first, because they touch billing and payments where errors have direct financial consequences.

Deduplicate with a human in the loop. Automated merging at scale on a first pass creates a worse problem than the one it solves, because a wrong merge is far harder to unwind than a duplicate.

Fix the top three consistency mismatches between systems, and fix them at the integration layer rather than by reconciling the outputs. Reconciliation is a treatment. Integration is a cure.

I saw this play out in a medical center where the referral and scheduling data sat in two systems that had drifted for years. The remediation was unglamorous: one owner, deduplication with clinical staff verifying merges, and a single source for patient contact details. The measurable outcome, once bookings stopped failing on stale contact records and slots stopped being double held, was roughly 20% more capacity from the same physical footprint and the same staff. No model was involved.

Days 61 to 90: prove it and lock it.

Re run the week one manual test on the remediated domains. Same method, same sample size, new records. If the clean rate has not moved, the remediation addressed symptoms and you need to go back to intake.

Publish the trend rather than the snapshot. A single number invites argument about methodology. A trend line across three measurement points ends that argument.

Write the maintenance cadence down and put it in someone's calendar: monthly recomputation, quarterly manual sample, annual scope review. Quality that is not maintained decays at a rate that surprises people, because the systems that create data change faster than the checks that validate it.

Only now scope the AI use case. If you have followed the sequence, you can state in one sentence what data the system will read, how good that data is, and what it is not allowed to be used for. That sentence is the difference between a pilot and a proof of concept that never ends. The framework for putting a number on what comes next is in the AI ROI guide for business.

Where AI genuinely helps with data quality

There is a circularity here worth naming: using AI to fix the data that AI needs. It works in some places and not others, and the boundary is fairly clear.

Entity resolution. Deciding whether "Acme Srl", "ACME S.r.l." and "Acme Limited, Milan branch" are the same company is a matching problem where modern embedding based approaches substantially outperform the deterministic rules most systems ship with. This is the highest value application, and it is mature.

Anomaly detection. A model trained on historical patterns flags the records that deviate: an invoice from a familiar supplier at an unfamiliar amount, a product with a margin outside its normal band, a customer whose payment behaviour just changed. This catches the errors that pass validation because they are structurally correct and factually wrong.

Classification and enrichment. Assigning categories, standardizing free text into controlled vocabularies, extracting structure from unstructured documents. Reliable, well understood, and where most of the immediate time savings live. The wider view of which document flows are worth automating is in the business process automation guide.

Where it does not help. A model cannot tell you the real world truth. It can tell you that two records are probably the same entity. It cannot tell you which of two conflicting addresses is the one where the customer actually receives mail. That requires contact with reality, and no amount of modelling substitutes for it. Anyone selling you automated accuracy correction without an external reference source is selling confidence, not correctness.

The other caution is dependency. Every automated correction that runs without review becomes a source of errors of its own within a year, and those errors are harder to find because they are systematic rather than random. Keep a human sampling step on every automated correction path. It costs a few hours a month and it is the only thing standing between you and a silent, consistent, confidently wrong dataset.

What good looks like after twelve months

The organizations that get this right do not end up with perfect data. Perfect data is not a goal any serious operator holds. They end up with four specific properties.

They know their numbers. Ask anyone accountable for a domain what the completeness and duplicate rate is, and you get a figure and a date rather than a promise to check.

They have named owners with real authority. When two departments disagree about what a customer record should contain, there is someone who decides, and the decision holds.

Prevention outweighs remediation in effort. In the first year the ratio is inverted, because there is a backlog to clear. By the second year, most of the effort has moved upstream to intake, and cleanup has become a small maintenance line.

They scope AI honestly. They can say which use cases their data supports and which it does not, and they decline the ones it does not without treating the refusal as a failure. Deloitte's long running work on the insight driven organization makes the same point from a different direction: the organizations that extract value from data are distinguished less by technology than by the discipline of embedding data into how decisions actually get made.

The uncomfortable part is that none of this is novel. Every element of this method was available and known a decade ago. What changed is the cost of ignoring it, and that cost is now high enough, and visible enough, that the argument for deferring the work has finally run out.

If you are looking at a stalled AI initiative and cannot tell whether the problem is the model, the use case or the data underneath it, that diagnosis is worth doing properly before another quarter of budget goes into the same pilot. It is a short, bounded piece of work, and it is almost always cheaper than the alternative of finding out at the end.

Five failure patterns, and how to recognize them early

I have watched enough of these programs to recognize the shapes they fail in. All five are avoidable, and all five look reasonable from the inside while they are happening.

Buying a platform before defining a metric. A data quality tool is a measurement instrument. Buying one before you have decided what to measure produces a subscription and a dashboard populated with vendor defaults that correlate weakly with anything your business cares about. The correct order is: define the metric, measure it by hand once, automate the measurement, then buy a tool only if the manual version has become the bottleneck. Most mid sized companies never reach that point, and the ones that do reach it know exactly what they are buying and why.

Cleaning history while intake stays broken. This is the most expensive pattern because it feels productive. A team spends a quarter deduplicating customer records, reports a clean rate improvement, and eighteen months later the duplicate rate is back where it started because nothing changed at the point of creation. Prevention before remediation is not a preference, it is arithmetic: if the creation rate of bad records exceeds the correction rate, the backlog grows regardless of effort.

Assigning ownership to a committee. A data domain owned by a cross functional working group is a domain with no owner. When two departments disagree about what a customer record should contain, a committee produces a meeting, and the disagreement persists in the data. One named person with the authority to decide resolves in an afternoon what a committee will not resolve in two quarters.

Measuring everything and prioritizing nothing. An assessment that covers eleven data domains produces a document too large to act on and a team too diffuse to move. Three to five domains, ranked by cost of error multiplied by volume, is the scope that produces decisions. The domains you leave out are not being ignored, they are being sequenced.

Declaring victory on a snapshot. A single measurement showing 94% completeness invites an argument about methodology and tells you nothing about direction. Three measurements over six months showing 78%, 86%, 94% ends the argument and demonstrates that the mechanism works. Publish trends, not snapshots, and re run the manual test with the same method each time so the comparison is honest.

What changes when the consumer is a retrieval system

Traditional data quality work optimized for reporting and for transaction processing. When the consumer becomes a retrieval system feeding an AI assistant, three requirements appear that most quality programs were never designed to handle.

Corpus hygiene matters more than record hygiene. A retrieval system reads documents as often as it reads rows. A policy document superseded two years ago but never archived is not a data quality problem in any traditional sense, because no table is wrong. It is a severe problem for an assistant, which will retrieve the old policy with the same confidence as the current one and has no way to know which is authoritative. Archiving discipline, which almost nobody measures, becomes a first class quality dimension the moment a retrieval layer exists.

Contradiction is worse than absence. A traditional system handles a missing value predictably: it errors, or it defaults, or it excludes the row. A retrieval system handling two contradictory sources does neither. It synthesizes, and the synthesis is plausible and untraceable. This inverts a longstanding priority: for retrieval, resolving conflicts between sources is more urgent than filling gaps within them.

Scope must be explicit and enumerated. Ask most organizations which stores their AI systems can read from and you get an approximate answer. Approximate is not sufficient, because the quality of the answer is bounded by the worst store in the set, not the average one. The list needs to be written, current, and reviewed when anything is connected. This is the single control that most reliably prevents an assistant from confidently citing a spreadsheet somebody abandoned in 2022.

None of this replaces the six dimensions. It adds a layer on top of them, applied specifically to the subset of data an AI system actually touches, which is why the assessment framework above insists on measuring that subset separately rather than assuming the overall figure applies to it.

Twelve questions to put to your own team this week

None of these require a project, a budget or a vendor. They require an hour and a willingness to write the answers down. Where an answer is "I would have to check", that is a finding, not a gap in the conversation.

What percentage of our customer records created last month are entirely free of errors? Who measured it, and when?
How many duplicate customer records do we have, by our own definition of duplicate? What is our definition?
If the CRM and the billing system disagree about a customer's address, which one is right, and who decided that?
Which single person is accountable for the supplier domain? Not which team. Which person.
When someone spots a wrong record, what do they do? Is there a path other than messaging a colleague?
How many hours per month does each team spend correcting data that arrived wrong from somewhere else?
Which incidents in the last twelve months were caused by bad data, and what did each one cost?
Which data stores can our AI systems read from? Is that list written down, and when was it last reviewed?
How many documents in our retrieval corpus have been superseded but not archived?
Where does validation happen: at entry, or in downstream reporting? For which fields?
What is our duplicate rate trend over the last three measurements? Do we have three measurements?
If we stopped all data quality work today, how long before anyone noticed?

The last question is the diagnostic one. In an organization with real instrumentation, degradation surfaces in weeks through the metrics. In an organization without it, degradation surfaces in months through a customer complaint or a failed close, which is both slower and considerably more expensive. The gap between those two answers is the actual value of the program, and it is measurable well before any AI system is involved.

FAQ

How do you measure data quality before AI adoption?

Start with a manual baseline before touching any tooling. Take the 100 most recently created records in each of three to five important data domains, examine each one field by field, and count how many are entirely error free. That number is defensible in any executive conversation because it involves no methodology anyone can dispute. Then profile the full tables automatically for null rates, format violations and referential integrity, compare entities that exist in more than one system, and convert the findings into rework cost, error cost and opportunity cost. The whole assessment takes four weeks with one part time analyst.

What are the main dimensions of data quality?

Six are enough to operate on: completeness, meaning required fields are populated; accuracy, meaning the record correctly describes the real world object; consistency, meaning systems agree with each other about the same entity; timeliness, meaning the lag between an event and its representation is acceptable for the decision at hand; uniqueness, meaning no duplicates; and validity, meaning values conform to their defined format or range. Accuracy is the expensive one because it can only be verified against something outside the system, so measure it on samples rather than populations.

How much does poor data quality actually cost?

Thomas Redman, writing in MIT Sloan Management Review in 2017, estimated the cost of bad data at 15% to 25% of revenue for most companies, and argued about two thirds of that is removable by fixing root causes. Gartner's widely cited figure from its 2020 research put the average cost to an organization at $12.9 million a year, based on reference customers of data quality vendors, which means it skews toward large enterprises. Rather than adopt either number, compute your own from three countable components: hours per month spent on downstream rework, direct cost of incidents traceable to bad data over the past year, and decisions delayed for lack of trusted data.

Is data quality the same as data governance?

No, and treating them as one project is a common way to make both fail. Governance answers who decides: who owns a domain, who may change a record, what the retention policy is, how definitional disputes are resolved. Quality answers what state the data is in right now and in which dimension it is wrong. Governance without quality measurement is policy nobody can verify. Quality measurement without governance produces dashboards showing decay that nobody has authority to act on. Run them as related but separate efforts with different owners.

Do we need to fix all our data before starting with AI?

No, and attempting it is the most reliable way to never start. The verdict should be per use case, not per company. A customer domain can be clean enough to ground a support assistant while being nowhere near clean enough for automated pricing decisions. Scope the first AI use case to a domain you have measured, state explicitly what the system is not allowed to be used for, and expand only as the underlying quality metrics improve.

Can AI fix our data quality problems?

Partly. It is genuinely strong at entity resolution, deciding whether differently spelled records refer to the same company or person, and at anomaly detection, flagging records that are structurally valid but factually improbable. It is also reliable for classification and for extracting structure from unstructured documents. What it cannot do is establish real world truth: when two systems hold conflicting addresses, no model can determine which one the customer actually uses without contact with reality. Keep a human sampling step on every automated correction path, because systematic errors introduced by unreviewed automation are far harder to detect than the random errors they replaced.

How long does a data quality program take to show results?

The first defensible measurement takes four weeks. Visible improvement on one or two prioritized domains takes another 60 days if intake validation is fixed before historical cleanup, which is the sequence that matters most. What takes a full year is the shift in where the effort sits: in year one most of the work is remediating a backlog, and by year two most of it should have moved upstream into prevention, with cleanup reduced to a small maintenance line. If that shift has not happened by month eighteen, the program is treating symptoms.