Context Layer und Semantikmodell in Microsoft Fabric einfach erklärt

Semantic Layer, Knowledge Graph, Context Layer: Was davon in Microsoft Fabric wirklich existiert (2026)

Alle reden über den Context Layer. Doch die wenigsten Organisationen können sagen, welche Spalte hinter einer einzelnen Kennzahl steckt. Forrester nennt diese fehlende Schicht den „Context Layer" und erklärt sie zur nächsten Evolutionsstufe der KI im Unternehmen. Allerdings verdeckt der Begriff mehr, als er klärt. Denn ein Context Layer ist keine neue Schicht, die man kauft. Er ist die Zusammenführung dreier bereits bestehender Bausteine: Semantic Layer, Knowledge Graph und — konsequent übersehen — die Provenienz der Daten. Dieser Beitrag ordnet zunächst die Begriffe. Anschließend zeigt er, was ein Context Layer in Microsoft Fabric konkret bedeutet und was Microsoft mit Fabric IQ davon liefert. Und schließlich, warum ohne nachweisbare Herkunft jedes „Grounding" nur eine Halluzination mit besserem Vokabular bleibt.

Das Wichtigste in Kürze
Drei Labels, ein Problemfeld: Forresters „Context Layer", Gartners „Context Graph" und die „Ontologie plus Provenienz" der Graph-Community beschreiben denselben Zielzustand — nur aus verschiedenen Blickwinkeln. Semantic Layer ≠ Knowledge Graph: Der eine weiß, wie gerechnet wird, der andere, worüber. Keiner von beiden trägt allein agentische KI. Die vergessene dritte Achse ist Provenienz. Lineage ist der einzige Bestandteil, der sich bottom-up aus dem Bestand parsen lässt — und der einzige, der eine Ontologie falsifizieren kann. Im Fallbeispiel hing eine einzige Faktenspalte an 58 abhängigen Objekten. Zeit ist die vierte Achse: Ohne zeitpunktbezogene Nachvollziehbarkeit lässt sich keine Entscheidung von vor sechs Monaten gegen den damaligen Kontext rekonstruieren. Fabric IQ läuft als Public Preview (Stand August 2026), die Ontologie ausdrücklich als „ontology (preview)". Microsoft geht top-down; der gewachsene Bestand lässt sich nur bottom-up erschließen. Regulatorik ist der Beschleuniger: Nachvollziehbarkeit ist in Europa keine Kür — sie setzt im Enterprise das Budget frei, nicht das Bild vom „Gehirn der Organisation".

Context Layer, Context Graph, Ontologie: Reden alle vom Gleichen?

Kurz gesagt: fast. Drei Fachwelten haben für dasselbe Problemfeld drei Etiketten geprägt, und wer die Herkunft der Begriffe kennt, spart sich die halbe Verwirrung des Marktes.

Forrester spricht vom Context Layer und meint die Schicht, die KI-Systemen sagt, was die Daten bedeuten. Gartner nennt eine sehr ähnliche Konstruktion Context Graph . Die Graph-Community wiederum reagiert auf beide mit einem Schulterzucken — für sie ist das seit Jahren bekannt und heißt Ontologie plus Provenienz . Statt einen dieser Anbieterbegriffe unkritisch zu übernehmen, legen wir die Herkunft offen. Daher treffen wir eine bewusste Wahl: „Context Layer" nutzen wir als Sammelbegriff für den Zielzustand. „Context Graph" verwenden wir dagegen dort, wo die konkrete graphtechnische Umsetzung gemeint ist.

Tabelle 1 — Begriff, Herkunft, Betonung

Woher kommen Semantic Layer und Knowledge Graph?

Antwort vorweg: aus zwei getrennten Disziplinen, die erst durch agentische KI aufeinandertreffen. Das erklärt, warum sie so schwer zusammenpassen.

Der Semantic Layer stammt aus der BI- und Analytics-Welt. Seine Linie reicht von den Business-Objects-Universes über SSAS/Tabular bis zu LookML, dbt und dem Power-BI-Semantikmodell. Sein Versprechen ist Konsistenz: eine Kennzahl, eine Definition, überall gleich. Wer „Umsatz" fragt, bekommt dieselbe Zahl, egal aus welchem Bericht.

Der Knowledge Graph kommt dagegen aus der Wissensrepräsentation — RDF, OWL und SHACL auf der einen, Labeled Property Graphs auf der anderen Seite. Sein Zweck ist ein anderer: Bedeutung und Beziehungen modellieren, unabhängig davon, wo die Daten physisch liegen. Also nicht „wie viel", sondern „was hängt womit zusammen".

Beide sind ausgereift, und beide lösen reale Probleme. Nur eben nicht dieselben. Genau darin liegt der Konflikt, den ein Context Layer auflösen muss.

Semantic Layer vs. Knowledge Graph: Was unterscheidet sie konkret?

Der Unterschied lässt sich in sechs Dimensionen fassen. Er ist fundamental, nicht graduell: Es sind zwei Weltanschauungen, nicht zwei Werkzeuge derselben Familie.

Tabelle 2 — Kernabgrenzung

Die entscheidende Zeile ist die Weltannahme. Ein Semantic Layer arbeitet geschlossen: Was nicht im Modell steht, existiert nicht. Ein Graph arbeitet offen und additiv — neue Beziehungen kommen hinzu, ohne das Modell zu brechen. Für eine KI, die über den Rand des Sterns hinausfragen soll, ist das der ganze Unterschied.

Warum reicht keiner von beiden allein?

Kurz: weil jeder genau dort blind ist, wo der andere sieht. Für agentische KI sind das keine Randfälle, sondern der Normalfall.

Ein Semantic Layer allein kennt keine Prozesse, Policies oder Ereignisse. Er weiß, wie „Deckungsbeitrag" berechnet wird, aber nicht, wer ihn unter welchen Bedingungen ändern darf. Jede Frage außerhalb des vorhandenen Sterns verlangt ein neues Modell, und Mehr-Hop-Beziehungslogik — „welche Lieferverzögerung hing an welchem Vertrag" — ist nicht vorgesehen.

Umgekehrt liefert ein Knowledge Graph allein keine reproduzierbare Kennzahl. Zwar kann er beschreiben, dass Umsatz mit Kunde und Region zusammenhängt. Deterministisch dieselbe Zahl zweimal ausgeben kann er jedoch nicht. Zudem skaliert er bei Aggregation schlecht. Ohne ausführbares Mapping bleibt er deshalb eine PowerPoint-Ontologie: hübsch modelliert, an keine reale Tabelle gebunden.

Merksatz: Der Semantic Layer weiß, wie gerechnet wird. Der Graph weiß, worüber gerechnet wird. Erst zusammen ergeben sie einen belastbaren Kontext.

Provenienz: Warum ist Lineage die entscheidende dritte Achse?

Hier liegt der Kern dieses Textes. Semantic Layer und Knowledge Graph sind beide behauptende Artefakte — jemand hat sie modelliert. Was fehlt, ist die Achse, die beweist , dass die Modellierung mit der Realität übereinstimmt: die Provenienz, technisch abgebildet als Lineage.

Tabelle 3 — Die vier Kantentypen eines Context Graphen

Zwei Dingen machen Data Lineage einzigartig.

Erstens: Lineage ist der einzige bottom-up-fähige Bestandteil. Ontologie- und Semantikprojekte brauchen Workshops, Konsens und Politik — Menschen müssen sich einigen, was ein Begriff bedeutet. Der Lineage-Graph dagegen entsteht durch das Parsen von SQL, M, DAX und RDL. Kein Konsens nötig: Das System sagt die Wahrheit, weil es liest, was tatsächlich ausgeführt wird.

Zweitens: Lineage ist der Falsifikationsmechanismus. Eine Ontologie ist wie ein Bauplan — sie behauptet , „Deckungsbeitrag" sei Umsatz minus variable Kosten. Lineage ist die Bauabnahme: Sie beweist , ob die Implementierung das auch tut. Ohne diese Prüfinstanz ist symbolisches Grounding nur eine Halluzination mit besserem Vokabular — dieselbe Erfindung, jetzt mit Ontologie-Zertifikat.

Wie weit Behauptung und Realität auseinanderliegen, zeigt ein reales Fallbeispiel: Eine einzige Faktenspalte zog über vier Ableitungsebenen 58 abhängige Objekte nach sich, davon 21 reine Filter-Abhängigkeiten. Kein Mensch hatte diese Kette dokumentiert — erst der geparste Graph machte sie sichtbar. Details zur Methodik der spaltengenauen Lineage finden Sie in unserer Pillar Page.

Transparenzfußnote: Das 1:58-Beispiel wurde mit ABIS (DBI Analytics) erhoben; die Konzepte gelten für jeden graphbasierten Lineage-Ansatz.

Warum braucht ein Context Layer eine Zeitachse?

Antwort zuerst: weil Determinismus ohne Zeitbezug nicht haltbar ist. „Dieselbe Frage, dieselbe Antwort" gilt nur, solange man sagen kann — Stand wann?

Kontext ist nicht statisch: Definitionen ändern sich, Regeln werden angepasst, Quellen umgebaut. Wer heute nach dem Umsatz von Q3 fragt, bekommt eine andere Herleitung als vor sechs Monaten — es sei denn, der Context Layer hält beide Stände fest. Dafür braucht jede Kante zwei Zeitstempel: seit wann etwas fachlich gilt (Gültigkeitszeit) und seit wann das System davon weiß (Systemzeit). Diese Bitemporalität ist der einzige Weg, eine Entscheidung gegen den damaligen statt den heutigen Kontext zu rekonstruieren.

In der Analystenliteratur fehlt dieser Punkt fast vollständig. Genau hier wird Auditierbarkeit von einem Adjektiv zu einer technischen Anforderung — und schlägt die Brücke zur Regulatorik weiter unten.

Was ist ein Context Layer — und was macht ihn neu?

Ein Context Layer ist die Konvergenz der genannten Schichten plus einer Laufzeitebene. Das Neue ist nicht die Summe, sondern die dritte Geschwindigkeit, die beide Vorgänger nicht kannten.

Drei Taktungen laufen in einem Modell zusammen: die Ontologie ändert sich langsam, Stamm- und Instanzdaten mittelschnell, Ereignisse und Ergebnisse schnell. Semantic Layer und Knowledge Graph decken die ersten beiden ab. Die dritte — der kontinuierliche Strom aus Ereignissen — fehlte bisher.

Die praktisch wichtigste Beobachtung dazu: Die ersten realen Laufzeit-Ereignisse einer Organisation sind keine Geschäftsereignisse, sondern Schema-Änderungen, Deployments, Refreshes und gebrochene Berichte. Ein Context Layer beginnt nicht mit „Kunde hat gekündigt", sondern mit „Spalte wurde umbenannt" — der erste Laufzeit-Layer einer Organisation ist ihr eigenes Änderungsprotokoll.

Was lässt die Analystendefinition offen?

Forrester beschreibt einen überzeugenden Zielzustand — und lässt die kniffligen Fragen offen. Vier Leerstellen entscheiden in der Praxis über Erfolg oder Ontologie-Friedhof.

Tabelle 4 — Was offenbleibt, und wie es real aussieht

Graphbasierte Plattformen leisten das heute bereits (ABIS ist ein Beispiel). Der Punkt ist nicht das Produkt, sondern die Einsicht: Ein Context Layer braucht ein Aktionsmodell , Policies als Guardrails und vor allem Kontextauswahl statt Kontextvollständigkeit . Ein vollständiger Graph, ungefiltert in den Prompt gekippt, ist kein Kontext, sondern Rauschen. Die eigentliche Frage lautet: Welchen Ausschnitt bekommt dieser Agent für diese Frage? Kontext ist ein Retrieval-Problem mit Budget.

In der ABIS Data Lineage kann man im Vergleich zu Microsoft Fabric bis auf die Spalten und einzelnen Visuals herunter scannen und analysieren. Hier zum Beitrag mit Details.

Ist ein Context Layer nur ein Data Catalog mit Graph-Anstrich?

Ehrliche Antwort: vom Umfang her fast. Neu ist nicht der Scope, sondern der Adressat.

Ein Data Catalog beschreibt Datenbestände für einen Menschen, der liest und interpretiert. Ein Context Layer wird von einer Maschine zur Laufzeit abgefragt — und die Maschine handelt anschließend danach. Genau deshalb reicht Beschreibung nicht mehr. Der Sprung ist von beschreibend zu ausführbar , nicht von klein zu groß. Ein Katalog, den nur ein Mensch liest, darf ungenau sein; ein Katalog, auf den ein Agent eine Schreiboperation stützt, darf es nicht.

Woran scheitern Context-Layer-Projekte in der Praxis?

Nicht an der Technik. Sie scheitern an drei Stellen, die in keinem Anbieter-Whitepaper stehen — und an denen auch der hier beschriebene Ansatz seine ehrlichen Grenzen hat.

• Identitätsauflösung über Quellen. „Quellenübergreifend, Identität statt Join-Key" liest sich als Vorteil. In Wahrheit ist es der Posten, an dem Projekte sterben: Der Kunde in SAP ist nicht der Kunde im CRM, und beide sind nicht der Kunde im Lakehouse. Diese Auflösung über Systemgrenzen hinweg bleibt ein offenes Problem — auch für graphbasierte Ansätze.

• Der Ontologie-Friedhof. Modelliert, nie ausgeführt, nach 18 Monaten tot. Die Konsequenz: aus Lineage wachsen, nicht aus Workshops. Ein rein technischer Lineage-Graph ist allerdings noch kein echtes semantisches Overlay mit Klassen, Relationen und Axiomen — dieser Schritt bleibt Arbeit.

• Ownership. Governance, BI-Team und Plattform-/AI-Team besitzen je einen Teil, keiner das Ganze. In DACH-Konzernen ist das der eigentliche Blocker, nicht die Technik. Und: Wo die Zeitachse nur über Versionsstände abgebildet ist, ist sie noch nicht voll bitemporal — auch das ist ehrlich zu benennen.

Woran misst man den Erfolg eines Context Layers?

An Kennzahlen, nicht an Adjektiven. Vier Messgrößen trennen ein tragfähiges Vorhaben von einer teuren Präsentation:

1. Abdeckung: Anteil der Kennzahlen mit spaltengenauer Lineage-Abdeckung.

2. Belegbarkeit: Anteil der KI-Antworten mit nachvollziehbarer Herleitung.

3. Reproduzierbarkeit: Reproduktionsrate identischer Fragen über die Zeit.

4. Reaktionsfähigkeit: Dauer einer Impact-Analyse vor einer geplanten Änderung. Diese vier Zahlen sind zugleich der Reifegrad-Maßstab: Wo sie steigen, entsteht Vertrauen; wo sie stagnieren, ist der Context Layer ein Katalog mit Graph-Anstrich geblieben. Die Reifegradstufen beschreiben wir in der Pillar Page.

Context Layer Microsoft Fabric: Was liefert Fabric IQ — und was fehlt?

Kurzantwort: Einen Context Layer in Microsoft Fabric liefert Microsoft mit Fabric IQ als genau diese Konvergenz — top-down und cloud-resident. Der gewachsene Bestand einer Organisation lässt sich allerdings nur von unten erschließen. Beide Richtungen treffen sich in der Mitte; nur eine davon startet ohne Projektbudget.

Niemand kauft einen fertigen Context Layer. Man setzt ihn aus Bausteinen zusammen: Katalog, Lineage, semantisches Modell, Ontologie beziehungsweise Graph und Event-Log. Microsofts Antwort heißt Fabric IQ . Der Fabric-IQ-Workload läuft Stand August 2026 als Public Preview ; die Ontologie ist ausdrücklich als „ontology (preview)" gekennzeichnet. Laut Microsoft Learn bilden „ontology (preview)" und „semantic model" die beiden Kern-Items des Workloads. Der Ansatz ist damit klar top-down: eine Ontologie auf Basis bestehender Power-BI-Semantikmodelle , ergänzt um Graph in Fabric. Auf diese Weise versucht Microsoft, beide Herkunftsfamilien in eine Plattform zu bringen.

Die Gegenrichtung kommt aus dem Bestand: bottom-up, aus dem Lineage-Graphen des real Vorhandenen. Ihr Vorteil ist der Einstiegspfad — eine top-down-Ontologie braucht Modellierung, Konsens und Freigaben; ein bottom-up-Graph braucht nur, dass jemand am Montag den Bestand parst. Für gewachsene, teils undokumentierte Landschaften ist das der entscheidende Unterschied. Keine Wettbewerbsbewertung, sondern eine Richtungsaussage: Wer beide kombiniert, kommt in der Mitte schneller an. Was Microsoft rund um agentische BI insgesamt angekündigt hat, ordnen wir in unserem Rückblick auf die Microsoft Build 2026 ein.

Warum macht Regulatorik den Context Layer dringlich?

Weil Nachvollziehbarkeit in Europa keine Kür ist. Und weil ein Context Layer mit Provenienz und Zeitachse die einzige technische Antwort auf die Frage ist: „Warum hat das System das entschieden?" — auch noch sechs Monate später.

Der regulatorische Druck speist sich aus mehreren Quellen. Dazu zählen die Rechenschaftspflicht der DSGVO und die sektorale Aufsicht (BaFin, Solvency II, GxP, BNetzA). Hinzu kommen die Dokumentations- und Protokollierungspflichten des EU AI Act. Diese greifen allerdings nur dort, wo ein KI-System tatsächlich in eine Hochrisiko-Kategorie fällt.

Wichtig zur Einordnung: Ein BI-Dashboard ist nicht automatisch ein Hochrisiko-System. Die Transparenzpflichten aus Artikel 50 knüpfen zudem an funktionale Kategorien an (etwa Chatbots, generative oder agentische Ausgaben), nicht an eine Risikostufe. Sobald ein Agent jedoch eigenständig handelt, verschiebt sich die Frage von „wer darf das sehen" zu „wer darf darauf handeln". Und beides muss belegbar sein. Genau das setzt im Enterprise das Budget frei — nicht das Bild vom „Gehirn der Organisation". Ergänzend kommt ein Architekturargument gegenüber reinen Cloud-Katalogen hinzu: die lokale Verarbeitung struktureller Metadaten statt Zeilendaten.

Fazit: Wie lässt sich ein Context Layer präzise definieren?

Wer die drei — besser vier — Achsen zusammenzieht, kann den Begriff schärfer fassen, als es die Analystenliteratur tut:

Ein Context Layer ist die ausführbare Weiterentwicklung des Metadatenmanagements. Er führt Business-Semantik, Ontologien und Governance zu einem gemeinsamen Modell zusammen, verankert es über ausführbare Mappings in den realen Daten- und Prozesssystemen, hält jeden Stand zeitpunktbezogen nachvollziehbar und aktualisiert sich kontinuierlich aus Ereignissen, Entscheidungen und Ergebnissen — damit KI-Systeme nicht nur Antworten erzeugen, sondern nachvollziehbar schlussfolgern und innerhalb definierter Regeln handeln können.

Drei Wörter machen den Unterschied: ausführbar , zeitpunktbezogen , regelgebunden . Wer einen Context Layer in Microsoft Fabric plant, kombiniert daher zwei Richtungen: die top-down-Ontologie von Fabric IQ und einen bottom-up-Lineage-Graphen aus dem Bestand. Die eine liefert die Bedeutung, der andere den Beweis. Der pragmatische erste Schritt ist deshalb eine spaltengenaue Lineage-Analyse Ihres Bestands — ganz ohne Ontologie-Projekt.

Bleibt eine Frage an die Community: Was fehlt in dieser Definition?

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen Semantic Layer und Knowledge Graph?

Ein Semantic Layer beantwortet „wie viel" — er definiert Kennzahlen, Dimensionen und Hierarchien reproduzierbar über einem Datenmodell. Ein Knowledge Graph beantwortet dagegen „wie hängt was zusammen und warum" — er modelliert Klassen, Relationen und Regeln quellenübergreifend. Kurz gesagt: Der eine weiß, wie gerechnet wird, der andere, worüber .

Was ist ein Context Layer?

Als Context Layer bezeichnet man die ausführbare Zusammenführung von Business-Semantik, Ontologie, Governance und Provenienz zu einem gemeinsamen Modell, das über reale Daten- und Prozesssysteme verankert ist. Er sagt KI-Agenten nicht nur, was Daten bedeuten. Darüber hinaus belegt er deren Herkunft und hält jeden Stand zeitpunktbezogen nachvollziehbar.

Was ist Fabric IQ?

Fabric IQ ist Microsofts Intelligenz-Schicht innerhalb von Microsoft Fabric, die rohe Unternehmensdaten in eine geteilte Ontologie überführt und Agenten wie Menschen einen konsistenten Geschäftskontext liefert. Der Fabric-IQ-Workload läuft Stand August 2026 als Public Preview, die Ontologie ausdrücklich als „ontology (preview)".

Kann man aus einem Power BI Semantic Model eine Ontologie erzeugen?

Ja — genau das ist Microsofts top-down-Ansatz. Fabric IQ generiert die Ontologie aus einem bestehenden Power-BI-Semantikmodell und lässt Teams sie zu reichhaltigeren Entitäten und Beziehungen erweitern. Das semantische Modell liefert dabei die Kennzahlen-Definitionen, die Ontologie ergänzt fachliche Relationen darüber.

Braucht ein Context Layer eine Ontologie, oder reicht Lineage?

Beides erfüllt unterschiedliche Aufgaben. Die Ontologie liefert die Bedeutung, Lineage liefert den Beweis, dass die Implementierung dieser Bedeutung entspricht. Lineage lässt sich als einziger Bestandteil bottom-up aus dem Bestand parsen und ist damit der pragmatische Einstieg — die Ontologie folgt idealerweise darauf, nicht umgekehrt.

Warum reicht ein Data Catalog nicht als Context Layer?

Ein Data Catalog beschreibt Daten für einen Menschen, der liest und interpretiert. Ein Context Layer wird von einer Maschine zur Laufzeit abgefragt, die anschließend handelt. Der Unterschied ist nicht der Umfang, sondern der Sprung von beschreibend zu ausführbar — Beschreibung darf ungenau sein, eine Handlungsgrundlage nicht.

Was hat ein Context Layer mit dem EU AI Act zu tun?

Ein Context Layer mit Provenienz und Zeitachse ist die technische Antwort auf die Nachvollziehbarkeitsfrage „Warum hat das System das entschieden?". Er ist relevant für Dokumentations- und Protokollierungspflichten, sofern ein KI-System tatsächlich als hochrisikoreich eingestuft ist. Ein BI-Dashboard ist nicht automatisch Hochrisiko; die Transparenzpflichten aus Artikel 50 knüpfen an funktionale Kategorien an, nicht an Risikostufen.

Quellen & Weiterführendes: Forrester — The Next Evolution Of AI Will Rely On Context Layers; Microsoft Learn — What is Fabric IQ? (learn.microsoft.com/fabric/iq/overview); Microsoft Learn — What is Ontology (preview)? (learn.microsoft.com/fabric/iq/ontology/overview); Microsoft Learn — Generating an Ontology from a Semantic Model (learn.microsoft.com/fabric/iq/ontology/concepts-generate); Microsoft Fabric — Fabric IQ (Public Preview, vorgestellt Build 2026). Interne Quelle: Pillar Page „Automatisierte Data Lineage in Power BI und Microsoft Fabric" (Reifegradmodell, 1:58-Fallbeispiel). Juristische Aussagen zu DSGVO/EU AI Act sind vor Veröffentlichung fachlich gegenzulesen.