Enterprise AI has a trust problem. A recent McKinsey article, AI transformations run on trust, highlights the central requirement of trust in AI and some ways to achieve it in your enterprise.
Interestingly, the survey highlights a very strong executive commitment to AI as organizations are moving rapidly to deploy copilots, natural-language analytics, AI agents and increasingly autonomous workflows.
The paradox is that many companies are building these systems before establishing the foundation required to trust them.
The pattern that is emerging is remarkably common considering the sheer investments organizations have in data or cloud platforms. A company has already invested heavily in Snowflake, Databricks, Microsoft or another data platform. New AI capabilities become available. The CIO understandably asks: Why don't we start with what we already own?
And it can be a valid starting point and show some early, seemingly positive results. A team connects an AI assistant to enterprise data. Some metadata is added. A handful of important metrics are defined. The demonstration looks impressive.
Someone asks:
"What were Western Region sales last quarter?"
Seconds later, AI responds with a number, a trend and perhaps even an explanation.
It feels like we hit a home run!
But there is a much harder question hiding underneath:
Is the answer actually correct?
And an even more important one:
What does the AI know to be true about the business?
Those questions expose what may become one of the biggest architectural challenges facing enterprise AI. And the more AI you deploy, the bigger the architectural challenge becomes.
Companies are discovering that trust cannot simply be added after AI is deployed. It has to be engineered into the foundation on which AI operates.
AI Creates the Illusion of Understanding
Traditional analytics systems are typically designed and certified by expert technical staff. Data engineers create the data pipelines. BI designers create the reports and dashboards. And the data is, for all intents and purposes, certified. Of course things can break because a database got changed, and usually that quickly shows up as an error in a report or dashboard and we go fix it. Of course all of this "built-in trust" comes at a price: time lag and real staff costs. And this is one of the drivers behind the quest for AI.
AI fails differently. It can of course fail with some error code because the database is offline, but there is a bigger risk with AI.
It can (and will) produce an articulate, confident and completely plausible answer even when its understanding of the underlying business is incomplete.
Consider the seemingly simple question:
"What were Western Region sales last quarter?"
Before answering correctly, a system may need to understand:
- What constitutes the Western Region?
- Does "sales" mean bookings, invoiced revenue, recognized revenue or net sales?
- Which date determines the quarter?
- How are returns handled?
- Which customer hierarchy applies?
- Which tables should be joined?
- Are intercompany transactions excluded?
Humans inside the organization often know these things implicitly.
The LLM does not.
Giving an AI access to enterprise data doesn't automatically give it an understanding of the enterprise.
This creates a critical distinction:
Plausibility is not the same as correctness. And correctness is not yet the same as trust.
For enterprise AI, trust requires something more demanding: the ability to consistently produce the correct answer based on the organization's accepted definitions and business rules.
The Perfectly Rational "Let's Try What We Have" Decision
Part of the AI trust paradox is that companies aren't necessarily making irrational decisions.
Imagine being the CIO who has invested millions of dollars building a modern data platform.
Snowflake announces new AI capabilities. Databricks introduces Genie. Microsoft adds increasingly sophisticated copilots and agents.
The obvious question is:
"Why should I buy another technology? Let's see how far we can get with what we already have."
That's reasonable.
But it can lead to an important architectural assumption. Having an AI platform does not mean you already have the business foundation required by AI.
Interestingly, the major data platforms themselves increasingly recognize this.
Snowflake's Semantic Views, for example, model logical tables, relationships, facts, dimensions and business metrics. Snowflake describes high-quality semantic views as the foundation for accurate and trustworthy answers from Cortex Agents.
Databricks is moving in a similar direction. Its Genie Ontology brings together governed semantics from Unity Catalog with inferred context discovered from assets such as metric views, dashboards, SQL queries and Genie Agents.
The market is therefore moving beyond the question of whether AI needs semantics. It implicitly does, and everyone agrees.
The more important question now becomes:
How should an enterprise create, certify, govern and scale those semantics?
That distinction matters enormously.
The Metric Trap
Most businesses experience semantics through metrics:
- Revenue
- Gross margin
- Customer acquisition cost
- Inventory turns
- Customer churn
- On-time delivery
- Utilization
Defining these metrics and attaching the appropriate context to them clearly improves AI accuracy.
But there is a danger in making the metric the center of the semantic architecture.
Every metric needs context. How is it calculated? Which fields are involved? Which filters apply? What synonyms describe it? What time dimension should be used? Which entities does it relate to? Are there exceptions? Which business rules govern it?
Do this for 20 metrics and the problem seems manageable.
Do it for 200 metrics across Finance, Sales, Marketing, Operations, Supply Chain and Customer Success and something different begins to happen.
Metric creation becomes a semantic authoring problem.
Every new metric requires someone to encode more business knowledge.
That creates a bottleneck precisely when AI is supposed to eliminate bottlenecks.
There is another way to think about the problem.
What if metrics aren't the starting point for business context?
What if metrics are an output of it?
Model the Business First. Generate the Metrics Second.
This is a fundamental architectural principle behind Codd AI.
Before asking AI to understand hundreds of individual metrics, establish a governed model of the business itself.
What are the important business entities? Customers. Products. Orders. Shipments. Suppliers. Employees. Facilities. Contracts.
How are those entities related? Which customer placed an order? Which products were included? Which facility fulfilled it? Which supplier provided the inventory? Which salesperson owns the account?
Then connect that business model to the physical data model. Where does Customer exist physically? Which tables represent Orders? What are the appropriate keys? Which joins are valid? Which date fields represent different business events?
Now enrich that foundation with business knowledge: definitions, synonyms, policies, calculation logic, business rules, exceptions and organizational terminology.
And, critically, put humans in the loop to certify it.
Only then generate the business metrics. The cool part is that with all the business and data foundation defined, AI can generate your metrics for you!
The distinction may sound subtle, but architecturally it is profound.
Instead of:
Data → Metric → Add Context → AI
the model becomes:
Data + Business Knowledge → Certified Semantic Foundation → Metrics → AI
The semantic foundation becomes reusable infrastructure.
A new metric no longer has to recreate its understanding of Customers, Products, Orders, Regions, relationships and underlying data from scratch.
It inherits that meaning from the foundation.
From Metric Engineering to Metric Generation
This changes the scaling economics of enterprise AI.
Imagine a sales organization wants a metric for Average Revenue per Customer.
In a metric-centric approach, someone needs to create the metric and make sure AI understands what "revenue" means, which customer entity applies, what relationships are valid, which filters matter and how the calculation should behave.
Then someone asks for Revenue per Active Customer.
Then Revenue per Customer by Product Family.
Then New Customer Revenue.
Then Existing Customer Expansion Revenue.
Each requirement potentially creates another semantic modeling task.
But if Customer, Product, Revenue, Order and their relationships are already understood and certified within a shared semantic foundation, AI has something fundamentally different to work from.
It has a model of the business: a deep, certified, contextual semantic understanding of the business.
Metrics can increasingly be generated from that model rather than individually engineered into existence.
This is an important distinction between automating metric creation and automating semantics.
Generating YAML faster doesn't necessarily solve the semantic problem if humans still have to repeatedly specify and validate the business meaning associated with every new analytical requirement.
The larger opportunity is to establish business meaning once, certify it and reuse it.
Define meaning once. Generate many analytical artifacts from it. In fact, we previously wrote about how this approach can allow AI to generate any kind of metric once it has this foundation: data quality, risk, compliance and more.
That is how semantics begins to scale at the speed AI requires.
Certification Is What Turns Context Into Trust
There is another problem with simply giving AI more context.
Not all context is correct.
Organizations contain enormous amounts of contradictory knowledge.
Two dashboards may calculate revenue differently. A Power BI report may contain local business logic that doesn't exist in the warehouse. An old SQL query may reflect a definition abandoned three years ago. A document may contain outdated policies.
Even different departments may legitimately use different definitions of the same term.
So discovering context isn't enough.
AI needs authoritative context.
This is why human-in-the-loop certification matters.
At Codd AI, AI can discover and generate elements of the semantic foundation, but humans remain responsible for certifying what becomes trusted.
- The ontology is reviewed.
- The physical data model and relationships are reviewed.
- Generated business metrics are reviewed.
Once certified, these artifacts become the governed foundation used by downstream analytics and AI.
The objective isn't to remove humans from semantic modeling.
It is to dramatically change where humans spend their time.
Instead of manually creating every artifact, humans review, correct and certify what AI creates.
AI generates. Humans certify. The enterprise reuses.
That is a fundamentally more scalable model.
Why AI Literacy Matters More Than Companies Realize
There is also a human dimension to the trust paradox.
McKinsey recently argued that AI transformations run on trust and highlighted the importance of building AI literacy: not simply teaching employees how to use AI, but helping them understand its capabilities and limitations.
That becomes particularly important in analytics.
AI produces answers so convincingly that users can easily mistake fluency for accuracy.
A SQL query either runs or doesn't. In our traditional BI world, the SQL was generated by technical experts to satisfy the request from a decision maker. An AI system can misunderstand the business question, choose an inappropriate reasoning path and still return a polished executive summary.
Organizations therefore need a much more rigorous definition of "working."
Ten successful demo questions aren't enough.
Neither is an executive saying, "The answers look right."
Trusted AI requires known questions, certified expected answers, ambiguous terminology, edge cases, alternative phrasings and regression testing.
The organization needs to know what a correct answer actually is before it can determine whether AI produced one.
Which leads to a deceptively simple principle:
You cannot govern AI analytics if you haven't established what "correct" means.
A certified semantic foundation provides that reference point.
The Trust Cliff
This matters because trust can disappear much faster than it is created.
Imagine an executive uses an AI analytics system ten times.
Seven answers are correct.
Three are wrong.
The problem isn't simply that accuracy is 70 percent.
The executive doesn't know which three answers are wrong.
Suddenly all ten answers become suspect.
That's the trust cliff.
And once users fall over it, rebuilding confidence is difficult.
They return to dashboards. They ask analysts to verify AI-generated results. They export data to Excel. The analytics team becomes the validation layer for the AI system that was supposed to reduce its workload.
The technology may still be impressive.
But the business transformation has stalled.
This is why trust should not be treated as something that emerges after deployment.
Trust is an architectural requirement.
The Stakes Get Higher With Agents
This issue becomes even more important as enterprise AI moves from answering questions to taking actions.
If a chatbot incorrectly calculates gross margin, someone may make a poor decision.
But imagine an autonomous agent using that same incorrect definition to identify underperforming products, recommend promotional spending, adjust inventory or initiate an automated workflow.
The consequences become much more significant.
The progression looks something like this:
AI Analytics → Recommendations → Decisions → Agentic Actions
At every stage, the importance of trusted business context increases.
An agent shouldn't have to rediscover what Revenue, Customer, Product or Gross Margin means every time it executes a workflow.
Those concepts should already exist within a governed, certified foundation.
This is why the semantic layer is evolving from an analytics convenience into something much more strategic: a control plane for business meaning across AI.
Stop Treating Semantics as Cleanup
For years, enterprises could tolerate semantic inconsistency.
Different departments had different dashboards. Analysts maintained different calculations. Business logic accumulated inside SQL, spreadsheets and BI tools.
It wasn't ideal, but humans acted as the reconciliation layer.
AI changes that equation.
AI operates at a scale humans cannot manually reconcile.
And agents will operate with increasing autonomy.
That means the old sequence:
Data → AI → Applications → Accuracy Problems → Fix the Semantics
needs to change.
The new sequence should be:
Data → Certified Semantic Foundation → AI → Applications and Agents
This does not mean enterprises need to spend years creating the perfect enterprise ontology before deploying AI.
Quite the opposite.
AI itself can dramatically accelerate the discovery, creation and enrichment of the semantic foundation.
But speed cannot replace certification.
The goal is not perfect documentation.
The goal is enough governed business understanding for AI to know what it can reliably treat as true.
The Question Every CIO Should Ask
The extraordinary thing about today's AI technology is how quickly organizations can build something impressive.
Connect an LLM to enterprise data and within days you can demonstrate natural-language analytics that would have seemed impossible only a few years ago.
But impressive isn't the same as trustworthy.
Trusted AI requires something deeper.
It requires an understanding of the business: its entities, relationships, data, terminology, rules, metrics and exceptions.
That knowledge needs to be captured.
It needs to be connected to physical data.
It needs to be certified.
And it needs to become reusable infrastructure for every AI system that follows.
The industry increasingly agrees that semantics matter. The next frontier is determining how to create those semantics without turning semantic modeling itself into the next enterprise bottleneck.
The answer isn't to manually add more context every time another metric is requested.
It is to establish a certified semantic foundation from which metrics, analytics and AI applications can be generated and governed at scale.
So perhaps the first question a CIO should ask about an AI analytics initiative isn't:
"Can we build this with the technology we already have?"
A better question is:
"What does our AI know to be true about our business, and who certified it?"
Because in the age of enterprise AI, trust doesn't begin with the model.
It begins with the foundation.
About Codd AI
At Codd AI, we believe enterprise AI should reason from a shared, trusted understanding of the business, not from isolated prompts or disconnected data sources. Our AI-powered contextual semantic layer combines technical metadata, business knowledge, governance, and human certification into a reusable enterprise foundation for conversational analytics, AI copilots, and agentic workflows.
By helping organizations capture and govern business context once, Codd AI enables every AI and BI application to deliver more consistent, explainable, and trusted insights, today and as the AI landscape continues to evolve. To learn more, visit us at www.codd.ai or schedule a conversation with one of our co-founders.