Data Readiness: The Prerequisite Most AI Projects Skip

Data readiness is measured by whether your data is accessible, labelled consistently, current, and clearly governed — not simply by whether it exists somewhere in a database. Skipping this check is the single most common reason a promising AI pilot stalls once it meets real production data, and it's discovered far too often mid-project rather than before scoping.

Why "We Have the Data" Isn't the Same as "It's Ready"

It's the sentence that kills more AI timelines than any technical limitation: "we have the data." Nearly every organisation does, in the sense that the information exists somewhere — a CRM, an ERP, a stack of spreadsheets, a data warehouse nobody has fully documented. What that sentence almost never means is that the data is accessible in a usable format, consistently labelled, current enough to be useful, and governed clearly enough that someone can authorise an AI system to use it. Those four gaps are what data readiness actually measures, and they are almost always discovered mid-project rather than diagnosed up front.

We've walked into projects where the data existed in three different systems with three different customer ID schemes and no reliable way to join them; where the "current" sales data was a monthly batch export that lagged reality by weeks; and where nobody on the client side could confirm whether customer data could legally be used for the intended AI use case without a privacy review that hadn't even started. None of these are AI problems. They're data and process problems that AI simply exposes.

The Four Dimensions That Actually Determine Readiness

Access asks a blunt question: can the system that needs this data actually get to it, in a reasonable timeframe, without a person manually exporting a spreadsheet every week? A dataset that only lives in someone's inbox as a monthly attachment is not ready, regardless of how clean it is. Quality asks whether the same entity — a customer, a product, an order — is labelled consistently across every source system involved, and how many records have missing or clearly wrong values in the fields the model actually depends on.

Freshness asks how stale the data is by the time it reaches the system that needs it — a model making decisions on data that's weeks old will behave very differently than the pilot that was tested against a curated recent snapshot. Governance asks whether there's a named owner who can authorise this specific use of this data, and whether a privacy or compliance review has actually happened rather than been assumed unnecessary. Any one of these four gaps, left unaddressed, is enough to derail a project that looked technically sound in every other respect.

The Data Readiness Checklist

• Can the target system query this data directly, without a person manually exporting it each time?
• Is the same entity — customer, product, order — labelled consistently across every source system involved?
• How stale is the data by the time it reaches the system: hours, days, or a monthly batch?
• Is there a named owner who can authorise this data's use for this specific purpose?
• Has a privacy or compliance review actually happened, not just been assumed unnecessary?
• What percentage of records have missing or clearly wrong values in the fields the model depends on?

Fixing Readiness Gaps Without Stalling the Whole Project

The instinct on discovering a readiness gap is often to treat it as a reason to pause the entire AI initiative until the data estate is perfectly clean — that's rarely necessary and usually the wrong call. Scope the fix to the minimum viable readiness for the specific use case in front of you: if the pilot only needs three fields from one system, get those three fields genuinely reliable rather than launching a company-wide data-cleaning programme. Treat the readiness audit itself as a deliverable that happens before timeline and budget get finalised, not a footnote discovered halfway through a sprint.

This scoping discipline is also what keeps data engineering from turning into an open-ended, unbudgeted line item that swallows the whole project timeline. Data engineering work has a well-earned reputation for expanding to fill whatever time is available, precisely because every dataset touches other datasets, and "just fix this one field" often reveals three more fields worth fixing behind it. Drawing a hard boundary around what the current use case actually requires — and explicitly deferring the rest to a documented backlog rather than an implicit scope creep — is what keeps a readiness fix a two-week task instead of a two-quarter one.

It also helps to name a single accountable owner for the readiness fix itself, distinct from the AI project's technical lead. Data readiness work tends to touch systems and teams outside the AI project's direct control — a CRM owned by sales operations, an ERP owned by finance — and without a named owner empowered to chase those dependencies, readiness fixes are the first thing that quietly slips when competing priorities show up.

The practical move is a short, focused readiness audit — typically a week or two, not months — run before any model work begins, covering exactly the data the specific use case depends on. It's a small time investment that reliably prevents the much larger one of discovering, three sprints in, that the data was never actually ready for what the project assumed.