Fabric Data Agents und Azure AI Search: strukturierte und unstrukturierte Daten verbinden

Fabric Data Agents und Azure AI Search lassen sich inzwischen in beide Richtungen verbinden. Genau das macht das Thema nützlich – und gleichzeitig leicht missverständlich. Denn „Data Agent mit AI Search verbinden“ kann zwei grundsätzlich verschiedene Architekturen meinen: Entweder holt sich der Fabric Data Agent unstrukturierte Inhalte aus einem Azure-AI-Search-Index. Oder Azure AI Search nutzt den Fabric Data Agent als Remote Knowledge Source für Live-Analysen. Wer diese Richtungen vermischt, trifft schnell falsche Entscheidungen zu Ingestion, Aktualität und Berechtigungen.

Die wichtigste Unterscheidung zuerst

Richtung A: Azure AI Search → Fabric Data Agent. Ein vorhandener Azure-AI-Search-Index wird als Datenquelle in den Fabric Data Agent eingebunden. Das ist sinnvoll, wenn eine Fabric-zentrierte Conversational-Analytics-Erfahrung strukturierte oder semantische Daten mit Dokumenten wie PDFs und Texten kombinieren soll.

Richtung B: Fabric Data Agent → Azure AI Search. Der Fabric Data Agent wird als Remote Knowledge Source einer Azure-AI-Search-Knowledge-Base verwendet. Das ist sinnvoll, wenn ein Azure-/Foundry-zentrierter Agent neben anderen Wissensquellen aktuelle analytische Antworten aus Fabric beziehen soll.

Beide Wege sind am 24. August 2026 Preview. Sie lösen unterschiedliche Probleme und sollten nicht als austauschbare Varianten derselben Integration behandelt werden.

Richtung A – unstrukturierte Dokumente in Fabric Data Agent holen

Microsoft unterstützt Azure AI Search als Datenquelle eines Fabric Data Agents. Ein Search Index kann unstrukturierte Inhalte wie PDFs, Textdateien oder angereicherte Dokumente enthalten.

Der Data Agent verbindet sich über die Resource URL mit dem Index. Bei einer Frage sendet er eine Suchanfrage unter Berücksichtigung der Nutzeridentität, erhält relevante Dokument-Chunks und nutzt sie zur Antwort. Wenn der Index geeignete URL- oder Dateipfadfelder enthält, kann der Agent Zitate automatisch in die Antwort aufnehmen.

Ein Data Agent kann bis zu fünf Datenquellen zusammenführen. Damit kann eine Konversation beispielsweise ein Power-BI-Semantikmodell, ein Lakehouse und einen Azure-AI-Search-Index gemeinsam nutzen. Ein realistisches Szenario wäre Vertriebsanalyse: Das semantische Modell liefert Umsatz, Marge und Pipeline-KPIs, während im Search Index Produktdokumentation, Angebotsunterlagen und Richtlinien liegen.

Was bei Richtung A technisch wichtig ist

Die Azure-AI-Search-Integration ist Preview. Die konkrete Verfügbarkeit und Voraussetzungen sollten vor produktiver Architekturentscheidung erneut geprüft werden.

Für Berechtigungen ist wichtig: Die Integration ist kein anonymer Retrieval-Kanal. Microsoft beschreibt, dass die Nutzeridentität an Azure AI Search übergeben wird und die dortigen Zugriffskontrollen respektiert werden. Der Search Index muss deshalb selbst sauber mit RBAC und gegebenenfalls dokumentbezogenen Zugriffskonzepten aufgebaut sein.

Auch die Datenqualität bleibt getrennt: Semantische Kennzahlen gehören dort hin, wo ihre Geschäftslogik definiert ist – typischerweise ins Power-BI-Semantikmodell oder andere kuratierte Fabric-Quellen. Dokumente gehören in den Search Index. Nur weil beides in einer Agent-Antwort zusammenkommt, sollte die fachliche Logik nicht doppelt gepflegt werden.

Richtung B – Fabric Data Agent als Knowledge Source in Azure AI Search

Die Gegenrichtung funktioniert anders. Azure AI Search kann einen Fabric Data Agent als Remote Knowledge Source für agentic retrieval einbinden.

Remote/live ist hier das Schlüsselwort: Anders als bei einem klassischen Search Index werden die Fabric-Daten nicht zunächst in Azure AI Search ingestiert und indexiert. Stattdessen wird der Data Agent zur Laufzeit abgefragt. Microsoft beschreibt diesen Ansatz als geeignet für Daten mit hoher Änderungsrate und analytische Abfragen.

Das passt zu dynamischen KPIs und fachlicher Logik. Wenn sich Umsatz, Forecast oder Bestände laufend ändern, ist es oft sinnvoller, eine kuratierte analytische Quelle live abzufragen als ihren Zustand periodisch in einen Dokumentindex zu kopieren. Die Knowledge Source kann neben Textantworten auch eingebettete Ressourcen wie Tabellen oder Diagramme zurückgeben.

Identity und On-Behalf-Of sind in Richtung B zentral

Für die Fabric-Data-Agent-Knowledge-Source nutzt Azure AI Search einen On-Behalf-Of-Flow. Die Retrieval-Anfrage enthält ein Endnutzer-Zugriffstoken; die Retrieval Engine tauscht dieses gegen einen für Fabric geeigneten Token und fragt den Data Agent im Namen des Nutzers ab.

Wichtig: Dieses Nutzer-Token ersetzt nicht die normale Authentifizierung gegenüber Azure AI Search. Beide Ebenen müssen korrekt konfiguriert sein.

Microsoft nennt außerdem als Voraussetzung, dass Azure AI Search Service und Fabric Workspace im selben Microsoft-Entra-Tenant liegen. Für die Einrichtung der Knowledge Source werden passende Search-Service-Berechtigungen oder ein API-Key benötigt.

Diese Architektur ist identity-aware, aber nicht automatisch sicher. Ihr müsst weiterhin prüfen, welche Datenquellen der Data Agent nutzt, welche Berechtigungen Nutzer in Fabric haben und welche Search-Rollen für Administration und Abfrage gelten.

Der Architekturvergleich

Frage	Richtung A: Search Index → Data Agent	Richtung B: Data Agent → AI Search
Primäre Oberfläche	Fabric Data Agent	Azure AI Search / Foundry / Knowledge Base
Hauptzweck	Dokumentwissen mit Fabric-Analyse kombinieren	Live-Fabric-Analysen in breitere Agentic-Retrieval-Lösung einbinden
Datenart	vor allem unstrukturierte, indexierte Inhalte	strukturierte/semantische Live-Analytik aus Fabric
Ingestion	Search Index wird vorab aufgebaut	keine zusätzliche Ingestion der Fabric-Antworten
Aktualität	abhängig vom Indexierungsprozess	Live-Abfrage zur Retrieval-Zeit
Identity	Nutzeridentität Richtung Search Index	OBO-Endnutzerfluss Richtung Fabric
Status 24.08.2026	Preview	Preview
Typischer Einsatz	Fabric als Conversational Front Door	Foundry/Azure AI Search als Agentic Front Door

Wann solltet ihr Richtung A wählen?

Richtung A passt, wenn der Fabric Data Agent die primäre Benutzeroberfläche sein soll und eure Nutzer Fragen stellen, die sowohl analytische Daten als auch Dokumentwissen benötigen. Typische Fälle sind Produkt- oder Vertragsdokumente plus KPIs, Richtlinien plus operative Kennzahlen oder ein Agent, der Lakehouse, Warehouse, Semantic Model und Dokumentindex kombiniert.

Die Grenze: Ein Search Index ist kein Ersatz für ein semantisches Modell. Aggregationen, Measures und geschäftliche Definitionen sollten nicht als Textfragmente in einen Dokumentindex ausgelagert werden, nur damit der Agent sie findet.

Wann solltet ihr Richtung B wählen?

Richtung B passt, wenn Azure AI Search beziehungsweise eine Knowledge Base Teil einer größeren Agentenarchitektur ist und Fabric eine analytische Wissensquelle unter mehreren sein soll. Typische Fälle sind ein Foundry-Agent mit Dokumenten, OneLake und Live-Analytics, dynamische KPIs ohne Replikation oder ein bereits kuratierter Fabric Data Agent als wiederverwendbarer virtueller Analyst.

Die Grenze: Die Remote Knowledge Source ist Preview und hat konkrete Plattformvoraussetzungen. Microsoft nennt derzeit Support über Foundry Portal, SDKs und REST; der Azure-Portal-Weg ist für diesen Knowledge-Source-Typ nicht unterstützt.

Unsere Entscheidungsmatrix

Situation	Empfehlung
PDFs + Power-BI-KPIs in einer Fabric-Konversation	Richtung A
Breiter Enterprise-Agent mit mehreren Knowledge Sources	Richtung B
Hochdynamische Kennzahlen ohne Replikation	Richtung B
Dokumentkorpus mit bestehenden Search-Enrichments	Richtung A
Kuratierte Geschäftslogik aus Semantic Models	Fabric live abfragen; nicht als Dokument duplizieren
Stark regulierte Berechtigungen	beide möglich, Identity-Flows prototypisch testen
Unterschiedliche Regionen für Search und Fabric	Residency-/Compliance-Prüfung vor Entscheidung

Governance – drei Fragen vor dem Pilot

1. Wo liegt die fachliche Wahrheit? Kennzahlen und Berechnungen sollten in kuratierten analytischen Quellen bleiben. Dokumentwissen wird separat indexiert. Der Agent verbindet beide, er ersetzt nicht deren Ownership.

2. Wer darf was sehen? Prüft nicht nur die Agent-Oberfläche, sondern die Rechte in Fabric und Azure AI Search. In Richtung B kommt zusätzlich der OBO-Flow ins Spiel.

3. Welche Daten bewegen sich zwischen Regionen? Microsoft weist darauf hin, dass Fabric IQ im Workspace-Region-Kontext verarbeitet. Liegt der Search Service in einer anderen Region, können Query-Ergebnisse regionsübergreifend zurückgegeben werden. Das gehört in Architektur und Compliance-Prüfung.

Fazit

Fabric Data Agents und Azure AI Search ergänzen sich gerade deshalb gut, weil sie unterschiedliche Datenprobleme lösen. Search ist stark bei indexierten, unstrukturierten Inhalten. Fabric ist stark bei strukturierten und semantischen Analysen über aktuelle Unternehmensdaten.

Die wichtigste Architekturentscheidung lautet deshalb nicht „integrieren oder nicht“, sondern welches System die Conversational Front Door ist, wo die fachliche Wahrheit liegt und welches System als Wissensquelle dient. Für eine Fabric-zentrierte Analyse mit Dokumentkontext ist Richtung A oft der natürliche Weg. Für eine breitere Agentic-Retrieval-Architektur, die Live-Analytics aus Fabric als Quelle nutzen soll, ist Richtung B strategisch interessanter.

Beide Wege sind Preview. Ein Pilot sollte deshalb nicht nur Antwortqualität, sondern auch Identity, Berechtigungen, Latenz, Region und Update-Stabilität testen.

---

Der nächste sinnvolle Schritt

Wenn ihr Fabric Data Agents in eine belastbare Analytics-/RAG-Architektur einordnen wollt, sollte der erste Schritt ein kleiner Architektur-Pilot mit echten Berechtigungen und Datenquellen sein. Im Microsoft Fabric Kick Start können wir den passenden Integrationspfad bewerten.