Your semantic layer is becoming the API for AI

AI can now write SQL perfectly well.

Give a language model access to a database, tell it which tables are in it, and ask what last month’s revenue was. There is a good chance it will produce a well-formed query and a convincing answer within seconds.

But that still does not tell AI what your organization means by revenue.

Does it mean booked revenue, invoiced revenue, or delivered revenue? Are credit notes included? What about intercompany revenue? Which date determines the month? And if someone asks about revenue in the Netherlands, do we mean the customer’s country, the delivery address, or the sales organization?

That is not a SQL problem. It is a semantic problem.

And that is precisely why a concept that has circulated in business intelligence for decades is suddenly receiving so much attention again: the semantic layer.

In fact, I think its role is fundamentally changing.

Until now, we mainly built semantic models to provide dashboards and reports with consistent business logic. Soon, AI agents will use that same layer to understand our organizations.

From BI layer to interface for AI

The semantic layer is not new

Anyone who has worked in Business Intelligence for some time will recognize the idea. In the traditional BI world, a semantic layer was standard practice. A well-known example is the BusinessObjects Universe. A Universe placed a business-friendly layer over the technical database structure. Users worked with familiar concepts, dimensions, measures, and hierarchies without needing to know exactly how the underlying tables and joins were structured.

SAP still describes a Universe as a collection of metadata objects that allows users to analyze data in non-technical, understandable business language. (SAP Help Portal)

Cognos had a similar concept with Framework Manager.

The idea was simple and actually very sensible:

The database tells you how data is stored; the semantic layer tells you what that data means.

Of course, there was also a downside.

These traditional BI environments could become quite cumbersome. Before a user could build a report, a data warehouse often had to be designed, a central model built, a Universe configured, and someone had to grant permission to use it.

That was not exactly agile.

Then came self-service BI

Starting around the second half of the 2000s, the landscape began to change.

Products such as QlikView, followed later by Qlik Sense and Tableau, made it much easier to work with data quickly. Instead of spending months designing a central BI layer, an analyst or developer could load, model, and visualize data and deliver something useful almost immediately.

That was a major step forward.

I worked with Qlik for years myself, and that speed and freedom were a large part of its appeal.

But this shift also had a consequence: the explicit, centrally managed semantic layer began to fade from view.

That does not mean Qlik, Tableau, or later Power BI contained no semantics. Quite the opposite. A Qlik data model contains relationships and business logic, Tableau has logical models, and Power BI now offers extensive semantic models.

But in practice, that meaning often became scattered across different layers. Especially in Qlik, much of the business logic was captured not only in the data model, but also in variables, set analysis, master measures, script logic, and even individual object expressions.

That worked well as long as experienced developers knew where everything was and why it had been built that way. But it made the business meaning less explicit, less centralized, and harder to reuse outside the original application.

As a result, the semantic layer received far less attention as an architectural principle in its own right.

We increasingly began capturing business logic wherever we needed it at the time:

• In a Qlik app
• In a Tableau workbook,
• In a Power BI semantic model,
• In a SQL view,
• In a DAX measure,
• In an ETL script.

And sometimes in several places at once.

Self-service made analytics more accessible, but it also made it very easy to create multiple versions of the same truth.

Ultimately, we ran into the same problem

As long as an organization has a limited number of dashboards, the problem is manageable. But as self-service BI becomes successful, dozens or hundreds of models, apps, and reports emerge. Then the familiar debates begin.

What is striking is that these are roughly the same problems the classic semantic layer was originally designed to solve.

And so the concept returned.

Power BI now explicitly refers to semantic models. Looker built much of its platform around LookML. dbt developed its Semantic Layer and MetricFlow. Data platform vendors are increasingly talking about metrics, data products, ontologies, and semantic layers.

I sometimes look back on BusinessObjects with a certain nostalgia. Universes were not such a bad idea after all. But the renewed appreciation for the semantic layer is mainly driven by our rediscovery that access to data is not the same as agreement on what it means.

And that is where AI comes in.

AI makes the problem much bigger

Consider that question again:

“What was our revenue last month?”

A human data analyst who lacks sufficient context can ask follow-up questions:

An analyst can also recognize when a result seems strange. If revenue is normally around five million and the query suddenly returns 28 million, that will probably set off alarm bells.

An AI agent does not automatically have that intuition.

It can find a table with a Revenue column, join it to another table, generate a plausible query, and confidently present the wrong answer.

Maybe the join is wrong. Maybe it uses bookings instead of revenue. Maybe every order line is counted three times. Maybe it is unaware of an exception from Finance.

The answer can still look excellent, which makes this more dangerous than a standard error message.

The challenge is no longer making data discoverable

Over the past twenty years, we have invested enormous effort in making data accessible.

Cloud data warehouses, lakehouses, APIs, ELT, notebooks, and self-service BI have made it increasingly easy to access data from a technical perspective.

Generative AI takes this a step further. Soon, users may not even need to know where the data is stored. They can simply ask a question. This shifts the problem. The question is no longer just:

“Can AI access our data?”

The more important question becomes:

“Does AI know how our organization interprets that data?”

That is where the semantic layer comes back into play.

The semantic model as a contract

I find it useful to think of a good semantic model as a kind of contract. It defines:

Technically, such a model can consist of measures, dimensions, relationships, calculated fields, hierarchies, metadata, and security rules, but functionally it does something more important. It captures part of the business language in a form that software can use. Until recently, dashboards were the primary consumers of that contract. Now, an entirely new type of consumer is emerging: the AI agent.

Microsoft is already explicitly building toward this

Microsoft has even published separate guidelines for making Power BI semantic models AI-ready. In these guidelines, Microsoft emphasizes the importance of clear names, descriptions, correct relationships, and reducing ambiguity in the model, among other things. According to Microsoft, the quality of a Data Agent’s answers depends heavily on how well the data sources and semantic models it uses have been prepared.

That is telling.

For years, we often viewed metadata as documentation—something we should really maintain, but rarely have enough time for in practice. For AI, metadata shifts from documentation to “runtime context.” A measure’s description is then useful not only to the next developer. An agent actually uses that description to determine what the measure means and when it should be applied.

And then MCP enters the picture

Microsoft also supports using a Fabric Data Agent as a Model Context Protocol server, which is currently still in preview. Through MCP, such an agent can make its data and query capabilities available to external AI systems.

MCP is a standard that allows AI applications to discover and use tools, context, and data sources in a consistent way. The interesting part is not so much MCP itself. Perhaps MCP will be replaced by something better in a few years. What is interesting is the architectural principle behind it.

The application where someone asks a question no longer needs to be the same application where the business logic is managed. An AI assistant can run elsewhere and still access a governed data or analytics layer. This suddenly makes the semantic layer much more than the backend of a dashboard.

It becomes a service.

Qlik is moving in the same direction

That is an interesting development. A traditional discussion would be:

“Do we use Qlik or Power BI?”

But with this architecture, you can ask a different question:

“Where do we manage the trusted analytical context that our users and agents need?”

For example, an organization could use Power BI as its primary reporting tool while certain governed data or analytical logic is managed elsewhere.

Or an AI assistant could access Qlik without the user ever opening a Qlik dashboard. That makes platform boundaries less clear-cut.

TimeXtender perhaps makes the idea even more explicit

TimeXtender describes the problem well: without this context, an AI system may select a field that sounds logical, miss an exception rule, or create a join that is technically valid but wrong in business terms.

And that actually brings us back to the BusinessObjects Universe. Once again, we are placing a business-friendly layer between the physical data and the consumer. But this time, the consumer is not necessarily a reporting user. It can also be software.

One semantic layer, multiple consumers

I see that as the fundamental shift. For a long time, we viewed a semantic model as something tied to a BI tool. A Power BI semantic model belongs with Power BI reports. A Qlik model or Master Items belong with Qlik visualizations. A Universe belongs with Web Intelligence (or Deski).

But imagine an architecture in which the same governed business logic is used by:

• Dashboards;
• Excel;
• Operational applications;
• APIs;
• Copilots;
• Chat interfaces;
• AI agents;
• Autonomous processes.

That considerably changes the economic value of the semantic layer. The dashboard becomes one of its potential users, rather than necessarily being the end product around which everything is built.

AI makes good modeling more important, not obsolete

There is also an opposing line of thought. If AI can write queries itself, why should we still spend so much time on models, measures, and business logic? Can’t the model simply figure that out?

Technically, it increasingly can, but from a business perspective, that is exactly what you do not want.

The easier it becomes to query any data, the more important a reliable semantic layer becomes.

Ten employees looking at the same dashboard at least see the same revenue. Give each of those same ten employees an AI agent that independently generates SQL against a complex data warehouse, and you may suddenly get ten different answers.

AI democratizes access to data. Without governance, it also democratizes the ability to produce different versions of the truth at scale. That makes well-modeled and governed semantics more important than ever.

This also changes the work of BI teams

If this development continues, some of the work of analytics teams will shift. Today, BI teams still receive many requests like:

When users can use AI to ask their own follow-up questions, some of that work will likely disappear. But that does not mean the work itself will disappear. Someone will still need to determine:

• What KPI definitions mean exactly;
• Where the official definition is maintained;
• Which relationships are correct;
• Which data is reliable;
• Which exceptions apply;
• Which information someone is allowed to use;
• Which models are authoritative;
• How changes are tested;
• How lineage and ownership are documented.

The value shifts from visualizing every question to structuring meaning people can trust. For data and analytics professionals, that strikes me as a healthy development. Although we should be honest: documenting definitions and maintaining metadata is usually a little less fun than building a polished visualization.

And our semantic models are often far from ready for that

There is just one problem. Many existing semantic models were designed for human developers.

A Power BI developer may know exactly what a measure named [NS Adj LY %] means. An AI agent does not.

A Qlik developer knows why a particular set analysis expression applies an unusual selection. An agent that only sees the end result has no idea why.

As a result, things we once easily considered “nice to have” become important for AI-ready semantic models.

These are not exotic AI techniques. They are largely the same disciplines we have always needed for good BI. AI simply raises the cost of carelessness.

From semantic layer to business infrastructure

That is why I believe we need to rethink how we view semantic models. Not as a technical component of Power BI. Not as something that exists only in Qlik apps. Not as an additional modeling tool layered on top of the data warehouse.

A well-designed semantic layer is essentially a machine-readable description of how an organization views its own data.

That is a valuable business asset. Perhaps even more valuable than many of the dashboards built on top of it. Dashboards come and go, but the definitions of revenue, customer, margin, inventory, occupancy, or churn should be much more stable. When that meaning is properly managed, more and more applications can connect to it. Power BI today, a Copilot tomorrow, and the day after that, an agent that automatically investigates anomalies or suggests actions.

We’re almost back to the Universe, but not quite

There is something ironic about this development. After twenty years of innovation, we are partly returning to an idea that BusinessObjects introduced a long time ago:

Put a semantic layer between the technical data and whoever wants to use it.

But we are not simply back where we started. The first generation of semantic layers was primarily intended to make it easier for people to build reports. The new generation needs to work for both people and machines.

And that brings different requirements.

The semantic layer needs better documentation, must be programmable and accessible through standardized interfaces, and must provide sufficient governance for automated systems to work with it. That is fundamentally different.

So don’t start with the chatbot

Many organizations looking to experiment with AI and data understandably start with the visible technology. Which LLM will we use? Microsoft Copilot? ChatGPT? Claude? Our own agent? Which vector database? Do we need MCP?

If the goal is to get reliable answers about your own business operations, I would start by asking a different question:

Where have we actually defined what our data means?

Where is the official revenue definition? Which customer classification is authoritative? Where does the gross margin logic reside? Are those definitions known only to a few experienced developers? Are they scattered across SQL, Power BI, Qlik, and Excel? Or do they actually exist as reusable, governed business logic?

If the answer is unclear, your primary problem is not yet an AI problem. It is a semantic layer problem. AI simply makes that problem suddenly very visible.

The semantic layer is becoming business infrastructure

Dashboards are not going away. For many forms of communication, a purpose-built visualization simply remains better than a chat window. But the dashboard is increasingly becoming less of the sole destination of our data architecture. The same business context can soon be used by reports, applications, and AI agents.

This turns the semantic layer from a component of the BI stack into part of the company’s infrastructure. A place where we define not only where the data is located, but, more importantly, what the data means. And once machines start using that meaning directly, the semantic model takes on an entirely new role: it becomes the API through which AI learns to understand your organization.

Is your data foundation ready for AI?

Becoming AI-ready does not start with choosing a language model. It starts with reliable data, clear definitions, and well-governed business logic.

Want to know whether your current data architecture, semantic models, and governance are ready? With our AI Readiness Assessment, we identify the most important gaps and the steps needed to enable AI to work reliably with business data.