Data quality and availability must be fixed. But Agentic AI also requires a connection to business context.
Ask most enterprise technology leaders about their biggest obstacle to AI, and the answer is data. The data isn’t clean enough, accessible enough, or consistent enough to feed AI with confidence. They’re right. Data quality and availability remain the number one challenge Lopez Research hears from enterprises deploying AI.
But fixing the existing data problem alone won’t get you there. There’s a second data problem that has to be addressed in parallel, and most organizations aren’t thinking about it yet: business context.
Context is the difference between AI that has data and AI that understands your business. Clean data tells AI what the numbers say. Business context tells AI what they mean — which customers have contractual guarantees, which products are strategic, and what trade-offs are acceptable under pressure. Without it, AI optimizes for the wrong thing, at speed.
These are not sequential problems. You can’t fix data quality first, then worry about context later. As Irfan Khan, President and Chief Product Officer for SAP Data and Analytics, put it at a recent virtual summit on data and AI strategy: “AI is incredibly good at producing results. It moves fast, but without context, it can’t exercise good judgment, and good judgment is what creates return on investment for the business. Speed without judgment doesn’t help.”
I attended that summit to understand how enterprise leaders are thinking about both problems — and what changes they decided were required. Three companies shared their experiences: Ericsson, Vodafone, and Google. Their challenges were different. Their conclusions pointed in the same direction.
Two Problems, One Strategy
For years, enterprise data strategies focused on a familiar cycle: extract data, land it in a centralized system or dashboard, and run reports. It worked decently, but not great, for analytics. It is not working for AI.
The first problem — data quality and availability — has always existed. AI makes it more urgent. Models trained or grounded on inaccurate, incomplete, or inconsistent data produce outputs that are inaccurate, incomplete, or inconsistent. Between 60% and 80% of AI budgets go to data preparation, according to various research reports.
The second problem is less urgent. Traditional data architectures were designed to capture what happened in the past and surface it for human interpretation. AI is different. It acts. An agentic system making autonomous decisions on behalf of the business needs to know more than what the data says. It needs to understand the business’s values, the rules, and the trade-offs. Business context is not something most data architectures were designed to preserve or carry.
Khan described the stakes with a supply chain example. Two companies both use AI to manage disruptions. The first feeds it raw signals such as inventory levels, lead times, and supplier scores. The second adds context across business processes, policies, and metadata: which products are strategic, which customers need to be prioritized, and what trade-offs are acceptable under pressure. His summary was direct: “Without context, AI doesn’t know this customer is flagged as strategic. It doesn’t know their lifetime value, whether substitutions are allowed, or when to expedite, so it calculates differently, and the decision changes completely. Both systems move very quickly, but only one moves in the right direction.”
The implication for enterprise leaders is practical. As you work through modernization tasks such as cleaning, consolidating, and governing, data stewards must simultaneously ask how business meaning will travel with that data.
Ericsson: Built for Analytics, Not for AI
Malin Persson, CIO and Head of Enterprise IT at Ericsson, described a data architecture that had served the company well for years — and then hit a wall when AI entered the picture.
Ericsson’s traditional setup had three layers: data creation, data analysis, and analytics. For reporting and dashboards, it worked. For AI, Persson identified three specific points of failure.
Context was locked inside individual systems. Business meaning — embedded in application-specific models, calculations, and system-specific rules — couldn’t travel across applications. “AI operates across systems,” Persson explained. “When context is trapped inside them, AI can only stitch together partial truths.”
The architecture was designed to capture the past, not support decisions about the present. AI needs to judge information and take action on the company’s behalf. A system built to explain historical data is not built for that.
Every AI initiative required rebuilding the same logic from scratch. Without governed data products, each use case started at zero — recreating models, assumptions, and definitions that had already been built elsewhere. “Without data products,” Persson said, “every AI use case required recreating models, logic and assumptions from scratch, which made scaling slow, expensive, and unsustainable.”
Her summary was blunt: “We did not have a data foundation built for AI.”
Ericsson’s response was to redesign its data strategy around three shifts: preserving business meaning in a knowledge core, scaling it through governed data products, and connecting it across an open architecture. The approach allows data to stay where it lives, across SAP and non-SAP systems, while business context is managed centrally. Persson described the principle: you define what revenue means, how hierarchies roll up across markets, which rules apply — once, centrally — and that context stays consistent as data moves across platforms.
The data and context problems were addressed together. That was a deliberate choice.
Vodafone: Available Data, Inconsistent Meaning
Ricard Rovira, Head of Corporate IT Platforms at Vodafone, described a common challenge in large enterprises that have grown through mergers and acquisitions: plenty of data, but no shared understanding of what it means.
As Vodafone expanded across markets, each acquisition brought its own systems, local processes, regulatory requirements, and KPI definitions. The data existed. The problem was that the same business concept was defined differently depending on which system or market you asked.
The practical consequence was one most enterprise technology leaders will recognize. Teams spent disproportionate time reconciling numbers and explaining why two reports produced different figures, rather than acting on the data. Time to insight stretched. Confidence in the output eroded. End users stopped trusting the systems and started downloading data to build their own versions of the truth.
The loyalty section of the My Vodafone app made the problem concrete. The same capability was running across five markets with five separate data models, five dashboards, and 40 report pages. Each market had its own reality. There was no shared one.
The fix wasn’t just cleaner data. It was consistent meaning. Vodafone built a unified semantic layer, which is a single place where business definitions are established once and consistently carried across processes, platforms, and use cases. Rovira described the goal plainly: “Governance is not about control. It’s about preserving the business meaning so it can be reused safely across the enterprise.”
The company consolidated onto SAP Datasphere and Business Data Cloud, reducing its data footprint by 80 percent on its first Business Warehouse instance. The shift moved teams from reassembling data repeatedly to drawing from governed data products that already carry the right definitions and constraints. Time to insight improved. So did confidence in the output.
Vodafone’s case illustrates a version of the data problem that often goes undiagnosed. The data is available. The data is not inaccurate in the traditional sense. The data’s meaning is inconsistent, which, in itself, is a form of bad data. For AI systems that act on it autonomously, the consequences are worse than a wrong number in a report. Google faced the same core problem. The cause was different.
Google: The Culture Problem Underneath the Data Problem
Jannie Affeld, VP of Finance Systems and ERP at Google, described the same symptom Vodafone experienced — the same data carrying different meanings across the organization — but traced it to a different root cause. At Vodafone, fragmented meaning arose from mergers and acquisitions, with incompatible systems layered over time. At Google, it came from its innovation culture.
Google operates across more than 200 data centers and offices on six continents, structured by product areas each large enough to function as a standalone global enterprise. The culture has long rewarded individual autonomy within product areas. Teams built their own solutions and defined the same business data differently. The result looked familiar: ten definitions of headcount, multiple approaches to foreign exchange transactions, no single version of the truth that anyone trusted.
“Technology alone isn’t enough for AI to truly scale,” Affeld said. “Culture must be a significant part of that equation.”
The data consequence was proliferating definitions. Ten definitions of headcount. Multiple approaches to foreign exchange transactions. When definitions multiply, you don’t have a data quality problem in the traditional sense. You have an alignment problem. And alignment problems do not get fixed by better pipelines or more sophisticated models.
Affeld described what the fix actually requires: “We actually have to take away some of the access or freedom to create solutions. We’re trying to segregate what is business data from product innovation. We shouldn’t have 10 definitions of headcount in the organization.” Getting there requires sponsorship from both the business side and finance partners — not just a mandate from IT.
This is a point most data modernization programs underestimate. The data governance conversation tends to focus on architecture and tooling. Google’s experience suggests that the harder work is getting the business to agree on what the data should mean, and then holding that line as teams accustomed to building independently push back.
For AI, the stakes of this organizational work are higher than they were for analytics. A dashboard with an inconsistent definition of headcount produces a wrong number that a human might catch. An AI agent making workforce decisions based on ten competing definitions produces confidently wrong autonomous actions that are harder to detect and harder to reverse.
What All Three Companies Have in Common
Ericsson, Vodafone, and Google came to the AI-readiness problem from different starting points. Ericsson’s challenge was architectural: context locked inside systems, no reusable data products, a foundation built for the past. Vodafone’s challenge was semantic. It had data available everywhere, meaning consistent nowhere. Google’s challenge was cultural: an organization that rewarded independence, producing data that couldn’t be shared with confidence.
But all three arrived at the same conclusion: fixing the data problem and establishing business context are not sequential steps. They are parallel workstreams.
You cannot finish cleaning and governing your data and then turn to context. By the time the data is clean, AI deployments are already in motion. Context has to be built into the architecture from the beginning, into how data products are defined, how semantics are governed, and how meaning is preserved as data moves across systems.
That is a meaningful shift from how most enterprises have approached data modernization. The question is no longer only “how do we make our data more accurate and accessible?” It is “how do we make sure our data carries the business understanding AI needs to act on our behalf?”
Where to Start
If you are in the middle of a data modernization program or about to start one, three questions are worth adding to the agenda.
Are you addressing both problems at once? Data quality and business context are separate challenges that require parallel effort. A data modernization program that focuses only on cleanliness and availability will produce better-quality inputs for AI, but it still lacks the judgment to use them well.
Where is business meaning living today, and can it travel? In most organizations, meaning is embedded in individual applications. It doesn’t survive when data moves. Identify the definitions, policies, and semantic rules that matter most for AI decision-making and decide how they will be captured and carried consistently. Some firms are calling this a context library.
Is this a leadership issue or an IT issue? Google’s experience suggests it has to be both. IT can build the architecture. Business leaders have to agree on what the data means and defend those definitions against teams accustomed to building their own. That requires sponsorship, not just tooling.
More than a decade ago, in my book Right-Time Experiences, I wrote about the importance of context in creating experiences that are adaptive, predictive, and prescriptive. It wasn’t a new concept, but mobility was the catalyst to drive that change. Companies made significant progress, especially as we moved into the early days of machine learning. But very few organizations today can say business context flows coherently across the systems that run their operations.
Agentic AI has made that gap consequential in a new way. When a human reads a dashboard with missing context, they can compensate for it. When an AI agent acts on data without context, the error compounds automatically, at scale, without a flag.
Fix the data. Build the context. Do both at the same time.
Subscribe to my AI Decoded Newsletter here and share with a friend. You can also find the AI with Maribel Lopez podcast on your channel of choice by clicking here.
Lopez Research 