Operations Agent für Fabric Pipelines

Eine fehlgeschlagene Fabric Pipeline lässt sich vergleichsweise leicht erkennen. Schwieriger wird es, wenn eine Pipeline zwar erfolgreich durchläuft, aber plötzlich dreimal so lange benötigt, ungewöhnlich wenige Daten verarbeitet oder regelmäßig Folgeprozesse verzögert. Genau dann reicht ein Status wie „Completed“ nicht mehr aus.

Microsoft erweitert das Fabric Pipeline Monitoring deshalb um einen KI-gestützten Operations Agent. Er soll Pipeline-Läufe beobachten, Auffälligkeiten analysieren und passende Reaktionen empfehlen. Die Funktion befindet sich im August 2026 noch in der Preview und unterstützt in der pipeline-spezifischen Variante vor allem Health-Monitoring-Szenarien.

Der Operations Agent ist kein selbstheilender Autopilot für Fabric Pipelines. Er ist eine intelligente Monitoring- und Reaktionsschicht, deren Nutzen von Telemetrie, Regeln, Berechtigungen und Betriebsprozessen abhängt.

Was ist der Operations Agent für Fabric Pipelines?

Der Operations Agent für Pipelines ist eine KI-gestützte Funktion in Microsoft Fabric Data Factory. Er wird direkt aus der Pipeline-Oberfläche erstellt und kann eine einzelne Pipeline oder alle Pipelines eines Workspaces überwachen.

Dazu verwendet er Pipeline-Ausführungsdaten, Metadaten auf Aktivitätsebene sowie Laufzeit- und Performance-Signale. Daraus leitet er Hinweise zu Fehlern, Engpässen, ungewöhnlichem Verhalten und möglichen Optimierungen ab. Ergebnisse können unter anderem über Microsoft Teams bereitgestellt werden. Anders als ein klassischer Alert soll der Agent nicht nur melden, dass etwas passiert ist, sondern den betrieblichen Kontext mitliefern.

Das Versprechen ist relevant: Teams sollen weniger Zeit mit dem manuellen Durchsuchen von Ausführungshistorien und Logs verbringen. Ob die Analyse belastbar ist, hängt jedoch von den verfügbaren Daten und der Qualität der Ziele und Anweisungen ab.

Warum erfolgreiche Pipelines trotzdem ein Problem sind

Viele Monitoring-Lösungen konzentrieren sich auf fehlgeschlagene Ausführungen. Für einen stabilen Betrieb reicht das nicht. Auch eine technisch erfolgreiche Pipeline kann gegen betriebliche Erwartungen verstoßen.

• Eine tägliche Ladepipeline benötigt statt 20 plötzlich 70 Minuten.

• Ein Kopiervorgang verarbeitet deutlich weniger Datensätze als üblich.

• Eine Pipeline startet verspätet und verzögert nachgelagerte Berichte.

• Einzelne Aktivitäten werden mit jedem Lauf langsamer.

• Fehler treten sporadisch auf, folgen aber einem wiederkehrenden Muster.

Pipeline Health bedeutet mehr als erfolgreich oder fehlgeschlagen. Entscheidend ist, ob ein Prozess rechtzeitig, vollständig und innerhalb der erwarteten Betriebsparameter läuft.

So funktioniert das Monitoring technisch

Die technische Grundlage bildet das Workspace Monitoring von Microsoft Fabric. Nach der Aktivierung erzeugt Fabric ein Monitoring Eventhouse mit einer schreibgeschützten KQL-Datenbank. Dort werden Ausführungsprotokolle unterstützter Elemente eines Workspaces gespeichert.

Pipeline-Ereignisse auf Jobebene werden unter anderem in der Tabelle ItemJobEventLogs erfasst. Sie enthält Pipeline-Name, Status, Start- und Endzeit, Laufzeit, Aufrufart und Job-Instanz. Ergänzende Protokolle liefern Details zu Aktivitäten innerhalb einer Pipeline.

Der Operations Agent greift auf diese Daten zu und erzeugt aus Geschäftszielen und Anweisungen ein Playbook mit Regeln und KQL-Abfragen.

Der Agent ersetzt die Monitoring-Daten nicht. Er interpretiert die vorhandene Telemetrie und macht sie für betriebliche Entscheidungen nutzbarer.

1. Eine Pipeline wird ausgeführt.

2. Workspace Monitoring schreibt die Ereignisse in das Monitoring Eventhouse.

3. Der Operations Agent prüft die definierten Bedingungen.

4. Bei einer Auffälligkeit analysiert er den verfügbaren Kontext.

5. Er erstellt eine Nachricht, Empfehlung oder konfigurierte Aktion.

Unternehmen, die Microsoft Fabric als gemeinsame Datenplattform etablieren, sollten Monitoring deshalb nicht erst beim ersten Produktionsfehler einplanen.

Praxisbeispiel: Eine Pipeline läuft dreimal so lange

Eine täglich gestartete Pipeline lädt Daten aus einem operativen System in ein Lakehouse. Normalerweise benötigt sie 25 Minuten. Seit mehreren Tagen steigt die Laufzeit und überschreitet schließlich 60 Minuten. Eine klassische Fehlermeldung greift nicht, weil die Pipeline erfolgreich abgeschlossen wurde.

Der Operations Agent kann den aktuellen Lauf mit historischen Ausführungen vergleichen, besonders langsame Aktivitäten identifizieren und einen nächsten Prüfschritt vorschlagen. Eine sinnvolle Meldung enthält Pipeline und Run-ID, aktuelle und durchschnittliche Laufzeit, betroffene Aktivitäten, den Zeitpunkt der Veränderung sowie eine wahrscheinliche Ursache.

Der Mehrwert entsteht nicht durch die Teams-Nachricht, sondern durch die Verbindung aus Ereignis, historischem Vergleich und konkreter Handlungsempfehlung.

Operations Agent, Activator oder klassische Benachrichtigung?

Nicht jedes Monitoring-Szenario benötigt einen KI-Agenten. Eine Benachrichtigung innerhalb der Pipeline eignet sich für bekannte Fehlerpfade. Fabric Activator ist stark, wenn eine eindeutige KQL-Bedingung workspaceweit geprüft und eine feste Aktion ausgelöst werden soll.

Der Operations Agent wird interessant, wenn eine Auffälligkeit anhand zusätzlicher Daten eingeordnet und eine situationsabhängige Empfehlung formuliert werden soll. Ziele und Anweisungen werden aktuell auf Englisch formuliert; ein aktiver Agent führt seine Datenabfragen derzeit im Fünf-Minuten-Takt aus.

In einer belastbaren Monitoring-Architektur ergänzen sich feste Regeln und kontextbezogene Analysen.

Bei der Auswahl der passenden Data-&-Analytics-Technologien sollte deshalb nicht automatisch die Funktion mit dem höchsten KI-Anteil gewinnen, sondern die mit der klarsten Betriebslogik.

Wo die Analyse an Grenzen stößt

Microsoft spricht von Root-Cause-Analyse. In der Praxis sollte der Begriff vorsichtig verwendet werden. Der Agent kann aus Logs und Mustern eine wahrscheinliche Ursache ableiten, aber keine vollständige oder garantiert korrekte technische Diagnose liefern.

Unabhängige Praxistests zeigen, dass mehrere Iterationen nötig sein können, bis die generierte KQL-Abfrage und die ausgegebene Benachrichtigung wirklich zum Ziel passen. Fehlende Telemetrie, unklare Benennungen oder schlecht formulierte Regeln werden durch ein Sprachmodell nicht automatisch behoben.

Natürlichsprachliche Konfiguration beseitigt die technische Arbeit nicht. Sie verschiebt sie hin zur Kontrolle und Verbesserung der generierten Logik.

Die Preview ist daher ein sinnvoller Testbaustein, aber kein Ersatz für ein eigenes DataOps- und Observability-Konzept.

Berechtigungen und Governance begrenzen die Autonomie

Jeder Operations Agent erhält eine eigene Entra-Agent-ID. Für Datenzugriffe und Aktionen verwendet er jedoch die delegierte Identität und die Berechtigungen seines Erstellers. Wird nur der Empfänger einer Benachrichtigung geändert, ändert sich diese Ausführungsidentität nicht.

Die zentrale Governance-Frage lautet nicht, wer eine Meldung erhält, sondern mit wessen Berechtigungen daraus eine Aktion ausgeführt wird.

Das passt zur grundsätzlichen Sicherheitslogik in Fabric: Auch bei OneLake Security müssen Identitäten, Zugriffspfade und wirksame Berechtigungen gemeinsam betrachtet werden.

Operations Agents können neben Nachrichten weitere Prozesse auslösen, etwa Fabric Pipelines, Notebooks oder Power-Automate-Flows. Für den Einstieg sollte deshalb ein Human-in-the-Loop-Modell gelten: beobachten, erklären, empfehlen, prüfen und erst danach ausgewählte risikoarme Aktionen automatisieren.

Welche Kosten entstehen?

Operations Agents verbrauchen Fabric Capacity Units. Zum Verbrauch gehören Agent-Compute, Copilot-Nutzung bei der Konfiguration, LLM-basiertes Reasoning und Abfragen gegen das Eventhouse. Hinzu können OneLake-Speicher und angebundene Power-Automate-Prozesse kommen.

Die Kosten hängen nicht nur von der Anzahl der Agents ab, sondern auch von Abfragehäufigkeit, Regelumfang, Datenmenge und ausgelösten Analysen.

Ein Agent mit unscharfen Regeln produziert möglicherweise viele Meldungen, unnötiges Reasoning und zusätzlichen Capacity-Verbrauch. Pilot und Produktivbetrieb sollten deshalb über die Fabric Capacity Metrics App und definierte Kostenobergrenzen beobachtet werden.

Vier Stufen für agentisches Pipeline Monitoring

Ein kontrollierter Einstieg lässt sich in vier Reifestufen strukturieren.

1. Beobachten: Der Agent erkennt Auffälligkeiten, löst aber noch keine operative Reaktion aus.

2. Erklären: Er ergänzt Laufzeiten, betroffene Aktivitäten und wahrscheinliche Ursachen.

3. Empfehlen: Er schlägt konkrete nächste Schritte vor; die Entscheidung bleibt beim Menschen.

4. Ausführen: Nur wiederholt getestete und risikoarme Aktionen werden automatisiert.

Technische Autonomie sollte das Ergebnis nachgewiesener Zuverlässigkeit sein – nicht das erste Ziel des Piloten.

Das gleiche Muster zeigt sich beim Remote Power BI MCP Server: Eine funktionierende agentische Schnittstelle ist noch keine belastbare Produktionslösung.

So sollte ein Pilot aufgebaut sein

Ein Pilot sollte mit zwei oder drei relevanten Pipelines starten. Geeignet sind Prozesse mit wiederkehrenden Ausführungen, nachvollziehbarer Historie und bekannten Fehlersituationen.

Für jede Pipeline werden konkrete Testfälle definiert: fehlgeschlagene Aktivität, ungewöhnlich lange Laufzeit, wiederkehrender Fehler, verspäteter Start oder auffällige Datenmenge. Zusätzlich werden erwartete Meldungsinhalte, zulässige Empfehlungen und verantwortliche Empfänger festgelegt.

Ein erfolgreicher Pilot misst nicht, ob der Agent beeindruckende Texte formuliert, sondern ob er den Betrieb nachweisbar verbessert.

• Zeit bis zur Erkennung eines Problems

• Anteil korrekt erkannter Ereignisse

• Fehlalarmquote

• Qualität und Umsetzbarkeit der Empfehlungen

• Zeitersparnis bei der Diagnose

• zusätzlicher Capacity-Verbrauch

• Pflegeaufwand für Regeln und Playbooks

Fehlen noch einheitliche Verantwortlichkeiten, Workspace-Strukturen oder Prioritäten, sollte zunächst ein Data Strategy Check die organisatorischen und technischen Voraussetzungen klären.

Für wen lohnt sich der Operations Agent?

Der Einsatz ist besonders interessant für Unternehmen, die viele wiederkehrende Fabric Pipelines betreiben und bereits über Workspace Monitoring, geregelte Verantwortlichkeiten und klare Betriebsanforderungen verfügen.

Je unreifer das Betriebsmodell, desto geringer ist der unmittelbare Mehrwert zusätzlicher Agentenlogik.

Weniger sinnvoll ist der Agent, wenn nur wenige einfache Pipelines vorhanden sind, Fehler bereits zuverlässig über feste Regeln erkannt werden oder keine Verantwortlichen für Reaktion und Freigabe definiert wurden.

Häufige Fragen zum Operations Agent für Pipelines

Ist der Operations Agent allgemein verfügbar?

Nein. Der Operations Agent für Fabric Pipelines befindet sich im August 2026 noch in der Preview.

Benötigt der Agent Workspace Monitoring?

Für workspaceweite Pipeline-Daten und die dokumentierten Monitoring-Szenarien bildet Workspace Monitoring mit dem Monitoring Eventhouse die zentrale Datenbasis.

Kann der Agent Pipelines automatisch reparieren?

Er kann Empfehlungen geben und konfigurierte Aktionen auslösen. Daraus folgt aber keine allgemeine Fähigkeit, beliebige Pipeline-Fehler selbstständig und zuverlässig zu beheben.

Ersetzt der Operations Agent Fabric Activator?

Nein. Activator eignet sich weiterhin für eindeutige, regelbasierte Bedingungen. Der Operations Agent ergänzt dies um Kontext, Analyse und Empfehlungen.

Reagiert der Agent in Echtzeit?

Nein. Ein aktiver Operations Agent führt seine Datenabfragen derzeit alle fünf Minuten aus.

In welcher Sprache wird der Agent konfiguriert?

Ziele und Anweisungen werden aktuell auf Englisch formuliert.

---

Fazit: Mehr Kontext, aber kein automatischer Betrieb

Der Operations Agent für Fabric Pipelines ist eine interessante Erweiterung des Fabric Monitorings. Er kann dabei helfen, aus Ausführungsdaten schneller Auffälligkeiten, Zusammenhänge und mögliche nächste Schritte abzuleiten.

Der Operations Agent macht Fabric Pipelines nicht automatisch zuverlässig. Richtig eingesetzt kann er aber die Zeit zwischen Auffälligkeit, Diagnose und kontrollierter Reaktion deutlich verkürzen.

Sein Nutzen entsteht nicht allein durch KI. Er benötigt eine saubere Monitoring-Grundlage, klar formulierte Regeln, überprüfbare KQL-Logik, begrenzte Berechtigungen und einen definierten Prozess für Empfehlungen und Aktionen.

---

Der nächste sinnvolle Schritt

Fabric-Pipeline-Betrieb gemeinsam einordnen

Nicht jede Pipeline-Landschaft benötigt einen Operations Agent. Häufig ist eine Kombination aus Workspace Monitoring, Activator, klaren Betriebsregeln und gezielt eingesetzter Agentenlogik sinnvoller.

Der nächste sinnvolle Schritt beginnt deshalb mit einem geeigneten Kernmodell, realen Fachfragen und klaren Kriterien dafür, wann eine Antwort als fachlich belastbar gilt. 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

• Power BI Coaching – für konkrete Herausforderungen bei Datenmodellen, DAX, Metadaten und der Vorbereitung auf Copilot

• Microsoft Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und einen ersten KI-gestützten Analytics-Use-Case

Die Daten-WG unterstützt dabei, Monitoring-Anforderungen, Risiken, Berechtigungen und sinnvolle Pilotszenarien zu bewerten.