Fabric IQ Ontology vs. Power BI Semantic Model: Was gehört wohin?

Fabric IQ bringt mit Ontologies eine neue semantische Ebene in Microsoft Fabric. Damit entsteht schnell der Eindruck, Unternehmen müssten sich zwischen Ontology und Power BI Semantic Model entscheiden. Genau das wäre die falsche Architekturfrage. Ein gutes Semantic Model bleibt die verlässliche Schicht für Kennzahlen, DAX-Logik, Dimensionen und analytische Beziehungen.

Eine Fabric IQ Ontology ergänzt dort, wo Geschäftskontext über einzelne Analysemodelle hinausgeht: Kunden, Produkte, Aufträge, Verträge oder Ereignisse sollen domänenübergreifend mit ihren Beziehungen, Eigenschaften und Regeln verstanden werden. Entscheidend ist deshalb: Welche Semantik braucht Analytics – und welche brauchen Prozesse und AI Agents? Stand August 2026 gilt außerdem: Fabric IQ wird von Microsoft seit Build 2026 als allgemein verfügbar positioniert, der Ontology-Item selbst ist in Microsoft Learn weiterhin als Preview gekennzeichnet.

Warum Unternehmen jetzt zwei semantische Ebenen haben

Microsoft beschreibt Fabric IQ als Zusammenspiel aus vereinheitlichten Daten in OneLake, Business Intelligence über Power BI Semantic Models und Operational Intelligence über Ontologies. Ein Semantic Model strukturiert Daten für Analyse und Reporting; eine Ontology beschreibt, was Geschäftsobjekte sind, wie sie zusammenhängen und welcher Kontext für Entscheidungen relevant ist.

Überschneidungen bei Begriffen, Entitäten und Beziehungen sind deshalb normal. Es sind zwei Ebenen mit unterschiedlichen Verantwortlichkeiten. Das Semantic Model bleibt der analytische Vertrag für verlässliche Kennzahlen, die Ontology wird zum gemeinsamen Geschäftskontext, wenn mehrere Domänen, Datenquellen oder Agenten dieselben Konzepte konsistent verstehen müssen.

Was das Power BI Semantic Model weiterhin leistet

Power BI Semantic Models sind darauf optimiert, Daten für verlässliche Analysen zu strukturieren. Dazu gehören Dimensionen und Hierarchien, Beziehungen, DAX-Measures, Formatierung und konsistente Kennzahlenlogik. Microsoft beschreibt sie in Fabric IQ ausdrücklich als kuratierte Analytics-Schicht für vertrauenswürdige KPIs und schnelle, interaktive Auswertungen.

Measures bleiben im Semantic Model. Umsatz, Deckungsbeitrag, Forecast-Abweichung oder Kundenprofitabilität sind kontextabhängige Berechnungen: Filter, Zeitbezug, Aggregation und fachliche Regeln bestimmen das Ergebnis. Diese Logik gehört weiterhin in das Semantic Model und sollte nicht in einer Ontology nachgebaut werden.

Das gilt auch für AI-Szenarien. Fabric Data Agents können Semantic Models über DAX abfragen, und Power BI Copilot profitiert von sauber benannten Tabellen, Spalten und Measures, Beschreibungen, Beziehungen sowie den Funktionen zur Vorbereitung von Daten für AI. Wer vor allem bessere Antworten auf analytische Fragen erreichen will, sollte deshalb zuerst das Semantic Model AI-ready machen.

Was Fabric IQ Ontology zusätzlich ermöglicht

Eine Fabric IQ Ontology beschreibt das Unternehmen stärker aus Sicht seiner Geschäftsobjekte. Entity Types wie Customer, Product, Order oder Plant erhalten Properties und Beziehungen; zusätzlich können Regeln und Aktionen Teil dieses gemeinsamen Kontexts werden. Die Definitionen werden an reale Datenquellen gebunden und können Beziehungen graphbasiert nutzbar machen.

Der Mehrwert beginnt jenseits eines einzelnen Analysemodells. Ein Kunde kann gleichzeitig Verträge besitzen, Produkte kaufen, Supportfälle haben, einer Vertriebsregion zugeordnet und von Lieferproblemen betroffen sein. Ein einzelnes Semantic Model könnte vieles davon technisch abbilden, würde aber schnell vom fokussierten Analytics-Modell zum Universalmodell.

Die Ontology ergänzt deshalb die analytische Semantik um domänenübergreifenden Kontext, den Anwendungen und AI Agents gemeinsam verwenden können. Sie ersetzt weder DAX noch ein Sternschema.

Ontology vs. Semantic Model im direkten Vergleich

Der Vergleich wird klarer, wenn nicht nach Features, sondern nach Verantwortung gefragt wird. Beide modellieren fachliche Bedeutung, aber für unterschiedliche Hauptaufgaben.

Kriterium	Power BI Semantic Model	Fabric IQ Ontology
Produktstatus	Etablierte produktive Analytics-Schicht	Ontology-Item aktuell Preview
Primärer Zweck	Analytics, Reporting, KPI-Steuerung	Gemeinsamer Geschäfts- und Operationskontext
Fachliche Semantik	Kennzahlen, Dimensionen, Hierarchien, Metadaten	Entity Types, Properties, Beziehungen, Regeln, Aktionen
Measures / KPIs	Autoritative DAX- und Berechnungslogik	Kontext für KPIs, kein Ersatz für die Measure-Engine
Entitäten	Fakten, Dimensionen und Tabellen im Analysemodell	Geschäftsobjekte als Entity Types
Beziehungen	Für Filterpfade und Analytics optimiert	Domänenübergreifende Relationship Types, graphbasiert nutzbar
Domänenübergreifender Kontext	Möglich, aber nicht Hauptzweck	Kernstärke
Analytics	Primäre Aufgabe	Ergänzend, besonders für Kontext und Beziehungen
AI-Agent-Nutzung	DAX, kuratierte Metriken, Power BI Copilot	Grounding, Domain Knowledge, Beziehungen und Operational Context
Governance	Modell- und KPI-Ownership	Domänenübergreifende Begriffs- und Beziehungs-Ownership
Pflegeaufwand	Etablierter BI-Lifecycle	Zusätzlicher Lifecycle für Definitionen, Bindings und Beziehungen
Typische Szenarien	Reporting, Self-Service, Finance-KPIs, Analyse	Cross-Domain Agents, Operational Intelligence, gemeinsame Geschäftssprache

Measures und KPIs bleiben die Stärke des Semantic Models; domänenübergreifender Geschäftskontext ist die Stärke der Ontology.

Was gehört ins Semantic Model – und was in die Ontology?

Ins Semantic Model gehört alles, was eine verlässliche analytische Antwort definiert: DAX-Measures, Zeitintelligenz, Aggregationslogik, Dimensionen und Hierarchien sowie Beziehungen für Reporting und Analyse. Wenn „Deckungsbeitrag“ im Monatsreport und in einer Agentenantwort identisch sein soll, braucht es eine autoritative Berechnungslogik.

In die Ontology gehören Geschäftsobjekte und Beziehungen, die über ein einzelnes Reporting-Modell hinaus Bestand haben. Wer verantwortet einen Kunden? Welcher Vertrag gilt für welches Produkt? Welche Anlage produziert welches Material? Welcher Lieferverzug betrifft welchen Kundenauftrag? Solche Zusammenhänge sind für Prozessverständnis und Agenten häufig wichtiger als eine weitere Measure.

Semantik nicht duplizieren. Eine Ontology sollte keine zweite Berechnungsschicht für Umsatz oder Marge werden; ein Semantic Model sollte nicht mit jeder operativen Beziehung überfrachtet werden.

Wie Semantic Model und Ontology zusammenspielen

Microsoft unterstützt in Preview die Generierung einer Ontology aus einem bestehenden Semantic Model. Tabellen werden zu Entity Types, Spalten zu Properties und Modellbeziehungen zu Relationship Types. Das ist ein guter Startpunkt, weil vorhandene fachliche Struktur wiederverwendet wird.

Die Generierung ist kein vollständiger semantischer Klon. Bei der Abfrage generierter Direct-Lake-Bindings werden Measures und calculated columns aktuell nicht übernommen; bei Import- und DirectQuery-Modellen sind Datenbindungen für diesen Weg noch stärker eingeschränkt. Die Ontology übernimmt damit nicht automatisch die analytische Berechnungslogik.

Ein robustes Zielbild ist deshalb häufig zweistufig: Das Semantic Model liefert geprüfte KPIs und Analysekontext; die Ontology ergänzt relevante Geschäftsobjekte und Beziehungen. So bleibt die Fachsprache konsistent, ohne Verantwortlichkeiten zu vermischen.

Was sich für Copilot und AI Agents verändert

Eine Ontology ist keine Voraussetzung für Power BI Copilot. Für analytische Fragen innerhalb eines gut abgegrenzten Modells bleibt ein vorbereitetes Semantic Model die wichtigste Grundlage. Benennung, Beschreibungen, geprüfte Measures, Beziehungen und AI-spezifische Konfigurationen beeinflussen direkt, wie zuverlässig DAX-basierte Antworten entstehen.

Bei Fabric Data Agents wird die Kombination interessanter. Microsoft unterscheidet Semantic Models als Quelle für Business-Logik, berechnete Measures und kuratierte Metriken von Ontologies als Quelle für Domain Knowledge und semantischen Integrationskontext. Ein Agent kann damit die Marge aus dem Semantic Model und Beziehungen zwischen Kunde, Vertrag oder Lieferereignis aus der Ontology nutzen.

Der Remote Power BI MCP Server löst wiederum ein anderes Problem: Er stellt einen technischen Zugriffspfad bereit, über den AI Agents Power BI Semantic Models abfragen können. Das ist Tool-Zugriff, nicht automatisch fachliches Grounding. Ontology und MCP können zusammenspielen, sind aber nicht austauschbar.

Praxisbeispiel: Von Kennzahlen zu Geschäftskontext

Nehmen wir ein Unternehmen mit Controlling und Vertrieb. Im Power BI Semantic Model liegen Auftrags- und Umsatzfakten sowie Dimensionen für Kunde, Produkt, Zeit und Vertriebsregion. Measures berechnen Umsatz, Rohertrag, Deckungsbeitrag und Forecast-Abweichung. Diese Kennzahlen sind geprüft und werden in Berichten einheitlich verwendet.

Die Ontology könnte zusätzlich Customer, Product, Contract, Account Manager, Sales Region und Delivery Incident als Geschäftsobjekte beschreiben. Sie modelliert, welcher Kunde welchem Account Manager zugeordnet ist, welche Verträge Produktgruppen abdecken und welche Lieferereignisse konkrete Aufträge oder Kunden betreffen.

Eine Agentenfrage könnte lauten: „Welche A-Kunden haben im laufenden Quartal eine sinkende Marge, sind gleichzeitig von kritischen Lieferproblemen betroffen und wer verantwortet den Account?“ Die Marge kommt aus dem Semantic Model; der Beziehungskontext aus der Ontology. Die Marge sollte dort bleiben, weil im Semantic Model die autoritative KPI-Logik liegt. Die Ontology liefert den Zusammenhang zwischen Kunde, Lieferereignis und Verantwortlichkeit.

Wenn sich eine Frage vollständig aus einem bestehenden Semantic Model beantworten lässt, ist eine Ontology wahrscheinlich unnötig. Wenn analytische Kennzahlen mit Beziehungen aus mehreren Domänen verbunden werden müssen, entsteht ein belastbarer Use Case für beide Ebenen.

Governance wird wichtiger, nicht einfacher

Mit einer zweiten semantischen Ebene steigt der Abstimmungsbedarf. Semantic Models liegen häufig bei BI- oder Analytics-Teams; bei einer Ontology braucht es zusätzlich fachliche Ownership für unternehmensweite Begriffe und Beziehungen. Jemand muss entscheiden, was „Customer“, „Active Contract“ oder „Critical Incident“ bedeutet und wie Änderungen konsistent nachgeführt werden.

Der Preview-Status verschärft diese Anforderung. Microsoft weist darauf hin, dass Ontology-Versionierung derzeit nicht verfügbar ist; auch Datenbindungen und unterstützte Modellmodi haben Einschränkungen. Für produktionskritische Szenarien müssen deshalb Lifecycle, Tests, Änderungsprozesse und Rückfalloptionen mitgedacht werden.

Eine Ontology ist kein Governance-Automat. Sie macht Semantik expliziter und wiederverwendbarer, erhöht aber den Pflegeaufwand. Ohne Verantwortlichkeiten, stabile Schlüssel und einen konkreten Konsumenten entsteht schnell eine zusätzliche Modellschicht, die niemand konsequent betreut.

Wann Unternehmen noch keine Ontology brauchen

Viele Unternehmen brauchen zunächst keine Ontology. Wenn Reporting, Self-Service Analytics und Copilot-Fragen innerhalb klarer Fachdomänen stattfinden und gute Semantic Models die relevanten Kennzahlen und Beziehungen enthalten, liefert die zusätzliche Schicht wenig unmittelbaren Nutzen. Dann sollten zuerst Modellqualität, Dokumentation, Governance und AI Readiness verbessert werden.

Auch ein unaufgeräumtes Datenfundament wird durch eine Ontology nicht automatisch sauber. Fehlende Business Keys, widersprüchliche Kundendefinitionen, uneinheitliche Stammdaten oder ungeklärte Ownership bleiben Architekturprobleme.

Vor einer Einführung sollten mindestens ein konkreter domänenübergreifender Use Case, stabile und fachlich verstandene Datenobjekte sowie ein Owner für die gemeinsame Semantik vorhanden sein. Zusätzlich müssen Preview-Voraussetzungen und Fabric-Tenant-Einstellungen zum geplanten Szenario passen.

Entscheidungshilfe: Drei sinnvolle Architekturpfade

Semantic Model only ist der pragmatische Standard für Reporting, KPI-Steuerung, Self-Service und analytische Copilot-Fragen. Solange ein Modell die relevanten Fragen zuverlässig beantwortet, ist eine weitere semantische Schicht nicht automatisch besser.

Semantic Model plus Ontology wird interessant, wenn dieselben Geschäftsobjekte in mehreren Domänen auftauchen und AI Agents Zusammenhänge über Analytics, operative Daten und Prozesse hinweg verstehen sollen. Das Semantic Model bleibt Quelle für berechnete KPIs, die Ontology liefert gemeinsame Entitäten und Kontext.

Ontology-first kann für einen klar abgegrenzten operativen oder agentischen Use Case sinnvoll sein, auch ohne bestehendes Semantic Model. Für kuratierte BI-Kennzahlen ist das aber kein automatischer Ersatz: Sobald verlässliche, wiederverwendbare KPIs gebraucht werden, bleibt eine dedizierte analytische Schicht sinnvoll.

---

Fazit: Nicht entweder oder, sondern klare Verantwortlichkeiten

Fabric IQ Ontologies ersetzen Power BI Semantic Models nicht. Microsoft positioniert beide innerhalb von Fabric IQ als zusammenarbeitende Ebenen: Semantic Models für vertrauenswürdige Business Intelligence und KPIs, Ontologies für gemeinsamen Geschäftskontext, Beziehungen und agentenfähige Operational Intelligence.

Klare Verantwortlichkeiten sind wichtiger als zusätzliche Artefakte. Entscheidend ist, wo eine Definition gepflegt, wo eine Kennzahl berechnet und welcher Kontext von Menschen, Reports und AI Agents gemeinsam genutzt wird. Für viele Unternehmen heißt das zunächst: Semantic Models stärken. Eine Ontology kommt hinzu, wenn ein konkreter domänenübergreifender Nutzen den zusätzlichen Governance- und Pflegeaufwand rechtfertigt.

---

Der nächste sinnvolle Schritt

Wer klären möchte, ob gute Semantic Models ausreichen oder zusätzlich eine Fabric IQ Ontology sinnvoll ist, sollte mit Use Cases, Verantwortlichkeiten und Zielbild beginnen – nicht mit einem neuen Fabric-Item.

Im Data Strategy Check ordnen wir gemeinsam ein, welche semantischen Ebenen tatsächlich gebraucht werden, welche Governance dazu passt und welche Fabric- oder AI-Use-Cases den zusätzlichen Aufwand rechtfertigen.