An AI-ready data foundation is data that meets measurable criteria for quality, availability, governance and context against one named use case, not a company-wide state of perfect data. That distinction decides most AI projects. When one stalls, the model and the platform are usually fine, while the data turns out to be incomplete where it matters, locked behind an owner who never agreed to share it, undocumented, or off limits for the intended purpose. Google researchers who interviewed 53 practitioners building AI in high-stakes domains found that 92% had experienced data cascades: compounding events that start with a data problem and surface as failure much later.
What AI-Ready Data Actually Means, and Why It Is Not an Infrastructure Question
Readiness is a property of data in relation to a purpose. The same customer table can be ready for a churn model that scores accounts monthly and unready for a pricing engine that needs the last hour. So “is our data ready for AI?” has no answer, while “is this data ready for this use case, by this date?” does.
That is also why buying a platform rarely settles it. Infrastructure is the plumbing; this article is about what flows through it. A lakehouse, a vector store and an orchestration layer can be running inside a quarter, and the case for that layer sits in our piece on AI-ready data infrastructure. Readiness cannot be procured, because the data is yours and so are the holes in it. Unlike data hygiene, it has a pass mark, set by what the use case tolerates, so it can be scheduled and closed.
The Evidence: Data Problems Kill AI Projects Before Models Do
The Google Research study behind that 92% defines a data cascade as compounding events causing negative, downstream effects from data issues, and finds them pervasive, delayed in effect and mostly avoidable. The delay is what makes them expensive: the symptom is a model that scores worse in production than in evaluation, so the team works on the model while the cause sits months upstream in a source that started writing nulls instead of zeros.
MIT NANDA points the same way, locating the barrier to value from business GenAI in a learning gap rather than in infrastructure: systems that never integrate with the workflow or adapt to the context around them. Context, in practice, is data and metadata sitting inside the process.
European figures show the pressure earlier in the funnel. Among EU enterprises that considered AI and did not adopt it, Eurostat records a lack of relevant expertise at 70.89%, unclear legal consequences at 52.52% and concerns about data protection and privacy at 48.83%. Two of the three leading brakes are questions about data and its governance.
The Four Dimensions of Data Readiness
Readiness breaks into four dimensions, and a use case can fail on one while scoring well on the other three. A 360-degree survey of data readiness for AI covering more than 140 papers proposes a taxonomy of readiness metrics for structured and unstructured data, and notes that standard metrics are still forming.
Quality and completeness covers accuracy, consistency and coverage of the cases the use case must handle. Coverage is the one teams miss: a dataset can be 99% accurate overall and useless for a rare event, because the rare class is where the missing records concentrate.
The practical test is whether anyone profiled the data itself rather than the catalogue entry describing it: null rates, duplicate keys, out-of-range values, drifted distributions. The practices that fix them are covered in our article on data quality for machine learning.
Availability and access asks whether the people and systems that need the data can read it as often as the use case requires. Projects lose more calendar time here than anywhere else, rarely for technical reasons: another team owns the system and exposing it competes with their own quarter. A one-off export is not availability; something has to read that source on a schedule.
Governance and compliance asks whether you may use this data for this purpose: lawful basis under the GDPR, contractual limits on third-party data, internal permissions, and lineage good enough to explain a decision later. For high-risk systems the EU AI Act makes part of that a documented obligation.
The failure mode is finding the constraint after the model works, usually in the week you planned to launch. The wider subject is covered in our article on data governance for AI.
Context and metadata asks whether the data explains itself: field definitions, units, business rules, what a null means, and which of the four tables called “customer” finance uses. A model cannot infer what the data does not say, and neither can a retrieval system. It is the cheapest dimension to fix and the most often skipped.
Each dimension becomes a question and a gate.
GenAI Changed What “Ready” Means: Unstructured Data Enters the Room
A readiness assessment used to look at tables. Retrieval assistants moved it to documents, wiki pages, tickets and call transcripts, where the same four dimensions need different tests. Version currency comes first: if a superseded travel policy sits in the index beside the current one, retrieval returns whichever matches the query better and the assistant states it with equal confidence. Readiness means one authoritative version per topic.
Deduplication is next, because six near-identical copies of an onboarding deck fill the results with the same evidence six times. Structure matters as much: a page with real headings chunks cleanly, while a scanned PDF whose key table spans a page break produces fragments that mean nothing alone.
Permissions are the hard one. An index flattens whatever it ingests, so unless document-level access is enforced at query time, every user inherits its reading rights. That is how a salary review ends up in an answer about holiday allowance, and the architecture that prevents it is covered in our work on enterprise RAG implementation.
Assessing Readiness: A Use-Case-Scoped Audit, Not a Boil-the-Ocean Programme
The standard response to poor readiness is a multi-year data transformation programme that fixes the estate before the first model ships. It rarely survives a budget cycle, because costs arrive for two years before any value does.
The alternative is narrower. Audit the data that one use case actually reads: list its sources down to field level, score each against the four dimensions, and write down what is missing. With the data owners in the room that takes weeks, not quarters. An audit that only reads the catalogue describes the data as people believe it to be, so profile the tables and open the documents.
The output should not be a verdict, because a grade gives a sponsor nothing to spend money against. A gap list does: the work to close each gap, an estimate in weeks and euros, and whoever owns the source. The business then has three honest options: fund the fix, cut the use case down to what the data supports, or start with one already close.
Closing the Gaps: The Data Work That Unblocks the Use Case
Closing gaps is ordinary engineering; sequencing is the decision that matters. Prioritize by effect on the use case rather than by how bad a defect looks in isolation: a 3% error rate in a field the model never reads is a note for later, while a missing consent flag on the one table it must read is the entire project. Ownership comes next, because most readiness gaps are unowned rather than unknown, and somebody has to answer for what each source promises.
The last shift is from extracts to data products. A one-off export unblocks this quarter and seeds the next cascade: nothing tests it and nobody notices when the upstream schema moves. A data product has a documented interface, tests that fail loudly, a refresh contract and an owner. Building and running those is what data engineering services are for.
The second use case that needs customer data inherits a documented source, an approved purpose, a working access path and a named owner, so its audit finds two gaps instead of nine. An AI-ready data foundation gets built one use case at a time.
Where Data Foundations Meet the AI Programme
At portfolio level, readiness becomes a scheduling rule. Score candidate use cases on data readiness for AI alongside expected value and the running order changes: the case with the third-best return and data that is already close beats the flagship whose data nobody is allowed to read. A failed gate queues that use case behind a named piece of data work with a cost and a date attached. Programmes run this way, including the ones we build inside an enterprise AI Factory, treat readiness as the entry gate to delivery rather than a week-six discovery.
If a project has stalled and the team says the data is bad, make that measurable: pick the use case that matters most, score its data against the four dimensions, and price the gaps. To do that with people who have closed gaps like these before, talk to our data engineering team about scoping a readiness audit.
Frequently Asked Questions
What does AI-ready data actually mean?
AI-ready data meets measurable criteria for quality, availability, governance and context for a specific AI use case. The same table can be ready for a monthly churn model and unready for a pricing engine that needs fresher input, so an AI-ready data foundation is defined per use case rather than company-wide.
How do you assess data readiness for an AI project?
Scope it to one use case, list the sources it reads down to field level, and score each against four dimensions: quality and completeness, availability and access, governance and compliance, and context and metadata. Profile the real data rather than its catalogue description, and report gaps with the cost of closing each.
Do you need perfect data before starting an AI project?
No, and waiting for it is the most reliable way never to start. Readiness is scoped to a use case, so the only question is whether the data that use case reads clears the bar it requires. Most organizations have at least one candidate close enough to deliver.
Is data quality or data access the bigger blocker for AI projects?
Quality gets discussed more; access consumes more calendar time. Quality problems sit in the data, where an engineering team can measure and fix them. Access problems are organizational: another team owns the system and exposing it competes with their roadmap, so the delay is measured in negotiation.
.webp)
