Enterprise AI Doesn't Have an AI Problem. It Has a Business Understanding Problem.

The broader industry has increasingly converged around this challenge. Gartner warns that AI agents require richer semantic context and business meaning if they are to operate accurately and consistently. Microsoft's investments in semantic models and semantic indexing similarly recognize that AI systems must understand business concepts and relationships rather than simply retrieve information. McKinsey's more recent research reaches the same destination from another direction, arguing that AI depends on governed, reusable, traceable business foundations. Although each organization uses different terminology, they are describing the same shift: enterprise AI depends on shared business understanding. (Gartner, 2026; Microsoft, 2025; Microsoft, 2026; McKinsey & Company, 2026)

About the Original McKinsey Research

McKinsey published A Data Leader's Technical Guide to Scaling Gen AI on July 8, 2024, during a period of rapid enterprise experimentation with generative AI. By that point, most large organizations had already run pilots. Many had built at least one impressive demonstration: a document summarizer, a customer service copilot, an internal search assistant. Fewer had managed to move those demonstrations into durable, governed, enterprise-scale production.

McKinsey's authors describe the tension directly. Generative AI held significant potential and had triggered a wave of rapid experimentation and promising pilots. Yet many organizations found it difficult to move from pilot to scale. The reported obstacles were consistent and specific: data-integration challenges across fragmented systems, output inaccuracy that undermined trust in AI-generated answers, and governance risk that made legal, risk and compliance teams understandably cautious about broader deployment. Underlying all of it was a still-maturing understanding, across many organizations, of the data capabilities generative AI actually requires to work reliably at scale.

It is worth being precise about timing here. McKinsey's findings describe the state of enterprise AI adoption as observed in 2024, not the state of the market today. We present them as evidence of the moment the guide was written, and we attribute the reported difficulties to McKinsey's own research and client work at that time.

We believe the article remains relevant, and this is our interpretation rather than a claim McKinsey made in 2024. Many of the technical issues McKinsey identified, fragmented source data, inconsistent governance, ungoverned orchestration, have become more important, not less, as enterprises move from copilots toward AI agents and more autonomous, multi-step workflows. An agent that can take action across systems inherits every weakness in the data and governance beneath it, often with less human review than a copilot receives. The technical guide reads, in hindsight, as an early and accurate description of a problem that has continued to grow with the ambition of enterprise AI itself.

McKinsey's Three-Part Framework

McKinsey's guide is organized around three actions that, taken together, describe a coherent technical strategy for scaling generative AI responsibly. We want to examine each in enough depth to respect the seriousness of the guidance, before turning to what we believe it means for business leaders who will never read the guide in its technical entirety.

Part One: Improve Data at the Source

McKinsey's first recommendation is to improve data quality at its source rather than attempting to compensate for poor inputs downstream. This is not simply a data-cleanliness exercise. The guide describes the risks of poor source data across both structured information, such as financial systems, and unstructured information, such as reports, contracts and internal documents. Generative AI increases the value of combining these two categories of information, because a language model can read unstructured text alongside structured records in ways earlier analytics tools could not. But combining them also increases the potential for error, because unstructured content is harder to validate, harder to trace and easier to misinterpret than a well-defined database field.

McKinsey argues that improving source data requires bringing subject-matter expertise directly into the data-preparation process, since much of the meaning embedded in enterprise information exists in the heads of experienced employees rather than in any system of record. The guide points to techniques such as knowledge graphs, which can encode relationships between business concepts in a way a language model can use as grounded context, and to the careful use of synthetic data where real examples are scarce or sensitive. It also emphasizes lineage and cataloging, tracing where data came from and how it has changed, and the difficult but necessary work of understanding legacy data and legacy code that still runs core enterprise processes.

McKinsey's argument here is that source quality is not strictly a technical cleanliness issue. It affects accuracy, because a model grounded in incomplete or contradictory data will produce incomplete or contradictory answers. It affects risk, because ungoverned or unclear data increases the chance of an output an organization cannot defend. It affects trust, security and explainability, because users and regulators increasingly want to know where an AI-generated answer came from. And it affects reuse, because information that is poorly defined at the source cannot easily be shared across multiple use cases without being redefined each time.

Part Two: Use Generative AI to Accelerate Reusable Data Products

The second action is, in some ways, the most interesting, because it turns generative AI back on the data problem itself. McKinsey argues that reusable data products are central to generating value from data at scale, and that generative AI can meaningfully accelerate the creation of those products. The guide describes generative AI being used for automated transformation of data, pipeline generation, documentation that would otherwise consume significant engineer time, feature engineering, and, in more advanced cases, end-to-end creation of data products against defined target data models that can support multiple use cases rather than a single report.

McKinsey references company examples and productivity figures to illustrate the potential of this approach, including the acceleration of legacy-code analysis and the reduction of manual effort in metadata and cataloging work. We want to be careful here, in keeping with McKinsey's own caveats, not to imply that every organization will achieve identical results. Productivity gains of this kind depend heavily on the starting condition of an organization's data estate, its existing tooling and the discipline of its engineering teams.

We believe reusable data products are not simply an architectural recommendation. They are the operating model through which business knowledge becomes available to every decision, every application and every AI agent. The question is no longer whether organizations should build reusable data products. The real question is how they make those products practical for business teams to create, govern, reuse and continuously improve.

What we find most important in this section of the guide is the distinction it draws, implicitly, between two very different uses of generative AI in data work. One is using AI to generate a single table or a single transformation, a narrow, task-level automation. The other is using AI to help create a coherent, reusable data product, one with a defined owner, a defined meaning, defined quality expectations and the ability to support multiple use cases over time. The first produces convenience. The second produces enterprise capability. McKinsey's guide is unambiguously arguing for the second, and we believe that distinction deserves more attention from business leaders than it typically receives.

Part Three: Scale Through Security, Orchestration and Standards

The third action addresses what happens once an organization moves beyond a handful of pilots. McKinsey examines modularization and reuse, agent-based frameworks, workflow orchestration and coordination, the operational complexity that comes with managing prompts at scale, metadata tagging and catalog enhancement, platform migration, model selection and code translation. It also addresses security at every stage of the pipeline, role-based access controls, and controls that run consistently from ingestion through retrieval and consumption. Coding standards and data-quality rules, applied consistently and understood in organizational context, are presented as prerequisites for scale rather than administrative overhead.

McKinsey's underlying argument is that scale requires consistency. A single pilot can tolerate manual intervention, a workaround here, a bespoke access control there, a one-time review of the output before it reaches a customer. An enterprise running dozens or hundreds of AI applications, and increasingly agents that act with some autonomy, cannot recreate security, context and standards from scratch for each one. Without consistent scaffolding, every new use case becomes its own small project, and the organization's total AI effort grows linearly with the number of use cases rather than compounding as a shared capability.

This is an important bridge to the signal we want to develop in this article. McKinsey is describing, in technical language, why enterprise AI needs an operating model rather than a series of independent projects. We agree with that conclusion. Our contribution is to explain why that operating model is as much a communication challenge as an engineering one.

The Technical Guide Contains a Leadership Message

Read closely, McKinsey's technical guide is saying something important to business leaders, even though it is not written for them. Beneath the detailed recommendations sits a consistent message: AI does not operate independently of enterprise information architecture. The model is only one component. Source data matters. Meaning matters. Context matters. Lineage matters. Security matters. Standards matter. Reuse matters. Organizational knowledge matters. The route to scale is system design, not isolated experimentation.

Very few business leaders will ever read a technical guide like this one in full, and fewer still will recognize themselves in terms such as retrieval-augmented generation, vectorization, knowledge graphs, orchestration, metadata enrichment, synthetic data, medallion architecture, agent frameworks or continuous integration and deployment pipelines. We want to be clear that this is not a criticism of the terms themselves. Each one describes a genuinely important capability, and McKinsey's technical audience needs that precision to do its work.

The problem is not that these terms exist. The problem is that leaders are frequently asked to approve budgets, set strategy, and take accountability for outcomes built on top of these terms without ever being given a translation of what they mean in business consequence. A leader does not need to understand how a vector database indexes text. A leader does need to understand that the AI system making recommendations to customers or employees is only as trustworthy as the information it can see, and that the organization has a specific, describable answer for what that information is, who defined it, and how it is kept current.

The Language Gap in Enterprise AI

This is where my own perspective, shaped by years spent helping markets understand new categories of technology, becomes most useful to this conversation. Markets learn to understand new technologies through language before they understand them through experience. The language a market uses to describe a technology shapes what buyers expect from it, what they measure, what they fund and what they hold leaders accountable for. Language is never a cosmetic layer on top of technology decisions. It is one of the primary mechanisms through which executive action actually happens.

It is also worth being honest about where most organizations actually are. Organizations did not suddenly develop a data problem because AI arrived. They are struggling because, after years of investment in data warehouses, lakehouses, catalogs, governance programs, data transformations and business intelligence initiatives, business users still cannot consistently access trusted information at the point of decision. Business users have struggled with this long before enterprise AI. AI did not create the problem. It exposed an existing business-understanding problem and made solving it far more urgent.

The current language of enterprise AI is dominated by terms that describe capability: model size, prompting technique, automation, productivity, copilots, agents, live demonstrations and generated outputs. These terms are exciting, and they are not wrong. They are simply incomplete. Enterprise leaders are not ultimately accountable for how impressive a demonstration looks. They are accountable for decisions, risk, customer outcomes, operational performance, policy compliance, trust, evidence and the value of the organization's investment. When AI capability is described without connecting it to those responsibilities, a communication gap opens between what leaders are shown and what leaders are actually accountable for.

We do not believe an executive needs every architectural detail McKinsey's guide provides. We do believe an executive needs a working answer to a short set of questions: what information is the AI using, who defined its meaning, whether it is appropriate for the decision at hand, which policies apply to it, who can access it, how it is kept current, how its origin can be traced if something goes wrong, and whether the same context can be reused the next time a similar decision arises. None of these questions require technical fluency. All of them require that someone in the organization has done the underlying technical work McKinsey describes, and translated it into a form a business leader can hold themselves accountable to.

Why Trusted Business Context Is the Better Bridge

We use the phrase trusted business context throughout our work, and we want to define it carefully here rather than treat it as a slogan. Trusted business context is not simply metadata, and it is not simply a data catalog entry. It includes the relevant data itself, the business definitions that give that data meaning, the relationships between different pieces of information, the purpose and intended use of that information, clear ownership, the policies that govern who can see and use it, quality expectations, lineage, the evidence needed to support a decision, and the specific decision context in which the information will be applied.

The value of this phrase is not that it replaces technical architecture. It does not, and it should not try to. Its value is that it gives business, technology and governance teams a shared way to discuss what AI actually needs before it can be trusted with a decision. A chief marketing officer, a chief risk officer and a head of data engineering can all understand what it means for AI to lack trusted business context, even if only one of them could describe how a knowledge graph is constructed. Trusted business context helps leaders understand what the underlying architecture must produce, without requiring them to design that architecture themselves.

At Data Tiles, we believe trusted business context should exist as reusable business-led data products rather than being recreated inside every report, dashboard, application or AI agent. Engineers build enterprise platforms, pipelines and infrastructure. Business experts contribute the definitions, policies, relationships and decision context that give enterprise information its meaning. Business-led data products bring those two disciplines together. Once business context is captured, governed and published as a reusable data product, it becomes immediately available wherever the organization needs to make decisions.

Where McKinsey and Data Tiles Align

It is worth stating plainly where we agree with McKinsey's guide, because our argument in this article builds on that agreement rather than departing from it. We agree that AI value is constrained by data. We agree that reusable data products matter more than isolated outputs. We agree that quality and readiness begin at the source, not downstream of it. We agree that generative AI can meaningfully accelerate the development of data products, when applied with the discipline McKinsey describes. We agree that understanding legacy systems and lineage is a prerequisite for trustworthy AI, not an optional cleanup task. We agree that orchestration and reuse are required for scale, that security cannot be attached only at the end of a process, and that standards must be enforced consistently rather than negotiated project by project. We also agree with McKinsey's implicit conclusion that organizations must improve usability, not simply infrastructure, if any of this technical work is going to reach the people who need to use it.

The Signal We Are Seeing: Enterprise AI Is Becoming a Business-Understanding Problem

Where our interpretation extends beyond McKinsey's technical guide is in how we describe the next constraint on enterprise AI value. The next constraint is not simply whether an agent can retrieve information. It is whether the agent can retrieve the right information, with the correct business meaning attached, the correct policy applied, and the correct decision context understood. Two AI systems can use the exact same underlying model and still produce very different enterprise value, because they are operating over different information environments.

The market has learned how to describe what AI can do. It must now explain what AI needs to understand.

This is our position, not McKinsey's stated conclusion, and we want that distinction to stay clear. The competitive advantage available to organizations investing in generative AI is therefore not only the intelligence of the model they have chosen. It is the organization's own ability to make its business knowledge understandable, trustworthy and reusable by AI. McKinsey explains the engineering discipline this requires. What follows is how organizations operationalize it through a business operating model. Enterprise AI success is not determined only by the intelligence of the agent. It is determined by the quality, governance and business context of the information that agent is allowed to access.

We would add one clarification, because it matters to how leaders prioritize. This is not a future operating model waiting for widespread AI adoption. Organizations need trusted business decisions today. AI simply amplifies the value of solving the underlying business data problem correctly.

Enterprise AI has exposed what was already a business-understanding problem.

Brand, Clarity and Trust

Brand, in an enterprise technology setting, is not simply visual identity or promotional language. At its best, brand is the discipline of creating shared understanding between an organization and the people it needs to convince. That discipline matters more, not less, in categories where the underlying technology is genuinely complex, because complexity creates a natural temptation to oversimplify or to lead only with the most exciting claim.

When organizations describe AI inaccurately or incompletely, the consequences compound quickly. Expectations become distorted, because a leader who is shown only a demonstration assumes the hard work is already done. Leaders invest in the wrong layer, often the model or the interface, when the constraint sits in the data and governance beneath it. Customers struggle to compare solutions, because vendors describe capability in language that obscures rather than reveals what is actually required to make that capability trustworthy. Technical teams inherit unrealistic promises made by people who did not have to build the underlying data foundation. Trust is damaged when pilots cannot scale, and the organization concludes the technology failed, when in fact the information environment around the technology was never built. The data and governance work McKinsey describes in such technical depth is too often treated as a secondary concern rather than the foundation it actually is.

A credible enterprise AI narrative has to explain the whole system: the model, the data, the business context, the governance, the people who own and use the information, the operating model that connects all of it, the decisions it supports, and the outcomes it produces. Leaving any one of these out of the narrative does not make the technology simpler. It only makes the explanation less honest.

From AI Capability to Decision Capability

At Data Tiles, we frame this shift as a move from AI capability to decision capability. AI capability asks whether the system can generate an answer, whether it can summarize a document, whether it can automate a task, whether it can be configured as an agent. These are legitimate and increasingly answerable questions, and vendors have become skilled at demonstrating positive answers to all of them.

Decision capability asks a different set of questions. Is the answer grounded in trusted business information. Is the meaning behind that information understood consistently across the organization. Are the relevant policies active at the point the answer is generated, not applied after the fact. Can the evidence behind the answer be traced if a customer, regulator or auditor asks how it was produced. Can the person accountable for the decision act on the answer while it still changes the outcome. And can the organization reuse the same trusted context the next time a similar decision needs to be made, rather than rebuilding it from scratch.

We believe decision capability is the more meaningful executive conversation, because it is the frame executives are already accountable to. Boards do not ask whether an organization has deployed an impressive model. They ask whether the organization is making better decisions, with acceptable risk, at a pace the business requires.

The Industry Is Converging Around Business Context

When McKinsey published its technical guide to scaling generative AI, much of the industry's attention remained focused on models, infrastructure and retrieval. Since then, the conversation has matured. Gartner increasingly emphasizes semantics and contextual understanding. Microsoft has invested heavily in semantic models and semantic indexing to help enterprise AI interpret organizational information using business meaning rather than keywords alone. McKinsey now emphasizes governed, reusable business foundations capable of supporting analytics, decisions and AI simultaneously. These developments are significant because they demonstrate that the industry is converging around a common requirement: AI becomes more valuable as enterprise understanding becomes more explicit, governed and reusable.

What Data Tiles Is Doing in This Space

We want to describe our own approach honestly, in proportion to the rest of this article, and without suggesting that McKinsey has evaluated or endorsed it in any way.

Organizations do not need another transformation program before they begin creating value. They need a way to activate the data platforms, governance investments and business knowledge they already possess. Latttice acts as the Business Activation Layer for enterprise data, connecting existing enterprise investments to trusted business decisions and AI.

Latttice is our Data Product Workbench. It is a zero-code environment for creating governed, trusted and fit-for-purpose data products, built to connect the platforms and sources organizations already own rather than replace them. It is deliberately not another general-purpose data-storage platform, and it does not ask organizations to begin by moving all of their enterprise data into a new central system. It complements data warehouses, lakehouses, catalogs, governance platforms and cloud platforms. Its purpose is to bring business expertise directly into the creation of data products, to activate governance during creation and consumption rather than after the fact, and to publish reusable products that can support decisions, analytics, applications and AI alike.

Latttice operationalizes many of the principles McKinsey describes by enabling business experts to create governed, reusable data products without relying entirely on traditional technical delivery cycles. The objective is not to replace years of investment in enterprise data platforms. The objective is to activate those investments so the business can finally access trusted information at the point of decision.

That distinction matters most in governance. Governance becomes part of the product itself. Ownership, policy, lineage, security and business meaning travel with every reusable data product wherever it is reused, rather than being recreated each time information is consumed. This dramatically reduces the effort required to scale analytics, applications and AI while increasing trust at the point of decision.

Lenz is our AI Factory, a way to create AI agents using the trusted, governed data products Latttice produces. It is a controlled environment for connecting AI capability to business context, designed to support transparency and governed prompts rather than open-ended access to enterprise data. Lenz is intended as part of a wider AI operating model, not a standalone chatbot proposition.

The operating model is straightforward to describe, even if it takes real engineering discipline to deliver. Latttice creates reusable, governed, business-led data products. Those products already contain business meaning, governance, ownership, lineage and security. Lenz consumes those same products. Every new AI agent therefore begins with the same trusted understanding of the business rather than rebuilding that understanding from scratch, making AI easier to scale while remaining consistent, transparent and governed.

Cameron's Operating-Model Perspective

Cameron Price, our CEO and Founder, has been consistent in arguing that the market has already learned how to build intelligent agents, and must now learn how to build intelligent organizations. His view is that the hard part of enterprise AI is not the first agent. Most organizations can build one capable agent, particularly with the platforms available today. The hard part is scaling from one agent to ten, from ten to fifty, from fifty to one hundred, without rebuilding the same definitions, context, permissions, policies, lineage and product logic for every single one.

Cameron's argument is that trusted data products provide the reusable foundation that makes this kind of scale possible. Without that foundation, every new agent becomes its own small integration project, with its own interpretation of what a customer, a product or a risk category actually means. The market is learning how to build and govern intelligent agents. Cameron is focused on the harder question, how to build an intelligent organization in which every agent shares the same trusted understanding of the business.

As Cameron puts it, McKinsey correctly explains how to engineer reusable data products. Our observation is that engineering alone has never been the limiting factor. The harder challenge is operationalizing reusable data products so business experts can continuously create, improve and govern them without waiting for technical delivery cycles.

Lili's Customer and Partner Perspective

Lili Marsh, our Head of Partner and Customer Success, brings a different and equally important vantage point. Customers do not experience this problem as an architectural diagram, and they rarely describe it using the language of data governance at all. They experience it as waiting for information that should already exist, receiving conflicting answers to the same question from different systems, encountering unclear definitions of basic business terms, submitting repeated requests for access or clarification, enduring approval delays that slow decisions that matter, and receiving AI outputs that nobody feels confident enough to act on without checking them manually. Partners implementing AI solutions frequently describe rebuilding the same business context for each new engagement, because it was never captured or governed as a reusable asset in the first place.

Lili's observation is that the strategic narrative around enterprise AI has to connect the technical investment McKinsey describes to these lived, everyday business problems. Executives fund technical architecture more willingly, and sustain that funding for longer, when they can see a direct line between the architecture and the frustration their own teams and customers describe.

What Leaders Should Take Away

We do not think the right response to McKinsey's technical guide is for business leaders to become data engineers. We think the right response is a short set of questions leaders should be able to answer confidently, in their own language, about the AI systems they are funding and accountable for.

• Can our leadership team explain what trusted information our AI is actually using, in plain business language.
• Are we presenting AI internally as a model initiative or as a decision capability.
• Can business experts contribute context and definitions without translating every requirement through a technical team.
• Do our agents share reusable definitions, policies and governed data products, or does each one start from scratch.
• Can we trace an AI output back through the information and transformations that shaped it, if a customer or regulator asks.
• Are security and governance controls consistent from source data through to AI consumption, or do they weaken at the edges.
• Does our AI strategy explain how business knowledge becomes available to AI, or does it only describe which models we plan to deploy.

Conclusion

The enterprise AI conversation is maturing, and that maturity is visible in guides like McKinsey's, which take for granted that leaders already understand AI is not going away and instead focus on the harder problem of making it work reliably at scale. We believe the market no longer needs more demonstrations that AI can generate an answer. It needs a clearer understanding of how organizations make those answers trustworthy, relevant and usable, and it needs that understanding explained in language business leaders can actually act on.

McKinsey's technical guide gives data and AI leaders a credible map for the engineering work required to scale generative AI. Our contribution, as a brand and strategy perspective sitting alongside that technical work, is to argue that the map needs a translation layer if it is going to reach the executives who fund it, govern it and answer for its outcomes. Trusted business context is our name for that translation layer. It does not replace the technical architecture McKinsey describes. It gives leaders a way to ask for what that architecture must ultimately produce.

The organizations that scale AI successfully will not necessarily be those with the most sophisticated models. They will be those that have operationalized their business knowledge into governed, reusable data products that every person, every application and every AI agent can immediately understand.

At Data Tiles, business experts create reusable, governed data products in Latttice. Those products become the trusted business context consumed by Lenz. Every new decision, every new application and every new AI agent begins with the same governed understanding of the business. That opportunity is available now. It does not require years inside another transformation program before value begins.

The next chapter of enterprise AI will not be won by the organizations that describe intelligence most impressively. It will be won by those that make their business understandable, to their people, their technology and their AI.