What the data problem costs, and why it always surfaces late.
An AI project that dies of a data problem almost never announces itself that way. The postmortem says the model underperformed, or the vendor overpromised, or the team never adopted it. Trace it back far enough and you usually land in the same week: the one where the build team asked for the last eighteen months of the records the system was meant to read, and the answer came back in pieces. Some of it sat in the ERP. Some of it sat in a shared spreadsheet that one operations person maintained by hand. Some of it existed only inside email threads. And the identifiers did not line up across any of them, so nobody could reliably say which rows referred to the same customer.
Nobody lied and nobody was careless. The question simply never got asked, because the sales conversation was about what the system would do rather than what it would need to read. Buyers evaluate output. Vendors demo output. The inputs are assumed to exist in roughly the shape a demo implies, and that assumption survives right up until somebody has to build against real records.
By the time it surfaces, the money is committed and the options are all bad. The scope shrinks to whatever the available data can support, which is usually a less valuable version of the thing that got approved. Or the timeline stretches while somebody cleans up records, which is real work that was never priced and does not look like progress to anyone watching from outside the project. Either way the schedule slips past what was sold, and the gap between a quoted timeline and a real one is worth understanding before it happens to you, which is the subject of how long a mid-market AI build actually takes.
The worse outcome is the one where the build proceeds anyway. The system reads inputs the team has private doubts about, produces output that is plausible on its face, and runs for a few weeks before someone with domain knowledge catches an answer that is confidently wrong. Confidence plus wrongness is the combination that ends adoption, because it teaches every user that the tool cannot be trusted without checking, and a tool that has to be checked is slower than not having it. That is one of the more common findings when working out what to do after a failed AI pilot, and it is almost always upstream of the model.
None of this requires a data platform to prevent. It requires knowing what you have before you commit, at the resolution of one workflow, which takes days rather than quarters.
Readiness belongs to a workflow, not to your company.
The sentence that costs mid-market operators the most money is "our data is not ready." It is almost always false at the company level and almost always answerable at the workflow level. Nobody's data estate is clean. Every business above about twenty people runs on some combination of a system of record, a set of spreadsheets that fill its gaps, and institutional knowledge that never made it into either. That is the normal condition, not a disqualifying one.
The relevant question is narrower. Pick the workflow you want automated, walk it backwards from the decision it produces, and write down every input the system will have to read. For most operational workflows that list runs to fifteen or twenty fields. Readiness is whether those fields, and only those fields, are in usable shape.
Start with where each one lives. A field in a system of record with an API is a different proposition from the same field in a spreadsheet somebody updates weekly, which is different again from a number that exists only because a manager remembers it and types it into an email. The spreadsheet is workable. The email is not, until the process changes. Most workflows turn out to be a mix, and the mix is the useful thing to see written down, because it tells you immediately whether this is a two-week integration or a process redesign wearing an integration costume.
Then structure. A system can query a table. It can extract from a well-formed PDF with effort. It struggles with free-text notes fields where five people used five conventions over six years, and it cannot do much with information that was never recorded because everyone knew it. Structure is not a binary; it is a cost curve, and knowing where on that curve each input sits is what makes a scope estimate honest instead of hopeful.
Identifiers matter more than any other single dimension, and they are the most commonly broken. If the same customer is a numeric ID in the ERP, a name string in the CRM, and an email address in the ticketing system, then joining those three sources is guesswork, and guesswork on identity produces errors that look like intelligence failures. A distributor whose shipping system keys on a customer number that its accounting system does not carry will find that no amount of model quality fixes the resulting mismatches. Identifier alignment is unglamorous, cheap relative to everything else, and the highest-leverage thing most companies can fix before a build starts.
Freshness comes next, and it is a question about the decision rather than the data. A system that recommends inventory buys against numbers refreshed nightly is fine. A system that quotes a customer against pricing refreshed nightly is a liability the first time a price moves at nine in the morning. Ask what decision the output drives and how stale the input can be before the decision goes wrong, and you get the latency requirement without a theoretical debate about real time.
Completeness is where a lot of projects get an unpleasant surprise. A field can exist in the schema and be blank on sixty percent of records, and nobody notices until a system tries to read it, because humans silently route around missing values using context. Check population rates on the three or four fields the decision actually turns on, not on the table as a whole. Access is the one that is purely administrative and still stops projects cold: if getting read access to a system means a ticket with a vendor and a two-week wait, that is a schedule item and it belongs in the plan.
The last dimension is historical record, and it is the one buyers skip most often. If there is no record of what the workflow produced over the past year, there is no baseline, and with no baseline you cannot demonstrate that the system helped. That turns the entire investment into a matter of opinion at review time, which is a bad position for whoever sponsored it. Establishing the baseline before the build is the cheapest measurement work you will ever do, and it is the foundation of measuring the return on an AI engagement in a way a finance team will accept.
The tells that you are not ready for the workflow you picked.
Four signals reliably indicate that the workflow in front of you is the wrong first one. None of them means the company is unready. Each means this particular process needs work first, or a different process should go first.
The clearest is a fact that lives in three systems with three different values, where nobody can say which is authoritative. This is not a data quality problem in the usual sense; it is an absence of ground truth. A system built on top of it will produce answers that some part of the business considers wrong no matter which source it reads, and the disagreement predates the software. Resolving which system wins is an operational decision somebody has to make, and it is worth making regardless of whether an AI project follows.
The second is a process that depends on knowledge only one person holds. Every mid-market company has at least one of these, usually a long-tenured employee who knows which accounts get exceptions and which shipments need a phone call. The rules exist and work, and they were never written anywhere a build team can find. That is not automatically disqualifying, because those rules can be extracted through interviews, but it converts an integration project into a knowledge-capture project with a different cost and a different timeline. It is also one of the sharper indicators in the broader question of whether a business is ready for custom AI at all.
The third is no historical record. If the workflow has been run for years without leaving a trace of its inputs and outputs, then the system has nothing to be evaluated against, and neither do you. The fourth is access that requires a vendor ticket. Legacy platforms with no API, systems where the integration tier costs extra, and databases the incumbent vendor guards are all common, and all of them turn a two-day connection into a two-month negotiation.
The right response to any of these is to name it as a line item with an owner and a date, not to conclude that the company is not ready for AI. Three of these four are fixable in weeks by people you already employ.
Fixing the gap without funding a two-year data program.
The expensive detour is the data warehouse. It gets proposed in good faith, usually by someone technical who is genuinely right that consolidation would help, and it postpones the AI work behind a multi-quarter program with its own budget, staffing, and political cost. Worse, it funds infrastructure on a hypothesis, because nothing has proven value yet. Consolidation earns its cost once several workflows are all reading the same messy inputs and the duct tape exceeds the platform. First, before anything has paid for itself, it is a way to spend a year looking busy.
Three moves do most of the work instead. The first is scoping down to the workflow whose inputs already sit in one system. This is the single highest-return decision available, and it usually means the first build is not the one that came up first in the meeting. The obvious candidate is often the one touching four systems, because that is where the pain is. Start with the boring one that lives in the ERP, ship it, and let it buy the credibility and the budget for the harder one. That sequencing logic is close to the reasoning in the build versus buy decision for a mid-market company, and it applies before either path starts.
The second is fixing identifiers before building pipelines. A shared key across the systems a workflow touches is worth more than any amount of clever integration logic downstream, and it is usually a bounded project measured in days: pick the authoritative system, add the key to the others, backfill the records that matter. Teams tend to skip it because it is unsatisfying work with no visible output, then spend three times as long writing matching heuristics that are wrong two percent of the time forever.
The third is treating a small manual cleanup as cheaper than an architecture project. Nobody wants to hear that the answer is two people spending a week normalizing four thousand records, but the arithmetic is frequently decisive. A week of labor against a quarter of engineering is not a close call, and the cleanup produces certainty about what the data contains while the engineering produces a system that automates whatever ambiguity was already there. This kind of tradeoff is a normal part of an honest scope, and it belongs in the conversation about what a mid-market AI engagement costs rather than as a surprise in week four. Any competent engagement should surface it in discovery, which is why the diagnostic phase exists at all in the way we structure a build.
When readiness gets over-bought, and the case for starting anyway.
Everything above can be taken too far, and it frequently is. Waiting for pristine data is one of the most effective stalls available to an organization that does not want to change, precisely because it sounds responsible. The data is never going to be clean. If the standard for starting is a state your company has never been in and has no plan to reach, then the standard is functioning as a veto with better manners.
Several kinds of workflow tolerate messy input fine. Anything where a human reviews the output before it takes effect has a built-in error filter, and the cost of a bad input is a few seconds of someone's attention rather than a bad decision reaching a customer. Drafting, summarizing, triage, first-pass classification, and routing all fall in this category. Systems that act autonomously against records, that touch pricing, or that produce numbers a finance team will rely on need much higher input discipline. The tolerance question is about consequence, not about data purity, and sorting workflows by consequence is faster than auditing everything.
There is also the argument for a pilot as a diagnostic instrument. A small scoped build against real data will teach you more about what your records actually contain than any amount of upfront assessment, because assessments read schemas and summaries while a build reads rows. Discovering in three weeks and for a contained cost that the completion rate on a key field is fifty-five percent is a good outcome, as long as the pilot was designed to surface that rather than to prove a foregone conclusion. That framing matters, because a pilot run as a demo produces theater, and a pilot run as an experiment produces information. The difference between those two is a recurring theme in why mid-market AI rollouts stall in month four.
So run the short version of the check and then move. Name one workflow rather than a category. List every input it reads and where each one lives. Pull fifty real records and look at them with your own eyes, because summaries hide what raw rows reveal. Check whether identifiers line up across systems on those fifty. Ask for the completion rate on the three or four fields the decision turns on. Find out who has to approve read access and how long that takes. Confirm whether a historical record exists to baseline against. That is a few days of work for someone internal, and it costs nothing compared to finding out in week four.
Then take the list to whoever you are considering hiring and ask them to sort it into two piles: what blocks the build, and what only limits the first version. Blocking items are the ones where the system cannot function correctly without a fix, which is a short list, usually identifiers, access, and any field the core logic requires that is mostly empty. Limiting items are everything else, and they shape a narrower version one that gets better as the data does. A vendor who cannot separate those two categories has not looked at your data seriously, and finding that out before a signature is worth more than the check itself.