Look at the budget for almost any enterprise AI initiative and you'll find the same three lines: platform, model or vendor licensing, and integration engineering. Occasionally a fourth for change management. What you will not find is a line for getting the data into a state where the thing can actually work.
That omission isn't carelessness. It's structural. The data was already there — it's in the warehouse, it's in the ERP, it's in the case management system — so it feels like an asset you already own rather than work you still have to do. Then the build starts, and the team discovers that the field they need is free text in 40% of records, that the two systems disagree about what a "customer" is, and that nobody can say which of the three date columns is the one the business actually uses.
None of that is a data science problem. It's a scoping problem, and it's the single most reliable predictor of whether an AI project lands on time.
Why this keeps happening
Three forces conspire, and they're all reasonable in isolation.
The first is that demos don't need clean data — they need one good example. A vendor proof-of-concept runs on a curated extract that someone hand-picked precisely because it was tidy. It proves the model can do the task. It proves nothing about whether your production data supports the task at scale.
The second is that data quality has no natural owner. The team that generates the data isn't measured on its downstream usefulness, and the team consuming it has no authority to change how it's captured. So the gap gets patched in transformation logic, invisibly, forever — until an AI system depends on it and the patch stops holding.
The third is that "we have a data lake" reads, to a steering committee, as "the data problem is solved." It isn't. A lake tells you the data was landed somewhere. It says nothing about whether it's complete, current, or interpretable by anyone who wasn't in the room when it was designed.
What data readiness actually means
The phrase gets used loosely enough to be useless. In practice, for a specific use case, it decomposes into five concrete questions with checkable answers.
- Access. Can the system reach this data in production, through a supported path, without a nightly manual export? A pilot that runs off a CSV someone emails on Mondays has not proven access — it has deferred the question.
- Coverage. What percentage of records actually have the fields the use case depends on, across the full population rather than the recent slice? Coverage that looks fine for last quarter frequently collapses on the back catalogue.
- Meaning. Does everyone agree what the field means? Two systems that both have a status column and disagree about its values will produce a model that is confidently wrong in one region and fine in another.
- Ground truth. Is there a trustworthy record of the right answer for a few hundred cases, so you can tell whether the system is working? Without this you cannot evaluate, and without evaluation you cannot safely go live.
- Freshness and permission. How stale is the data at the moment of use, and who is allowed to see what it exposes? A recommendation built on yesterday's inventory, or one that surfaces a record the user shouldn't see, fails for reasons that have nothing to do with accuracy.
Data readiness is not a property of your data estate. It's a property of one use case against that estate — which is why it can't be answered once, centrally, in advance.
The readiness pass: a week or two, before the build
The fix isn't a data program. It's a short, bounded investigation that happens after you've picked the use case and before anyone writes the integration. Four things come out of it.
- A traced field list. Every field the use case needs, followed back to the system and the human process that produces it. This is tedious and it is where most of the surprises surface — usually in the form of a field that is populated by hand, inconsistently, by a team that has no idea anyone downstream depends on it.
- Measured coverage, not assumed coverage. Run the counts. Nulls, defaults, free-text overflow, duplicates, and the distribution across business units and time. Ten minutes of SQL routinely overturns a confident answer from a system owner.
- An evaluation set. A few hundred cases with a known correct outcome, agreed with the business before the build, and held back from it. This is the artifact that makes every later argument about performance resolvable — and the one teams most often skip because it requires people, not engineering.
- A refresh contract. Written agreement on how current the data will be at the point of use, who is on the hook when a feed breaks, and what the system does when the data is late. Design the degraded path now; you will need it.
How much readiness is enough
Here's the trap on the other side. Once an organization accepts that data is the constraint, the natural instinct is to fix the data — all of it, properly, first. That's how a nine-month AI initiative becomes a two-year data platform program that quietly ends before any AI ships.
The scope is the use case, not the enterprise. You need the fields this workflow touches to be good enough for this decision, at the accuracy this decision requires. A model that routes a case to one of four queues tolerates far messier inputs than one that produces a number a customer sees. Set the bar from the consequence of being wrong, then fix only what's below it.
The corollary is that readiness work should ship alongside the use case, not before it. Each use case pays down the part of the data estate it depends on, and the second project in the same domain starts from a better position than the first. That compounding is real — but only if you sequence use cases so that it can happen, rather than spreading the first three across three unrelated domains.
A short worked example
An insurer wants to triage inbound claims documents automatically. The demo worked beautifully on 200 sample PDFs. The readiness pass took eight working days and found three things: 22% of claims arrived as photographs of paper rather than digital documents; the "claim type" field the routing logic depended on was populated after triage, not before, so it wouldn't exist at decision time; and there was no labelled set of correctly-triaged historical claims because the outcome was only ever recorded in a case note.
None of those killed the project. The photographs got their own pre-processing path, the routing logic was rebuilt on fields available at intake, and two adjusters spent three days labelling 400 historical claims to create the evaluation set. Total cost: roughly three additional weeks, identified before a single integration was built. Discovered six months later, in production, the same three findings would have been a rebuild and a credibility problem.
The honest takeaway
If your AI business case has no line for data work, it isn't a complete business case — it's an estimate with a known omission. The fix is small and unglamorous: a two-week readiness pass per use case, scoped to that use case, with a traced field list, real coverage numbers, an evaluation set, and a refresh contract at the end of it.
That work is cheap when it's planned and expensive when it's discovered. It is also, in our experience, the clearest difference between the programs that reach production and the ones that spend a year being nearly ready.