KI-GRC-Agent mit Microsoft Purview, Power Automate und Copilot Studio bauen: Compliance-Berichte automatisch

Governance, Risk & Compliance (GRC) verbraucht in vielen Organisationen mehr Zeit, als es nützt. Analysten kopieren Prüfprotokolle Zelle für Zelle in Excel, pflegen Arbeitsmappen mit dutzenden Registerkarten und erklären Prüfern am Ende, dass alles unter Kontrolle sei. In der Woche darauf haben sich die Daten verschoben, und die sauberen Diagramme stimmen nicht mehr.

Es geht auch anders: mit einem regelbasierten GRC-Agenten, der vollständig im Microsoft-Ökosystem entsteht. Microsoft Purview liefert die Daten, Power Automate steuert den Ablauf, Copilot Studio formuliert den Bericht. Dieser Artikel zeigt, wie die drei Bausteine zusammenspielen, wie Sie die Pipeline aufbauen und an welchen Stellen es typischerweise hakt.

Warum manuelles GRC-Reporting an seine Grenzen stößt

Manuelles Reporting entsteht oft dort, wo Dokumentation mit Erkenntnis verwechselt wird. Daten werden aus Microsoft Purview exportiert, auf Tabellen verteilt und als Governance bezeichnet. Prüfpfade, die Verantwortlichkeit schaffen sollen, führen so vor allem zu Überlastung im Team.

Dabei behandeln viele Unternehmen Purview wie einen Tresor, der nur vor einer Prüfung geöffnet wird. Die Audit-Logs protokollieren ununterbrochen, wer wann was getan hat. Nützlich ist das, lesbar aber kaum: Jeder Eintrag ist ein dichter JSON-Block. Das Kernproblem lautet deshalb Datenüberfluss bei praktisch null Lesbarkeit.

Ein Agent löst dieses Problem, weil ein Großteil der Compliance-Arbeit Mustererkennung ist und keine Ermessensentscheidung. Als Richtwert gelten rund 90 % der Aufgaben. Muster wie Aktivitätstypen oder Ergebnisstatus lassen sich automatisch kategorisieren und zusammenfassen. Der Ansatz funktioniert nicht, weil das System wie ein Mensch denkt, sondern weil es besser strukturiert arbeitet.

Der GRC-Agent: Aufbau aus Purview, Power Automate und Copilot Studio

Hinter dem Agenten steckt keine Magie, sondern eine strukturierte Automatisierung, die Intelligenz nur nach außen zeigt. Jede der drei Komponenten übernimmt eine klar abgegrenzte Rolle.

Microsoft Purview: das Gedächtnis

Purview ist die Compliance-Blackbox. Jede Benutzeraktion in Microsoft 365 wird protokolliert, etwa das Teilen eines Dokuments, das Erstellen einer Richtlinie oder das Ändern eines Aufbewahrungslabels. Purview liefert Audit-Logs, Klassifizierungsdaten und Compliance-Ereignisse als maßgebliche Quelle.

Power Automate: das Nervensystem

Power Automate löst pünktlich aus, sammelt Signale, filtert Rauschen und stellt sicher, dass der Prozess planmäßig läuft. Sie definieren zum Beispiel einen täglichen Lauf um 8 Uhr, und der Flow ruft per Konnektor die neuesten Purview-Aktivitäten ab. Bei Fehlern protokolliert er präzise, und gerade das schätzt die Compliance.

Copilot Studio: der Übersetzer

Copilot Studio verwandelt strukturierte Daten in lesbaren Text. Aus einer Tabelle mit risikoreichen Aktionen pro Benutzer wird eine Aussage wie: Ein Benutzer hat innerhalb von 24 Stunden fünfmal Berechtigungen eskaliert und damit den Richtlinien-Schwellenwert überschritten. Das Modell rät dabei nicht, sondern folgt den Regeln des Prompts, den Sie entworfen haben.

Wichtig ist der Unterschied zu Dashboards. Ein Dashboard zeigt Werte, erklärt sie aber nicht. Der Agent schreibt eine Analyse und schließt damit die Interpretationslücke, die in Prüfungen immer wieder zu Beinahe-Fehlern führt. Der Stack ist deterministisch: Logik, Häufigkeit, Umfang und sogar der Tonfall sind von Ihnen festgelegt.

Die Purview-Datenpipeline aufbauen

Bevor der Agent bewerten kann, muss er sehen können. Die Pipeline soll Zugriff auf die richtigen Ausschnitte der Audit-Daten geben, nicht mehr und nicht weniger.

Schritt 1: Daten extrahieren

Sie starten entweder mit dem integrierten Purview-Connector oder mit einer HTTP-Aktion, die die Purview-Audit-Log-API direkt aufruft. Beide Wege liefern einen Datenstrom mit Dateifreigaben, Berechtigungsänderungen, Zugriffsverletzungen, Administrator-Logins und mehr. Schränken Sie den Umfang früh ein und definieren Sie, welche Ereignisse sich tatsächlich auf die Compliance auswirken. Sonst wird der Flow unnötig groß und unhandlich.

Schritt 2: Zugriff sauber regeln

Power Automate arbeitet nur mit den vergebenen Berechtigungen. Kann das Dienstkonto die Audit-Logs nicht lesen, meldet der Agent pflichtbewusst, dass keine Probleme gefunden wurden. Das ist keine Beruhigung, sondern Blindheit, die als Erfolg getarnt ist. Beachten Sie deshalb:

• Das Dienstkonto benötigt in Purview die Rolle „Audit-Logs-Leser“.
• Es muss sich ohne MFA-Unterbrechung authentifizieren können, denn nachts klickt niemand eine Anfrage weg.
• Anmeldeinformationen gehören in den Azure Key Vault oder in Verbindungsreferenzen.

Schritt 3: Nach Risikoindikatoren filtern

Niemand braucht jeden Zugriff auf einen beliebigen Ordner. Filtern Sie nach echten Risikoindikatoren, zum Beispiel:

• Anmeldung von neuem Standort
• geänderte Rollenzuweisung
• aktivierte externe Freigabe
• geänderte Labelrichtlinie

Das gelingt bereits über API-Parameter bei der Abfrage oder später in Power Automate mit bedingter Logik. Entscheidend ist, dass die Datenmenge überschaubar bleibt.

Schritt 4: JSON in Struktur verwandeln

Mit der Aktion „JSON analysieren“ und einem Schema aus einem Purview-Beispielereignis wird jede Eigenschaft zu einer eigenen Variable, etwa Benutzer-ID, Vorgang, Workload, Ergebnisstatus oder Client-IP. Manche Audit-Felder erscheinen als Arrays, obwohl sie nur einen Wert enthalten, andere sind mehrfach verschachtelt. Power Automate bewältigt das mit Ausdrücken und Apply-to-Each. Ein kleiner Tippfehler führt hier später zu unsinnigen Ergebnissen, daher lohnt es sich, jede Extraktion mit kleinen Testläufen zu prüfen.

Schritt 5: Speichern und planen

Die bereinigten Daten lassen sich in SharePoint, Dataverse oder einer SQL-Datenbank ablegen. So kann der Agent historische Vergleiche anstellen, ohne Purview ständig abzufragen. Dataverse eignet sich besser, wenn Sie Spaltenfunktionen oder Beziehungen zwischen Datensätzen brauchen. SharePoint ist einfacher, wird aber bei einigen tausend Zeilen unhandlich.

Für die Planung nutzen Sie den Serienmuster-Trigger: täglich in dynamischen Umgebungen, wöchentlich in ruhigeren. Stellen Sie unbedingt Ihre Zeitzone ein statt UTC, sonst treffen Berichte zu unpassenden Zeiten ein.

Die Logik-Ebene: Schwellenwerte, Risikostufen und Nachweise

Power Automate halluziniert keine Risiken. Es führt Schritt für Schritt aus, was definiert wurde, und genau diese Starrheit macht Autonomie zuverlässig.

Der Flow beginnt mit einem Wiederholungsauslöser, gefolgt von einem Initialisierungsblock mit Variablen wie Gesamtereignisse, Anzahl der Hochrisikofälle und Berichtsdatum. Sie bilden den Arbeitsspeicher des Agenten. Danach ruft der Flow den Purview-Connector oder die HTTP-API auf und bereinigt die Rohdaten:

• Ein Filter-Array-Schritt entfernt Rauschen, etwa Datensätze mit dem Benutzertyp Dienstprinzipal. Behalten Sie nur Vorgänge mit Bezug auf Data Governance oder Richtlinienänderungen.
• Doppelte Ereignisse entfernen Sie mit einer Union-Funktion oder einer Schleife.
• Mit Compose oder Select gruppieren Sie die Datensätze nach Benutzerprinzipalnamen und Vorgang, Apply-to-Each-Schleifen summieren jede Kategorie.

Das Ergebnis ist eine Momentaufnahme: Wer hat was wie oft getan, und wurden Risikogrenzen überschritten? Die Risikostufen ergeben sich aus Ihren Schwellenwerten. Ein Beispiel: Bei drei Berechtigungseskalationen setzen Sie die Stufe auf „hoch“, bei einer externen Freigabe auf „mittel“, sonst auf „normal“. Die Logik erfindet keine Bedeutung, sie erzwingt eine definierte. Mit verschachtelten Bedingungen sortieren Sie Benutzer in ein Hochrisiko-Array oder Vorgänge in eine Prüfliste.

Wichtig ist auch der Fall ohne Auffälligkeiten. Protokollieren Sie dann eine „Keine Funde“-Meldung, statt Stille zurückzugeben. Der Unterschied zwischen fehlenden Daten und keinen Daten ist in der Compliance zentral.

Fehlertoleranz und Nachvollziehbarkeit

Die Purview-API drosselt gelegentlich oder meldet zu viele Anfragen. Kapseln Sie HTTP-Aufrufe deshalb in einem Scope-Container mit Wiederholungsrichtlinie: drei Versuche mit exponentiellem Backoff. Im Fehlerzweig protokollieren Sie Fehlermeldung, Zeitstempel und Flowrun-ID in einer SharePoint-Liste oder Dataverse-Tabelle, etwa „Automatisierungsintegrität“. Bei Überschreitung von Schwellenwerten kann zusätzlich eine Teams-Nachricht ausgehen. Fehler werden so zu Daten statt zum Drama, denn Auditoren bestrafen nicht den Fehler, sondern die fehlende Dokumentation.

Jeder Lauf sollte außerdem einen Ausführungsnachweis schreiben: verarbeitete Ereignisse, Benutzer mit dem höchsten Risiko und Laufzeit. Eine Run-ID hilft später zu belegen, welche Logik zu welchem Ergebnis geführt hat, wenn sich Grenzwerte ändern.

Copilot Studio: Berichte in natürlicher Sprache

Bis hierher kann die Automatisierung klassifizieren, zählen und entscheiden, bleibt aber stumm. Copilot Studio macht daraus einen lesbaren Bericht, höflich genug für Führungskräfte und präzise genug für Prüfer.

Drei Kommunikationsformen

Meist werden drei Textarten benötigt: eine Management-Zusammenfassung, ein technischer Anhang und Empfehlungen. Das Management möchte einen Absatz, Prüfer brauchen lückenlose Nachweise, die IT jedes Feld. Sie bauen eine Copilot-Erfahrung mit mehreren Prompts, die Tonfall, Format und Ausführlichkeit festlegen.

Anbindung an den Flow

Der Flow sendet über eine HTTP-Aktion den strukturierten JSON-Payload an die Endpoint-URL des Copiloten. Dieser interpretiert ihn anhand des System-Prompts. Die Authentifizierung läuft über Azure-ID, sodass nur Ihr Flow zugreifen kann. Zurück kommt Text, und dieser Text ist der Bericht. Er benennt etwa Benutzer mit mehreren Berechtigungseskalationen, nennt eine Empfehlung je Befund und schließt mit dem Gesamttrend. Es ist keine freie Generierung, sondern formatierte Synthese nach festen Vorgaben.

Prompt Engineering mit Leitplanken

• Geben Sie exakte Überschriften vor, zum Beispiel „Überblick“, „Wichtige Erkenntnisse“ und „Empfehlungen“.
• Fordern Sie einen neutralen, professionellen Ton, vermeiden Sie spekulative Sprache und verlangen Sie messbare Kennzahlen.
• Nutzen Sie Kontextvariablen für Berichtsdatum und Anzahl analysierter Ereignisse, die beim Aufruf automatisch aufgelöst werden.

Je präziser die Anweisungen, desto reproduzierbarer das Ergebnis. Compliance lebt von Reproduzierbarkeit, nicht von Persönlichkeit.

Validierung und Verteilung

Prüfen Sie per Power-Automate-Bedingung, ob die Antwort des Copiloten nicht leer ist. Andernfalls speichern Sie den Fehler im Protokoll und starten einen neuen Versuch. Für die Verteilung eignen sich zwei Zweige desselben Flows: Einer postet die Zusammenfassung in einen Teams-Kanal, der andere archiviert eine vollständige HTML-Version in SharePoint. Das Management liest den Teams-Beitrag, Auditoren nutzen das Archiv. Beide erhalten automatisch Zeitstempel und identischen Wortlaut.

Versionieren Sie zudem den System-Prompt (V1, V1.1 usw.) und halten Sie fest, welche Version welchen Bericht erzeugt hat. So lässt sich später nachvollziehen, wie das Sprachmodell zum jeweiligen Zeitpunkt instruiert war.

Häufige Fehler und Stolpersteine

• Fehlende Berechtigungen: Fehlt dem Dienstkonto die Rolle „Audit-Logs-Leser“, meldet der Agent null Probleme. Das wirkt wie perfekte Compliance, ist aber nur gehorsame Blindheit. Automatisierung setzt genau das durch, was Sie vorgeben, und nichts weiter.
• Zu großer Datenumfang: Den gesamten Audit-Feed abzurufen überlädt den Flow. Definieren Sie früh, was compliance-relevant ist.
• MFA-Unterbrechungen: Ein Dienstkonto, das sich nachts nicht authentifizieren kann, lässt den Lauf scheitern.
• Tippfehler in Ausdrücken: Fehler beim Verarbeiten verschachtelter JSON-Strukturen führen später zu unbrauchbaren Ergebnissen. Testen Sie in kleinen Schritten.
• Falsche Zeitzone: Wer UTC beibehält, bekommt Berichte zu ungünstigen Zeiten.
• Fehlende Wiederholungslogik: API-Drosselung ist normal. Ohne Retry-Richtlinie und Fehlerprotokoll bleiben Lücken unbemerkt.
• Unscharfe Prompts: Ohne Vorgaben schmückt der Copilot den Text erzählerisch aus. Für Prüfberichte ist das ungeeignet.
• SharePoint als Speicher bei großen Mengen: Bei einigen tausend Zeilen wird es unhandlich, dann ist Dataverse die bessere Wahl.

Praktische Takeaways

• Verteilen Sie die Rollen klar: Purview liefert Daten, Power Automate steuert und entscheidet, Copilot Studio formuliert.
• Vergeben Sie dem Dienstkonto die Rolle „Audit-Logs-Leser“ und legen Sie Zugangsdaten im Azure Key Vault oder in Verbindungsreferenzen ab.
• Beschränken Sie die Abfrage früh auf echte Risikoindikatoren wie externe Freigaben, Rollenänderungen oder Labelrichtlinien.
• Wandeln Sie JSON mit „JSON analysieren“ in strukturierte Variablen um und testen Sie jede Extraktion einzeln.
• Speichern Sie bereinigte Daten in SharePoint, Dataverse oder SQL, um historische Vergleiche zu ermöglichen.
• Legen Sie Schwellenwerte numerisch fest und protokollieren Sie auch den Fall „Keine Funde“.
• Kapseln Sie API-Aufrufe in Scopes mit Wiederholungsrichtlinie und führen Sie ein Fehlerprotokoll.
• Geben Sie dem Copilot feste Überschriften, einen neutralen Ton und Kontextvariablen vor.
• Prüfen Sie, dass die Copilot-Antwort nicht leer ist, bevor Sie veröffentlichen.
• Veröffentlichen Sie parallel in Teams und SharePoint und versionieren Sie den System-Prompt.

Fazit

Ein GRC-Agent aus Microsoft Purview, Power Automate und Copilot Studio ersetzt das manuelle Kopieren und Interpretieren von Audit-Logs durch einen verlässlichen, nachvollziehbaren Ablauf: extrahieren, filtern, bewerten, zusammenfassen, veröffentlichen. Der größte Gewinn liegt weniger in der Geschwindigkeit als in der Standardisierung. Jeder Bericht nutzt dieselben Grenzwerte, dieselbe Terminologie und dieselben Metadaten, sodass Auditoren die Substanz prüfen statt das Format. Wer Berechtigungen, Fehlerbehandlung und Prompt-Disziplin sauber umsetzt, macht Compliance-Berichterstattung vom Sprint vor der Prüfung zu einem kontinuierlichen Prozess.