.png){kind=small}
Creator Agent für Fabric Data Agents: Was automatisiert er wirklich?
- Dirk Müller
- vor 1 Tag
- 7 Min. Lesezeit
Fabric Data Agents lassen sich inzwischen deutlich schneller konfigurieren. Microsoft hat dafür im Juni 2026 den Creator Agent als Preview vorgestellt. Die aktuelle Feature-Dokumentation und Produktoberfläche nennen die Funktion inzwischen „Build agent with AI“. Sie kann Datenstrukturen untersuchen, Instructions und Example Queries vorschlagen und Abfragen schon während des Setups testen.
Das klingt zunächst nach einem Data Agent, der sich weitgehend selbst aufbaut. Genau das ist aber nicht der Fall. Datenquellen, Schema, fachliche Definitionen, Berechtigungen und Produktionsfreigabe bleiben außerhalb dieser Automatisierung. Der Creator Agent beschleunigt die Konfiguration – er ersetzt nicht die Verantwortung für die Qualität des Agenten.
Kurz eingeordnet: Build agent with AI unterstützt aktuell SQL- und Eventhouse-Datenquellen. Er kann Agent Instructions, Data Source Instructions, Data Source Descriptions und Example Queries erzeugen beziehungsweise verbessern. Datenquellen- und Schemaauswahl sowie Semantic Models, Prep for AI und Ontologies bleiben außerhalb seines aktuellen Funktionsumfangs.
Was ist der Creator Agent für Fabric Data Agents?
Microsoft führt die Funktion in seinen aktuellen Release-Informationen weiterhin als Creator Agent. Die spezielle Learn-Seite und die Schaltfläche im Data Agent heißen dagegen „Build agent with AI“. Für die Praxis sind damit derzeit beide Begriffe relevant. Die Funktion selbst befindet sich weiterhin in Preview.
Der Creator Agent ist kein eigener Daten-Agent und auch keine zusätzliche Datenquelle. Er ist ein KI-Assistent innerhalb des Entwicklungsprozesses eines bestehenden Fabric Data Agents.
Das unterscheidet ihn vom allgemeinen Konzept der Fabric Data Agents. Dort geht es darum, wie Anwender Unternehmensdaten über natürliche Sprache abfragen. Beim Creator Agent geht es dagegen darum, wie das Team den Data Agent schneller und systematischer konfiguriert.
Was Build agent with AI tatsächlich vorbereitet
Bevor Build agent with AI genutzt werden kann, muss der Data Agent bereits existieren. Mindestens eine unterstützte SQL- oder Eventhouse-Datenquelle muss angebunden und das relevante Schema ausgewählt sein.
Danach kann der Assistent das Schema untersuchen. Er identifiziert Tabellen und Spalten, kann mögliche Join-Pfade erkennen und dabei helfen, die für typische Fachfragen relevanten Objekte zu verstehen.
Mit den entsprechenden Berechtigungen kann er zusätzlich Query-Historien analysieren. Wiederkehrende Joins, Filter und Aggregationsmuster liefern Kontext für bessere Konfigurationsvorschläge. Fehlt der Zugriff auf die Query History, arbeitet der Assistent weiterhin auf Basis des Schemas.
Auf dieser Grundlage unterstützt er vier Konfigurationsarten:
Agent Instructions
Data Source Instructions
Data Source Descriptions
Example Queries
Außerdem kann Build agent with AI schreibgeschützte Queries gegen die angebundene Datenquelle ausführen. Damit kann er Annahmen und vorgeschlagene Example Queries technisch überprüfen, ohne Daten zu verändern.
Was weiterhin manuell konfiguriert werden muss
Die aktuelle Preview hat klare Grenzen. Build agent with AI wählt keine Datenquellen aus und entscheidet auch nicht, welche Tabellen oder Schemaobjekte dem Data Agent zur Verfügung stehen sollen. Die Beschreibung des Data Agents für die spätere Veröffentlichung gehört ebenfalls nicht zu den unterstützten Konfigurationen.
Das ist mehr als ein technisches Detail. Datenquelle und Schema definieren den fachlichen Raum,
innerhalb dessen sich der Agent bewegen darf. Ein Finance-Agent sollte nicht einfach Zugriff auf alle verfügbaren Tabellen erhalten, nur weil sie technisch erreichbar sind.
Scope bleibt eine Architektur- und Governance-Entscheidung.
Genauso wenig kann der Creator Agent verbindlich entscheiden, welche Definition von Umsatz, Deckungsbeitrag oder Forecast im Unternehmen gilt. Er kann aus Schema, Query History und dem Gespräch mit dem Ersteller Vorschläge ableiten. Ob diese Regeln fachlich korrekt sind, muss das zuständige Team beurteilen.
Agent Instructions und Example Queries mit KI erstellen
Einer der größten praktischen Vorteile liegt bei den Instructions. Agent Instructions enthalten übergreifende Regeln dazu, wie der Data Agent Fragen interpretiert oder Datenquellen auswählt. Data Source Instructions können konkreten Kontext über Tabellen, Spalten, Beziehungen und Query-Logik enthalten.
Build agent with AI kann solche Instructions erzeugen, bestehende Texte verbessern und Widersprüche aufzeigen. Damit reduziert sich vor allem die manuelle Arbeit beim initialen Context Engineering.
Bei SQL- und KQL-basierten Quellen lassen sich zusätzlich Example Queries nutzen. Dabei wird eine typische fachliche Frage mit einer konkreten SQL- oder KQL-Abfrage kombiniert. Der Data Agent nutzt passende Beispiele später als Orientierung für ähnliche neue Fragen.
Microsoft validiert diese Queries gegen das ausgewählte Schema. Eine Query, die die technische Validierung nicht besteht, wird vom Data Agent nicht als Beispiel verwendet.
Das ist wichtig, aber noch keine Qualitätssicherung.
Eine valide SQL-Abfrage ist nicht automatisch eine valide betriebswirtschaftliche Antwort.
Ein Query kann technisch korrekt sein und trotzdem das falsche Datumsfeld, eine ungeeignete Umsatzdefinition oder eine nicht freigegebene Forecast-Version verwenden.
Warum Power BI Semantic Models eine wichtige Grenze sind
Für viele Power-BI-Teams liegt hier die wichtigste Einschränkung der aktuellen Preview: Build agent with AI unterstützt Semantic Models derzeit nicht. Auch Power BI Prep for AI wird vom Assistenten nicht konfiguriert.
Fabric Data Agents selbst können dagegen Power BI Semantic Models als Datenquelle verwenden. In diesem Fall erzeugt der Data Agent DAX-Abfragen auf Basis des Semantic Models. Entscheidend für die Qualität sind dann das semantische Modell, seine Metadaten und die Konfiguration über Prep for AI.
Microsoft stellt dafür drei zentrale Bausteine bereit:
AI Data Schema
AI Instructions
Verified Answers
Data-Agent-Instructions werden bei der DAX-Generierung für Semantic Models nicht verwendet. Auch die normalen Example Queries des Data Agents stehen für Semantic Models derzeit nicht zur Verfügung; entsprechende fachliche Beispiele werden über Verified Answers im Semantic Model adressiert.
Wer einen Data Agent hauptsächlich auf Power-BI-Semantik aufbauen will, sollte deshalb zuerst semantische Modelle AI-ready machen. Ein Creator Agent macht ein schlecht vorbereitetes Semantic Model nicht automatisch besser.
Praxisbeispiel: Data Agent für Umsatz, Forecast und Plan-Ist
Ein Controlling-Team möchte einen Fabric Data Agent aufbauen, über den Führungskräfte Fragen zu Umsatz, Deckungsbeitrag, Forecast und Plan-Ist-Abweichungen stellen können.
Die Daten liegen in einem Fabric Warehouse. Dort stehen kuratierte Finance-Views für Ist-, Plan- und Forecast-Daten bereit. Ein solches SQL-Szenario passt grundsätzlich gut zum aktuellen Funktionsumfang von Build agent with AI.
Das Team erstellt zunächst den Data Agent, verbindet das Warehouse und wählt ausschließlich die freigegebenen Finance-Views aus. Diese Entscheidungen bleiben manuell.
Anschließend kann Build agent with AI die Struktur untersuchen und beispielsweise Data Source Instructions vorschlagen:
Finance-Fragen verwenden ausschließlich die kuratierten Finance-Views.
Geschäftsjahre werden anhand des Fiscal Calendar interpretiert.
Plan-Ist-Fragen verwenden nur die freigegebene Budgetversion.
Forecast-Fragen beziehen sich standardmäßig auf die aktuelle Forecast-Version.
Auch Example Queries wären sinnvoll:
Wie hoch war der Nettoumsatz im letzten abgeschlossenen Monat?
Welche Kostenstellen haben die größte negative Plan-Ist-Abweichung?
Wie entwickelt sich der aktuelle Forecast gegenüber dem Jahresbudget?
Welche Regionen unterschreiten ihren Deckungsbeitragsplan?
Der Assistent kann dazu SQL-Muster erzeugen und die Queries schreibgeschützt ausführen. Damit lässt sich die erste technische Konfiguration deutlich beschleunigen.
Was er nicht entscheiden sollte, ist beispielsweise die Definition des Deckungsbeitrags. Sind variable Logistikkosten enthalten? Welche Wechselkurse gelten? Wie werden Nachbelastungen behandelt? Welche Forecast-Version besitzt fachliche Freigabe?
Das sind Business-Definitionen – keine Konfigurationsdetails, die eine KI eigenständig festlegen sollte.
Liegt diese verbindliche Kennzahlenlogik bereits in einem Power BI Semantic Model, muss das Team eine andere Architekturentscheidung treffen. Das Semantic Model kann direkt als Data-Agent-Datenquelle genutzt werden, Build agent with AI kann dieses Modell aktuell jedoch nicht konfigurieren. AI Data Schema, AI Instructions und Verified Answers werden dann über Prep for AI gepflegt.
Vor der Freigabe sollte das Team einen festen Testkatalog verwenden. Sinnvoll sind beispielsweise bekannte Kontrollsummen, unterschiedliche Zeiträume, Plan-Ist-Szenarien, Grenzfälle, verschiedene Formulierungen derselben Frage und Tests mit unterschiedlichen Berechtigungen.
Example Queries helfen bei der Query-Generierung. Sie ersetzen keinen fachlichen Abnahmekatalog.
Creator Agent und manueller Aufbau im Vergleich
Creator Agent vs. manueller Aufbau
Dimension | Build agent with AI | Manueller Aufbau |
Initiale Konfiguration | KI-Vorschläge | vollständig manuell |
Schemaanalyse | unterstützt | manuell |
Agent Instructions | generieren/optimieren | selbst formulieren |
Data Source Instructions | generieren/optimieren | selbst formulieren |
Example Queries | vorschlagen und testen | selbst entwickeln |
Datenquelle auswählen | manuell | manuell |
Schema auswählen | manuell | manuell |
Semantic Model Prep for AI | nicht unterstützt | separat in Power BI |
fachliche Kontrolle | erforderlich | erforderlich |
Governance | erforderlich | erforderlich |
Produktionsfreigabe | separat | separat |
Der entscheidende Unterschied liegt damit vor allem in der Geschwindigkeit der Konfiguration – nicht in einer Verlagerung der fachlichen Verantwortung.
Governance beginnt nicht erst nach dem Setup
Ein schneller erstellter Agent ist nicht automatisch ein sicherer oder zuverlässiger Agent.
Fabric Data Agents arbeiten bei Datenabfragen grundsätzlich schreibgeschützt und berücksichtigen Berechtigungen der verwendeten Identität. Governance-Vorgaben auf Organisations- und Workspace-Ebene stehen über den Instructions des Agent-Erstellers und den Prompts der Nutzer.
Für Power BI Semantic Models reicht bei der Interaktion über Fabric Data Agents inzwischen Read Permission. RLS und CLS gelten weiterhin. Änderungen am Modell oder Prep for AI benötigen dagegen entsprechende Schreibrechte.
Gerade weil Konfiguration einfacher wird, braucht es klare Regeln darüber, wer Agents erstellen darf, welche Datenprodukte verwendet werden können und welcher Teststandard vor einer Veröffentlichung gilt.
Schnelleres Setup senkt die Governance-Anforderungen nicht – es macht klare Governance eher noch wichtiger.
Vom unterstützten Setup zum produktiven Data Agent
Microsoft trennt bei Data Agents zwischen Entwurfs- und veröffentlichter Version. Ein Agent wird zunächst entwickelt und getestet und anschließend veröffentlicht. Danach kann die Draft-Version weiterentwickelt werden, während Nutzer mit der Published-Version arbeiten.
Zusätzlich unterstützt Fabric für Data Agents Git-Integration und Deployment Pipelines. Damit lässt sich ein kontrollierter Entwicklungs-, Test- und Produktionsprozess aufbauen.
Ein sinnvoller Ablauf lautet deshalb:
Datenprodukt auswählen → Scope definieren → Data Agent erstellen → Datenquelle und Schema auswählen → Build agent with AI einsetzen → Queries prüfen → fachlich testen → Berechtigungen validieren → veröffentlichen.
Der Creator Agent verkürzt vor allem die Konfigurationsphase. Er macht den gesamten Lebenszyklus nicht überflüssig.
Für Unternehmen, die Microsoft Fabric bereits mit kuratierten SQL- oder Eventhouse-Datenquellen einsetzen, ist das besonders interessant. Sie können mehr Konfigurationsarbeit automatisieren und ihre Zeit stärker in Validierung und fachliche Verbesserung investieren.
Wer dagegen noch mit widersprüchlichen Kennzahlen, ungeklärter Ownership und unkontrolliertem Datenzugriff kämpft, sollte zuerst diese Grundlagen stabilisieren. Der Creator Agent löst keine strukturellen Datenprobleme.
Fazit: Beschleuniger statt Autopilot
Der Creator Agent ist ein sinnvoller Schritt für Fabric Data Agents. Schema Exploration, Query History, KI-generierte Instructions, Example Queries und ausführbare Testabfragen können die bisher manuelle Konfigurationsarbeit deutlich reduzieren.
Entscheidend ist aber die Grenze: Datenquelle und Schema bleiben bewusste Entscheidungen, Power BI Semantic Models und Prep for AI liegen aktuell außerhalb des Creator Agents. Kennzahlendefinitionen, Datenqualität, Berechtigungen, Testverfahren und Produktionsfreigabe bleiben Aufgabe der Organisation.
Ein schneller erstellter Data Agent ist deshalb noch kein zuverlässiger Data Agent.
Der nächste sinnvolle Schritt
Wenn ihr Fabric Data Agents produktiv einsetzen wollt, sollte der erste Pilot nicht nur die Geschwindigkeit der Agent-Erstellung messen. Prüft gleichzeitig, ob Datenprodukt, fachliche Semantik, Berechtigungen und reale Nutzerfragen belastbar genug sind.
Ein sinnvoller Einstieg ist ein klar abgegrenzter Use Case mit einer kuratierten Datenquelle und einem festen Testkatalog. So lässt sich früh erkennen, wo Build agent with AI tatsächlich Zeit spart und wo Modellierung oder Governance nachgeschärft werden müssen.
Wenn ihr einen solchen Pilot einordnen wollt, können wir gemeinsam Use Case, Datenbasis, Agent-Konfiguration und Governance für Microsoft Fabric prüfen und daraus einen realistischen nächsten Umsetzungsschritt ableiten.
Die Daten-WG unterstützt euch mit:
Data Strategy Check – um Datenprodukte, AI Readiness, Governance und Verantwortlichkeiten ganzheitlich einzuordnen
Consulting Abo – für kontinuierliche Unterstützung bei Modellpflege, Tests, Governance und produktivem Betrieb
Microsoft Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und einen ersten KI-gestützten Analytics-Use-Case
