.png){kind=small}
Fabric Data Agents: Die Einführung
Aktualisiert: 9. Sept.
abric Data Agents versprechen einen deutlich direkteren Zugang zu Unternehmensdaten: Fachanwender stellen Fragen in natürlicher Sprache und erhalten Antworten aus vorhandenen Datenquellen, ohne selbst SQL, DAX oder KQL schreiben zu müssen. Entscheidend ist aber nicht die Chatoberfläche. Entscheidend ist, ob Daten, Semantik, Berechtigungen und fachlicher Scope gut genug vorbereitet sind, damit aus einer plausiblen Antwort auch eine belastbare Antwort wird.
Fabric Data Agents stehen für einen nächsten Schritt von Self-Service BI zu Agentic Analytics. Statt immer den richtigen Report zu suchen, Filter zu verstehen oder eine Ad-hoc-Auswertung beim BI-Team anzufragen, können Anwender Fragen direkt gegen vorbereitete Datenquellen stellen.
Der entscheidende Punkt: Ein Fabric Data Agent macht schlechte Daten nicht gut. Er macht die Qualität – oder die Schwächen – einer bestehenden Analytics-Landschaft schneller sichtbar.
Was ist ein Fabric Data Agent?
Ein Fabric Data Agent ist eine dialogorientierte Analyseschicht in Microsoft Fabric. Nutzer stellen fachliche Fragen wie „Welche Region liegt im aktuellen Quartal unter Plan?“ oder „Welche Produktgruppen erklären den Margenrückgang?“
Der Agent plant die Beantwortung, wählt eine geeignete Datenquelle aus und verwendet ein passendes integriertes Query-Tool. Je nach Quelle entsteht beispielsweise SQL, DAX oder KQL. Die Abfrage läuft lesend auf den Daten, anschließend formuliert der Agent daraus eine Antwort.
Damit ist ein Fabric Data Agent weder klassischer Report noch Datenpipeline. Er ist eine zusätzliche Zugriffsschicht zwischen Geschäftsfrage und vorhandener Datenplattform.
Welche Datenquellen können Fabric Data Agents heute nutzen?
Das Spektrum ist inzwischen deutlich größer als zum Start. Ein Data Agent kann mehrere Quellen kombinieren und damit unterschiedliche Analytics- und Wissenskontexte zusammenführen.
Lakehouse
Fabric Data Warehouse
Fabric SQL Database
Mirrored Databases
Eventhouse / KQL Database
Power BI Semantic Models
Graph Models – Preview
Fabric Ontologies – Preview
Azure AI Search Index – Preview
Ein einzelner Data Agent kann bis zu fünf Datenquellen kombinieren. Damit können strukturierte, semantische, Real-Time- und – über Azure AI Search – auch unstrukturierte Informationsquellen in einem Agent zusammengeführt werden.
Der Data Agent entscheidet selbst zwischen Datenquellen
Sobald mehrere Datenquellen verbunden sind, muss der Agent zunächst entscheiden, welche Quelle für eine Frage die richtige ist. Dafür nutzt der Orchestrator unter anderem Namen und Beschreibungen der Quellen, ausgewählte Tabellen und Felder, Schema-Metadaten, Beispielabfragen und Routing-Regeln in den Agent Instructions.
Seit August 2026 ist dieses Data-Source-Routing allgemein verfügbar. Die Routing-Entscheidung ist außerdem in den Run Steps nachvollziehbar. Das ist ein wichtiger Reifegradschritt, weil ein Agent mit mehreren Quellen nicht nur gute Abfragen erzeugen, sondern zuerst zuverlässig entscheiden muss, wo überhaupt gesucht werden soll.
Gute Datenquellenbeschreibungen werden zur Architekturkomponente
Eine Beschreibung wie „Sales Data“ hilft dem Agenten kaum. Besser ist eine Beschreibung, die Domäne, enthaltene Daten und typische Fragestellungen klar benennt.
Metadaten sind für Agentic Analytics keine Dokumentation neben dem System – sie werden Teil des Systemverhaltens.
Standard Runtime oder Preview Runtime?
Microsoft unterscheidet inzwischen zwischen einer Standard Runtime und einer Preview Runtime. Die Standard Runtime ist GA, Default für neue Data Agents und für stabilen produktiven Betrieb gedacht. Die Preview Runtime erhält neue Query-Generation-, Routing- und Orchestrierungsverbesserungen früher und kann ihr Verhalten deshalb häufiger ändern.
Runtime-Änderungen gehören getestet wie Änderungen am Datenmodell oder an den Instructions. Für produktive Agents ist die Standard Runtime in der Regel der sinnvollere Ausgangspunkt; Preview-Funktionen sollten zuerst in Testumgebungen evaluiert werden.
Advanced NL2SQL und Advanced DAX: Was die Preview Runtime verbessert
Advanced NL2SQL verbessert vor allem die Übersetzung komplexer natürlicher Sprache in SQL. Die Preview Runtime orientiert sich stärker an Beispielabfragen, kann implizite Filterwerte besser ableiten und fragt bei Mehrdeutigkeiten gezielter nach, bevor SQL generiert wird.
Advanced DAX geht einen Schritt weiter. Bei komplexeren Fragen plant die Preview Runtime mehrere Schritte, prüft Zwischenergebnisse und durchsucht Werte im Semantikmodell, um passende Filterwerte zu finden. Erst danach wird die finale DAX-Abfrage formuliert.
Für Power-BI-Semantikmodelle ist das ein relevanter Fortschritt – aber weiterhin Preview. Die Funktion sollte mit repräsentativen Geschäftsfragen, Grenzfällen und bekannten Soll-Antworten getestet werden. Ein schwaches Datenmodell oder unklare Measures werden dadurch nicht automatisch repariert.
Das Power-BI-Semantikmodell bleibt ein wichtiger Qualitätshebel
Für viele Unternehmen wird das Power-BI-Semantikmodell weiterhin eine besonders attraktive Quelle sein. Dort liegen bereits Measures, Beziehungen, fachliche Bezeichnungen, Hierarchien, Security, Formatierungen und Geschäftslogik.
Technisch korrekte DAX-Abfragen können fachlich trotzdem die falsche Kennzahl verwenden. Deshalb gilt: Gute Modelle schlagen gute Prompts.
Wie Modelle gezielt für KI vorbereitet werden, behandeln wir in Semantische Modelle AI-ready.
Enger fachlicher Scope bleibt wichtiger als maximale Datenmenge
Ein Agent für „alle Unternehmensdaten“ klingt ambitioniert, ist für einen ersten produktiven Einsatz aber meist eine schlechte Idee. Je mehr Domänen, Kennzahlen, Quellen und Begriffe gleichzeitig im Spiel sind, desto mehr Routing- und Interpretationsentscheidungen muss der Agent treffen.
Begrenzte Domänen lassen sich deutlich besser testen, steuern und optimieren.
Der erste Schritt sollte deshalb nicht die technische Konfiguration sein. Zuerst müssen die relevanten Geschäftsfragen klar definiert werden.
Antworten sind nicht auf Text beschränkt
Fabric Data Agents können inzwischen neben Text und Tabellen auch visuelle Antworten erzeugen – etwa Linien-, Säulen-, Flächen-, Kreis- oder Scatter-Diagramme. Diese Funktion befindet sich noch in Preview.
Der Data Agent ersetzt damit weiterhin kein kuratiertes Management-Dashboard. Er ergänzt standardisiertes Reporting um explorative Anschlussfragen.
Normale Antworten sind außerdem bewusst begrenzt und keine Datenexport-Funktion. Für Massendaten, operative Exporte oder nachgelagerte Verarbeitung bleiben APIs, SQL, Notebooks und andere Datenzugriffe die sinnvollere Wahl.
MCP macht den veröffentlichten Data Agent zu einem wiederverwendbaren Tool
Ein veröffentlichter Fabric Data Agent kann als MCP Server genutzt werden. Dann wird er von einem kompatiblen AI-System als Tool angesprochen – zum Beispiel aus einer eigenen Anwendung, Entwicklungsumgebung oder einem anderen Agent. Die Funktion befindet sich weiterhin in Preview.
Strategisch wird der Data Agent dadurch von einer einzelnen Fabric-Oberfläche zu einer wiederverwendbaren Unternehmensdaten-Schnittstelle für AI-Systeme.
API, SDK, CI/CD und MCP im Detail behandeln wir im Deep Dive Fabric Data Agent API & SDK: Automatisierung, CI/CD und MCP.
Assistants API beendet: MCP und Responses API sauber unterscheiden
Der frühere externe Consumption-Pfad auf Basis von beta.assistants, Threads und Runs ist seit dem 26. August 2026 nicht mehr verfügbar. Für externe Anwendungen, die diesen Pfad genutzt haben, verweist Microsoft auf den MCP-Endpunkt eines veröffentlichten Data Agents.
Parallel stellt Microsoft im Fabric Data Agent Python SDK den Abfrage-Client von der Assistants API auf einen Responses Client um. Das ist kein Widerspruch: MCP beschreibt die veröffentlichte Runtime- und Consumption-Schnittstelle; der Responses Client betrifft die Query-Code-Migration innerhalb des SDK.
Der Fabric Data Agent selbst ist davon nicht betroffen. Für neue Integrationen sollte deshalb nicht mehr mit der alten Assistants-Architektur geplant werden; entscheidend ist, welcher Consumption-Weg zur Anwendung und zum Betriebsmodell passt.
Die Integration in Copilot in Power BI ist seit dem 26. August beendet
Die spezifische Integration von Fabric Data Agents in Copilot in Power BI ist seit dem 26. August 2026 eingestellt.
Das bedeutet nicht, dass Fabric Data Agents eingestellt wurden. Microsoft entwickelt andere Consumption-Kanäle weiter. Deshalb sollte die Architektur nicht um eine einzelne Chatoberfläche herum gebaut werden.
Die stabilere Denkweise lautet: Fabric Data Agent = fachlicher Analytics-Agent. Consumption-Kanal = austauschbare Zugriffsschicht.
Welche Consumption-Wege bleiben?
Nach dem Retirement der Power-BI-Copilot-Integration gibt es weiterhin mehrere relevante Wege, einen veröffentlichten Fabric Data Agent zu verwenden: Fabric selbst, Microsoft 365 Copilot, Microsoft Copilot Studio, Microsoft Foundry, MCP und eigene Anwendungen.
Der eigentliche Wert liegt weniger in einer einzelnen Oberfläche als darin, dass dieselbe kuratierte Analytics-Logik über unterschiedliche Agenten- und Anwendungskontexte wiederverwendet werden kann.
Copilot Studio wird zu einem besonders interessanten Integrationsweg
Ein Fabric Data Agent kann in Copilot Studio als Tool über Fabric IQ Data MCP eingebunden werden. Der Copilot-Studio-Agent entscheidet anhand der Beschreibung und seiner Instructions, wann der Fabric Data Agent für eine Benutzerfrage aufgerufen werden soll.
Die Beschreibung eines Data Agents beeinflusst damit nicht mehr nur Menschen, sondern zunehmend auch andere Orchestratoren.
Bei Copilot Studio wird die verwendete Identität zur Architekturentscheidung
Beim Zugriff auf einen Fabric Data Agent kann die verwendete Identität Teil des Architektur- und Governance-Modells werden. Je nach Konfiguration greift der übergeordnete Agent mit der Identität des Nutzers oder einer eingerichteten Maker-Identität auf den Data Agent und dessen Datenquellen zu.
Damit ist die Wahl des Authentifizierungsmodus eine echte Security- und Governance-Entscheidung und nicht nur technische Konfiguration.
Microsoft 365 Copilot bringt den Agent zum Business-Nutzer
Fabric Data Agents können in Microsoft 365 Copilot veröffentlicht und dort von Business-Nutzern verwendet werden. Damit lassen sich Unternehmensfragen an den kuratierten Analytics-Agent stellen, ohne dass der Nutzer zunächst in Microsoft Fabric arbeiten muss.
Der Consumption-Kanal verändert nicht nur die User Experience, sondern kann auch die relevante Compliance- und Verarbeitungsgrenze verändern.
Foundry verbindet Fabric Data Agents mit breiteren AI-Anwendungen
Auch Microsoft Foundry kann Fabric Data Agents in agentischen AI-Szenarien verwenden. Ein übergeordneter Agent kann unterschiedliche Werkzeuge und Wissensquellen kombinieren und den Fabric Data Agent gezielt einsetzen, wenn analytische Unternehmensdaten benötigt werden.
Damit wird der Fabric Data Agent zu einer spezialisierten Analytics-Fähigkeit innerhalb größerer AI-Systeme.
RLS, CLS und Datenquellenrechte bleiben wirksam
Der Data Agent hebt bestehende Security nicht auf. Bei Power-BI-Semantikmodellen reicht für das Abfragen über den Agent Read Permission; RLS und CLS bleiben wirksam.
Gleichzeitig reicht die Freigabe des Agenten allein nicht. Der aufrufende Benutzer oder Service Principal benötigt auch Zugriff auf die tatsächlich verwendeten zugrunde liegenden Datenquellen.
Die richtige Denkweise lautet deshalb: Agent-Berechtigung + Datenquellen-Berechtigung + fachliche Security.
Service Principals öffnen den Weg für Anwendungen und Automatisierung
Für nicht-interaktive Szenarien unterstützt Fabric Data Agent inzwischen auch Service Principals. Damit können eigene Anwendungen, Hintergrunddienste und Automatisierungen einen veröffentlichten Agent ansprechen. Die Funktion befindet sich derzeit noch in Preview.
Fabric Data Agents sind damit nicht mehr auf einen menschlichen Benutzer in der Fabric-Chatoberfläche beschränkt.
Ein Data Agent sollte wie ein Analytics-Produkt betrieben werden
Ein überzeugender Demo-Chat ist schnell gebaut. Produktionsreife braucht mehr: Diagnostik, Evaluation, Source Control, Deployment, Runtime-Entscheidungen und einen klaren Änderungsprozess.
fachlicher Owner für Scope und Geschäftsbegriffe
Data Owner für Datenqualität und Zugriff
Modellverantwortung für Semantic Model beziehungsweise Datenquelle
technischer Owner für Runtime, Deployment und Monitoring
Ein Fabric Data Agent ist langfristig kein Chatbot, sondern ein betriebenes Analytics-Artefakt.
So sollte ein Pilot aufgebaut werden
Ein sinnvoller Pilot beginnt nicht mit der Agent-Konfiguration, sondern mit echten Geschäftsfragen aus dem Arbeitsalltag.
Welche Datenquelle beantwortet die Frage?
Ist die Kennzahl eindeutig?
Ist der fachliche Scope klar?
Welche Security gilt?
Welche Antwort gilt als korrekt?
Welche Varianten der Frage müssen ebenfalls funktionieren?
Nicht der Agent sollte definieren, welche Fragen wichtig sind. Die Geschäftsfragen sollten definieren, wie der Agent gebaut wird.
Pilot-Checkliste für Unternehmen
klarer Use Case
klar abgegrenzte fachliche Domäne
reale Testfragen
stabile Datenquellen
definierte Kennzahlen
gepflegte Metadaten
Routing zwischen Quellen getestet
RLS/CLS und Zugriffsrechte geprüft
Standard- oder Preview-Runtime bewusst gewählt
fachlicher Owner definiert
Qualitätskriterien für Antworten festgelegt
Deployment- und Änderungsprozess vorhanden
Fabric Data Agents sollten nicht eingeführt werden, weil KI gerade spannend ist. Sie sollten eingeführt werden, wenn sie ein reales Analyseproblem besser lösen als bestehende Wege.
Fazit: Data Agents testen nicht nur KI – sie testen Analytics-Reife
Fabric Data Agents können den Zugang zu Unternehmensdaten deutlich vereinfachen. Die eigentliche Innovation liegt aber nicht darin, dass Nutzer Fragen in natürlicher Sprache stellen können, sondern darin, dass aus vorhandenen Datenmodellen wiederverwendbare, dialogorientierte Analytics-Schnittstellen entstehen.
Datenqualität, Semantik, Routing, Security, fachlicher Scope und Betriebsmodell entscheiden stärker über die Qualität als die Chatoberfläche selbst.
Wer diese Grundlagen beherrscht, kann Fabric Data Agents sinnvoll in Richtung Agentic Analytics weiterentwickeln. Wer sie nicht beherrscht, bekommt durch den Agenten vor allem schneller gezeigt, wo die Analytics-Landschaft noch nicht belastbar genug ist.
Der nächste sinnvolle Schritt
Wenn ihr prüfen möchtet, ob Fabric Data Agents in eurer Datenlandschaft sinnvoll einsetzbar sind, sollte der Einstieg nicht mit einem breiten Rollout beginnen.
Im Microsoft Fabric Kick-Start beziehungsweise in der Microsoft Fabric Beratung können Use Cases, Datenquellen, Semantic Models, Security und Betriebsmodell gemeinsam bewertet und ein fokussierter Pilot definiert werden.
FAQ zu Fabric Data Agents
Was sind Fabric Data Agents?
Fabric Data Agents ermöglichen es, Unternehmensdaten in Microsoft Fabric über natürliche Sprache abzufragen. Der Agent interpretiert Fragen, wählt passende Datenquellen und erzeugt lesende Abfragen gegen die vorbereiteten Daten.
Ersetzen Fabric Data Agents klassische Power-BI-Reports?
Nein. Reports bleiben wichtig für standardisierte Steuerung, Monitoring und abgestimmte KPI-Sichten. Data Agents ergänzen diese Welt durch dialogorientierte Antworten auf Anschlussfragen.
Welche Datenquellen können Fabric Data Agents nutzen?
Unter anderem Power BI Semantic Models, Lakehouses, Warehouses, Fabric SQL Database, Mirrored Databases, Eventhouse/KQL sowie Preview-Quellen wie Ontologies, Graph Models und Azure AI Search.
Sind Fabric Data Agents sicher?
Sie berücksichtigen die Berechtigungen der zugrunde liegenden Datenquellen. Bei Power BI Semantic Models bleiben RLS und CLS wirksam. Für externe MCP-Clients muss zusätzlich geprüft werden, wo Antworten verarbeitet oder gespeichert werden.
Welche Runtime sollte produktiv genutzt werden?
Für produktive Agents ist die GA Standard Runtime in der Regel der stabilere Ausgangspunkt. Preview Runtime sollte eingesetzt werden, wenn neue Funktionen bewusst getestet und mögliche Verhaltensänderungen akzeptiert werden.
