The pilot worked. That was the point the VP of Engineering was making, and the data supported him. The model performed at 91% accuracy on the test set. The user satisfaction scores from the pilot group were strong. The business case had been built, reviewed, and signed off. The ask was simple: scale it from one team to the full organization.
Two weeks later, the data team came back with a list.
Fourteen source systems feeding the data the model would need. Six different schemas — some overlapping, some contradictory, one completely undocumented because the person who built it left in 2021. Three teams with competing ownership claims over the same dataset, none of whom trusted each other’s pipelines. A data governance policy last updated in 2019 that hadn’t contemplated AI use cases. And a question nobody had thought to ask during the pilot: the pilot had used a clean, manually curated dataset. Production would not.
The meeting ended without a timeline. The pilot results went into a slide deck that got updated to say “scaling in progress.”
The Constraint McKinsey Named
McKinsey’s June 2026 analysis of enterprise AI scaling named data readiness as the primary constraint for companies trying to move from pilot to production at scale. Not model quality. Not compute costs. Not organizational resistance or change management. Data.
This finding is both obvious and persistently underestimated. It’s obvious in retrospect — of course a model trained on clean pilot data doesn’t generalize to messy production data; of course scaling requires data infrastructure that most enterprises haven’t built. It’s underestimated because data quality is invisible until it breaks something. In the pilot, it didn’t break anything. The pilot was designed to succeed. Production is not.
The pattern McKinsey describes is consistent: organizations build their AI strategy on an implicit assumption that their data is “good enough.” The assumption gets tested when they try to scale. It usually fails. The failure is expensive — not just in direct costs, but in the six to eighteen months of data remediation work that delays the ROI the business case promised.
What Data Readiness Actually Means
The term gets used loosely, which is part of the problem. Data readiness for AI is not the same as having a data warehouse. It’s not the same as running analytics. It’s not even the same as having good BI infrastructure. AI systems have specific and demanding requirements that most enterprise data estates weren’t built to satisfy.
Structured vs. unstructured. Most enterprise AI use cases involve unstructured data: documents, emails, support tickets, meeting transcripts, contracts, customer feedback. Most enterprise data infrastructure was built for structured data: rows, columns, schemas, relational databases. Bridging that gap requires more than a new pipeline — it requires decisions about what unstructured content to ingest, how to clean and classify it, and how to maintain it over time.
Governed vs. wild. Governed data has known provenance: you know where it came from, who owns it, when it was last validated, and what transformations were applied to it. Wild data doesn’t — it’s the spreadsheet someone exports from a third-party tool, the database that was migrated three times and lost some provenance along the way, the data sitting in a system that IT has marked as “legacy” and nobody has formally decommissioned. AI models trained on wild data produce outputs with unknown reliability characteristics. Most enterprises have more wild data than they think.
Reusable vs. one-off. Pilot data is usually one-off: assembled for the purpose, cleaned for the purpose, validated for the purpose. Scaling requires reusable data pipelines — ones that pull from authoritative sources, apply consistent transformations, and produce outputs that any AI application can consume without custom work. Building reusable pipelines is a different engineering investment than building a pilot dataset, and it’s one that requires treating data as infrastructure rather than as a project artifact.
The Audit That Precedes Everything Else
Before any data readiness initiative can be meaningful, organizations need to know what they have. This is the data estate audit, and it is less common than it should be.
The audit covers: what data systems exist, including shadow systems and SaaS tools that contain business-critical data but aren’t formally managed; what data those systems contain, including whether it’s documented and who maintains the documentation; who owns each dataset, with a definition of “owns” that includes accountability for quality and fitness for purpose; what the quality profile of each dataset actually is, not by assumption but by measurement; and what governance policies apply to each dataset, including data residency requirements, retention schedules, and access controls.
Most organizations have done portions of this. Almost none have done all of it. The gaps are where the scaling failures hide.
Ownership as the Structural Problem
Data quality failures at scale are almost never caused by a lack of tools or a lack of budget. They’re caused by unclear ownership. When nobody is accountable for a dataset’s fitness for purpose, nobody invests in maintaining it. When a dataset is used across multiple teams with different requirements, nobody has the authority to make quality decisions that affect all of them. When the source system is managed by a vendor, neither IT nor the business has full control over what the data looks like or when it changes.
Establishing data ownership with teeth — not just a name in a RACI chart, but a person with authority, budget, and accountability for a dataset’s quality — is the structural change that precedes everything else in data readiness. It’s also the change most organizations resist most fiercely, because it requires resolving the political conflicts that undocumented joint ownership has allowed everyone to avoid.
The CTO who wants to accelerate AI scaling has a data governance problem before they have a data engineering problem. The governance problem is harder and costs more political capital. It’s also the only lever that produces lasting change rather than a one-time cleanup that degrades again in 18 months.
Building Reusable Pipelines
The technical work of data readiness is real, and it’s worth being specific about what it entails. Reusable pipelines for AI workloads typically require: source system integrations that are durable and monitored (not brittle ETL scripts that break when a schema changes), data quality checks at ingestion that catch problems before they propagate downstream, a feature store or similar architecture that makes transformed and validated features available across AI applications without redundant work, and a lineage system that tracks where data came from so that when something is wrong, the source can be traced.
None of this is novel. Data engineering as a discipline has the tools. The gap is not technical — it’s that the investment required to build this infrastructure is hard to justify against a pilot budget and easy to justify against a scaling budget, which means most organizations discover they need it at exactly the moment they’re already behind.
The implication for VPs of Data and CTOs considering AI scaling: the pipeline work should start before the models are ready, not after. Data infrastructure is the long lead-time item. Models are increasingly commoditized. The organization that starts data infrastructure work six months before it needs to scale will have a materially different experience than the one that starts it when the business is asking why the pilot results aren’t generalizing.
Data as Infrastructure, Not Artifact
The deepest mindset shift required is one that most organizations haven’t made: treating data as infrastructure rather than as a byproduct of other work.
When data is an artifact, it’s produced in the course of running the business, stored somewhere, and accessed when needed. Maintenance happens reactively. Quality is assumed until something breaks. Ownership is diffuse because the data is incidental — it’s a log of what happened, not a thing someone built.
When data is infrastructure, it’s designed, owned, maintained, and invested in with the same intentionality as software infrastructure. It has SLAs. It has owners accountable for its quality. It has a roadmap. It has a budget that reflects its strategic importance. The people who maintain it are recognized as building something the rest of the organization depends on — not doing administrative work that happens to involve databases.
The AI race is not being won by the company with the best model access or the largest compute budget. It’s being won by the company that started treating data as infrastructure two or three years ago, when the investment was hard to justify and the payoff was invisible. Those organizations are scaling now. The ones still running data cleanup projects are discovering what the real bottleneck was.