Scaling AI Shouldn’t Mean Rebuilding Data Foundations Every Time

The 2027 planning season is right around the corner for enterprises, and AI investments are once again at the top of C-suite conversations. Akeneo’s recent survey of IT decision-makers showed 93% reported productivity gains from AI, yet 43% said AI has also added new responsibilities to their roles.
These findings highlight the significant amount of groundwork required to bring AI projects to life. Data preparation, in particular, represents a substantial part of that work. Among IT leaders Akeneo surveyed, 36% said their organizations spend more than half of the total effort on an AI project preparing data. Another 53% reported spending between 26% and 50% of their AI project effort on data preparation. While this preparation is necessary, the opportunity lies in ensuring that the work completed for one AI deployment can be reused to support the next.
AI may eliminate work in one part of the business, while creating a different set of tasks for IT teams as they prepare data and rebuild context for each new deployment. The opportunity now is to make more of that work reusable, so each deployment builds on the last instead of starting from scratch.
Humans remain central to all AI pilots and deployments. IT teams are embedded throughout the lifecycle of new technologies, from understanding business needs and evaluating solutions to implementation, training, process development, and ongoing security. Over time, teams may fail to document the exceptions and unwritten rules they encounter, including instances where the same term is defined differently across systems. That context often becomes institutional knowledge held by individual team members rather than information the broader organization can reliably access.
This work can continue until the person with knowledge of the answer is unavailable. When employees change roles, leave the organization, or simply aren’t available when a problem arises, the context is gone. Capturing that knowledge in a structured, digitally accessible format makes it available beyond any one person. It also allows individual teams to maintain ownership of their expertise while ensuring that knowledge can be accessed and reused across the organization, rather than rediscovered with every new deployment.
It is tempting to describe all of this as another data-quality problem, but Akeneo’s research suggests something more complex. 92% of IT leaders rate the product and operational data used by their AI systems as good or excellent. Even though the vast majority spend more than a quarter of an AI project’s total effort preparing data.
Good data does not guarantee it is AI-ready, particularly because what qualifies as “good” can depend on who or what is consuming it. Models and agents need more than accurate information. They need to understand where data comes from, how it relates to other information, which source takes priority, and under what conditions it can be used. These rules can be easy to overlook because they are often implicit in how experienced teams already work.
McKinsey’s recent research on AI data readiness makes a similar point about context. Not all information will be valuable to models or agents. But when information is valuable, its context must be transmissible. Once information moves beyond its original source, its origins and relationships to surrounding data must remain clear so its meaning is not lost.
This is where the architecture behind AI starts to matter just as much as the model itself. Unlike traditional software, LLMs can often work across fragmented data and disconnected systems, even when information is structured or labeled differently across sources. They can identify relationships that may not have been explicitly defined before. The bigger challenge is the absence of data altogether. As models and agents work across systems, the information and context they need must exist and be accessible in the first place.
PwC’s 2026 research on the AI execution gap found that integration remains the leading reason technology investments fall short of expectations. Connecting a wide web of unstructured data takes time, often slowing projects before they reach full deployment.
The work required to solve those problems for one implementation can make the next implementation easier.
For one AI project, much of that preparation can happen behind the scenes. IT teams resolve inconsistencies, prepare the information an application needs, and integrate the application with other systems to move the project into production.
The problem is when that work only solves the immediate use case. Data preparation will always be part of AI deployment, but much of that effort should carry forward. If a team discovers that the same field or term has different meanings across two systems, resolving the ambiguity should create a definition future applications can reuse. If they determine which source should be trusted when systems disagree, that decision should continue to futu