The Data Quality Tax That Nobody Budgeted For

Every serious enterprise AI implementation eventually arrives at the same meeting. Someone from the data engineering team, who has spent the previous three months trying to connect the AI system to the company’s data sources, presents their findings to the project steering committee. The findings are variations on a theme: the customer data is in six different systems with no canonical identifier; the product catalog has 40,000 duplicate entries from three ERP migrations; the document repository has not been governed since 2018 and contains a ratio of useful content to outdated noise that nobody has measured but everyone suspects is bad; the data governance team has a six-month backlog and cannot approve real-time access to three critical datasets within the project timeline.

The reaction in the room is usually a form of collective surprise that nobody who was paying attention should feel. The data quality problem in most large enterprises is not a secret. It is documented in annual IT assessments, flagged by data governance teams, surfaced in every previous enterprise software implementation of the last twenty years. What is new is not the problem. What is new is that AI, more than previous generations of enterprise software, cannot work around it.

Why AI Is Less Tolerant of Bad Data Than Previous Systems

Legacy enterprise software — ERP, CRM, analytics platforms — was designed by people who had spent careers working with enterprise data and built with tolerance for its messiness as a first-class design requirement. A CRM system can be configured to handle duplicate customer records through deduplication rules. An analytics platform can be built on top of data warehouses that normalize and clean data before it is queried. These systems put the cleaning logic upstream of the business application, so the application works tolerably well even when the underlying data is inconsistent.

AI systems, particularly the LLM-based ones that have driven most of the enterprise excitement, are different in a specific way. Their intelligence is contextual — they understand information relative to everything else in their context, and they are quite good at working with ambiguous or incomplete information when that ambiguity is natural language ambiguity. They are considerably less good at working with inconsistency that arises from data management failures rather than natural ambiguity: multiple spellings of the same entity, conflicting values for the same attribute across different systems, documents whose metadata says they are current but whose content is outdated, identifiers that mean different things in different parts of the organization.

Related reading

When an LLM-based retrieval system retrieves five documents about a company’s return policy and three of them describe a policy that was changed in 2022, the system does not know that three of them are outdated. It synthesizes an answer that blends old and new policy in ways that seem coherent and are wrong. This is worse than the old keyword search, which would have returned all five documents and let the human decide which to trust.

The other dimension is that AI amplifies data quality problems at scale. A human processing claims manually will notice when a particular data field is frequently missing or incorrect and will adapt their behavior — either filling in the missing data through other means or flagging the record for manual review. An AI system processing claims at ten times the volume with no human in the loop will propagate the data quality error through ten times as many decisions before anyone notices.

The Measurement Gap

The data quality tax is systematically underestimated in AI project planning for a reason that has nothing to do with incompetence and everything to do with how enterprises assess their data.

Most enterprises have data quality assessments that measure technical quality metrics: completeness (are required fields populated?), uniqueness (are there duplicate records?), validity (do values conform to expected formats?). A customer record with a valid email address, a complete name, and a properly formatted phone number passes a technical data quality check.

What those checks do not measure is semantic quality — whether the information is accurate, current, and contextually meaningful for the AI use case. A document that is technically complete (it has a title, an author, a creation date, content text) can still be useless or actively harmful to an AI system if the content is outdated, if the document describes a superseded process, or if the document’s apparent scope does not match its actual content.

This is why AI projects consistently discover data quality problems later than planned, with costs and timelines that exceed the original estimates. The enterprise’s data quality assessment said the data was 94% complete and 97% unique. The AI deployment discovered that 40% of the documents in scope were outdated, that a critical field in the customer database meant different things in different business units, and that the product catalog’s taxonomy was inconsistent enough that the AI could not reliably classify products across categories.

Related reading

None of these are discoverable without actually running AI inference against the data — which means the discovery happens during implementation, not during planning. By that point, the project timeline is committed, the vendor contracts are signed, and the steering committee’s expectations are set.

The Remediation Cost Problem

When enterprises do discover their data quality problems in the context of an AI implementation, the remediation costs are regularly between three and ten times what was budgeted, and the timelines extend by six to eighteen months.

The reasons are structural. Data quality remediation requires a combination of technical work (writing data transformation rules, building deduplication logic, implementing validation pipelines) and human judgment work (deciding which of two conflicting records is correct, determining the current authoritative version of a document, reconciling classification inconsistencies that require domain knowledge). The human judgment work cannot be fully automated, which means it requires pulling time from subject-matter experts who have other jobs and who were not included in the AI project’s resource planning.

The governance dimension adds another layer. Cleaning enterprise data is not only a technical act. It is an organizational act that requires agreement on what the correct answer is, which requires surfacing disagreements about data definitions that have existed for years without being resolved because nobody had to resolve them before. These disagreements are frequently political. They represent territory disputes between business units that have maintained their own data definitions for good reasons. Resolving them takes time and sometimes requires escalation to senior leadership.

A healthcare organization that discovered its patient matching logic was inconsistent across its five legacy systems spent eleven months on remediation before its AI clinical documentation tool could be deployed to production. The eleven months were not wasted — the organization’s data infrastructure is genuinely better than it was, and the AI system performs significantly better against clean data. But the eleven months were not in anyone’s original plan, and the delay had real costs in consultant contracts extended, infrastructure costs sustained, and project team retention challenges.

What Good Data Preparation Actually Looks Like

The enterprises that have moved through this problem most efficiently share an approach that is deceptively simple: they treat data readiness as a launch prerequisite rather than a parallel workstream.

Related reading

This means running a data audit before writing an AI architecture. Not during the pilot (when you can control the data), and not after the business case is approved (when changing scope is painful). Before. The audit asks: for this specific AI use case, what data does the system need? Where does that data live today? What is its actual quality? What would remediation require?

This front-loading discipline has two effects. First, it surfaces blocking issues before they become expensive surprises. Second, it gives the business case realistic cost and timeline estimates, which allows the organization to make an informed decision about whether the investment is justified rather than making an optimistic decision that later requires painful rescoping.

The companies that have built genuine AI deployment capability — companies like Capital One, which has been running ML in production for a decade before the LLM era — treat data infrastructure investment as a prerequisite to AI capability investment. The foundation comes first. You cannot build a production AI system on a data foundation that was designed for a previous generation of tools, at a previous generation of scale, with previous generation quality standards. Trying to do so is not optimism. It is a reliable way to donate eighteen months and several million dollars to the AI pilot graveyard.