Czy warstwa polityk nie spowolni agenta?

Zależy od tego, gdzie stoi punkt decyzyjny. Silniki takie jak Open Policy Agent można uruchomić jako proces obok aplikacji albo jako bibliotekę w jej procesie, co znosi przeskok sieciowy przy każdej decyzji. Zmierz opóźnienie p95 na własnym zbiorze reguł i własnym ruchu, zamiast przyjmować liczby z materiałów dostawcy — wynik silnie zależy od liczby polityk i od tego, ile danych trzeba dociągnąć ze źródeł kontekstu.

Czym orkiestracja polityk różni się od guardrails?

Guardrails oceniają treść: czy to, co model napisał albo dostał na wejściu, nie łamie zasad. Orkiestracja polityk rozstrzyga uprawnienia: czy agent w tej roli, w tym celu i na tych danych ma prawo wykonać daną operację. To dwie różne warstwy i dobrze zbudowany system ma obie — filtr treści nie zatrzyma wywołania API, do którego agent po prostu nie powinien mieć dostępu.

Czy do oceny polityk można użyć drugiego modelu językowego?

Jako uzupełnienie tak, jako jedyny organ rozstrzygający nie. Model dobrze radzi sobie z kryteriami nieostrymi, ale jego odpowiedź nie jest powtarzalna, więc nie da się jej obronić przed audytorem ani odtworzyć po pół roku. Bezpieczny wzorzec: ocena modelu wchodzi jako jedna z danych wejściowych do deterministycznej reguły, która podejmuje ostateczną decyzję.

Mamy trzech agentów wewnętrznych. Czy to nie przerost formy?

Przy trzech agentach nie potrzebujesz pełnej architektury z czterema komponentami, ale potrzebujesz dziennika decyzji i reguł zapisanych poza promptem. Zacznij od pięciu najbardziej ryzykownych reguł i jednego punktu egzekwowania przy wywołaniach narzędzi. Koszt dołożenia warstwy rośnie z każdym miesiącem, w którym reguły rozmnażają się po promptach.

Jak przekonać zespół do usunięcia reguł z promptów po wdrożeniu polityk?

Najlepiej działa pokazanie dryfu na konkretnym przykładzie: znajdź regułę, która w promptcie i w kodzie brzmi już inaczej, i zapytaj, która obowiązuje. Zostawienie duplikatu „na wszelki wypadek" nie zwiększa bezpieczeństwa, tylko tworzy drugie, nieaktualizowane źródło prawdy. Usunięcie reguły z prompta powinno być formalnym elementem procedury wdrożenia polityki, a nie dobrą wolą autora.

Który silnik wybrać, jeśli zespół nie zna języka Rego?

Cedar ma składnię bliższą zwykłemu zapisowi uprawnień i łatwiej go czytają osoby spoza zespołu inżynierskiego, co ma znaczenie, gdy polityki mają zatwierdzać ryzyko lub dział prawny. Rego jest bardziej wyrazisty przy regułach złożonych i ma większą społeczność. Jeśli twoje uprawnienia wynikają głównie z relacji między obiektami, rozważ OpenFGA zamiast obu.

Orkiestracja polityk agentów AI: jedna warstwa decyzyjna zamiast reguł w promptach

Dwa panele: po lewej cztery osobne karty reguł leżące pod różnymi kątami, bez połączeń; po prawej jedna karta reguł połączona prostymi liniami z czterema mechanizmami bramek ustawionymi w rzędzie

Reguła „agent nie przekazuje danych osobowych klienta do zewnętrznego modelu bez maskowania” żyje w przeciętnej firmie w czterech miejscach naraz: w akapicie promptu systemowego, w warunku if wewnątrz kodu narzędzia, w konfiguracji bramki API i w rejestrze czynności przetwarzania, który prowadzi inspektor ochrony danych. Cztery zapisy, cztery brzmienia, żadnego wspólnego wersjonowania.

Cała rzecz sypie się przy jednym pytaniu kontrolnym: która wersja tej reguły obowiązywała 14 marca o 11:20, kiedy agent wysłał zgłoszenie do zewnętrznego dostawcy? Odpowiedzi nie ma. Prompt zmieniał się bez historii, kod miał własny cykl wydań, a bramka — jeszcze inny.

Czym jest orkiestracja polityk dla agentów AI

Orkiestracja polityk polega na wyprowadzeniu wszystkich reguł decyzyjnych z promptów i z kodu do jednej warstwy, która na każde żądanie agenta odpowiada rozstrzygnięciem — zezwól, odmów, przekształć albo eskaluj do człowieka — wraz z uzasadnieniem i wpisem w dzienniku decyzji. Prompt przestaje wtedy pełnić rolę regulaminu i wraca do swojej: opisuje zadanie. Reguła istnieje w jednym egzemplarzu, ma numer wersji, testy i właściciela, a każde jej zastosowanie zostawia ślad, który da się pokazać audytorowi.

Pomysł nie jest nowy — to przeniesienie wzorca sprawdzonego w autoryzacji. Standard OASIS XACML od ponad dwudziestu lat oddziela punkt decyzyjny (PDP) od punktu egzekwowania (PEP); tej samej pary pojęć używa NIST SP 800-207 przy opisie architektury zero trust. Agenty AI niczego tu nie wywracają. Zmienia się jedno: pytającym jest program, który podejmuje decyzje probabilistycznie — a to czyni wnętrze jego rozumowania najgorszym z możliwych miejsc na regułę.

Dlaczego prompt jest najgorszym miejscem na regułę

Prompt jest sugestią, nie mechanizmem. Model może się do niej zastosować, może ją pominąć, może zinterpretować ją inaczej po podbiciu wersji modelu — i nie da się wykazać, że w konkretnym wywołaniu ją uwzględnił. Reguła w warstwie decyzyjnej albo się wykonała, albo nie. Jedno i drugie widać w dzienniku.

Prompt jest też bezbronny wobec treści, którą sam przetwarza. Jeśli reguła „nie przelewaj kwot powyżej 5000 zł bez akceptacji” siedzi w tym samym oknie kontekstu co treść maila od klienta, to instrukcja wstrzyknięta w tego maila leży tuż obok reguły i może ją przykryć. Ta sama reguła egzekwowana poza modelem — w kodzie narzędzia płatniczego — jest dla prompt injection nieosiągalna.

Wreszcie: promptu się nie testuje. Nie napiszesz testu jednostkowego, który potwierdzi, że akapit numer siedem zadziała w dwustu wariantach żądania. Politykę zapisaną jako kod przetestujesz jak każdy inny kod — silnik Open Policy Agent ma do tego wbudowane polecenie opa test, a Cedar (język polityk o otwartym kodzie, opracowany przez AWS) daje narzędzia do porównania dwóch wersji polityki pod kątem tego, czy nowa nie poszerza uprawnień.

Kryterium	Reguła w prompcie	Reguła w kodzie agenta	Reguła w warstwie polityk
Wersjonowanie	brak albo tylko historia pliku	wspólne z cyklem wydań aplikacji	własne, niezależne od wydań
Test przed wdrożeniem	wyłącznie ocena jakościowa	test jednostkowy	test jednostkowy i tryb obserwacji
Odporność na prompt injection	żadna	pełna	pełna
Zasięg	jeden agent	jeden agent	wszystkie agenty i narzędzia
Ślad dla audytora	brak	log aplikacji, o ile ktoś go dopisał	dziennik decyzji z uzasadnieniem
Zmiana reguły	poprawka w tekście, ryzyko regresji	wydanie nowej wersji aplikacji	wydanie samej polityki
Kto może zmienić	autor promptu	zespół inżynierski	właściciel polityki, wedle procedury

Anatomia warstwy decyzyjnej

Warstwa ma cztery elementy o rozdzielonych rolach. Punkt decyzyjny (PDP) rozstrzyga i nie wie nic o tym, kto go pyta. Punkty egzekwowania (PEP) stoją wszędzie tam, gdzie agent styka się ze światem, i wykonują wyrok. Repozytorium polityk (PAP) trzyma reguły jako kod — w gicie, z przeglądem zmian. Źródła kontekstu (PIP) dokładają dane, których w samym żądaniu nie ma: klasyfikację zbioru, status zatrudnienia zlecającego, limit wykorzystany w bieżącym miesiącu.

Jedna decyzja, cztery możliwe rozstrzygnięcia. PEP przechwytuje, PDP rozstrzyga, PAP wydaje reguły, a PIP dokłada fakty, których samo żądanie nie niesie — i każdy wynik ląduje w śladzie audytowym.

Przy wdrożeniu najczęściej sypią się PEP-y. Zespół stawia jeden przed wywołaniem modelu i uznaje temat za zamknięty. W praktyce potrzeba ich co najmniej czterech: przy wyborze i wywołaniu narzędzia, przy sięganiu po dane (również w wyszukiwaniu RAG), przy odpowiedzi wychodzącej poza organizację i przy przekazaniu zadania innemu agentowi. Punkt narzędziowy omawiamy osobno w tekście o bramce MCP i autoryzacji.

Co musi wiedzieć punkt decyzyjny

To, jak precyzyjne mogą być reguły, przesądza się w modelu kontekstu. Minimum to: tożsamość agenta i — osobno — tożsamość człowieka, w którego imieniu agent działa; operacja i jej parametry; klasyfikacja danych, których dotyczy; cel nadany zadaniu przy starcie; przypisany mu poziom autonomii; oraz stan sesji, czyli ile podobnych operacji agent wykonał już w danym oknie czasowym.

Ostatnia pozycja bywa pomijana, a odpowiada za całą klasę zagrożeń. Pobranie jednego rekordu klienta jest niegroźne. Pobranie ośmiu tysięcy rekordów, po jednym, rozłożone na kilka dni, to już eksfiltracja. Reguła bezstanowa tego nie zobaczy.

Cztery rozstrzygnięcia zamiast dwóch

Polityka sprowadzona do „zezwól albo odmów” tworzy system, który ludzie zaczynają obchodzić. Warstwa decyzyjna dla agentów potrzebuje czterech odpowiedzi:

Zezwól — bez zastrzeżeń, choć decyzja i tak trafia do dziennika.
Zezwól z obowiązkiem — operacja przechodzi, ale system musi przy okazji coś zrobić: zamaskować numer PESEL, dopisać znacznik do rekordu, powiadomić właściciela zasobu. XACML nazywa je obligations — najbardziej niedoceniane z czterech rozstrzygnięć.
Przekształć — żądanie wraca zawężone: zamiast całej tabeli trzy kolumny, zamiast pełnej historii ostatnie 30 dni.
Eskaluj — operacja czeka na człowieka. To techniczna realizacja nadzoru ludzkiego, którego wymaga art. 14 unijnego rozporządzenia o sztucznej inteligencji (2024/1689); o samym progu autonomii piszemy szerzej przy nadzorze i poziomach samodzielności agenta.

Odmowa bez alternatywy kosztuje: użytkownik znajdzie drogę obok systemu, najczęściej przez własne konto w publicznym czacie. Przekształcenie i eskalacja trzymają pracę w kontrolowanym torze.

Cykl życia polityki

Reguła zapisana jako kod idzie tą samą drogą co kod aplikacji, z jednym dodatkiem, który przesądza o powodzeniu całego wdrożenia: trybem obserwacji. Nowa polityka rusza w wersji, która niczego nie blokuje, tylko zapisuje, jaką decyzję by podjęła. Po kilku dniach zestawiasz jej rozstrzygnięcia z prawdziwym ruchem i widzisz dokładnie, ile procesów zatrzymałaby niepotrzebnie. Dopiero wtedy przełączasz ją w tryb egzekwowania.

Najczęściej pomijany jest krok ostatni: usunięcie reguły z promptu i z kodu po tym, jak zaczęła działać w warstwie polityk. Bez tego zostają dwa zapisy tej samej reguły, które w kilka miesięcy się rozjadą — i nikt już nie będzie wiedział, który obowiązuje. Migracja bez sprzątania mnoży bałagan, zamiast go ograniczać.

Potrzebna jest też zasada rozstrzygania konfliktów, ustalona z góry i spisana. Domyślnie: odmowa ma pierwszeństwo, polityka organizacji wygrywa z polityką zespołu, a zespołowa z regułą pojedynczego agenta. Bez tego pierwszy sprzeczny zestaw reguł zamienia warstwę decyzyjną w loterię.

Czym to nie jest

Warstwa polityk nie zastępuje filtrów treści. Guardrails oceniają, co model napisał albo co do niego przyszło — czy w odpowiedzi nie ma treści zakazanej, czy w danych wejściowych nie siedzi wstrzyknięta instrukcja. Orkiestracja polityk rozstrzyga co innego: czy agent w ogóle ma prawo wykonać daną operację na danym zasobie. To odpowiedzi na dwa różne pytania i potrzebne są obie.

Warstwa polityk to również nie jest drugi model językowy w roli sędziego. Model oceniający bywa przydatny przy kryteriach nieostrych („czy ta treść obraża odbiorcę”), ale jego rozstrzygnięcia nie są powtarzalne i nie stanowią dowodu. Jeśli sięgasz po ten wzorzec, niech ocena modelu będzie jedną z przesłanek deterministycznej reguły, nigdy jej zamiennikiem.

Czym to zbudować

Nie ma dziś standardu polityk pisanego specjalnie pod agenty i nic nie wskazuje, żeby był potrzebny — silniki autoryzacyjne ogólnego przeznaczenia obsługują ten model bez przeróbek:

Open Policy Agent — projekt fundacji CNCF o statusie graduated, czyli najwyższym stopniu dojrzałości; język Rego, uruchamiany jako osobny proces obok aplikacji albo jako biblioteka w jej procesie. Ma wbudowane testy i dziennik decyzji.
Cedar — język polityk o otwartym kodzie, opracowany przez AWS; składnia bliższa zwykłemu zdaniu niż Rego, do tego narzędzia do analizy zmian. Ten sam silnik napędza usługę Amazon Verified Permissions.
OpenFGA — projekt fundacji CNCF oparty na modelu relacyjnym w duchu opisanego przez Google systemu Zanzibar; przydaje się, gdy uprawnienia wynikają z relacji („agent czyta dokumenty zespołu, do którego należy jego zleceniodawca”).

To, co w tej układance jest naprawdę agentowe, nie siedzi w silniku, tylko w modelu kontekstu i w rozstawieniu punktów egzekwowania. Jeśli pracujesz z protokołem MCP, zajrzyj do aktualnego rozdziału specyfikacji o autoryzacji na modelcontextprotocol.io — zmienia się szybko i notatki sprzed pół roku bywają już nieaktualne.

Co z tego wynika dla wymogów regulacyjnych

Dziennik decyzji to jeden artefakt, który zamyka kilka niezależnych wymagań naraz. Rozporządzenie 2024/1689 nakłada na systemy wysokiego ryzyka obowiązek rejestrowania zdarzeń (art. 12) i zapewnienia nadzoru ludzkiego (art. 14) — wpis „decyzja X, reguła Y w wersji Z, eskalacja do osoby Q” realizuje jedno i drugie. Harmonogram stosowania poszczególnych obowiązków był przedmiotem dalszych prac legislacyjnych, więc daty sprawdzaj w tekście rozporządzenia na EUR-Lex, a stan krajowej ustawy o systemach sztucznej inteligencji — na stronach Rządowego Centrum Legislacji.

Poza AI Actem działa to tak samo. Zasada rozliczalności z art. 5 ust. 2 RODO każe wykazać zgodność, a nie tylko ją zadeklarować. Rozporządzenie DORA (2022/2554), stosowane od 17 stycznia 2025, wymaga od podmiotów finansowych udokumentowanej kontroli nad środowiskiem teleinformatycznym; Rekomendacja D KNF nakłada to samo na banki. W żadnym z tych przypadków zdanie „mamy to opisane w prompcie” nie jest dowodem. Wpis w dzienniku decyzji — jest.

Od czego zacząć: plan na pierwszy miesiąc

Zinwentaryzuj reguły (tydzień 1). Przejrzyj prompty systemowe wszystkich agentów i wypisz każde zdanie z „nie wolno”, „zawsze”, „tylko jeśli”, „nigdy”. To jest twój prawdziwy, nigdzie nieopisany regulamin.
Oceń ryzyko (tydzień 1). Wybierz pięć reguł, których złamanie kosztowałoby najwięcej — zwykle dotyczą pieniędzy, danych osobowych i komunikacji na zewnątrz.
Zapisz je jako kod (tydzień 2). Przenieś reguły do wybranego silnika razem z testami obu przypadków: tego, który ma przejść, i tego, który ma zostać zablokowany.
Uruchom tryb obserwacji (tydzień 3). Włącz polityki na produkcji bez blokowania, zbierz rozbieżności, popraw reguły.
Przełącz na egzekwowanie i posprzątaj (tydzień 4). Włącz blokowanie, a potem wykreśl te same reguły z promptów i z kodu.

Na kolejne miesiące warto pilnować czterech wskaźników: jaka część wywołań narzędzi przechodzi przez punkt decyzyjny (pokrycie), ile reguł żyje jeszcze wyłącznie w promptach (ma spadać do zera), ile czasu mija od zatwierdzenia zmiany polityki do jej działania na produkcji oraz jaki odsetek decyzji trafia do eskalacji. Jeśli ten ostatni rośnie, polityki są za ciasne i wkrótce ktoś zacznie je obchodzić.