Yes, if you want AI to answer questions about your business metrics. Without a semantic layer, an AI assistant writes its own SQL against raw tables and defines revenue, active users, or churn its own way, confidently and differently from your finance team.
What a semantic layer is
A semantic layer is a single, shared definition of your business metrics that sits between your warehouse and everything that reads from it. Revenue, active customers, churn, and margin are each defined once, in code, along with the dimensions you can slice them by and the joins needed to get there. Dashboards, spreadsheets, and AI tools ask the semantic layer for a metric, and it writes the SQL.
Open tools such as MetricFlow and Cube do this, and most BI platforms have their own version. The idea matters more than the product: one definition per metric, maintained like software, read by everything.
Why AI makes the problem worse
Inconsistent metrics are an old problem. Two teams bring different revenue numbers to the same meeting, someone reconciles them, and everyone moves on. People catch it because people know the business.
An AI assistant does not. Large language models are good at writing SQL that runs. They are not good at knowing that your revenue excludes refunds, that "active" means a login in the last 28 days, or that one table is deprecated but still updated. Given raw tables, an assistant will make those choices silently, and the answer will look exactly as authoritative as a correct one. It also answers far more questions than an analyst team does, so every wrong definition spreads faster.
How grounding works
With a semantic layer in place, the assistant stops writing SQL from scratch. Its job becomes understanding the question and choosing the right metric, dimensions, and filters. The semantic layer turns that choice into SQL using the approved definition. If the question needs a metric that does not exist, the assistant can say so instead of inventing one.
This is how I build agentic analytics: agents that give product, marketing, and finance plain-language access to governed metrics, grounded in the semantic layer rather than in the raw schema. The agent's answers match the dashboard because both read the same definition.
Built-in assistants versus a layer you own
Warehouse and BI vendors now ship their own AI assistants, and they are easy to switch on. The catch is that each one understands only its own platform. If your data lives on more than one warehouse, or you might move, a vendor-specific assistant fixes your metric definitions inside that vendor. A semantic layer you own is portable: the same definitions can serve any assistant, any BI tool, and whichever warehouse you run next.
That does not make vendor assistants wrong. For a company on one platform with no plans to change, they can be the fastest route. Just make the choice on purpose.
Do not forget identity
An assistant that queries data on behalf of many people needs to respect what each person is allowed to see. The easy shortcut is a single service account with broad access, which quietly gives every user the union of everyone's permissions. Propagate each user's own identity to the warehouse, for example through per-user OAuth, so row-level and column-level policies still apply when the question comes through a chat window.
Start small
- Pick the metrics in your board deck. Usually ten to twenty. These are the numbers people already argue about and the ones an AI will be asked about first.
- Write down the definition that finance signs off on, including the edge cases, then encode it.
- Point one dashboard and one assistant at it. Compare the answers with what the business already trusts before widening access.
- Add metrics when people ask for them, not in a big modeling project up front.
When you do not need one yet
If you have one BI tool, a small set of well-modeled tables, and no plans to put AI on top of them, a semantic layer can wait. It is also not the answer for exploratory work on new data, where the definitions do not exist yet. The trigger is scale of access: the more people and tools that read your metrics, the more a single definition is worth.
Sid SrivastavaFounder of Millwright Data. He has run data platforms in semiconductor manufacturing, digital health, hospitality, and AAA games, on Snowflake, Databricks, and AWS.
