Copilot Studio + Microsoft Fabric: einen Agenten bauen, der deinen Data Lake liest
Microsoft Fabric legt deine Daten in OneLake ab; Copilot Studio lässt dich Agenten darauf bauen. So verbinden sich die beiden Teile — Grounding, der SQL-Endpunkt, Fabric-Datenagenten — und die Fallen, die es zu vermeiden gilt.
- Copilot Studio
- Microsoft Fabric
- OneLake
- KI-Agenten
- Azure
„Können wir nicht einfach mit unseren Daten chatten?“ ist die Bitte, die jedes Datenteam mittlerweile wöchentlich hört. Microsofts Antwort näht zwei Produkte zusammen: Fabric hält die Daten, Copilot Studio baut den Agenten, der mit ihnen spricht. Die Demo ist Magie. Die Produktionsversion hat scharfe Kanten. So passen die Teile wirklich zusammen — und wo sich die Leute schneiden.
Die Teile: Fabric, OneLake, Copilot Studio
Microsoft Fabric ist eine SaaS-Analytics-Plattform, die Data Engineering, Warehousing, Echtzeit-Analytik und Power BI bündelt. OneLake ist ihr einziger, tenant-weiter Data Lake — stell es dir als das „OneDrive für Daten“ vor — aufgebaut auf ADLS Gen2 und, entscheidend, alles als offenes Delta-Parquet speichernd. Dasselbe Format wie das Databricks-Lakehouse, und das ist kein Zufall: Die Branche hat sich weitgehend auf Delta und Iceberg als offene Tabellenschicht geeinigt.
Copilot Studio ist Microsofts Low-Code-Plattform zum Bau von Agenten — der Nachfolger von Power Virtual Agents. Du gibst einem Agenten Anweisungen, Wissensquellen und Aktionen, und er antwortet mit generativer KI. Die Frage ist, wie du diesen Agenten auf den Lake richtest.
Wo die Daten leben: OneLake und der SQL-Endpunkt
Ein Fabric-Lakehouse oder -Warehouse stellt seine Delta-Tabellen auf zwei Arten bereit, die ein Agent nutzen kann. Der SQL-Analytics-Endpunkt ist eine schreibgeschützte T-SQL-Oberfläche über den Tabellen — alles, was SQL spricht, kann sie abfragen. Das semantische Modell sitzt darüber: benannte Kennzahlen, Beziehungen und Geschäftslogik, abfragbar im Direct Lake-Modus, der Parquet direkt aus OneLake liest, ohne eine zweite Kopie zu importieren oder zu cachen. Shortcuts erlauben es OneLake, Daten zu referenzieren, die in S3 oder einem anderen ADLS-Konto liegen, ohne sie zu verschieben — so kann „dein Data Lake“ mehrere Clouds umspannen.
Die Lektion: Ein Agent, der auf einem gut gebauten semantischen Modell fußt, ist weit zuverlässiger als einer, der auf Rohtabellen gerichtet ist, weil das Modell kodiert, was ein „Kunde“ oder „Umsatz“ wirklich bedeutet.
Drei Wege, einen Agenten in deinem Lake zu verankern
- Fabric-Datenagent (der native Weg). Fabric hat seinen eigenen KI-Agenten — früher „AI Skills“ —, den du über einem Lakehouse, Warehouse oder semantischen Modell baust. Er übersetzt natürliche Sprache in Abfragen gegen deine Daten, und du kannst ihn in Copilot Studio als verbundene Wissensquelle hinzufügen. Das ist der kürzeste Weg und der, in den Microsoft investiert.
- Copilot-Studio-Wissen über einem semantischen Modell. Richte den Agenten auf ein Power-BI-semantisches-Modell als Wissensquelle. Gut für Frage-Antwort über definierte Kennzahlen; schwächer bei offenen Abfragen auf Zeilenebene.
- Maßgeschneidertes Grounding. Nutze Power Automate oder einen benutzerdefinierten Connector, um auf den SQL-Endpunkt zuzugreifen, oder verdrahte Azure OpenAI „on your data“. Maximale Kontrolle, maximale Klempnerei — du verantwortest Retrieval, Prompt-Konstruktion und Ergebnisformung.
Ein minimaler Aufbau
Der Weg, der von Anfang bis Ende am zuverlässigsten funktioniert:
- Lande die Daten in einem Fabric-Lakehouse und forme eine saubere Gold-Schicht — die Medallion-Disziplin gilt hier genau wie in Databricks.
- Baue ein kleines semantisches Modell mit benannten Kennzahlen und Beziehungen. Hier wird die Genauigkeit gewonnen oder verloren.
- Erstelle einen Fabric-Datenagenten über diesem Modell und teste seine generierten Abfragen gegen bekannte Antworten.
- In Copilot Studio: Erstelle einen Agenten, füge den Fabric-Datenagenten als Wissen hinzu, schreibe knappe Anweisungen und veröffentliche in Teams oder im Web.
Sicherheit ist das ganze Spiel
Der Fehler, der Karrieren beendet, ist ein Agent, der fröhlich Zeilen zurückgibt, die ein Benutzer nie sehen sollte. Bring das in Ordnung, bevor du ausrollst:
- Die Identität fließt durch. Bevorzuge, dass der Agent im Namen des angemeldeten Benutzers abfragt (Entra ID), nicht mit einem festen Service Principal mit Gott-Modus-Zugriff.
- Sicherheit auf Zeilen- und Spaltenebene lebt im semantischen Modell und im Lakehouse — setze sie dort durch, nicht im Prompt. Ein Prompt ist keine Zugriffskontroll-Grenze.
- Least Privilege auf OneLake. Shortcuts und Workspace-Rollen entscheiden, was der Agent überhaupt erreichen kann.
Wo es bricht
- Halluziniertes oder falsches SQL. Natürliche-Sprache-zu-Abfrage ist probabilistisch. Ohne ein semantisches Modell, das es einschränkt, erfindet der Agent plausible, aber falsche Aggregationen. Validiere immer gegen ein goldenes Frageset.
- Direct Lake fällt auf DirectQuery zurück, wenn ein Modell zu groß oder zu komplex wird, und die Latenz verschlechtert sich still und leise. Behalte es im Auge.
- Kostenschleichgang. Fabric-Kapazitätseinheiten plus generative Aufrufe summieren sich. Miss es ab Tag eins.
Copilot Studio über Fabric ist der schnellste Weg, nicht-technischen Benutzern ein echtes Gespräch mit governten Daten zu geben — wenn du in das semantische Modell investierst und Sicherheit als ein Problem der Datenschicht behandelst, nicht des Prompts. Wenn deine Agenten dem Low-Code entwachsen und du das Modell und den Loop besitzen musst, betrachtet das nächste Stück den offenen agentischen Stack — Hermes und NVIDIA Nemotron.
War das hilfreich?