AI analytics engines are only as strong as the governance layer beneath them. Most enterprise warehouses still rely on tribal knowledge, partial lineage, and implicit metric definitions, so an LLM cannot reliably reason over them. The highest-value path is to build a data catalogue, semantic layer, ontology, and a discover-verify-promote lifecycle so AI can accelerate metric discovery without compromising governance.
The old way: how enterprises get new metrics today
When leadership wants analysis on a new metric, the typical flow looks like this:
- Business throws a request over the wall to engineering.
- Engineering works on the pipeline: modifying data objects, adding sources, and adjusting transformations.
- The new metric flows through the layers — landing, normalization, business, presentation — until it shows up on a dashboard.
Time: days to weeks
This takes days, sometimes weeks. Not because the final SQL is hard to write, but because the archaeology is hard. Figuring out which tables, which joins, which layer the data lives in, and how it connects to what already exists.
Enter the AI analytics engine
Frontier models have made natural-language-to-SQL engines much more practical than they were two years ago. There are plenty of AI analytics tools where users describe what they want in plain English and get data back.
But most enterprises are not ready for this yet.
Why most enterprise warehouses are not AI-ready
Most data systems are designed by humans, for humans. An analyst knows what “Revenue” means because they sat in a meeting where someone explained it. An LLM does not have that context.
These systems rely on tribal knowledge. The business glossary lives in someone’s head, lineage is implicit in ETL code, and the relationships between entities are understood through experience, not through any machine-readable structure.
The 4-layer readiness stack
To make your warehouse AI-ready, you need to fill these gaps in data governance:
Layer 1: data catalogue
This includes:
- Data dictionary: what does each column mean, and what are its valid values?
- Data lineage graph: table-level and column-level lineage at each layer — landing, normalization, business, presentation. Where did this column come from? What was it called in the previous layer? How did it become what it is today?
Without this, the LLM is navigating your warehouse blind.
Layer 2: semantic layer
The semantic layer is where business glossaries get tied directly to the data dictionary. It maps technical metadata to user-friendly business terms.
This is where “rev_amt_net” becomes “Net Revenue,” and the LLM knows which table, which column, and which filter conditions define that metric.
Layer 3: ontology layer
A business glossary plus semantic layer marriage alone is not enough for an advanced AI engine. The ontology makes the marriage work for an LLM.
It sits on top of the semantic layer’s clean concepts. It maps how metrics and entities relate to one another using graph logic. It teaches the LLM how your enterprise operates:
In data engineering terms, an ontology is a machine-readable model that defines the real-world concepts, entities, and rules of a business domain, along with the relationships between them.
Layer 4: LLM as reasoning layer
The LLM reads the ontology to understand the user’s intent, figures out which relationships matter, and requests the data it needs from the semantic layer.
It does not guess. It follows the map.
The hard question: aren’t we just hardcoding metrics?
If we define every metric in the semantic layer, how is that different from just writing the SQL query that refreshes the view feeding the dashboard?
Hardcoding a metric in the semantic layer is just like writing a SQL query that runs each time to update data. If we replace that cheap SQL with an LLM call that burns tokens every single time, that is wasteful. It is replacing something that costs fractions of a cent with something that costs real money per execution.
| Use case | AI value | Verdict |
|---|---|---|
| Serving known metrics repeatedly (dashboards, scheduled refreshes) | Replaces cheap SQL with expensive tokens | Wasteful |
| Discovering new metrics that do not exist yet | Replaces days of engineering archaeology with minutes of AI reasoning | Valuable |
So where does the AI actually add value?
The real value: discover-verify-promote
The AI analytics engine is not useful for serving known metrics repeatedly. It is useful for discovering new metrics that do not exist yet.
Here is the scenario where it works: the business gives a brand new metric in natural language to the AI analytics engine. The engine, backed by the ontology and semantic layer, produces the data for that metric, along with the reasoning used to calculate it.
This replaces the old process of schema changes at each layer, pipeline modifications, new query introduction at the presentation layer, and days of engineering time. Instead, it happens in minutes.
The safety architecture: discover-verify-promote lifecycle
If the LLM can produce a new metric on the spot from the ontology, have we thrown away the safety we built with the semantic layer?
No. But only if we treat that first answer as provisional, not final.
LLM generates metric, shows its work, and is flagged as unverified.
Sanity check, human review, and business intent confirmation.
Written into the semantic layer and served cheaply as a governed metric.
Discovery (provisional)
When the business asks for a brand new metric, the LLM’s first response is a discovery draft. The engine shows the number, but also shows its work:
- Which tables it touched
- What join path it used
- What grain it assumed
- Confidence level and any assumptions
That output gets flagged as “unverified,” so nobody mistakes a first-draft AI answer for an audited metric.
Verification gate
Before anyone trusts the metric going forward, it passes through one gate:
- Sanity check: does this number roughly reconcile against something adjacent we already know is correct?
- Human review: an analytics engineer looks at the generated logic and reviews it rather than building it from scratch.
- Business intent confirmation: does “Active User” actually mean what the LLM assumed it means?
Promotion
Once it clears that gate, the metric gets written back into the semantic layer. Permanently, as a governed object. From that point forward, every dashboard or exec that asks for it again gets the cheap, deterministic, cached version.
Solving the determinism problem
Why can two similar prompts produce different data points?
During discovery, identical-intent prompts can produce different SQL paths. Different join orders, different filter interpretations, and different grain assumptions. LLMs are stochastic by nature.
1. Pin LLM temperature to 0 for analytical queries to minimize randomness.
2. Use the ontology to constrain the solution space so there is ideally one valid path per intent.
3. Hash the generated query logic to detect drift between runs.
4. Once promoted, freeze the definition so the problem disappears permanently.
The determinism problem only exists during discovery, and discovery is temporary by design.
The compounding effect
The system compounds.
Every metric that gets promoted enriches the ontology. New relationships become permanent nodes in the graph. The next novel question the business asks has a richer map to reason over.
The AI analytics engine does not stay a token-hungry query generator. Over time it becomes a governance accelerant that makes the semantic layer grow faster with each use.
The cold-start reality
On day one, the ontology is sparse. The first 50 metrics will have higher error rates and require heavier human involvement. That is the ramp-up curve.
The system gets better as it goes, but expecting day-one results from an empty ontology is unrealistic. The first phase is investment. The returns come after the knowledge graph reaches critical mass.
Feedback when the LLM gets it wrong
When the human reviewer rejects a generated metric, that rejection needs to feed back into the system. If “Customer” does not mean the same as “Account” in this context, the model should learn that distinction.
This negative feedback prevents the same hallucination from recurring. Without it, the system does not learn. With it, every correction makes future generations more accurate.
The bottom line
The expensive, slow part of the old process was never writing the SQL query. It was finding which tables, which joins, which layer the data lives in, and aligning three teams on what a metric actually means.
That is the work an ontology-aware LLM can do in minutes instead of days.
- The human’s job shifts from building the whole pipeline to reviewing and approving.
- The semantic layer keeps doing what it always does: serving metrics cheaply, once they are proven correct.
And the warehouse? It is ready for this, but only if you build the map first. Without the data catalogue, without the semantic layer, and without the ontology, the LLM is just generating hallucinations.
Build the map. Then let the AI navigate it.
Who does this serve?
| Stakeholder | What changes for them |
|---|---|
| C-suite executives | Get new metrics in hours, not weeks. |
| Analytics engineers | Shift from pipeline builders to metric reviewers and higher-leverage operators. |
| Data governance teams | The semantic layer gets populated faster and more consistently. |
| The enterprise | Compounds its data knowledge with every question asked. |