Agent AI do GRC z Microsoft Purview, Power Automate i Copilot Studio

Raporty GRC, czyli z zakresu zarządzania ryzykiem i zgodności, w wielu organizacjach nadal powstają tak samo. Analityk eksportuje logi audytowe, wkleja je do Excela i buduje kolejne tabele przestawne, które po kilku tygodniach przeczą sobie nawzajem. Dokumentacja wygląda porządnie, ale nie daje prawdziwego wglądu w to, co dzieje się w organizacji.

Alternatywą jest zautomatyzowany agent GRC zbudowany z narzędzi Microsoftu. Microsoft Purview dostarcza dane, Power Automate zarządza procesem, a Copilot Studio zamienia wyniki w czytelny raport. Poniżej opisujemy, jak ten układ działa, jak go zbudować i na co uważać.

Czym jest agent GRC i dlaczego ręczne raportowanie zawodzi

Ręczne raportowanie GRC bierze się z mylenia dokumentacji z wglądem. Dane z Microsoft Purview trafiają do arkusza, a po tygodniu pojawiają się nowe aktywności i wykresy przestają być aktualne. Wiele firm traktuje Purview jak sejf otwierany tylko przed audytem. Tymczasem jego logi gromadzą ogromne ilości informacji o tym, kto, co, gdzie i kiedy zrobił. Każdy wpis to gęsty obiekt JSON, więc dane są przydatne, ale niemal nieczytelne.

Agent GRC to nie magiczny pilot, który zgaduje odpowiedzi. To ustrukturyzowana automatyzacja oparta na regułach, złożona z trzech elementów:

• Microsoft Purview to pamięć agenta: dzienniki audytu, dane klasyfikacyjne i zdarzenia dotyczące zgodności.
• Power Automate to układ nerwowy: zbiera sygnały, odfiltrowuje szum i pilnuje harmonogramu.
• Copilot Studio to „usta” agenta: zamienia techniczne dane w zrozumiałe podsumowania, na przykład informację, że użytkownik pięciokrotnie podniósł uprawnienia w ciągu 24 godzin i przekroczył limit zasad.

Podejście to działa, bo większość zadań związanych ze zgodnością to rozpoznawanie wzorców, a nie ocena sytuacji. Według przytaczanej tu oceny dotyczy to około 90% takich zadań. System nie musi myśleć jak człowiek. Wystarczy, że uporządkuje pracę lepiej niż on. Cały stos jest przy tym deterministyczny: sam definiujesz logikę, częstotliwość, zakres, a nawet ton wypowiedzi.

Potok danych z Microsoft Purview: ekstrakcja i filtrowanie

Zanim agent zacznie „myśleć”, musi widzieć. Bez dostępu do właściwych danych audytowych zautomatyzujesz tylko ślepotę.

Ekstrakcja danych

Dane pobierzesz na dwa sposoby: wbudowanym łącznikiem Purview albo akcją HTTP, która bezpośrednio wywołuje API dziennika audytu. Oba prowadzą do strumienia zdarzeń z całej dzierżawy: udostępnień plików, zmian uprawnień, naruszeń dostępu czy logowań administratorów. Zakres warto ograniczyć na samym początku i wybrać tylko zdarzenia, które faktycznie wpływają na zgodność z przepisami. Pobieranie całego kanału audytu przeciąża przepływ i szybko staje się uciążliwe.

Uprawnienia i bezpieczeństwo konta serwisowego

Power Automate działa wyłącznie w granicach nadanych mu uprawnień. Konto serwisowe przepływu powinno mieć w Purview rolę czytelnika dzienników audytu i musieć się uwierzytelniać bez przerywania przez MFA, bo automat nie kliknie niczego o drugiej w nocy. Poświadczenia przechowuj w Azure Key Vault lub w referencjach połączeń.

Filtrowanie pod kątem ryzyka

Nie każde zdarzenie interesuje audytora. Warto zostawić rzeczywiste wskaźniki ryzyka:

• logowanie użytkownika z nowej lokalizacji,
• zmiana przypisania roli,
• użycie udostępniania zewnętrznego,
• modyfikacja zasad etykietowania.

Filtrować można już w zapytaniu, przez parametry API, albo później w Power Automate, za pomocą logiki warunkowej. Zasada jest prosta: nie gromadzisz wszystkiego, tylko selekcjonujesz.

Przetwarzanie i przechowywanie danych audytowych

Kolejny etap odróżnia automatyzację od kopiowania i wklejania. Bloki JSON trzeba zamienić w ustrukturyzowane kolumny. Najprościej użyć akcji Parse JSON ze schematem pobranym z przykładowego zdarzenia Purview. Każda właściwość, taka jak identyfikator użytkownika, operacja, obciążenie, status wyniku czy adres IP klienta, staje się osobną zmienną.

Na tym etapie wychodzą na jaw kłopoty z formatem danych. Niektóre pola audytowe są tablicami, nawet gdy zawierają jedną wartość, a inne ukrywają wynik pod kilkoma warstwami zagnieżdżeń. Power Automate radzi sobie z tym za pomocą wyrażeń, ale drobny błąd literowy daje później bezsensowne wyniki. Dlatego każdą ekstrakcję testuj na małych próbkach.

Oczyszczone dane warto zapisać w SharePoint, Dataverse lub bazie SQL, zależnie od tego, jak ciężkie są raporty. Taki magazyn działa jak pamięć krótkotrwała: pozwala porównywać dane historyczne bez ciągłego odpytywania Purview. Dataverse lepiej współpracuje z Power Automate, gdy potrzebujesz możliwości kolumnowych lub relacji między zbiorami. SharePoint jest łatwiejszy, ale staje się niezgrabny po przekroczeniu kilku tysięcy wierszy.

Harmonogram

Częstotliwość dobierz do środowiska: raporty dzienne dla dynamicznych organizacji, tygodniowe dla spokojniejszych. Użyj wyzwalacza cykliczności i ustaw własną strefę czasową zamiast UTC. W przeciwnym razie raporty mogą przychodzić o niewygodnych porach, na przykład o trzeciej nad ranem. W przykładzie z omawianego rozwiązania przepływ uruchamia się codziennie o 8 rano.

Logika w Power Automate: jak agent ocenia ryzyko

Power Automate nie jest sztuczną inteligencją. Nie halucynuje zagrożeń, jest przewidywalny i nie improwizuje, a właśnie tego wymaga autonomia. Logika agenta składa się z kilku kroków.

1. Wyzwalacz cykliczny uruchamia przepływ zgodnie ze strefą czasową audytorów.
2. Blok inicjalizacji tworzy zmienne, takie jak suma zdarzeń, liczba wysokich ryzyk i data raportu. To pamięć operacyjna agenta.
3. Pobranie danych odbywa się łącznikiem dzienników audytu Purview lub przez HTTP.
4. Filtrowanie tablicy usuwa szum, na przykład rekordy, w których typ użytkownika to główna usługa, i zostawia operacje związane z zarządzaniem danymi lub zmianą zasad.
5. Usuwanie duplikatów, bo strumienie logów często powtarzają te same zdarzenia. Pomaga proste wyrażenie typu union albo porównanie w pętli.
6. Grupowanie i zliczanie według nazwy głównej użytkownika i operacji, z podsumowaniem kategorii w pętli „zastosuj do każdego”.

W ten sposób agent dostaje migawkę: kto zrobił co, jak często i czy przekroczył zdefiniowane granice ryzyka.

Progi decyzyjne zamiast przeczucia

Sam definiujesz, co znaczy „zbyt wiele”. Jeśli liczba eskalacji uprawnień wynosi 3, poziom ryzyka jest wysoki. Jeśli występuje jedno udostępnienie zewnętrzne, poziom jest średni. W pozostałych przypadkach jest normalny. Zagnieżdżone akcje warunkowe dodają użytkowników wysokiego ryzyka do osobnej tablicy, a przypadki średnie kierują do kolejki przeglądu. Gdy nic się nie dzieje, agent zapisuje komunikat o braku ustaleń zamiast milczeć. W zgodności różnica między brakiem danych a danymi o braku problemów jest zasadnicza.

Obsługa błędów i dowody wykonania

Wywołania HTTP owiń w kontener zakresu z polityką ponawiania: trzy próby z wykładniczym wycofywaniem. W gałęzi awarii zapisuj komunikat błędu, znacznik czasu i identyfikator uruchomienia w liście SharePoint lub tabeli Dataverse, na przykład o nazwie „Kondycja Automatyzacji”. Jeśli progi zostaną przekroczone, wyślij wiadomość na Teams. Audytorzy nie karzą za błędy, tylko za brak ich dokumentacji.

Każde uruchomienie powinno zostawiać dowód: metryki podsumowujące, liczbę przetworzonych zdarzeń, użytkowników najwyższego ryzyka i czas trwania. Dołącz identyfikator uruchomienia i wersję przepływu, aby po zmianie progów dało się prześledzić, jaka logika doprowadziła do wyniku.

Copilot Studio: jak zamienić dane w czytelny raport

Po klasyfikacji agent wie, co się stało, ale jeszcze tego nie wyjaśnia. Tu wchodzi Copilot Studio, który tłumaczy ustrukturyzowane dane na język zrozumiały dla zarządu i wystarczająco precyzyjny dla audytorów.

Zacznij od określenia, jakiej komunikacji potrzebujesz. Zwykle są to trzy elementy:

• podsumowanie dla kadry zarządzającej, czyli jeden akapit,
• dodatek techniczny ze ścieżkami dowodowymi, na przykład z tabelą zdarzeń wysokiego ryzyka,
• rekomendacje.

W jednym środowisku Copilot Studio osadzasz wiele instrukcji, a każda kształtuje ton, format i poziom szczegółowości. Przykładowa instrukcja brzmi: podsumuj główne ryzyka prostym językiem, ogranicz się do pięciu punktów i zasugeruj rozwiązanie dla każdego z nich.

Połączenie z Power Automate odbywa się przez akcję HTTP, która wysyła ustrukturyzowany ładunek JSON na adres punktu końcowego Copilota. Wywołanie uwierzytelniasz przez Azure AD, więc dostęp ma tylko Twój przepływ. Copilot interpretuje ładunek według zdefiniowanej instrukcji systemowej i zwraca tekst, który jest gotowym raportem. Efekt przypomina notatkę analityka: wskazuje użytkowników z podwyższonym ryzykiem, opisuje przekroczenia progów, podaje zalecenia i kończy się oceną ogólnego trendu względem wartości bazowej.

To nie jest swobodne generowanie treści. To sformatowana synteza oparta na deterministycznych promptach, a Copilot relacjonuje statystyki, które sam mu dostarczasz.

Dystrybucja raportów i dyscyplina promptów

Raporty powinny trafiać do ludzi bez logowania się do Dataverse. Użyj konektorów Power Automate i podziel przepływ na dwie gałęzie. Pierwsza publikuje podsumowanie Copilota na kanale Teams, druga zapisuje pełną wersję HTML w SharePoint. Kierownictwo czyta wiadomość na Teams, a audytorzy sięgają do archiwum. Oba materiały docierają automatycznie, z sygnaturą czasową i identycznym sformułowaniem.

Zasady inżynierii promptów

• Określ dokładne nagłówki, na przykład „Przegląd”, „Kluczowe wnioski”, „Zalecenia”. Inaczej Copilot może sięgnąć po narracyjny styl lub emoji, które w raporcie z audytu są nie na miejscu.
• Wymagaj profesjonalnego, neutralnego tonu, unikania języka spekulatywnego i podawania mierzalnych wskaźników.
• Używaj zmiennych kontekstowych i symboli zastępczych, takich jak data raportu czy liczba rekordów. Wynik może brzmieć: „wygenerowano 15 marca, przeanalizowano 563 zdarzenia audytowe”.
• Dodaj walidację: warunek w Power Automate sprawdza, czy odpowiedź Copilota nie jest pusta. Jeśli jest, błąd trafia do logów i przepływ uruchamia się ponownie.

Im bardziej rygorystyczne instrukcje, tym bardziej powtarzalny wynik, a zgodność opiera się na powtarzalności, nie na osobowości.

Wersjonowanie promptu

Prompt systemowy wersjonuj za każdym razem, gdy zmieniają się kryteria zgodności, na przykład V1, V1-1 i kolejne. Rejestruj, która wersja wygenerowała dany raport. Przyszłe audyty mogą wtedy odnieść się nie tylko do tego, co się stało, ale też do tego, jak model był wtedy instruowany.

Częste błędy i stolpersteiny

• Brak roli czytelnika dzienników audytu. Agent zgłosił zero problemów, a okazało się, że konto usługi nie miało uprawnień. Raport nie świadczył o zgodności, tylko o „posłusznej ślepocie”.
• Pobieranie całego kanału audytu. Bez wczesnego ograniczenia zakresu przepływ staje się ciężki i trudny do utrzymania.
• MFA na koncie serwisowym. Automat nie przejdzie dodatkowego uwierzytelniania.
• Błędy w wyrażeniach przy zagnieżdżonym JSON. Drobna literówka daje później bezsensowne wyniki, dlatego testuj na małych próbkach.
• Strefa czasowa UTC. Raporty przychodzą wtedy o nieoczekiwanych godzinach.
• Brak polityk ponawiania. API może zgłosić zbyt wiele żądań, a przepływ powinien kończyć się bezpiecznie.
• Luźne instrukcje dla Copilota. Bez narzuconej struktury i tonu raport traci powtarzalność.
• Brak dokumentowania błędów i wersji. Utrudnia to później obronę wyników przed audytorem.

Praktyczne wnioski

• Połącz trzy role: Purview jako źródło prawdy, Power Automate jako orkiestrator, Copilot Studio jako narrator.
• Ogranicz zakres danych na początku i filtruj tylko rzeczywiste wskaźniki ryzyka.
• Nadaj kontu serwisowemu rolę czytelnika dzienników audytu i przechowuj poświadczenia w Azure Key Vault lub referencjach połączeń.
• Zamień JSON w ustrukturyzowane zmienne i testuj wyrażenia na małych próbkach.
• Wybierz magazyn danych odpowiedni do skali: Dataverse przy relacjach, SharePoint przy prostszych zestawach.
• Ustaw harmonogram w swojej strefie czasowej.
• Zakoduj progi ryzyka jawnie, żeby zastąpić intuicję liczbową jasnością.
• Zapisuj komunikat o braku ustaleń, gdy nic się nie dzieje.
• Dodaj polityki ponawiania i rejestr błędów, na przykład „Kondycja Automatyzacji”, oraz powiadomienia na Teams.
• Narzuć Copilotowi nagłówki, ton i zmienne kontekstowe, a odpowiedź waliduj.
• Wersjonuj prompt i zapisuj, która wersja wygenerowała dany raport.

Fazit

Agent GRC zbudowany z Microsoft Purview, Power Automate i Copilot Studio zmienia zgodność z żmudnej dokumentacji w ciągły proces. Purview gromadzi dane, Power Automate je interpretuje, a Copilot Studio opisuje w spójnym, powtarzalnym języku. Największą korzyścią jest standaryzacja: każdy raport używa tych samych progów, rejestruje te same metadane i ma weryfikowalne pochodzenie. Audytorzy oceniają wtedy merytoryczną treść, a nie format, a zespół przestaje zależeć od ręcznego kopiowania logów. Warunkiem jest staranna konfiguracja uprawnień, filtrów, obsługi błędów i wersjonowania promptów, bo automatyzacja robi dokładnie to, co jej zlecisz, i nic więcej.