Polityki AI w Power Platform

Jakie polityki AI da się wyegzekwować w Power Platform?

Siedem zapisów polityki AI przełożonych na konkretne kontrolki Power Platform — z ich zakresem i ograniczeniami.

Firma wdraża [politykę AI](/polityka-zarzadzania-ai): czternaście stron, przegląd prawny, akceptacja zarządu i mail do wszystkich z prośbą o zapoznanie się. Dwa tygodnie później ktoś z obsługi klienta tworzy w Copilot Studio [agenta](/agentyczna-ai), podpina mu jako źródło wiedzy SharePointa z wewnętrzną dokumentacją i publikuje go na Teams. W dokumencie było napisane, że rozwiązania AI mogą powstawać wyłącznie w kontrolowanych środowiskach, ale na samej platformie zabrakło jakichkolwiek barier przed publikacją przez nieuprawnione osoby. Zapis istniał, ale zachowanie platformy się nie zmieniło. Polityka nie została złamana \- ona nie miała jak zadziałać. Między zdaniem w dokumencie a tym, co faktycznie robi system, leży warstwa, o której mało kto pisze: konkretne opcje w panelu administracyjnym, które albo są włączone, albo nie istnieją wcale. W tym tekście biorę siedem najczęstszych zapisów z polityk AI i sprawdzam po kolei, czy Power Platform ma na nie przełącznik, gdzie go szukać, co dokładnie robi i czego mimo wszystko za nas nie zrobi. ## Dlaczego ten tekst nie zakłada licencji Microsoft 365 E5 Materiały o governance agentów mają jedną wspólną cechę: zaczynają się od licencji, których czytelnik po prostu nie ma. Purview, DSPM for AI, Insider Risk Management, Conditional Access, Defender. Wszystko to świetnie działa i jest dokładnie opisane, tyle że 80-osobowa firma na planie Business Basic czyta taki tekst i wyciąga prosty wniosek: governance leży poza jej zasięgiem, więc nic w tej sprawie nie robi. Moja teza jest inna. Polityki AI często piszemy w ciemno, nie sprawdzając, czy platforma ma pod dany zapis przełącznik i jak go skonfigurować \- a niektórych deklaracji i tak nie da się wymusić technicznie na żadnej licencji. Żeby nie być gołosłownym: wszystkie zrzuty ekranu w tym tekście pochodzą z tenanta demo TrustInAI, na którym mam wyłącznie Microsoft 365 Business Basic, rozliczenie Copilot Studio w modelu pay-as-you-go przez subskrypcję Azure oraz Power Apps Developer Plan. Jedno zastrzeżenie: ten tekst z założenia nie jest poradnikiem, jak nie kupować licencji Microsoftu. ## Środowisko jako granica egzekwowania Prawie każdy mechanizm kontrolny opisany w tym tekście działa wyłącznie w granicach jednego środowiska. Od polityk danych i uwierzytelniania agentów, przez Managed Environments, politykę rozliczeniową, po zapis transkryptów. Jeśli nikt wcześniej świadomie nie zdecydował, gdzie ma być tworzony agent, wszystkie te zabezpieczenia zaczynają obowiązywać tam, gdzie akurat wylądował ich twórca \- najczęściej w środowisku domyślnym, o którym przy pisaniu polityki łatwo zapomnieć.  *Rysunek: Warstwy egzekwowania \- od ustawień tenantowych, przez środowisko i konfigurację agenta, po uprawnienia na danych źródłowych.* ### Środowisko domyślne jest pułapką Każdy użytkownik z licencją Power Apps (a taka jest zwykle wliczona w większość planów Microsoft 365\) automatycznie dostaje w środowisku domyślnym uprawnienia twórcy. Wszystko leży tam obok siebie bez izolacji, a nazwa sugeruje, że to główne środowisko firmy, w którym powinniśmy budować rozwiązania. Najtańsza kontrolka w całym tym tekście polega na zmianie tej nazwy. PPAC (Power Platform Admin Center) → Manage → Environments → wybrane środowisko → Details → Edit, wpisujesz „Personal Productivity” albo „Piaskownica osobista”, zapisujesz. Microsoft rekomenduje to zresztą w swojej dokumentacji strategii środowisk.  *Rysunek: Lista środowisk w moim tenancie demo. Środowisko domyślne nosi nazwę „Personal Productivity”.* ### Ile środowisk naprawdę potrzebujemy Praktyka budowania klasycznych aplikacji biznesowych podpowiada układ dev/test/prod. W mniejszych firmach, z jednym lub dwoma twórcami agentów, to nie zadziała: testy i tak przejdą na dev, a środowisko testowe będzie tylko formalnością. Moja rekomendacja na start to dwa środowiska: deweloperskie i produkcyjne, plus zabezpieczone i przemianowane środowisko domyślne (Default). Architekturę rozbudowujemy wraz ze skalą. Trzecie środowisko pojawia się, gdy rośnie liczba twórców albo agent zaczyna pracować na danych, przy których nie możemy pozwolić sobie na błędy. Grupy środowisk (Environment Groups) wprowadzamy, gdy samych środowisk robi się więcej niż kilka. Dalej pojawia się Environment routing: wskazana grupa zabezpieczeń trafia automatycznie do własnych środowisk deweloperskich zamiast do Defaulta. To czystsze podejście niż samo blokowanie środowiska domyślnego, bo przekierowuje twórcę we właściwe miejsce. Wymaga jednak Managed Environments i uprawnień administratora. W tej drabince najczęściej gubi się jedno rozróżnienie: osobiste środowisko deweloperskie twórcy nie jest kolejnym etapem procesu wdrożeniowego, tylko prywatną piaskownicą do testów. Agent i tak musi zostać przeniesiony do dedykowanego środowiska dev typu sandbox, a następnie do produkcji. Jest tu też istotny haczyk: środowiska deweloperskie w ogóle nie zapisują transkryptów konwersacji. Agent udostępniony użytkownikom bezpośrednio ze środowiska deweloperskiego twórcy nie zostawi więc żadnych logów ani historii potrzebnej do audytu. ### Trzy ustawienia, które warto przejść od razu **Kto może tworzyć środowiska** \- ustawienie tenantowe w PPAC, jedno kliknięcie, ogromny efekt, prawie nikt tego nie zmienia. Domyślnie środowisko produkcyjne albo sandbox może założyć każdy, kto ma odpowiednią licencję. PPAC → Manage → Tenant settings → **Environment assignments: Production**.  *Rysunek: Ograniczenie tworzenia środowisk do administratorów, ustawienie tenantowe w Power Platform admin center.* **Kto ma dostęp do Copilot Studio** \- PPAC → Manage → Tenant settings → **Copilot Studio Authors**: przypisujesz grupę zabezpieczeń i tylko jej członkowie mogą tworzyć agenty. Precyzyjniejsze niż ograniczanie samego środowiska domyślnego.  *Rysunek: Ustawienie Copilot Studio Authors \- grupa zabezpieczeń jako brama do Copilot Studio.* **Grupa zabezpieczeń na środowisku** \- granica dostępu, a przy okazji fakt, o którym mało kto wie: nowe środowiska z Dataverse domyślnie blokują gościom dostęp do danych. Typowy zapis o podmiotach zewnętrznych ma więc pokrycie domyślne.  *Rysunek: Grupa zabezpieczeń przypisana do środowiska.* ## Siedem zapisów, siedem przełączników Dalej idę stałym schematem: zapis polityki, tłumaczenie na język platformy, kontrolka i czego kontrolka nie obejmuje. Cytowane zdania to moje przykłady, wzorowane na typowych sformułowaniach z polityk AI i dokumentów takich jak AI Act czy ISO 42001\. Kolejność od najszerszego zasięgu do najwęższego. ### 1\. „Rozwiązania AI powstają w wydzielonych, kontrolowanych środowiskach” **Co to oznacza w praktyce?** Istnieje osobne środowisko do budowania i osobne do działania, a nikt nie tworzy samodzielnie dodatkowych instancji. **Kontrolka.** Wszystko z poprzedniej sekcji razem: ograniczenie tworzenia środowisk do administratorów, przypisanie grup zabezpieczeń, ustawienia środowisk deweloperskich, a przy większej skali grupy środowisk z regułami nakładanymi zbiorczo. Ten zapis nie ma jednego przełącznika \- ma topologię. **Czego nie obejmuje?** Wszystkiego poza tenantem. Pracownik, który wklei dokument do publicznego czatbota z przeglądarki na prywatnym laptopie, jest poza zasięgiem każdego ustawienia opisanego w tym tekście. To zupełnie inny problem, zwany Shadow AI. ### 2\. „Dane firmowe nie trafiają do usług zewnętrznych” **Co to oznacza w praktyce?** Agent nie może wysłać treści do konektora, którego nikt nie zatwierdził. **Kontrolka.** Advanced Connector Policies (ACP) działają na zasadzie allowlisty: każdy nowy konektor jest domyślnie zablokowany, dopóki administrator świadomie go nie zatwierdzi. Kontrola działa na poziomie pojedynczych akcji i pozwala też zablokować serwery MCP. PPAC → Manage → Environment groups → wybrana grupa środowisk → zakładka Rules → Advanced connector policies.  *Rysunek: Advanced Connector Policies \- allowlista z domyślną blokadą.* Jest jednak istotne „ale”: ACP obejmują wyłącznie konektory certyfikowane. Rozwiązania custom i HTTP nie są jeszcze wspierane i dla nich obowiązuje klasyczne DLP. ACP nie obsługują też konektorów wirtualnych (virtual connectors) \- dokumentacja deklaruje, że nigdy nie będą. Tymczasem wszystkie kontrolki agentowe Copilot Studio, o których piszę dalej (źródła wiedzy, kanały, uwierzytelnianie, umiejętności, wyzwalacze), to właśnie konektory wirtualne. Oznacza to, że te same zapisy polityki są dziś egzekwowane przez trzy równoległe systemy: - ACP \- dla konektorów certyfikowanych, - klasyczne polityki danych \- dla virtual connectors oraz rozwiązań custom i HTTP, - nowe reguły w sekcji Security → Identity and access \- dla kontrolek agentowych. Najważniejszy wniosek: polityka nie powinna nazywać kontrolek, tylko efekty. Zapis „stosujemy politykę DLP klasyfikującą konektory jako biznesowe i niebiznesowe” zdezaktualizuje się przy najbliższej zmianie w platformie. Zapis „dane firmowe nie opuszczają zatwierdzonego zestawu usług, a lista zatwierdzonych usług podlega przeglądowi kwartalnemu” zniesie każdą taką zmianę. **Czego nie obejmuje?** Treści rozmowy z agentem. ACP kontroluje, którym konektorem wolno wysłać dane, a nie to, co użytkownik napisał w prompcie ani co odpowiedział agent. Jeśli ktoś wklei dane poufne do rozmowy, a agent przekaże je dalej przez dozwolony konektor, polityka tego nie wyłapie. Blokowane są kombinacje konektorów, nie same połączenia. Przy MCP da się zablokować cały serwer, ale nie pojedyncze narzędzie w jego obrębie. I rzecz najbardziej praktyczna: w środowiskach niezarządzanych konektory oznaczone jako nieblokowane pozostają nieblokowane \- dopiero Managed Environment pozwala zablokować dowolny konektor lub akcję. ### 3\. „Agent nie działa anonimowo” **Co to oznacza w praktyce?** Dostęp do agenta wymaga uwierzytelnienia, a każda interakcja jest przypisana do konkretnego użytkownika. **Kontrolka, warstwa pierwsza (GA).** W klasycznej polityce danych blokujesz virtual connector `Chat without Microsoft Entra ID authentication in Copilot Studio`. Twórca traci wtedy możliwość wypuszczenia agenta z opcją „No authentication” \- zostaje uwierzytelnianie Microsoft albo ręczna konfiguracja. Egzekwowanie jest twarde i widoczne: przycisk Publish przestaje działać, a twórca dostaje do pobrania raport naruszeń.  *Rysunek: Blokada anonimowego czatu ustawiona w klasycznej polityce danych (GA).*  *Rysunek: Skutek blokady widziany od strony twórcy \- w zakładce Security agenta opcja braku uwierzytelniania jest niedostępna.* Tworząc tę politykę (PPAC → Security → Data and privacy → Data policies → nowa polityka), warto od razu ustawić jej zakres na „Add all environments”. Polityka obejmie wtedy automatycznie każde nowo utworzone środowisko.  *Rysunek: Zakres polityki danych ustawiony na wszystkie środowiska, łącznie z tymi, które dopiero powstaną.* **Kontrolka, warstwa druga (preview).** PPAC → Security → Identity and access → **Authentication for agents**: reguła na poziomie środowiska lub grupy środowisk, cztery opcje: brak uwierzytelnienia, wymagane Microsoft, wymagane Entra, wszystkie wspierane metody. Dokumentacja opisuje ją wprost jako zmodernizowany framework istniejącego virtual connectora i rekomenduje migrację w tę stronę.  *Rysunek: Authentication for agents (preview) \- reguła nakładana na grupę środowisk.* Gdy obie kontrolki działają równolegle, obowiązuje najsurowsza z reguł: blokada w którymkolwiek miejscu odrzuca wywołanie w czasie działania (runtime). Z tego powodu warstwę GA należy zachować nawet podczas migracji, tym bardziej że reguły w statusie preview nie dają gwarancji produkcyjnych. Druga część zapisu dotyczy miejsc publikacji agenta i opiera się na tym samym dwuwarstwowym wzorcu. Podstawę tworzą virtual connectors w klasycznym DLP (Teams, Microsoft 365, Direct Line, Facebook, SharePoint, WhatsApp, Omnichannel), a wyższy poziom to Agent access channels w sekcji Identity and access. Co ważne: Direct Line jest dozwolony domyślnie. W praktyce demo website i osadzenie agenta na stronie są otwarte, dopóki świadomie ich nie wyłączysz.  *Rysunek: Konfiguracja Agent access channels w PPAC \- kanały publikacji zablokowane na poziomie administracyjnym.*  *Rysunek: Skutek widziany od strony twórcy \- w zakładce Channels agenta zablokowane kanały są oznaczone jako niedostępne.* **Czego nie obejmuje?** Uwierzytelnienie to nie autoryzacja do danych. Agent działa pod tożsamością użytkownika końcowego, więc o tym, co konkretnie zwróci, decydują uprawnienia na źródłach wiedzy, a nie sam fakt zalogowania. ### 4\. „Agent korzysta wyłącznie z zatwierdzonych źródeł wiedzy” **Co to oznacza w praktyce?** Twórca nie może wskazać agentowi dowolnej biblioteki SharePointa ani dowolnej strony internetowej. **Kontrolka.** Tu jest największa niespodzianka tego artykułu: źródła wiedzy powszechnie uchodzą za ustawienie twórcy, a są kontrolką administracyjną. W klasycznej polityce danych (PPAC → Security → Data and privacy → Data policy) występują jako trzy osobne virtual connectors: `Knowledge source with SharePoint and OneDrive in Copilot Studio`, `Knowledge source with public websites and data in Copilot Studio` oraz `Knowledge source with documents in Copilot Studio`.  *Rysunek: Trzy virtual connectors źródeł wiedzy na liście klasycznej polityki danych.* Pierwsze dwa konektory wspierają filtrowanie punktów końcowych (Configure connector → Connector endpoints). Pozwala to jawnie zezwalać na konkretne adresy SharePointa i witryny publiczne lub je blokować, także z użyciem wzorców (np. wildcardów). Dokładnie tej funkcji brakowało: zasada „ta biblioteka tak, tamta witryna nie” przestaje być kwestią dobrej woli twórcy, a staje się twardą polityką egzekwowaną przez platformę.  *Rysunek: Filtrowanie endpointów \- allowlista konkretnych adresów SharePointa.* Politykę można przypisać do jednego środowiska, wybranych środowisk lub całego tenanta, z opcją automatycznego obejmowania nowo tworzonych zasobów. Przy naruszeniu przycisk Publish przestaje działać, a wygenerowany raport zawiera osobny wiersz dla samego źródła i dla każdego węzła generative answers, który z niego korzysta.  *Rysunek: Tak wygląda egzekwowanie od strony twórcy \- publikacja zablokowana, raport naruszeń do pobrania.* Po stronie samego Copilot Studio nadal warto wyłączyć ogólną wiedzę modelu oraz przeszukiwanie publicznego internetu. Dobrą praktyką pozostaje też wskazywanie konkretnej biblioteki zamiast całej witryny. **Czego nie obejmuje?** Allowlista adresów mówi, skąd wolno czerpać, a nie komu wolno zobaczyć. Agent działa w kontekście tożsamości użytkownika, więc o zawartości odpowiedzi decydują jego realne uprawnienia w SharePoincie. Jeśli jakaś biblioteka ma zbyt szerokie dostępy i jest widoczna dla całej organizacji, agent wyciągnie te dane. Ale to już osobny wątek. ### 5\. „Rozwiązanie przechodzi kontrolę przed publikacją” **Co to oznacza w praktyce?** Każdy agent przechodzi proces weryfikacji lub akceptacji, zanim zostanie udostępniony użytkownikom. **Kontrolka.** Managed Environments dają limity udostępniania, solution checker, treści powitalne dla twórców i cotygodniowy raport e-mailowy dla administratora. Ten raport pokazuje, co jest używane, a co nie.  *Rysunek: Panel Managed Environments.* Kwestia kosztów to jedna z najczęstszych pułapek przy wdrażaniu Copilot Studio. Managed Environments nie generują dodatkowych opłat, o ile w danym środowisku nie uruchamiasz tradycyjnych aplikacji kanwy, a rozliczenie opiera się na modelu pay-as-you-go. Jeśli tworzysz wyłącznie agenty, ten warunek jest spełniony automatycznie \- właśnie dlatego działają one bez problemu nawet na licencji Business Basic. **Czego nie obejmuje?** Żadna licencja nie oferuje natywnego mechanizmu zatwierdzania publikacji. W Power Platform po prostu nie ma wbudowanego przełącznika dla zasady „publikacja wymaga akceptacji właściciela biznesowego”. To sprowadza się do migracji między środowiskami i zarządzania cyklem życia agenta, a to temat na osobny wpis. ### 6\. „Kontrolujemy koszty i wiemy, kto co uruchomił” **Co to oznacza w praktyce?** Nikt nie wygeneruje kosztów, o których dowiesz się dopiero przy przeglądaniu faktury. **Kontrolka, warstwa Azure.** Polityka rozliczeniowa w PPAC wiąże środowiska z konkretną subskrypcją i resource group. Jedna polityka na grupę środowisk daje jedną resource group, a więc jeden budżet z alertami na koszcie rzeczywistym i prognozowanym.  *Rysunek: Polityka rozliczeniowa \- środowiska związane z konkretną subskrypcją i resource group.*  *Rysunek: Budżet i alerty na resource group po stronie Azure.* **Kontrolka, warstwa Power Platform.** PPAC → Licensing → Copilot Studio pokazuje zużycie Copilot Credits per środowisko i per agent: dziennie, miesięcznie, z danymi historycznymi za rok wstecz.  *Rysunek: Zużycie Copilot Credits per środowisko i per agent, natywnie w PPAC.* W zakładce Summary → Manage Agents znajdziesz listę wszystkich płatnych agentów w tenancie wraz z limitami, zużyciem od początku miesiąca i statusem (Within limit / Nearing limit / Over limit). Dla każdego agenta określa się miesięczny limit kredytów chroniony dwustopniowo: powiadomieniem dla administratorów (środowiska i tenanta) o zbliżaniu się do progu oraz twardym zatrzymaniem. Zgodnie z dokumentacją agent po przekroczeniu limitu po prostu automatycznie się wyłącza. Mechanizm działa zarówno w modelu przedpłaconym (prepaid), jak i w pay-as-you-go. **Czego nie obejmuje?** Budżet ustawiony w Azure to tylko alert, nie mechanizm blokujący. Twarde zatrzymanie oferuje wyłącznie limit na poziomie agenta w PPAC. Najlepiej połączyć oba podejścia: PPAC pilnuje limitu kredytów, a Azure monitoruje wydatki w walucie i ostrzega administratora, gdy zbliżają się do ustalonego progu. ### 7\. „Prowadzimy ślad rozmów z agentem na potrzeby audytu” **Co to oznacza w praktyce?** System zachowuje rejestr pozwalający odtworzyć pytania użytkownika i odpowiedzi generatywne agenta, wraz z informacją, z jakich narzędzi i źródeł agent skorzystał. **Kontrolka.** PPAC → Manage → Environments → wybrane środowisko → Settings → Product → **Features** → sekcja **Copilot Studio agents**. Są tam dwa osobne przełączniki: czy transkrypty w ogóle zapisują się do Dataverse i czy właściciele oraz edytorzy agenta mogą je oglądać i pobierać.  *Rysunek: Zapis transkryptów do Dataverse \- dwa osobne przełączniki w ustawieniach środowiska.* Do wglądu w transkrypty potrzebna jest rola *Bot Transcript Viewer*. Administrator przypisuje ją osobno \- nie wchodzi ona w skład roli Environment Maker, która pozwala budować agenty. To bardzo konkretny przykład tego, jak platforma rozdziela uprawnienia twórcy agenta od dostępu do historii rozmów. I tu wraca kwestia doboru środowisk. Jeśli agent działa w środowisku deweloperskim, żaden z tych przełączników nie ma znaczenia, bo transkrypty tam po prostu nie powstają. W moim tenancie ten problem nie występuje, bo agenty trafiają do środowisk typu sandbox i do produkcji. W firmach, gdzie agent zostaje na stałe w miejscu utworzenia, ten zapis polityki nie będzie jednak spełniony. **Czego nie obejmuje?** Gdy źródłem wiedzy jest SharePoint, natywny transkrypt zawsze gubi jeden z dwóch kluczowych elementów rozmowy. Co dokładnie znika, zależy od metody podpięcia źródła, a dokumentacja Microsoftu jest tu niespójna: jedna strona twierdzi, że odpowiedź agenta zostaje ukryta jako REDACTED, inna, że z pola search\_results znika treść dokumentów. Który wariant obowiązuje w danej konfiguracji, sprawdzę empirycznie we wpisie poświęconym audytowi. Kluczowe jest jednak co innego: obietnicy odtworzenia rozmowy nie da się na tej warstwie zrealizować. I nie wynika to z braku licencji, lecz z samej architektury logów. Rozwiązaniem jest Application Insights \- o tym za moment. ## Obejścia: co zrobić, gdy kontrolki nie masz Zanim przejdę do konkretów, jedno zastrzeżenie, bez którego łatwo o nieporozumienie: > Obejście jest uzasadnione, gdy zastępuje widoczność, ewidencję albo dowód. Nie jest uzasadnione, gdy udaje kontrolę techniczną. Rejestr prowadzony ręcznie działa, bo jest osobnym spisem, a ten nie musi być generowany przez samą platformę. Deklaracja typu „pilnujemy, żeby nikt nie wskazał poufnej biblioteki jako źródła wiedzy” nie działa, bo to nie mechanizm kontroli, tylko zapisane oczekiwanie. ### Rejestr systemów AI Tabela w Dataverse albo lista SharePoint, uzupełniana ręcznie, uzgadniana kwartalnie z [inwentaryzacją systemów AI](/operacjonalizacja/inwentaryzacja) jako listą kontrolną.  *Rysunek: Natywny inwentarz agentów \- punkt odniesienia przy kwartalnym uzgodnieniu rejestru.*  *Rysunek: Schemat rejestru \- pola, których natywny inwentarz nie ma.* Argument, który przekonuje mnie najbardziej: w wersji zrobionej samodzielnie można dopisać znacznie więcej \- pola na klasyfikację ryzyka według AI Act, cel przetwarzania czy odwołanie do oceny skutków. Taka wersja jest bliżej wymagań prawnych, niż mogłaby być wersja natywna. ### Klasyfikacja danych zamiast etykiet wrażliwości Etykiet Purview nie da się w ten sposób zastąpić i nie ma sensu udawać, że jest inaczej. Można jednak odtworzyć podobny efekt architekturą zamiast klasyfikacją: dane wrażliwe trafiają do osobnej witryny, do której użytkownik końcowy nie ma dostępu, a agentowi wskazuje się konkretną bibliotekę zamiast całego serwisu. Kontrola przenosi się z warstwy danych na warstwę uprawnień. Czego nie osiągniesz: etykieta chroni sam plik, a uprawnienia chronią tylko miejsce, w którym się znajduje. Jeśli ktoś skopiuje plik poza ten obszar, ochrona znika. ### Ślad audytowy zamiast DSPM for AI Application Insights podpięty do agenta sprawia, że telemetria konwersacji trafia do twojego własnego zasobu Azure. Retencja danych i zapytania są pod twoją pełną kontrolą, a działanie agenta przestaje być czarną skrzynką. Na tym na razie poprzestanę, bo audyt i transparentność mają złożony kontekst prawny (art. 12 AI Act, RODO) i zasługują na osobny artykuł. Czego w ten sposób nie załatwisz? Automatycznego wykrywania anomalii i korelacji z sygnałami ryzyka na poziomie całego tenanta. Dodatkowo koszt i utrzymanie tej infrastruktury analitycznej przechodzą na twoją stronę. ### Warunkowy dostęp agenta Na poziomie samej platformy możesz ograniczyć to, kto w ogóle widzi agenta: grupami zabezpieczeń na środowisku i kontrolą kanałów publikacji. Nie uzależnisz jednak dostępu od lokalizacji sieciowej, typu urządzenia czy poziomu ryzyka. Uczciwa odpowiedź brzmi: do tego potrzebujesz licencji Entra ID P1. Warto jednak wiedzieć, co konkretnie zyskujesz w tym modelu. Entra Agent ID osiągnęło status GA i tworzy się automatycznie dla każdego nowego agenta (od lipca 2026 r. bez możliwości wyłączenia). Podczas publikacji Copilot Studio przypisuje do tożsamości agenta uprawnienia API dla każdego użytego konektora. Administrator Entra widzi dzięki temu pełne możliwości agenta bez zaglądania do PPAC.  *Rysunek: Entra Agent ID \- uprawnienia konektorów widoczne jako API permissions na tożsamości agenta.* Ponieważ są to zwykłe uprawnienia API na tożsamości agenta w Entra ID, można na nie nałożyć politykę Conditional Access: zażądać, żeby dostęp do danego konektora działał tylko z sieci firmowej, tylko z urządzenia zgodnego z polityką, albo był blokowany przy podwyższonym ryzyku logowania. Jest tu jednak istotne ograniczenie: dokumentacja wprost mówi, że egzekwowanie tych zakresów w czasie działania, łącznie z Conditional Access na tożsamości agenta, działa dziś wyłącznie przy publikacji do kanału Microsoft Teams, bo to jedyny kanał wykonujący pełne uwierzytelnianie end-to-end z użyciem Entra Agent ID. Widoczność uprawnień w Entra obejmuje wszystkich agentów niezależnie od kanału, ale wymuszenie polityki już nie. Agent opublikowany np. do web chatu będzie miał te same uprawnienia widoczne w Entra, lecz żadna polityka CA nałożona na tę tożsamość nie zostanie tam faktycznie wyegzekwowana. Działa to też bezpiecznie w drugą stronę: nawet jeśli agent ma szerokie uprawnienia na swojej tożsamości, przy każdym wywołaniu są one ponownie sprawdzane wobec ACP i klasycznych polityk danych. Samo posiadanie uprawnienia API nie pozwala agentowi obejść blokad nałożonych w tych dwóch systemach. ## Co odblokowuje wyższa licencja | Kontrolka | Próg licencyjny | Zapis polityki, który dopiero wtedy działa | | :---- | :---- | :---- | | Etykiety wrażliwości (ręczne) | Business Premium / E3 | „Dane są klasyfikowane, a klasyfikacja wędruje razem z dokumentem” | | Automatyczne etykietowanie | E5 / Purview Information Protection Plan 2 | „Klasyfikacja nie zależy od dobrej woli autora dokumentu” | | Conditional Access na tożsamości agenta | Entra ID P1 (docelowo \+ Microsoft Agent 365\) | „Dostęp do agenta zależy od sieci, urządzenia i poziomu ryzyka” | | Global Secure Access for Agents | Global Secure Access / Entra Suite | „Ruch wychodzący agenta podlega filtrowaniu treści i threat intelligence” | | IP Firewall (Managed Environments) | A5/E5/G5 albo dodatki Compliance / Information Protection / Insider Risk | „Do środowiska wchodzi się wyłącznie z sieci firmowej” | | DSPM for AI, Insider Risk Management | E5 | „Wykrywamy anomalie w użyciu AI i korelujemy je z sygnałami ryzyka” | | Alokacja przedpłaconych kredytów per środowisko | pakiet pojemnościowy | „Każdy dział ma własny, wydzielony budżet zużycia” | Celowo nie podaję konkretnych kwot \- szybko się dezaktualizują, a ja nie jestem doradcą licencyjnym. Podane nazwy SKU wystarczą, żeby sprawdzić aktualne stawki w cenniku Microsoftu. Osobny temat to odporność na manipulację promptem. Copilot Studio oferuje wbudowaną ochronę przed atakami prompt injection (UPIA oraz XPIA), która działa domyślnie i bez dopłat. To jednak mechanizm heurystyczny \- [testy bezpieczeństwa AI](/cyberbezpieczenstwo-ai) pokazują, że da się go obejść. Jeśli twoje polityki wymagają twardych gwarancji bezpieczeństwa, domyślny filtr nie wystarczy. Potrzebne są dodatkowe zabezpieczenia: wykrywanie zagrożeń w czasie rzeczywistym (np. Microsoft Defender for Cloud Apps), ścisłe polityki DLP ograniczające konektory oraz zatwierdzanie kluczowych operacji przez człowieka (human-in-the-loop). ## Co zostaje po stronie procesu, nie platformy Cztery zapisy, które w politykach AI występują, a nie mają odpowiednika technicznego na żadnym poziomie licencji. **Informowanie użytkownika, że rozmawia z AI** (art. 50 AI Act) \- to kwestia projektowa, nie techniczny mechanizm kontroli. System nie sprawdzi za ciebie, czy powitanie agenta rzeczywiście zawiera taką informację. **Właściciel biznesowy agenta** \- w ewidencji automatycznie zapisuje się konto dewelopera. Platforma nie oferuje pola na biznesowego opiekuna agenta, choć to on najlepiej wie, jaki jest cel projektu. **Zatwierdzenie merytoryczne przed publikacją** \- nie ma natywnej kontroli, o czym pisałem przy Managed Environments. Jedynym zbliżonym mechanizmem jest proces zatwierdzania przy zgłaszaniu agenta do katalogu organizacyjnego. To jednak decyzja administratora IT, a nie kogoś, kto zna dziedzinę danego agenta: admin ocenia zgodność z politykami i bezpieczeństwo, nie poprawność merytoryczną odpowiedzi. Co więcej, ta weryfikacja dotyczy tylko jednej ścieżki dystrybucji \- agent udostępniony bezpośrednio lub opublikowany w aplikacji Teams przez samego twórcę w ogóle przez nią nie przechodzi. W praktyce żaden natywny mechanizm nie wymusza weryfikacji jakości odpowiedzi. Na to trzeba przygotować osobny proces. **Ocena skutków dla ochrony danych przed uruchomieniem agenta** (art. 35 RODO) \- DPIA jest obowiązkowa tylko przy wysokim ryzyku dla praw i wolności osób, a nie przy każdym kontakcie z danymi osobowymi. Agent AI sięgający po takie dane łatwo jednak przekracza ten próg, łącząc status „nowej technologii” z automatyzacją decyzji, profilowaniem czy dużą skalą. Platforma w żaden sposób tego nie weryfikuje \- Microsoft wprost zaznacza w dokumentacji, że żaden element Power Platform nie wymaga domyślnie przeprowadzenia DPIA. Żaden automat nie sprawdzi więc, czy taka ocena powstała, ani nie zablokuje publikacji w razie jej braku. Kwalifikacja agenta i decyzja o DPIA muszą zapaść ręcznie, w osobnym procesie, zanim źródła wiedzy dla agenta zostaną skonfigurowane. ## Powrót do punktu wyjścia Wracając do scenariusza z pierwszego akapitu: nikt tam nie złamał procedury z premedytacją. Czternaście stron polityki i tak trzeba przeczytać, ale sam dokument nie wystarczy. Konkretne zapisy muszą trafić do konfiguracji platformy. Tego kroku zabrakło, a konkretnie dwóch kontrolek opisanych w tym artykule. Grupa zabezpieczeń Copilot Studio Authors decyduje, kto w ogóle może tworzyć agenty \- pracownik obsługi klienta nigdy nie doszedłby do etapu publikacji, gdyby nie był jej członkiem. Filtrowanie endpointów na źródle wiedzy SharePoint działa jako druga linia: nawet gdyby agenta stworzył, kontrolka nie pozwoliłaby mu wskazać wewnętrznej dokumentacji spoza zatwierdzonej biblioteki. Dzięki odpowiedniej konfiguracji platforma zyskuje możliwość egzekwowania polityk AI, choć nie można opierać się tylko na niej. Procedury i nadzór procesowy pozostają niezbędne \- choćby po to, by weryfikować, czy platforma działa jak należy, i pokryć obszary, których nie obejmuje. Ten tekst opisuje jedną warstwę: środowisko jako granicę kontroli. Przechodzenie agenta między środowiskami, czyli jego cykl życia, to temat na kolejny artykuł. ## Powiązane materiały - [Polityka zarządzania AI](/polityka-zarzadzania-ai) — od zapisów w dokumencie do praktycznego ładu. - [Agentyczna AI](/agentyczna-ai) — ryzyka, autonomia i odpowiedzialność za systemy agentowe. - [Cyberbezpieczeństwo AI](/cyberbezpieczenstwo-ai) — prompt injection, dane i kontrola bezpieczeństwa. - [Inwentaryzacja systemów AI](/operacjonalizacja/inwentaryzacja) — rejestr systemów jako element operacyjnego ładu. - [Ocena dostawcy AI](/ocena-dostawcy-ai) — pomoc w uporządkowaniu pytań do dostawcy rozwiązania AI.

Kacper Janowski

Tekst powstał przy współpracy człowieka i AI. Autor odpowiada za dobór przykładów, wnioski i ostateczną treść materiału.

Zauważyłeś błąd, nieścisłość lub zmianę w Power Platform? Napisz — zgłoszenie pomoże utrzymać artykuł aktualnym.

Polityki AI w Power Platform

Jak przełożyć polityki AI na kontrolki Power Platform: środowiska, dane, uwierzytelnianie agentów, publikację, koszty i transkrypty.