Enterprise AI advantage increasingly comes from governed context, semantic models, and operational data contracts, not only from model choice. For executives and platform leaders planning enterprise AI strategy, the useful question is what changes in production and what simply sounds current.
The Same Model Can Produce Very Different Business Value Depending on What Is Behind It
The same model can produce very different business value depending on the data contract behind it.
This is where lakehouse design is changing. The platform is no longer only serving dashboards. It is serving automated workflows that need context and limits. That matters because the model is not what differentiates an AI answer from a trusted AI answer. What differentiates it is whether the data behind the answer is governed, fresh, lineaged, and semantically correct.
The contracts that already mattered now matter more. Storage layout, catalog behavior, semantic definitions, identity, quality, and cost controls have to be explicit enough for both people and software to rely on them.
What the Research Supports
The strongest public sources for this topic are Dremio Agentic Lakehouse, the AgentTrust paper, and the Trustworthy AI in the Agentic Lakehouse paper. I use those to ground the architecture and avoid treating every June 2026 announcement as a shipped production capability.
The evidence supports a few grounded points:
- Models are becoming easier to swap, while trusted enterprise context remains hard to build.
- Semantic definitions, governance, lineage, and performance shape AI usefulness.
- The durable advantage is the system that turns messy enterprise data into safe action.
That is enough to write a useful technical article. It is not enough to make sweeping claims. I separate released behavior, design direction, and market language because readers can work with careful distinctions. They cannot operate slogans.
The Architecture Pattern
The moat is the governed path from business intent to trusted action. That path includes open data access, semantic meaning, policy, quality checks, lineage, query performance, and auditability. A better model helps, but a better model pointed at ambiguous data still produces ambiguous work. Enterprises win by making context operational.
For this architecture, the five layers worth keeping distinct are storage, catalog, execution, semantics, and agent interface. Storage holds durable files and snapshots. The catalog resolves identity and access. The execution layer plans and runs work. The semantic layer gives business meaning. The agent interface controls which questions and actions are allowed.
The point is not to collapse those layers into one box. The point is to make the handoffs clear. If a user or agent asks for an answer, the platform should be able to explain which table, which snapshot, which definition, which identity, and which policy shaped the result.
A Production-Shaped Example
Ask two companies the same AI question: which customers are most likely to expand this quarter? The model may be identical. The answers differ because one company has certified account definitions, clean usage events, approved revenue metrics, reliable freshness checks, and a safe action path. That is the real advantage.
The test should include a happy path and at least three failure paths. One failure should involve access. One should involve stale or incompatible data. One should involve an operational problem: a missing semantic definition, an uncertified metric, or an expired lineage trace. Those failures are where the platform either earns trust or loses it.
The test should also produce evidence. Save query IDs, semantic object used, lineage trace, policy decision, and validation output. If the team cannot find that evidence after the pilot, the rollout is not ready for a wider audience.
What To Measure
Start with four specific measurements:
- Semantic definition coverage for AI-accessible metrics: Track what percentage of the metrics and dimensions that AI tools can access are formally defined, certified, and owned. Uncertified metrics in the AI surface are ambiguous by design. The goal is to get that coverage above 90% before broad agent exposure.
- Lineage and quality visibility to agents at query time: Confirm that the agent’s tool response includes the lineage chain for the answer and any active quality flags on the source data. An agent that returns a revenue number without its lineage is returning a less trustworthy answer than one that can cite the source table, owner, and last quality check.
- Model choice separated from data readiness in evaluation: When evaluating AI performance, track data readiness independently. A poor answer from a capable model on bad data is a data problem. A correct answer from a simpler model on well-governed data is a data success. Conflating them leads to expensive model upgrades that do not address the real gap.
- Trust and adoption measured by business teams: Track whether business teams treat AI answers as reliable enough to act on without a manual check. If the re-check rate is high, the data contract is not strong enough, regardless of model accuracy.
Measurements should connect to decisions. A metric that nobody uses is telemetry decoration.
Common Failure Modes
The first mistake is treating the semantic layer as a feature checklist. A checklist can confirm that a semantic definition exists, but it rarely explains what happens when that definition is ambiguous under a novel AI question. The better move is to write the operating contract. Name the owner, the approved use cases, the exclusion list, and the freshness expectation before exposing the metric to an AI tool.
The second mistake is ignoring boundaries. Most enterprise AI problems appear where systems meet: semantic layer to query engine, lineage system to tool response, or quality check to agent decision. Boundary testing should be part of the rollout. If only the happy path was tested, the team has not tested production.
The third mistake is hiding tradeoffs behind category language. Words like moat, AI-ready, and governed can be useful, but they are not a substitute for mechanics. What is the actual certification rate for AI-accessible metrics? What is the lineage coverage? What happens when an agent asks a question that crosses a semantic boundary? If the answers are vague, the design is still vague.
The most expensive failures are usually quiet. The AI answer is plausible but uses a metric definition that excludes a segment the business cares about. The lineage trace points to a table that was updated without the semantic layer being refreshed. The governance label says certified, but the certification was done two years ago without a review. Those failures do not show up as red alerts. They show up as eroded executive trust in AI answers.
Guardrails for Agentic Use
Agents should start with certified metrics, narrow tool descriptions, and explicit lineage requirements. They should not receive access to every semantic object in the catalog just because a human analyst can query it. A tool should say which metrics it can answer, which freshness level it requires, and which questions are out of scope.
I would also require a visible refusal path. If the metric is not certified for this use case, the agent should say so. If the lineage trace is broken, the agent should warn rather than return an unattributed answer. A graceful limitation is not a bad user experience. It is a trust feature.
Operational Checklist
| Area | Question to answer | Why it matters |
|---|---|---|
| Ownership | Who owns the semantic definition, the lineage trace, and the AI tool? | Incidents need named owners, not shared confusion. |
| Scope | Which metrics are approved for AI access in this rollout? | A narrow surface is easier to certify and govern. |
| Identity | Which agent identities are mapped to which semantic objects? | Machine-speed access needs machine-enforced policy. |
| Evidence | Which query IDs, semantic objects, and lineage traces are saved? | Trust needs a trail. |
| Rollback | What happens when an AI answer uses an uncertified definition? | Recovery is part of the design, not an afterthought. |
This checklist is intentionally plain. The hard part is not inventing a complex governance framework. The hard part is answering the simple questions before AI tools depend on the semantic layer.
What Engineers Should Verify
Engineers should verify exact semantic object versions, lineage coverage, quality check outcomes, and certification status for each AI-accessible metric. Claiming “semantic layer support” is not enough. The team needs to know which metrics were tested under AI queries, which lineage paths were validated, and which scenarios are explicitly out of scope.
The practical test is simple: can another engineer reproduce an AI query result, trace it back to the source table, confirm the owner and certification status, and verify the quality check outcome without asking the original author for help? If not, the semantic contract is not verified.
The setup should also be tested under novel queries. Many semantic layers behave well when AI queries follow expected patterns. They reveal gaps when AI tools combine metrics, cross domains, or ask questions the semantic model was not designed to answer.
What Data Owners Should Verify
Data owners should verify that the semantic definitions they are responsible for are correctly interpreted by AI tools. A data owner who defined a revenue metric should review whether AI answers using that metric exclude the right segments and apply the right freshness rules.
This review should happen before broad AI exposure. Once an AI tool is answering business questions, the answers become part of the operating rhythm. Weak definitions become expensive to fix because they have already shaped decisions.
Data owners should also decide which metrics are appropriate for AI use and which require human interpretation. Some metrics have nuance that is difficult to encode in a semantic definition. Those should be excluded from the AI surface until the definition is stronger.
What Executives Should Hear
The summary should be plain: the enterprise that builds a governed, well-understood data foundation will get more value from AI than the enterprise that constantly chases a better model. Model capability is converging across vendors. The differentiation will come from the quality of the data contract behind the AI tool.
The value is not the model. The value is certified semantic definitions, clean lineage, reliable quality checks, and fast governed access. That value shows up as AI answers that business teams trust enough to act on without a manual check.
Executives should also hear the limit. No semantic layer removes the need for data ownership, quality reviews, and certification processes. Agentic systems raise the bar for those disciplines because they can ask more questions and surface more gaps in less time.
A Good First Rollout
Start with one business question that a team is already asking manually. Pick one AI use case, one certified metric, one semantic path, one or two identities, and one measurable outcome. Run it manually first. Then run it through the intended platform path. Then run it through the AI tool.
Define success with three outcomes. The first is correctness: the AI answer matches the expected business meaning as validated by the data owner. The second is safety: uncertified metrics or broken lineage produce a warning, not a silent answer. The third is adoption: at least one business team uses the answer without a manual re-check.
After that, expand by adding another metric, another domain, or another AI tool. Expanding one dimension at a time is slower than a dramatic rollout, but it creates fewer trust gaps.
Deeper Design Notes
The design work should begin with the nouns in the enterprise AI workflow. Name the metrics, the semantic definitions, the lineage chains, the certification owners, the quality checks, and the failure states. When those nouns are vague, every later AI discussion becomes vague too. Start with the concrete semantic objects and build outward.
The next step is to define the dimensions that actually change behavior: semantic contracts, lineage coverage, governance cadence, performance, and action paths. These are not decorative details. They determine whether the AI system is predictable under real use.
Review Questions Worth Asking
The first question is simple: what percentage of the metrics an AI tool can access are formally certified with an owner, a definition, and a freshness expectation? If the answer is below 80%, the semantic surface is not ready for broad AI exposure.
The second question: can the AI answer for each metric be traced back to a source table with a named owner and a recent quality check? If lineage is broken for more than a few metrics, the semantic layer is not production-ready.
The third question: who gets notified when a new AI question exposes a gap in the semantic model? If the answer is unclear, the semantic layer has no feedback loop. Gaps will accumulate silently.
A Realistic Pilot Shape
A realistic pilot should look like two business analysts asking the same expansion opportunity question. One asks a human analyst who uses certified data manually. The other asks an AI tool backed by the semantic layer. Compare the answers, the time to answer, and the confidence level from each business stakeholder. The point is not to prove that AI is faster. The point is to determine whether the AI answer is equally trustworthy.
Include a repetition test. Run the same AI query across a few weeks as the underlying data changes. Many semantic layers produce correct answers right after certification. Fewer remain correct as tables evolve, metrics are refined, and lineage paths shift.
Metrics That Should Drive the Next Decision
The first metrics to watch are semantic reuse rate across AI queries, certified metric coverage, answer trust measured by business adoption without manual checks, and lineage trace completeness per answer. Those measurements should lead to a decision about whether to expand AI exposure, fix semantic gaps, or add more certified metrics.
A second group of metrics should track trust: how often did the AI tool return a warning about certification status? How often did business teams escalate an AI answer to a human for verification? Those signals tell you whether the semantic layer is production-ready.
A third group should track cost: how much maintenance do semantic definitions require as underlying data evolves? A semantic layer with low maintenance cost and high reuse is a genuine competitive advantage. One with high maintenance cost and low reuse is just documentation overhead.
What I Would Cut From a Weak Rollout
Cut uncertified metrics from the AI surface first. An AI tool that can access uncertified metrics is one that can produce plausible but wrong answers. Start with the certified subset and expand as more metrics are reviewed.
Cut broad domain access from the initial rollout. Pick one business domain where the semantic model is strongest. Add other domains after the first one is proven.
Cut novel cross-domain queries from the first phase. Single-domain questions are easier to validate. Add cross-domain questions when the base case is already clean and well-tested.
The Practical Standard
The practical standard is not model accuracy. It is semantic contract quality. When a business team challenges an AI answer, an operator should be able to explain which metric was used, who certified it, what it excludes, when the underlying data was last validated, and which lineage path produced the result.
That standard is demanding, but it is realistic. It lets enterprises build AI advantage without pretending that a better model is the primary lever. The model is one participant. The semantic contract is what makes the result trustworthy.
My Recommendation
Take the semantic lakehouse layer seriously as an enterprise AI investment, but do not oversell it. The useful bar is simple: can the team certify the metrics, maintain the lineage, enforce the policy, measure the trust, and recover when definitions drift?
If the answer is yes, the pattern deserves a production pilot. If the answer is no, the next step is not a better model. The next step is a better semantic contract.
This is a favorable strategic frame for platforms like Dremio because the product story is about open data, semantic context, fast SQL, and governed AI access. When teams understand that the model is not the moat, the platform that provides the best governed semantic layer becomes self-evidently important.
For a deeper foundation on lakehouse and AI architecture, explore Alex Merced’s books on data lakehouses and AI at books.alexmerced.com. To try a governed, open, agent-ready lakehouse in practice, start a free trial of Dremio’s Agentic Lakehouse at dremio.com/get-started.