"AI-ready" has become one of those phrases that gets used in every pitch and defined in none of them. A vendor puts it on a slide next to a dashboard screenshot, a consultancy puts it in a proposal, and nobody in the room stops to ask what it would actually take to be ready, because the phrase is doing its job either way. It sounds like due diligence without requiring anyone to do any.
Ask five people in the same business what it means and you'll get five different answers: a bigger dataset, a data warehouse, sign-off from IT, a licence for the right platform. None of those is entirely wrong, and none of them is the answer either. Strip the phrase back to what it's actually asking and it's a plain question with an uncomfortable answer for most organisations: if you pointed a model at this data today and let it act on what it found, would you trust the result? For the large majority, honestly asked, the answer is no, not because the model is lacking, but because the data was never built to survive being looked at that closely by something that doesn't know when to stop and check with a colleague.
Garbage in, confident-sounding garbage out
The old warning about computers was garbage in, garbage out. The AI version is worse, because what comes out the other side is fluent, well-formatted and entirely convincing. A spreadsheet with a duplicated customer record just sits there being duplicated, inert, until someone notices. A model summarising or acting on that same record states the duplicate as fact, in exactly the same confident register it uses for everything it gets right, with no visible seam between the two.
That's the mechanism worth understanding before any project starts: a model has no institutional memory of which fields to distrust. It doesn't know the "status" column means something different in three regional offices, or that the free-text notes field has been used for four unrelated purposes since whichever reorganisation left it that way. To the model it's a column with values in it, and it produces the most plausible-sounding answer from whatever it's given, every time. A person who's worked with that spreadsheet for years catches the duplicate out of habit. A model catches nothing. It amplifies whatever quality was already there, at a speed and confidence that used to belong only to the correct answers.
Accessible beats abundant
The instinct, faced with an AI project, is to reach for more data: buy a dataset, switch on more logging, connect another source. That instinct usually points the wrong way. Most enterprises already hold more than enough data to do something useful. What they don't hold is access to it, or agreement on what it means once they've got it.
Access is the duller problem and the one that actually blocks projects: the customer history that lives in a PDF export nobody parses, the pricing logic that exists only in one person's spreadsheet, the exceptions list emailed round every Monday and never saved anywhere a system can query. None of that is unusual (most businesses run some material fraction of themselves this way) but it means the data a model needs is locked in formats built for a person to glance at once, not a system to query repeatedly.
Agreement is the quieter problem. Two teams both have a field called "active customer", and both are certain what it means, and both are wrong about the other's definition. A model fed both without being told they disagree won't flag the conflict. It will pick one, silently, and be equally fluent about the answer either way. Consistency of definition isn't a nice-to-have here; it's the difference between an answer and a coin flip that happens to be well written.
Lineage, and who's allowed to see it
Two more properties matter as much as accessibility, and they get less airtime because they're less visible in a demo. The first is lineage: knowing where a piece of data came from, when it was last verified, and what's been done to it since. A model given a customer's "last verified" address with no sense of whether that check happened last week or five years ago will use it exactly the same way either time. Provenance is what lets a person, or eventually a system, decide how much weight an answer deserves: without it, every output carries the same unearned confidence.
The second is permissioning, and it's the one businesses reach for last, usually after something has already gone wrong. The right question isn't just "can this system access this data": it's "on whose behalf should the model be allowed to see this, and for what purpose". A model that can query the whole customer database to answer a support query needs the same access boundaries a support agent would have, not the access boundaries of whoever happened to set up the integration. Get this wrong and the failure mode isn't a wrong answer: it's a correct one, handed to somebody who should never have been able to ask the question.
You don't need to fix everything first
The myth that stalls more AI projects than bad data ever does: the belief that a business needs a fully governed, cleaned, unified data platform before it can start. That belief is usually sincere, frequently reinforced by whoever is selling the platform, and wrong. It sets the bar at "ready for every use case we might ever have", when the only bar that matters is "ready for this one".
A single, well-chosen use case needs a specific, narrow slice of data to be accessible, consistently defined, traceable and properly permissioned, not the entire estate. An invoice-extraction pilot needs clean invoices and somewhere to put the output; it doesn't need the HR system tidied up first. Treating readiness as an all-or-nothing platform programme is how a three-month proof of value turns into an eighteen-month data programme that never quite finishes, and never quite proves anything either.
A readiness checklist
There's an unexpected upside to all this: taking AI seriously is one of the few things that reliably gets a business to fix data problems it already knew about but had never quite prioritised. "We might feed this to a model" turns out to be a more persuasive argument for finally documenting what a field means than several years of a governance committee asking nicely. Use that. The tidying an AI project forces is tidying the business needed regardless of whether the model ever gets built.
Before committing data to any specific AI use case, it's worth checking it against a short list, not the whole estate, just the slice the project actually touches:
- Accessible in a form a system can query, not a PDF, an inbox, or one person's spreadsheet
- Defined the same way by everyone who touches it, with no silent disagreement over what a field means
- Traceable to its source, with a sense of how current or verified it is
- Permissioned for the specific purpose and audience the model will serve, not just for whichever system currently holds it
- Scoped to the one use case in front of you, not treated as a proxy for the whole data estate
Where to start
Not with a data platform business case, and not with a data quality audit of everything the organisation holds. Start with the use case (the specific process, the specific decision, the specific question the model needs to answer) and work backwards to find out exactly which data it touches and whether that slice meets the bar above.
That's a short, focused discovery exercise rather than a data strategy exercise, and it's how we start every AI engagement, because the readiness gap that matters is the one standing in front of the use case you're actually planning to build, not the one standing in front of every use case you might build one day.
