8 Semantic Layer für BI und KI-Agenten im Jahr 2026

Ein Semantic Layer sitzt zwischen Ihren Rohtabellen und den Menschen oder Agenten, die Fragen stellen. Er hält die Definitionen. Was „Umsatz“ bedeutet, wie „aktiver Kunde“ berechnet wird, welche Tabellen sich zu einer Kennzahl verknüpfen. Ohne ihn leitet sich jedes Dashboard und jeder KI-Agent diese Definitionen selbst neu her, und die Antworten laufen auseinander. Mit ihm bedeutet eine Zahl überall dasselbe.

Bis 2026 teilt sich die Landschaft in vier Kategorien. Drei davon widmen sich dem Definieren von Kennzahlen: eigenständige Semantic Layer, die Sie selbst betreiben, warehouse-eigene Schichten, eingebaut in Snowflake und Databricks, und BI-eigene Schichten in Werkzeugen wie Looker und Power BI. Die vierte ist weniger eine neue Technik als ein neuer Name für eine alte Disziplin. Die Fähigkeiten, aus denen ein Context Layer gebaut ist, ein Datenkatalog, ein Business Glossary, Data Lineage und Klassifizierung, regeln Daten seit Jahren. Geändert hat sich der Abnehmer. Statt diese geregelten Metadaten über Dashboards an Menschen zu liefern, setzt ein Context Layer sie zusammen und liefert sie über ein offenes Protokoll an KI-Agenten. Die Disziplin ist ausgereift. Sie auf KI zu richten, ist der neue Teil. Auch diese Einteilung ist nicht hier erfunden; dieselben vier Kategorien ziehen sich durch die meisten Betrachtungen des Feldes aus dem Jahr 2026.

Die Liste unten ist nach diesen Kategorien gruppiert und zur besseren Bezugnahme nummeriert, nicht gereiht. Die richtige Wahl hängt davon ab, wo Ihre Landschaft ohnehin liegt, und die meisten Teams enden damit, einen Semantic Layer mit einem Context Layer darüber zu verbinden.

Eines sollten Sie beim Lesen im Kopf behalten. Die meisten dieser Werkzeuge treten inzwischen mit KI an, und mehrere setzen Zugriffsregeln durch, definieren fachliche Bedeutung und stellen einen eigenen MCP Server bereit, es ist also keine Geschichte darüber, wer „Kontext“ hat und wer nicht. Der wirkliche Unterschied ist der Umfang. Ein Semantic Layer regelt die Kennzahlen, die Sie in ihm modellieren. Er katalogisiert nicht Ihre gesamte Datenlandschaft, stuft nicht sensible Daten ein, wo immer sie liegen, verfolgt keine Lineage durchgängig über Plattformen hinweg und bringt nicht mehrere Semantic Layer unter einer geregelten Sicht zusammen. Diese weitere, plattformübergreifende Aufgabe ist das, was ein Context Layer tut, und sie ist der Teil, der sich zu besitzen lohnt, für welche Engine Sie sich auch entscheiden. Lesen Sie das Folgende also weniger als „wer ersetzt die anderen“ und mehr als „welche Engine passt, und was regelt die gesamte Landschaft für KI“.

Eigenständig. Am besten für Teams, die ihre Transformationen ohnehin in dbt modellieren. Der dbt Semantic Layer führt den Arbeitsablauf von dbt in die Definition von Kennzahlen weiter, mit MetricFlow darunter und Definitionen, die in versionsverwaltetem YAML neben den Modellen liegen, die sie beschreiben. Als früher Unterstützer des Open Semantic Interchange (OSI) hält dbt diese Definitionen über BI-Werkzeuge und KI-Agenten hinweg portabel, statt sie an eine Syntax zu binden.

Was dbt definiert, definiert es gut, und das ist seine ganze Aufgabe: Kennzahlen, als Code. Es katalogisiert nicht den Rest Ihrer Landschaft, stuft keine sensiblen Felder ein, verfolgt keine Lineage über Plattformen hinweg und umgibt eine Kennzahl nicht mit dem Glossar, der Verantwortung und der Herkunft, die ein Agent braucht. dbt und Dawiso sitzen also nebeneinander, statt zu konkurrieren. dbt ist die Engine für Kennzahlen, die Ihre Analytics Engineers verantworten; Dawiso katalogisiert diese Kennzahlen neben allem anderen, regelt sie und liefert sie an jeden MCP-fähigen Agenten. Sie behalten dbt für die Definition und ergänzen Dawiso für Governance und Auslieferung, und keines macht das andere überflüssig.

Wichtige Fähigkeiten

• Kennzahlen als Code in versionsverwaltetem YAML (MetricFlow)
• Liegt neben den Transformationen in dbt, in derselben Prüfung in Git
• An OSI ausgerichtet, sodass Definitionen über Werkzeuge hinweg portabel bleiben

Eigenständig. Am besten für Headless Analytics und KI-Agenten. Cube ist ein Headless-Semantic-Layer. Er stellt Kennzahlen über Schnittstellen bereit (SQL, REST, GraphQL und eine auf KI ausgerichtete Schnittstelle), sodass eingebettete Analytik, Anwendungen und Agenten alle dieselben Definitionen abfragen. Er ist unabhängig vom Warehouse und dafür gebaut, vor mehr als einer Datenquelle zu sitzen, was ihn zu einer häufigen Wahl macht, wenn ein Agent gleichbleibende Kennzahlen braucht, ohne an ein einzelnes BI-Werkzeug gebunden zu sein. Der Preis dafür ist der Betrieb: Cube aufzusetzen ist technisch aufwendiger als ein BI-eigenes Modell, es bringt weniger fertige Anbindungen an BI-Werkzeuge mit als Looker oder der dbt Semantic Layer, und es bringt Aufwand für den Eigenbetrieb mit sich, sofern Sie nicht Cube Cloud nutzen. Cube setzt eigene Zugriffsregeln durch und liefert einen MCP Server mit, sodass ein Katalog Ihrer gesamten Landschaft, plattformübergreifende Lineage, Klassifizierung und ein Business Glossary die weitere Aufgabe sind, die ein Context Layer darüber übernimmt.

Wichtige Fähigkeiten

• Headless: Kennzahlen über SQL, REST, GraphQL und KI-Schnittstellen
• Unabhängig vom Warehouse, sitzt vor mehreren Quellen
• Gebaut für eingebettete Analytik und KI-Agenten

Eigenständig. Am besten für große Unternehmen mit gemischter BI-Landschaft. AtScale ist ein universeller Semantic Layer mit Unterstützung für MDX und einer Beschleunigung von Abfragen über vorberechnete Aggregate, weshalb Unternehmen mit alten Festlegungen auf OLAP danach greifen. Excel, Tableau, Power BI und KI-Werkzeuge treffen alle auf einen geregelten Satz von Definitionen über demselben Warehouse, und die Beschleunigungsschicht hält interaktive Abfragen schnell, während die Datenmengen wachsen. Der Preis ist für große Unternehmen gemacht, weshalb kleinere oder junge Teams es als schwergewichtig empfinden, es bringt mehr Aufwand für die Konfiguration mit sich als Headless-Alternativen, und am natürlichsten passt es zu Organisationen mit einer Vergangenheit in OLAP-Würfeln. AtScale regelt die Kennzahlen, die es modelliert, auch über Quellen hinweg, und tritt mit KI an; ein Katalog Ihrer gesamten Landschaft, ein Business Glossary, Klassifizierung und durchgängige Lineage sind die weitere Aufgabe, die im Context Layer darüber sitzt.

Wichtige Fähigkeiten

• Universeller Semantic Layer mit Unterstützung für MDX
• Beschleunigung von Abfragen über vorberechnete Aggregate bei großen Mengen
• Versorgt Excel, Tableau, Power BI und KI-Werkzeuge gleichermaßen

Der Context Layer. Er erledigt die Aufgabe eines Semantic Layer und geht dann darüber hinaus. Hier nimmt die Liste eine Wendung. Dawiso ist kein vom Semantic Layer getrenntes Werkzeug, sondern geht über ihn hinaus, und seine Rolle hier ist die Schicht darüber. Es leistet die semantische Arbeit selbst: Sein Business Glossary definiert, was Ihre Kennzahlen und Begriffe bedeuten, und es erzeugt geregelte Semantic Views über OSI, den herstellerneutralen Standard, der diese Definitionen portabel hält statt an eine Syntax gebunden, und schreibt sie nach Snowflake. Dann arbeitet es in einem Umfang, den eine einzelne Engine für Kennzahlen nicht erreicht. Ein Semantic Layer regelt die Kennzahlen, die Sie in ihm modellieren, und die besseren setzen durch, wer sie abfragen darf. Dawiso regelt die gesamte Landschaft um diese Kennzahlen herum: Es katalogisiert Ihre Bestände über die Plattformen hinweg, mit denen es verbunden ist, stuft ein, was sensibel ist, wo immer es liegt, verfolgt Lineage durchgängig, hält fest, wer jede Definition verantwortet, und sitzt über den Semantic Layern, mit denen es verbunden ist, etwa dbt, Snowflake, Databricks und Power BI, und bringt deren Definitionen in eine geregelte Sicht, der ein Agent trauen kann. Das ist die Linie, die wir in Context Layer und Semantic Layer im Vergleich ziehen.

Dawiso verbindet sich mit mehr als 40 Plattformen und baut über alle hinweg ein geregeltes Fundament: einen Data Catalog dessen, was es gibt, das Business Glossary dessen, was jeder Begriff bedeutet, eine Klassifizierung dessen, was sensibel ist, und Interactive Data Lineage dessen, woher alles kommt. Über den Context Layer und seinen MCP Server liefert es diesen geregelten Kontext samt Definitionen an jeden MCP-fähigen Assistenten und Agenten. Sie können Dawiso einen Semantic Layer regeln und ausliefern lassen, mit dem es verbunden ist, etwa dbt oder die warehouse-eigenen, sich auf sein eigenes Glossar und seine Semantic Views stützen oder beides tun. So oder so ist die Bedeutung geregelt und vertrauenswürdig genug, dass ein Agent danach handeln kann.

Wichtige Fähigkeiten

• Business Glossary, Katalog, Lineage und Klassifizierung in einer Schicht
• Erzeugt geregelte Semantic Views über OSI (portabel)
• Liefert geregelten Kontext an jeden MCP-fähigen Agenten
• Spannt sich über mehr als 40 Plattformen, sodass Kontext plattformübergreifend ist und nicht an ein Warehouse gebunden

Warehouse-eigen. Am besten für Teams, die auf Snowflake vereinheitlicht sind. Cortex Analyst beantwortet Fragen in natürlicher Sprache, indem es eine Semantic View oder ein semantisches Modell in YAML liest statt roher Tabellen, und der Horizon Catalog von Snowflake regelt den Zugriff darunter. Innerhalb von Snowflake ist es ausgezeichnet und schnell aufgesetzt.

Es passt außerdem ungewöhnlich gut zu Dawiso, und zwar in beide Richtungen. Dawiso scannt Snowflake Cortex Agents und ihre Semantic Views in die interaktive Lineage, sodass Sie genau sehen, welcher Agent welche Tabelle liest, und es erzeugt geregelte Semantic Views über OSI zurück nach Snowflake. Diesen Aufbau in beide Richtungen gehen wir in Governance für Cortex Agents und Semantic Views durch. Das Einzige, was die hauseigene Schicht von Snowflake nicht kann, ist reisen. Ihre Definitionen und Richtlinien enden an der Grenze der Plattform, sobald Snowflake also eine von mehreren Plattformen ist, hält ein Context Layer die eine plattformübergreifende Definition, die Rolle, die wir in Context Layer für Snowflake beschreiben.

Wichtige Fähigkeiten

• Cortex Analyst liest Semantic Views, keine rohen Tabellen
• Zugriff geregelt durch den Horizon Catalog innerhalb von Snowflake
• In beide Richtungen mit Dawiso: in die Lineage gescannt, Views über OSI zurückgeschrieben

Warehouse-eigen. Am besten für Lakehouse-Teams auf Databricks. Metric Views im Unity Catalog definieren Kennzahlen einmal, und AI/BI Genie liest diese semantischen Metadaten, um Fragen zu beantworten, wobei die Sicherheit auf Zeilenebene und die Maskierung von Spalten aus Unity Catalog in die Antwort einfließen. Die Governance ist echt, und wie bei Snowflake ist der Umfang die Plattform.

Dawiso arbeitet daneben statt dagegen. Es scannt Unity Catalog und Genie in die interaktive Lineage, legt ein plattformübergreifendes Glossar, Klassifizierung und Governance darüber und liefert das Ergebnis über MCP an jeden Agenten aus, der Aufbau, den wir in Context Layer für Databricks beschreiben. Unity Catalog ist selbst ein Katalog und eine Schicht für Governance, überschneidet sich also stärker mit einem eigenständigen Werkzeug für Governance als die reinen Semantic Layer. Der Unterschied ist die Reichweite. Es regelt innerhalb von Databricks, während ein Context Layer eine Definition über Databricks, Ihr Warehouse und Ihre BI-Werkzeuge hinweg hält und Agenten erreicht, die außerhalb des Lakehouse laufen.

Wichtige Fähigkeiten

• Metric Views einmal im Unity Catalog definiert
• Genie antwortet mit angewandter Sicherheit auf Zeilenebene und Maskierung
• Arbeitet neben Dawiso für plattformübergreifende Reichweite

BI-eigen. Am besten für Organisationen auf der Landschaft von Google. LookML ist seit mehr als einem Jahrzehnt ein semantisches Modell, und Google hat es um Gemini erweitert, sodass Nutzer Fragen in natürlicher Sprache gegen geregelte Kennzahlen stellen können. Es ist ausgereift und für BI vertrauenswürdig, mit dem Preis, den BI-eigene Schichten gemeinsam haben: Das Modell ist innerhalb von Looker und dem weiteren Umfeld von Google am stärksten und lässt sich weniger gut zu Werkzeugen und Agenten außerhalb davon mitnehmen, eine Bindung an ein BI-Werkzeug, die eine Abwägung wert ist. Für Teams, die auf Microsoft ausgerichtet sind, füllen die semantischen Modelle von Power BI dieselbe BI-eigene Schublade.

Wichtige Fähigkeiten

• Ausgereiftes semantisches Modell LookML, mehr als ein Jahrzehnt alt
• Fragen in natürlicher Sprache über Gemini
• Am stärksten innerhalb von Looker und dem Umfeld von Google

BI-eigen. Am besten für Organisationen mit Microsoft im Zentrum. Die semantischen Modelle von Power BI, die auf DAX gebaute Schicht, die früher Datasets hieß, gehören zu den am weitesten verbreiteten Definitionen von Kennzahlen überhaupt, sind inzwischen Teil von Microsoft Fabric und werden an Copilot gereicht. Für Teams, die ohnehin in Microsoft 365 und Fabric arbeiten, ist das der Weg des geringsten Widerstands. Wie bei Looker sind die Definitionen innerhalb der Microsoft-Landschaft am meisten zu Hause, und eine Schicht darüber hilft, wenn Agenten sie neben Daten von überall sonst lesen sollen.

Wichtige Fähigkeiten

• Auf DAX gebaute semantische Modelle, unter den am weitesten verbreiteten überhaupt
• Teil von Microsoft Fabric, an Copilot gereicht
• Am besten geeignet für Landschaften aus Microsoft 365 und Fabric

Zwei Fragen klären das meiste. Erstens: Wo liegt Ihre Landschaft ohnehin? Wenn Sie tief in einer Plattform stecken, ist ihre hauseigene Schicht der schnellste Anfang. Wenn Sie mehrere betreiben, bewahrt Sie eine reine oder BI-unabhängige Schicht davor, dieselbe Kennzahl in jeder neu zu definieren.

Zweitens, und das ist die für KI wichtigste Frage: Wie werden Agenten diese Definitionen gefahrlos lesen? Ein Semantic Layer reicht einem Agenten eine geregelte Zahl, und viele setzen durch, wer sie abfragen darf. Was er nicht mitliefert, ist der weitere Kontext um diese Zahl herum: ein Katalog des restlichen Bestands, durchgängige Lineage, eine Klassifizierung dessen, was plattformübergreifend sensibel ist, und ein Nachweis, wer jede Definition verantwortet. Ein Agent, der über diese Kennzahlen hinaus ohne diesen Kontext handelt, ist ein Risiko. Die meisten Empfehlungen aus dem Jahr 2026, auch die der Anbieter von Semantic Layern selbst, laufen auf denselben Rat hinaus. Verbinden Sie Ihren Semantic Layer mit einem Context Layer und stellen Sie ihn Agenten über MCP bereit.

Es gibt einen Grund aus der Architektur, diesen Context Layer getrennt zu halten, und einen kaufmännischen. Ein zusammensetzbarer Aufbau, in dem jede Schicht ein bestmögliches Werkzeug ist, das Sie tauschen können, hält Ihre Wechselkosten niedrig. Wenn der Preis eines Warehouse steigt, können Sie diese eine Schicht bewegen, ohne Ihr gesamtes Geschäft neu zu regeln, weil Ihre Definitionen, Ihre Verantwortung und Ihre Lineage in einer Schicht liegen, die Ihnen gehört, statt im Innern des Anbieters, den Sie verlassen. Kontext aus jedem einzelnen Werkzeug herauszuhalten, ist der Weg, eine Bindung an einen Anbieter genau an der Schicht zu vermeiden, die am schwersten neu zu bauen ist. Den Open Semantic Interchange gibt es aus genau diesem Grund: portable Semantik, die keiner einzelnen Syntax ausgeliefert ist.

Dawiso ist dieser Context Layer. Es verbindet sich mit mehr als 40 Plattformen, den Warehouses, BI-Werkzeugen und Transformationsschichten, in denen Ihre Daten und Kennzahlen ohnehin liegen, darunter Snowflake, Databricks, Power BI und dbt aus dieser Liste. Über alle hinweg baut es ein geregeltes Fundament, einen Katalog dessen, was es gibt, ein Business Glossary dessen, was jeder Begriff bedeutet, eine Klassifizierung dessen, was sensibel ist, und durchgängige Lineage, und liefert es an jeden MCP-fähigen Agenten aus. In Dawiso liegen die Bedeutung, die Verantwortung und die Herkunft dieser Kennzahlen, und es hält diesen Kontext so, dass er Ihnen gehört und mitgenommen werden kann.

Der Semantic Layer beantwortet, was die Zahl ist. Dawiso beantwortet, ob Sie ihr trauen können, und lässt jeden Agenten dieselbe vertrauenswürdige Antwort über die Quellen hinweg lesen, die es regelt.