If I could put one sentence on a poster in every executive corridor, it would be this: your AI is only as good as the data it can reach, trust, and legally use. Every word in that sentence is load-bearing, and organisations fail on each of them in turn. Data the model cannot reach. Data nobody trusts. Data you were never permitted to use that way.
The industry has finally, painfully, internalised this. The 2026 consensus across every major survey and vendor report is the same: the bottleneck in enterprise AI is no longer model capability, it is data readiness. Analysts describing the new wave of agent-oriented data platforms put it memorably: without a grounded data layer, agents are “fast but blind.” And the outcome gap is not subtle. Analysis across more than 20,000 organisations found that those with proper data infrastructure and governance pushed roughly 12 times more AI projects into production than those without.
Twelve times is not an optimisation. It is the difference between a programme and a graveyard. So before this track discusses vendors, roadmaps, or agents, we are going to spend this article, and the four after it, on data. This one covers readiness: what it actually means, how to assess it per use case, and how to fix gaps in the right order.
What data readiness actually means
“Data readiness” gets used as a vague synonym for “data quality,” which undersells it badly. Readiness is a relationship between a specific dataset and a specific use. The same customer table can be perfectly ready for a churn model and completely unready for a customer-facing agent, because the two uses have different requirements for freshness, permission, and completeness.
I assess readiness across six dimensions, and Figure 1 shows them as the checklist I run for every candidate use case.
Accessible. Can the AI system actually reach the data through a supported, secure path? Not “it exists in a system somewhere.” Reachable, with authentication your security team will sign off, at the latency the use case needs. Agents raise the bar here sharply: an agent that needs to check inventory, pricing, and customer history mid-task needs live, integrated access across three systems, not a monthly extract.
Accurate. Is the data correct, and do the people who know it best say so? Accuracy is discovered by asking the domain experts embarrassing questions, not by reading the schema. Every organisation has a table that is officially authoritative and unofficially wrong.
Complete. Are the fields the use case depends on actually populated? A claims-triage model trained on records where the injury description is blank 40% of the time will learn to be confidently useless 40% of the time.
Fresh. Is the data current enough for the decision being made? Overnight batch is fine for a monthly forecast and disqualifying for an agent rebooking a flight.
Permitted. Are you allowed to use this data for this purpose? Consent, contracts, privacy law, and data residency all bite here, and they bite hardest late in a project when the redesign is most expensive. Permission review belongs at the start, on the strategy canvas, not in the pre-launch scramble.
Understood. Does documentation exist that a new team could use? Field definitions, lineage, known quirks. Undocumented data is a dependency on the memory of specific employees, which is a resignation letter away from being no data at all.
Run every priority use case through the six dimensions in Figure 1 and score each red, amber, or green. The exercise takes days, not months, and it converts “our data isn’t great” (unactionable) into “the triage use case is blocked on completeness and permission” (a plan).
Why unready data kills projects the way it does
It is worth understanding the failure mechanics, because they explain why data problems so often masquerade as AI problems.
Root-cause analysis of AI deployments that reported negative ROI at twelve months attributes about a third of failures to insufficient tool or data access, alongside unclear success criteria and evaluation gaps. Almost none trace to model quality. The pattern on the ground looks like this: the pilot works beautifully because someone hand-curated a clean dataset for it. Production arrives, the model meets the real data, and quality collapses. The team blames the model, swaps vendors, and repeats. I have watched this loop consume eighteen months and three vendors before anyone examined the data.
The agentic shift makes the stakes higher again. A chatbot grounded in stale data gives a wrong answer, which a human can catch. An agent grounded in stale data takes a wrong action: refunds the wrong amount, orders against phantom inventory, emails the wrong customer. Enterprises repeatedly name data confidentiality, system context limits, and verification gaps among their chief blockers to agent deployment. Every one of those is a readiness dimension wearing a different name.
This is also why readiness must be assessed per use case rather than as a global grade. Global data programmes (“fix all the data everywhere”) take years, cost fortunes, and usually stall. Use-case-scoped readiness (“make these four tables green for this workflow”) delivers in weeks and creates value that funds the next increment.
The readiness assessment in practice
Here is the process I recommend, sized for an organisation doing this seriously for the first time.
Step one: inventory against the portfolio. Take your top five use cases from the strategy canvas. For each, list the datasets it depends on. Be concrete: systems, tables, fields. This step alone surfaces surprises; teams routinely discover a “simple” use case touches nine systems.
Step two: score the six dimensions. For each dataset, score accessible, accurate, complete, fresh, permitted, and understood. Get the scores from the people who work with the data daily, not from architecture diagrams. Diagrams describe intent; practitioners describe reality.
Step three: identify the binding constraint. Each use case usually has one or two dimensions doing most of the blocking. Fixing the binding constraint first is basic theory-of-constraints discipline, and it is astonishing how often programmes instead fix whatever is easiest.
Step four: estimate the fix, honestly. Some gaps are days of work (documentation, an API grant). Some are quarters (consolidating two CRMs). Some are strategic programmes (a data platform migration). The estimate feeds the sequencing decision: use cases with cheap fixes move up the roadmap, and use cases blocked by strategic gaps either wait or get redesigned to need less.
Figure 2 shows this flow, from portfolio to scored assessment to a sequenced fix list.
The output that matters from Figure 2 is the last box: a fix list ordered by value unblocked per unit of effort. That ordering is the bridge between data work and business outcomes, and it is what earns data investment its budget. “We need data quality funding” loses in a budget meeting. “These three fixes unblock the two use cases worth $4M” wins.
Fixing gaps without boiling the ocean
A few hard-won principles for the remediation itself.
Fix forward, not backward. Cleaning ten years of historical records is usually poor value compared with fixing the process that creates dirty records. Stop the leak before mopping the floor. Historical cleanup earns its cost only where models genuinely need the history.
Make readiness a product requirement, not a project phase. The organisations in the 12x cohort treat data readiness as continuously maintained, with owners, monitoring, and quality checks wired into pipelines. One-off cleanup projects decay within quarters; owned datasets stay green. The ownership question is big enough that it gets its own article later in this track.
Buy down permission risk early. Legal and privacy review of intended data use should happen at portfolio time. It is the cheapest point in the lifecycle to discover you cannot use the data, and the review often improves the design: minimising fields, aggregating where possible, choosing consented sources.
Instrument freshness and completeness. These two dimensions decay silently. A pipeline that starts dropping a field will not announce itself; your model’s slow degradation will. Cheap automated checks on volume, nulls, and latency catch most of it.
Readiness as competitive advantage
Let me end with the strategic reframe, because “data readiness” sounds like homework and it deserves better.
Model capability is now broadly available to everyone at similar prices. Your competitors call the same APIs and download the same open weights you do. What they cannot buy is your data in a usable state. In a world of commoditised models, readiness is the differentiator, which is exactly what the 2026 production statistics show: the winners are not running better models, they are running the same models against better-prepared data, and shipping 12x more because of it.
The clients and organisations that move fastest are consistently the ones that invested in readiness before deploying agents, not after. The sequence matters. Done in the right order, each ready dataset compounds: the tables you prepared for use case one accelerate use cases two through five.
The next article stays on data but shifts from readiness to rules: data governance for the AI era, and why the governance conversation changed completely once models started training on, retrieving from, and acting upon your data.