LLM jako „kompilator polityk”: jak przekładać procedury na reguły, które agent egzekwuje

1. Wprowadzenie: czym jest podejście „LLM jako kompilator polityk” i po co je stosować

Podejście „LLM jako kompilator polityk” polega na traktowaniu dużego modelu językowego nie jako „autora decyzji”, lecz jako narzędzia, które przekłada zapisy z dokumentów organizacyjnych na jednoznaczne reguły możliwe do egzekwowania przez system (np. agenta lub warstwę kontrolną). W praktyce LLM wykonuje rolę podobną do kompilatora: bierze wejście w postaci naturalnego języka (procedury, regulaminy, standardy) i transformuje je do postaci, którą da się wykonać, przetestować i monitorować.

Kluczowa idea brzmi: agent nie powinien „domyślać się” polityki podczas działania. Zamiast tego polityka jest opisana w sposób zrozumiały dla maszyny, a agent w runtime porusza się w granicach wyznaczonych przez reguły. LLM pomaga w tym, bo potrafi sprawnie czytać i streszczać złożone teksty, identyfikować zależności oraz ujednolicać język, ale końcowym celem nie jest elegancka odpowiedź w czacie, tylko deterministyczne (lub kontrolowalnie niedeterministyczne) decyzje zgodne z wymaganiami.

Warto odróżnić to podejście od dwóch częstych wzorców:

• „LLM jako decydent”: model dostaje prośbę użytkownika i na bieżąco interpretuje polityki, często na podstawie promptu. To bywa szybkie na start, ale trudniej zapewnić powtarzalność, audytowalność i spójność.
• „LLM jako wyszukiwarka”: model wspiera dostęp do dokumentów (np. poprzez RAG), ale decyzja nadal powstaje w rozmowie. To pomaga w dostępności wiedzy, lecz nie gwarantuje egzekwowania zasad.

„Kompilator polityk” przesuwa środek ciężkości: z interpretacji ad hoc na jawne, wersjonowane reguły, które można kontrolować niezależnie od bieżącego dialogu i zmienności generacji.

Dlaczego to podejście jest potrzebne, szczególnie przy agentach wykonujących działania (np. inicjowanie procesów, składanie wniosków, modyfikacja danych, wysyłka komunikacji)? Ponieważ wraz ze wzrostem autonomii rośnie cena błędu. Organizacje potrzebują mechanizmu, który łączy elastyczność języka naturalnego z wymaganiami inżynieryjnymi: przewidywalnością, weryfikowalnością i możliwością rozliczenia decyzji.

Najczęstsze powody stosowania „LLM jako kompilatora polityk”:

• Spójność decyzji: ta sama sytuacja powinna prowadzić do tej samej klasy decyzji, niezależnie od stylu pytania czy kontekstu rozmowy.
• Audyt i zgodność: łatwiej wykazać, jakie reguły zadziałały i dlaczego, niż odtwarzać „proces myślowy” modelu z promptów.
• Bezpieczeństwo operacyjne: agent dostaje klarowne ograniczenia, a działania ryzykowne wymagają dodatkowych warunków (np. zatwierdzeń), zamiast polegać na ostrożności modelu.
• Skalowalność utrzymania: zmiany w procedurach można przekładać na aktualizacje reguł, a następnie wdrażać w kontrolowany sposób, zamiast modyfikować liczne prompty i instrukcje.
• Rozdzielenie odpowiedzialności: treść polityk może pochodzić od właścicieli procesów, a ich formalna egzekucja jest domeną systemu; LLM wspiera „tłumaczenie” między tymi światami.

W tym ujęciu LLM jest elementem pipeline’u: pomaga wydobyć intencje, definicje, role i warunki z dokumentów oraz ujednolicić je do formy, którą da się wdrożyć. Sama egzekucja polityk odbywa się jednak w sposób zaprojektowany pod kontrolę: tak, aby decyzje agenta były ograniczane regułami, a nie wyłącznie „dobrymi praktykami promptowania”.

Źródła prawdy: typy dokumentów i typowe pułapki interpretacyjne

Żeby LLM mógł działać jak „kompilator polityk”, musi mieć jasno wskazane źródła prawdy — czyli dokumenty, które są wiążące, aktualne i mają określoną moc w organizacji. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. W praktyce polityki agentów rzadko wynikają z jednego tekstu; częściej są wypadkową procedur operacyjnych, regulaminów wewnętrznych, umów oraz wymogów prawnych. Kluczowe jest rozróżnienie, które zapisy są normatywne (nakaz/zakaz/warunek), które są opisowe (wyjaśnienie, kontekst), a które są tylko rekomendacją.

Główne typy dokumentów, z których „kompiluje się” polityki

• Procedury operacyjne (SOP, instrukcje) – opisują kroki procesu „jak to robimy”. Są świetne do wyprowadzania reguł warunkowych (kiedy, kto, co może zrobić), ale często zawierają też praktyki lokalne, skróty myślowe i zależności od narzędzi.
• Polityki i regulaminy wewnętrzne – definiują „co wolno / czego nie wolno” oraz wymagania zgodności (np. bezpieczeństwo informacji, zakupy, podróże służbowe). Zwykle mają wyższy priorytet niż procedury i bywają bardziej ogólne.
• Prawo i regulacje – narzucają ograniczenia zewnętrzne i minimalne standardy. Ich język bywa abstrakcyjny, pełen definicji i wyjątków; nie zawsze da się go przenieść 1:1 na reguły bez decyzji interpretacyjnych i doprecyzowania kontekstu organizacji.
• Umowy, warunki licencji, zobowiązania wobec klientów – często wprowadzają twarde granice w obszarach danych, poufności, retencji, praw autorskich czy dozwolonego użycia narzędzi. Mogą być bardziej restrykcyjne niż regulaminy wewnętrzne.
• Standardy i ramy (wewnętrzne lub branżowe) – dostarczają wymagań „jak powinno być”, ale nie zawsze są bezpośrednio egzekwowalne bez mapowania na konkretne procesy i role.
• Dokumentacja systemowa i konfiguracje – pokazują, co jest technicznie możliwe (role w IAM, uprawnienia w narzędziach, logika workflow). To źródło prawdy o egzekwowaniu, ale niekoniecznie o intencji biznesowej.

Hierarchia i rozstrzyganie konfliktów

Przy kompilacji polityk podstawowym problemem nie jest brak reguł, tylko ich niespójność. W praktyce trzeba przyjąć jasną hierarchię: prawo i zobowiązania kontraktowe zwykle dominują nad dokumentami wewnętrznymi, a regulaminy nad procedurami. Jednak organizacje często mają wyjątki („za zgodą”, „w uzasadnionych przypadkach”), które bez doprecyzowania tworzą luki. Już na etapie wyboru źródeł prawdy warto ustalić: które dokumenty są nadrzędne, co jest obowiązujące globalnie, a co lokalnie, oraz jak traktować rozbieżności między wersjami.

Typowe pułapki interpretacyjne przy zamianie dokumentów na reguły

• Nieostre modalności – słowa typu „powinien”, „zaleca się”, „w miarę możliwości” nie są równoważne „musi”. W regułach trzeba rozróżnić obowiązek od rekomendacji, inaczej agent zacznie blokować działania, które miały być tylko sugerowane.
• Wyjątki ukryte w przypisach i załącznikach – kluczowe ograniczenia bywają w dodatkach, definicjach, aneksach, matrycach odpowiedzialności albo w sekcjach „Postanowienia końcowe”. Pominięcie ich prowadzi do polityk „prawie poprawnych”.
• Zakres i kontekst – zapis może dotyczyć tylko określonych działów, jurysdykcji, typów danych, kanałów komunikacji albo progów kwotowych. Bez wyraźnego zakresu agent może egzekwować regułę zbyt szeroko.
• Niejednoznaczne role i nazwy stanowisk – „kierownik”, „przełożony”, „właściciel procesu” mogą oznaczać różne osoby w różnych jednostkach. Jeśli źródło prawdy nie ma jednoznacznego mapowania do ról systemowych, reguły będą niewykonalne lub łatwe do obejścia.
• Definicje, które zmieniają sens słów – dokumenty prawne i regulaminowe często definiują terminy (np. co jest „danymi wrażliwymi”, „incydentem”, „zatwierdzeniem”). LLM musi wiązać regułę z definicją, a nie z potocznym znaczeniem.
• Reguły „procesowe” vs „wynikowe” – część zapisów opisuje kroki (np. kolejność akceptacji), a część wymaga rezultatów (np. „musi istnieć ślad audytowy”). Mylenie tych typów skutkuje polityką, która albo nie kontroluje ryzyka, albo jest przesadnie restrykcyjna.
• Sprzeczne cele: szybkość vs kontrola – dokumenty tworzone w różnych celach (operacyjnych, compliance, bezpieczeństwa) mogą wymuszać odmienne zachowania. Bez jawnego rozstrzygnięcia priorytetów agent będzie „losowo” wybierał, co egzekwować.
• Nieaktualność i „żywe” interpretacje – praktyka operacyjna często wyprzedza dokumenty albo je omija (np. przez ustne ustalenia). Jeśli źródła prawdy nie mają wersjonowania i właścicieli, kompilacja utrwali błędny stan lub przestarzałe wymogi.
• Wymagania nieegzekwowalne technicznie – dokument może żądać kontroli, której nie da się zrealizować w obecnej architekturze (brak atrybutów, brak logów, brak rozróżnienia typów danych). Wtedy reguły muszą być powiązane z rzeczywistymi punktami kontroli, inaczej pozostaną deklaracją.
• „Za zgodą” bez definicji zgody – częsty zapis, który bez doprecyzowania oznacza wszystko i nic. Dla agenta „zgoda” musi mieć postać sprawdzalnego faktu (kto, kiedy, na co, na jak długo, w jakim zakresie).

Praktyczny wniosek: najpierw ustal, co jest wiążące

Skuteczność podejścia „LLM jako kompilator polityk” zależy mniej od samego modelu, a bardziej od jakości i jednoznaczności źródeł prawdy. Zanim zacznie się przekład na reguły, trzeba jasno wskazać dokumenty nadrzędne, ich aktualne wersje, obowiązujący zakres oraz sposób rozstrzygania niejasności. To ogranicza ryzyko, że agent będzie egzekwował „interpretację tekstu”, a nie rzeczywistą politykę organizacji.

3. Etap 1 – Analiza dokumentu: ekstrakcja wymagań, wyjątków, ról i definicji

W podejściu „LLM jako kompilator polityk” analiza dokumentu to etap zamiany narracyjnego języka procedur na materiał wejściowy do formalizacji: listę jednoznacznych wymagań, wyjątków, ról, definicji oraz miejsc, gdzie dokument jest nieprecyzyjny. Celem nie jest jeszcze projekt reguł, lecz zbudowanie mapy semantycznej tego, co organizacja faktycznie chce egzekwować.

3.1. Co dokładnie „wydobywamy” z dokumentu

W praktyce warto rozdzielić treść na kilka typów elementów, bo każdy z nich będzie inaczej traktowany w kolejnych krokach:

• Wymagania (obowiązki/zakazy) – zdania typu „musi”, „należy”, „nie wolno”, „jest zabronione”.
• Uprawnienia – „może”, „jest uprawniony”, „dopuszcza się”.
• Warunki i progi – kiedy coś obowiązuje (np. kwota, czas, typ danych, kanał, lokalizacja).
• Wyjątki – „chyba że”, „z wyjątkiem”, „w sytuacji awaryjnej”, „po uzyskaniu zgody”.
• Role i odpowiedzialności – kto inicjuje, kto zatwierdza, kto wykonuje, kto audytuje.
• Definicje – znaczenie pojęć (np. „dane wrażliwe”, „incydent”, „zatwierdzenie”).
• Artefakty i dowody – wymagane ślady: numer zgody, załączniki, uzasadnienie, log.
• Ścieżki eskalacji – co zrobić, gdy warunki nie są spełnione (np. dodatkowa akceptacja, blokada, kontakt z właścicielem procesu).

3.2. Różnica między „wymaganiem” a „instrukcją operacyjną”

Dokumenty proceduralne często mieszają dwa porządki: normy (co wolno/nie wolno) i opis działań (jak kliknąć, gdzie znaleźć formularz). Na etapie analizy warto je rozdzielać, bo tylko pierwsza część staje się polityką do egzekwowania przez agenta.

3.3. Ekstrakcja ról: „kto” to nie zawsze nazwa stanowiska

Role w dokumentach bywają opisane stanowiskiem („kierownik”), funkcją („osoba zatwierdzająca”), lub relacją do obiektu („właściciel danych”). W analizie warto sprowadzić je do spójnych kategorii, które da się później mapować na tożsamości i uprawnienia.

• Role procesowe: inicjator, wykonawca, recenzent, zatwierdzający, audytor.
• Role domenowe: właściciel zasobu (np. danych), opiekun systemu, osoba odpowiedzialna za ryzyko.
• Role kontekstowe: zastępstwo, dyżur, tryb awaryjny (kto może działać „w imieniu”).

Typowa pułapka: ten sam termin oznacza różne osoby w zależności od kontekstu („menedżer” jako przełożony vs. „menedżer systemu”). Na tym etapie nie rozstrzygamy implementacji, ale wyłapujemy kolizje pojęć i oznaczamy je do doprecyzowania.

3.4. Wyjątki: warstwa, która najczęściej „łamie” prostą regułę

Wyjątki są krytyczne, bo to one decydują, czy agent ma blokować działanie, czy dopuścić je pod dodatkowymi warunkami. W analizie warto klasyfikować wyjątki, zamiast traktować je jako dopisek.

• Wyjątki warunkowe: „jeśli spełnione są dodatkowe warunki”.
• Wyjątki proceduralne: „można, ale po uzyskaniu zgody / zgłoszeniu / rejestracji”.
• Wyjątki awaryjne: „w sytuacji incydentu / przerwy w działaniu”.
• Wyjątki czasowe: „do końca miesiąca / w oknie serwisowym”.
• Wyjątki zakresowe: „nie dotyczy” określonych obszarów, systemów, typów danych.

Ważne: analizując wyjątki, zapisujemy co dokładnie jest zwalniane (z którego obowiązku) oraz jakie zabezpieczenie zastępcze dokument wprowadza (np. dodatkowa akceptacja, logowanie, powiadomienie).

3.5. Definicje i słowniki: ujednoznacznianie pojęć zanim powstaną reguły

Dokumenty rzadko mają kompletne definicje. LLM potrafi zasugerować definicje robocze, ale na etapie analizy chodzi o zebranie terminów, które muszą mieć jedno znaczenie, bo będą użyte jako warunki reguł.

• Terminy klasyfikacyjne: kategorie danych, poziomy ryzyka, typy operacji.
• Jednostki i progi: waluty, kwoty, limity, przedziały czasowe (z formatem).
• Zdarzenia: co uznaje się za „incydent”, „naruszenie”, „eskalację”.

Jeżeli definicja jest niepełna (np. „dane wrażliwe” bez listy), w wyniku analizy powstaje punkt do doprecyzowania oraz propozycja, jakiego rozróżnienia brakuje (np. klasyfikacja danych, etykiety, źródło atrybutu).

3.6. Wykrywanie niejednoznaczności i konfliktów

Dobry rezultat analizy to nie tylko lista „zasad”, ale też lista miejsc, gdzie zasady nie są egzekwowalne bez decyzji biznesowej lub doprecyzowania. Najczęstsze sygnały ostrzegawcze:

• Modalność miękka: „zwykle”, „w miarę możliwości”, „zaleca się” – czy to obowiązek, czy wskazówka?
• Brak warunków brzegowych: limit bez waluty, termin bez strefy czasowej, „niezwłocznie” bez SLA.
• Konflikty: jedna część dokumentu zezwala, inna zabrania w tym samym kontekście.
• Niekompletne role: jest obowiązek akceptacji, ale brak informacji kto akceptuje.
• Domyślne wyjątki: „za zgodą” bez wymogu rejestracji zgody jako dowodu.

W analizie warto oznaczać takie fragmenty etykietami typu: ambiguous, missing_threshold, missing_actor, conflict. To ułatwia późniejsze decyzje oraz audyt tego, co zostało przyjęte jako interpretacja.

3.7. Minimalny „format wyniku” analizy (artefakt dla formalizacji)

Efektem etapu 1 powinien być ustrukturyzowany zestaw elementów, które da się przeglądać, wersjonować i recenzować. Przykładowy szkic (ilustracyjny) pokazuje, jak można opisać pojedyncze wymaganie wraz z wyjątkami i rolami:

{
  "requirement_id": "REQ-012",
  "statement": "Operacja typu A wymaga zatwierdzenia, gdy wartość > próg.",
  "modality": "must",
  "subject_role": "inicjator",
  "approver_role": "zatwierdzający",
  "conditions": ["operation_type == A", "amount > threshold"],
  "exceptions": [
    {
      "type": "procedural",
      "when": "tryb_awaryjny == true",
      "compensating_controls": ["rejestracja_uzasadnienia", "powiadomienie_audytora"]
    }
  ],
  "definitions_needed": ["operation_type A", "threshold", "tryb_awaryjny"],
  "evidence": ["identyfikator_zgody", "uzasadnienie"],
  "notes": ["Brak definicji progu w dokumencie – do ustalenia."]
}

Taki zapis nie przesądza jeszcze o docelowym języku reguł ani mechanizmie egzekucji. Jest natomiast wystarczająco precyzyjny, by ocenić: czy zasada jest kompletna, jakie ma warunki i wyjątki, oraz jakie definicje muszą być doprecyzowane, zanim przejdzie się do formalizacji.

Etap 2 – Formalizacja: model polityk, język reguł, warunki, akcje, ograniczenia i priorytety

Formalizacja to moment, w którym opis „jak powinno być” z dokumentów zostaje przełożony na jednoznaczne, wykonywalne reguły. W podejściu „LLM jako kompilator polityk” LLM pomaga zaprojektować i wypełnić strukturę polityk (policy model), ale wynik ma postać deterministyczną: da się go uruchomić, przetestować i audytować. Celem jest ograniczenie miejsca na interpretację w runtime oraz zapewnienie, że agent egzekwuje zasady w sposób spójny. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — najczęściej nie chodzi o brak zasad, tylko o ich przełożenie na format, który nie zostawia miejsca na „domyślanie się” przez system.

1) Model polityk: co musi być opisane, aby reguła była wykonywalna

Żeby reguła była „kompilowalna”, potrzebuje wspólnego szkieletu. Minimalny model polityki zwykle obejmuje:

• Podmiot (subject): kto inicjuje działanie (rola, uprawnienia, atrybuty, delegacje).
• Obiekt (resource): na czym wykonywana jest operacja (typ zasobu, klasyfikacja danych, właściciel, lokalizacja, system).
• Akcja (action): co ma być zrobione (np. „zatwierdź”, „udostępnij”, „usuń”, „wyślij”).
• Kontekst (context): warunki środowiskowe (czas, kraj, kanał, ryzyko, powód, incydenty, limity budżetowe).
• Decyzja (effect): wynik oceny (allow/deny/require-approval/require-justification).
• Uzasadnienie i ślad (rationale/audit): dlaczego reguła zadziałała i jakie dane wejściowe to potwierdziły.

Kluczowe jest rozdzielenie: polityka opisuje logikę, a dane wejściowe (atrybuty, klasyfikacje, progi) pochodzą z konfigurowalnych źródeł, aby uniknąć „twardego kodowania” wyjątków w samych regułach.

2) Język reguł: od naturalnego języka do formy wykonywalnej

„Język reguł” może przyjmować różne formy. Wybór zależy od tego, czy priorytetem jest czytelność, interoperacyjność, czy możliwość formalnej analizy. Poniżej typowe podejścia (na poziomie różnic i zastosowań):

LLM może pomóc w transpilacji z opisu procedury do wybranej formy reguł, ale „kontrakt” jest jeden: wynik musi być jednoznaczny i możliwy do sprawdzenia mechanicznie (parsowanie, walidacja, typowanie, ograniczenia).

3) Warunki: jak wyrażać „kiedy” reguła ma działać

Warunki powinny być opisane w sposób, który minimalizuje niejednoznaczność. W praktyce używa się kombinacji:

• Predykatów atrybutowych (ABAC): np. klasyfikacja danych, rola, poziom ryzyka, kraj przetwarzania.
• Progów i limitów: kwoty, limity czasowe, liczba prób, limit transakcji na okres.
• Relacji: „właściciel zasobu”, „przełożony”, „delegowany zatwierdzający”, „użytkownik spoza organizacji”.
• Stanów procesu: „przed zatwierdzeniem”, „po publikacji”, „w trakcie incydentu”.

W formalizacji warto konsekwentnie rozróżniać:

• Warunki twarde (must): niespełnienie = blokada lub eskalacja.
• Warunki miękkie (should): niespełnienie = dodatkowe wymagania (uzasadnienie, alert, dodatkowa weryfikacja).

4) Akcje i efekty: co agent ma zrobić po ocenie polityki

Reguły nie powinny kończyć się na „tak/nie”. Dla agentów szczególnie ważne jest, aby polityka wskazywała efekt oraz wymagane działania towarzyszące. Najczęstsze efekty i akcje to:

• ALLOW: wykonaj operację.
• DENY: zablokuj i zwróć powód/uzasadnienie.
• REQUIRE_APPROVAL: wstrzymaj operację i uruchom ścieżkę zatwierdzania (kto, w jakim czasie, z jakimi danymi).
• REQUIRE_JUSTIFICATION: wymuś uzasadnienie w określonym formacie (np. cel biznesowy, podstawa, identyfikator sprawy).
• LOG/ALERT: rejestracja i powiadomienie (np. do SOC/komórki compliance) przy spełnieniu kryteriów.
• REDACT/TRANSFORM: dopuszczaj, ale z modyfikacją (np. anonimizacja, maskowanie, ograniczenie pól).

Ważne: efekt polityki powinien być możliwy do zrealizowania przez runtime (agent/silnik), dlatego akcje warto ograniczać do zdefiniowanego katalogu, a parametry akcji trzymać w strukturze danych.

5) Ograniczenia (constraints): „jak” wolno wykonać działanie

Ograniczenia różnią się od warunków: nie tyle decydują o dopuszczeniu, co precyzują ramy wykonania. Typowe kategorie:

• Ograniczenia kanału: np. tylko poprzez zatwierdzony system, zakaz prywatnych kanałów.
• Ograniczenia zakresu: minimalny niezbędny dostęp, ograniczenie do określonych pól/dokumentów.
• Ograniczenia czasu: dostęp tymczasowy, ważność tokenu, okno operacyjne.
• Ograniczenia geograficzne/prawne: rezydencja danych, transfer transgraniczny, wymagane podstawy.
• Ograniczenia bezpieczeństwa: wymóg MFA, wymóg szyfrowania, zakaz kopiowania.

Formalnie constraints warto traktować jako część wyniku decyzji: „allow, ale tylko jeśli spełnisz X”, co jest naturalne dla agentów wykonujących zadania w wielu krokach.

6) Priorytety i rozstrzyganie konfliktów: co robić, gdy reguły się kłócą

Dokumenty źródłowe często zawierają wyjątki i nakładające się zasady. Formalizacja wymaga jawnej strategii rozstrzygania konfliktów, np.:

• Priorytet liczbowy: reguły o wyższym priorytecie nadpisują niższe.
• Zasada „deny-overrides”: jakakolwiek blokada wygrywa z dopuszczeniem.
• Zasada „specific-over-general”: reguła bardziej szczegółowa wygrywa z ogólną.
• Warstwowanie: osobne warstwy dla prawa/regulacji, polityk wewnętrznych i konfiguracji zespołowych, z ustalonym porządkiem.

Ważne jest także formalne ujęcie wyjątków: zamiast dopisywać je „na końcu”, lepiej modelować jako reguły o wyższym priorytecie lub jako odrębny mechanizm „break-glass” z dodatkowymi wymogami (np. silniejsze logowanie, ograniczenie czasu).

7) Minimalny przykład struktury polityki (orientacyjny)

Przykład pokazuje, jak może wyglądać polityka jako dane: warunki, efekt, obowiązki i priorytet. To nie jest „jedyne słuszne” API, ale ilustruje elementy, które warto ustandaryzować.

{
  "id": "policy.data.share.external",
  "priority": 90,
  "target": {
    "action": "share",
    "resourceType": "document"
  },
  "when": {
    "resource.classification": ["confidential", "restricted"],
    "recipient.type": "external"
  },
  "effect": "REQUIRE_APPROVAL",
  "obligations": [
    {"type": "LOG", "level": "high"},
    {"type": "REQUIRE_JUSTIFICATION", "schema": "business_purpose"},
    {"type": "REDACT", "mode": "remove_personal_identifiers"}
  ],
  "denyReason": null
}

8) Co odróżnia dobrą formalizację od „spisu zasad”

• Jednoznaczność: żadnych „w miarę możliwości”, „zwykle”, „odpowiednio” bez mapowania na warunki/akcje.
• Kompozycja: reguły dają się łączyć i nadpisywać bez przepisywania całości.
• Śladowość: decyzja zawsze potrafi wskazać regułę i dane, które ją uruchomiły.
• Wykonalność: efekty i obowiązki są w katalogu działań, które agent umie zrealizować.
• Odporność na luki: jawne priorytety i strategia konfliktów minimalizują „przypadkowe” pozwolenia.

5. Etap 3 – Testy i weryfikacja: testy jednostkowe polityk, scenariusze, fuzzing, symulacje i metryki pokrycia

Po sformalizowaniu polityk największym ryzykiem nie jest już „czy reguły da się uruchomić”, lecz czy egzekwują intencję: czy nie blokują poprawnych działań, nie przepuszczają zakazanych, poprawnie obsługują wyjątki oraz czy zachowują się deterministycznie w obliczu niepełnych danych. Etap testów i weryfikacji traktuje polityki jak kod: wersjonowany, podlegający regresji i wymagający mierzalnej jakości.

W praktyce weryfikacja polityk ma dwa cele:

• Poprawność funkcjonalna – zgodność z wymaganiami i wyjątkami (w tym priorytetami i konfliktami reguł).
• Odporność operacyjna – przewidywalne zachowanie przy brakach danych, szumie, nietypowych wejściach i zmianach w otoczeniu.

5.1. Rodzaje testów: co sprawdzają i kiedy je stosować

Różnice są istotne: unit mówi „czy reguła działa”, scenariusze mówią „czy proces działa”, fuzzing mówi „czy system nie pęka i nie przepuszcza luk”, a symulacje mówią „czy to da się utrzymać operacyjnie”.

5.2. Testy jednostkowe polityk

Test jednostkowy polityki to minimalny przypadek wejścia (kontekst, atrybuty podmiotu i zasobu, żądana akcja) oraz oczekiwana decyzja. Dobre testy jednostkowe są:

• Deterministyczne – ten sam input daje tę samą decyzję (ważne zwłaszcza, gdy agent korzysta z LLM, ale silnik polityk powinien zwracać wynik powtarzalny).
• Skoncentrowane – sprawdzają jedną regułę lub jeden wyjątek naraz.
• Dwustronne – obejmują przypadek pozytywny (permit) i negatywny (deny), a także boundary cases (progi, daty, kwoty).

Warto rozdzielić asercje na: (1) decyzję (permit/deny), (2) wymagane obligations (np. loguj, uzyskaj akceptację), (3) uzasadnienie (np. kod reguły), aby łatwiej diagnozować regresje.

# Pseudotest (schemat): wejście → decyzja → obowiązki
case = {
  "actor.role": "manager",
  "action": "approve",
  "resource.type": "expense",
  "expense.amount": 950
}
expect(decide(case)).toEqual({
  "decision": "permit",
  "obligations": ["audit_log"],
  "rule": "EXP-APPROVE-UNDER-1000"
})

5.3. Testy scenariuszowe: przepływy i interakcje reguł

Scenariusze łączą reguły w realistyczne historie: wniosek → walidacja → ewentualna eskalacja → decyzja końcowa. Ich celem jest wykrywanie problemów, które nie wychodzą w unit testach, np. gdy reguła A pozwala wykonać krok 1, ale reguła B uniemożliwia krok 2, mimo że proces biznesowy zakłada taką ścieżkę.

Typowe klasy scenariuszy do pokrycia:

• Happy path – standardowa realizacja bez wyjątków.
• Ścieżki wyjątków – odstępstwa, progi, warunki szczególne.
• Konflikty – gdy jednocześnie spełnia się przesłanka pozwalająca i blokująca (sprawdza priorytety).
• Braki danych – np. nieznany koszt, brak klasyfikacji danych, brak właściciela zasobu.

W scenariuszach ważne jest, by nie testować „samej narracji”, tylko konkretne punkty kontrolne: decyzje pośrednie, wymagane akceptacje, wymuszone logowanie, momenty zatrzymania.

5.4. Fuzzing i testy własności: odporność na nieprzewidziane wejścia

Fuzzing (lub property-based testing) nie polega na ręcznym wypisywaniu przypadków, ale na generowaniu ich automatycznie w celu znalezienia luk. W kontekście polityk kluczowe są trzy rodzaje własności:

• Własności bezpieczeństwa: „bez wymaganej klasyfikacji – nigdy permit”, „bez roli – nigdy permit”.
• Własności spójności: „deny ma pierwszeństwo nad permit (jeśli tak przyjęto)”, „ta sama polityka przy tych samych danych zawsze zwraca to samo”.
• Własności brzegowe: zachowanie na progach (np. dokładnie limit), przy pustych listach, nietypowych formatach, wartościach skrajnych.

Fuzzing jest szczególnie przydatny tam, gdzie dane pochodzą z wielu systemów i mogą zawierać nieciągłości: brakujące atrybuty, różne formaty dat, rozbieżne identyfikatory. Celem nie jest „udowodnienie poprawności”, tylko szybkie znalezienie wejść, które łamią założenia.

5.5. Symulacje: skutki polityk w skali i w czasie

Symulacja traktuje polityki jako element sterujący ruchem decyzji: ile spraw zostanie przepuszczonych, ile zatrzymanych, ile trafi do eskalacji, jak szybko będą się tworzyć kolejki i gdzie pojawią się wąskie gardła. Weryfikacja na tym poziomie odpowiada na pytania:

• czy polityki nie powodują nadmiernej liczby eskalacji w normalnych warunkach,
• czy przy wzroście obciążenia nie dochodzi do kaskad blokad (np. zbyt restrykcyjne wymagania danych),
• czy zmiana progu/wyjątku nie wywołuje nieproporcjonalnego efektu na liczbę decyzji „deny”.

Symulacje są też miejscem na testowanie zachowań „czasowych”: wygasanie zgód, okna czasowe na akceptację, rotacja ról, sezonowe piki.

5.6. Metryki pokrycia: jak mierzyć jakość testów polityk

Same testy to za mało bez mierników, które pokażą, co jest nietestowane. Dla polityk przydatne są metryki analogiczne do świata oprogramowania, ale dopasowane do decyzji i wyjątków:

• Pokrycie reguł – ile reguł zostało uruchomionych w testach co najmniej raz.
• Pokrycie gałęzi/warunków – czy każdy istotny warunek był sprawdzony jako prawdziwy i fałszywy (szczególnie progi i wyjątki).
• Pokrycie decyzji – udział przypadków permit/deny/needs-approval (jeśli występuje), by uniknąć sytuacji „wszystko testuje permit”.
• Pokrycie atrybutów – czy testy obejmują brak danych, wartości skrajne i typowe formaty kluczowych pól.
• Pokrycie konfliktów – czy przetestowano sytuacje, w których jednocześnie aktywuje się więcej niż jedna reguła.

Metryki pokrycia mają praktyczne zastosowanie: pomagają planować testy, uzasadniać gotowość do wdrożenia oraz szybko wykrywać „martwe” reguły, które nigdy się nie aktywują (co może oznaczać błąd w warunkach albo nieaktualne założenia).

5.7. Kryteria akceptacji: minimalny „definition of done” dla polityk

Aby etap weryfikacji nie kończył się arbitralnie, warto przyjąć prosty zestaw kryteriów akceptacji:

• Regresja: testy jednostkowe i scenariuszowe przechodzą w pełni po każdej zmianie.
• Brzeg i wyjątki: każdy wyjątek opisany w wymaganiach ma co najmniej jeden test pozytywny i negatywny.
• Odporność: zdefiniowane własności bezpieczeństwa są sprawdzone testami generatywnymi/fuzzingiem.
• Pokrycie: osiągnięto uzgodnione minimum pokrycia reguł i krytycznych gałęzi.
• Brak niespodzianek operacyjnych: symulacje nie wskazują na kaskady eskalacji lub blokad w typowym obciążeniu.

6. Etap 4 – Wdrożenie w runtime: policy engine, egzekucja przez agenta, obserwowalność i bezpieczne aktualizacje

Na etapie runtime podejście „LLM jako kompilator polityk” materializuje się w postaci policy engine oraz sposobu, w jaki agent odwołuje się do reguł przed wykonaniem działań. Celem nie jest już „zrozumienie dokumentu”, lecz powtarzalne i audytowalne egzekwowanie polityk w rzeczywistych przepływach pracy: przy zapytaniach o dane, uruchamianiu narzędzi, podejmowaniu decyzji i eskalacjach.

Policy engine w runtime: co robi i gdzie siedzi

Policy engine to komponent, który odpowiada na pytanie: czy dana akcja jest dozwolona, w jakim zakresie i pod jakimi warunkami. W praktyce łączy cztery funkcje:

• Ocena reguł na podstawie kontekstu (kto, co, na czym, po co, w jakim kanale, z jakim ryzykiem).
• Rozstrzyganie konfliktów (np. reguły ogólne vs wyjątki; allow vs deny) według ustalonych priorytetów.
• Wymuszanie warunków (np. maskowanie danych, wymóg akceptacji, limit kwotowy, obowiązkowy logging).
• Generowanie decyzji i uzasadnienia (decision + rationale) do logów i audytu.

Wdrożeniowo policy engine może działać:

• W procesie agenta (niższe opóźnienia, prostsza integracja, mniejsza izolacja).
• Jako usługa (centralne zarządzanie, łatwiejszy audyt, spójność między wieloma agentami).
• Na brzegu (gateway / proxy narzędzi) – gdy chcesz blokować niepożądane wywołania niezależnie od tego, co „myśli” agent.

Egzekucja przez agenta: kiedy i jak polityka ma „zatrzymywać rękę”

Egzekucja polityk w agentach najczęściej odbywa się w punktach kontrolnych (policy checkpoints). W typowym cyklu działania agenta można wyróżnić trzy momenty, w których polityka ma największą wartość:

• Przed wyborem narzędzia / działania – ograniczenie repertuaru akcji (np. „nie wolno wysyłać danych poza organizację”).
• Przed wykonaniem wywołania – walidacja parametrów i kontekstu (np. zakres danych, odbiorca, kanał, identyfikator zgody).
• Po wykonaniu – wymuszenie obowiązków następczych (np. rejestracja, notyfikacja, przypięcie numeru sprawy).

Ważne jest rozdzielenie: LLM proponuje kolejne kroki, ale policy engine autoryzuje (lub modyfikuje) to, co ostatecznie jest wykonywane. Dzięki temu reguły są egzekwowalne nawet wtedy, gdy model jest niepewny, podatny na manipulację promptem lub działa w nietypowym kontekście.

Decyzje polityk: allow/deny to za mało

W praktyce przydatny jest bogatszy wynik oceny niż proste „tak/nie”. Decyzja może zawierać m.in.:

• Allow – akcja dozwolona bez zmian.
• Deny – akcja zablokowana.
• Allow with constraints – dozwolone, ale z ograniczeniami (np. redukcja pól, limit, dozwolone kanały).
• Require approval / escalation – wymagaj zatwierdzenia, drugiej pary oczu, ticketu, zgody właściciela danych.
• Redact / transform – dozwolone pod warunkiem transformacji (maskowanie, anonimizacja, skrót, agregacja).

Minimalny kontrakt integracyjny: kontekst wejściowy i wynik

Żeby polityki były przenośne między agentami i narzędziami, potrzebujesz stabilnego „kontraktu” wymiany informacji. W uproszczeniu policy engine powinien dostawać ustrukturyzowany kontekst i zwracać ustrukturyzowaną decyzję.

{
  "subject": {"type": "user|service", "id": "...", "role": "..."},
  "action": {"name": "tool.call", "tool": "...", "operation": "..."},
  "resource": {"type": "data|system", "id": "...", "classification": "..."},
  "environment": {"channel": "...", "time": "...", "location": "..."},
  "purpose": {"reason": "...", "case_id": "..."},
  "risk": {"score": 0.0, "signals": ["..."]}
}

Kluczowe jest, aby agent nie „dopowiadał” krytycznych atrybutów w sposób swobodny; atrybuty wysokiej wagi (rola, klasyfikacja danych, tożsamość, zgody) powinny pochodzić z zaufanych źródeł systemowych.

Obserwowalność: logi decyzji, ślad audytowy i metryki

Runtime to miejsce, gdzie polityki muszą być widoczne. Bez obserwowalności nie da się odróżnić: „model zawiódł” od „reguła zablokowała” albo „kontekst był niekompletny”. Dobre praktyki obejmują:

• Decision logs: każda decyzja policy engine (wraz z wersją polityk, identyfikatorem reguł i uzasadnieniem).
• Trace end-to-end: korelacja decyzji z wywołaniami narzędzi i odpowiedziami (request-id / trace-id).
• Metryki: liczba blokad, eskalacji, decyzji warunkowych; rozkład przyczyn; trendy w czasie.
• Alerting: anomalie (nagły wzrost deny, nowe typy narzędzi, podejrzane kombinacje akcji i zasobów).

W logach warto trzymać równowagę między audytem a prywatnością: uzasadnienie i identyfikatory reguł są cenne, ale treści wrażliwe należy ograniczać lub maskować.

Bezpieczne aktualizacje polityk: wersjonowanie, rollout i „hamulce”

Polityki będą się zmieniać: prawo, regulaminy, procesy i katalog narzędzi ewoluują. Aktualizacja w runtime musi być bezpieczna, bo błędna reguła potrafi zarówno zablokować biznes, jak i otworzyć lukę. W praktyce stosuje się:

• Wersjonowanie: jawna wersja polityk dołączana do decyzji oraz możliwość szybkiego rollbacku.
• Kontrolowany rollout: canary / stopniowe włączanie dla części ruchu, zespołów lub typów akcji.
• Tryb „shadow”: nowe polityki oceniają, ale nie egzekwują (zbierają metryki i porównania).
• Feature flags: przełączniki dla ryzykownych reguł lub nowych integracji narzędzi.
• Bezpieczne domyślne zachowanie: przy braku kontekstu lub błędzie oceny – decyzja konserwatywna (np. eskalacja zamiast allow).

Różne warstwy kontroli: gdzie kończy się agent, a zaczyna platforma

Polityki można egzekwować na kilku poziomach, które się uzupełniają. Zwięzłe porównanie:

Praktyczna definicja sukcesu na runtime

• Egzekucja jest deterministyczna: te same warunki dają tę samą decyzję.
• Decyzje są wyjaśnialne: wiadomo, która reguła zadziałała i dlaczego.
• Zmiany są odwracalne: rollback działa szybko i przewidywalnie.
• System jest obserwowalny: widać wpływ polityk na zachowanie agentów i ryzyko.

7. Przykłady polityk end-to-end: wydatki i delegacje, dostęp do danych, działania wysokiego ryzyka i eskalacje

Poniższe przykłady pokazują, jak podejście „LLM jako kompilator polityk” przekłada realne procedury na zestaw reguł, które agent potrafi egzekwować w całym przebiegu zadania: od interpretacji intencji użytkownika, przez weryfikację warunków, aż po decyzję, logowanie i ewentualną eskalację. Różnice między domenami sprowadzają się głównie do tego, co uznajemy za ryzyko, jakie dowody są wymagane i jaki mechanizm zgody (autoryzacji) jest akceptowalny.

Wydatki i delegacje

W obszarze wydatków polityki zwykle mają charakter transakcyjny: agent ma dopilnować limitów, celowości kosztu, kompletności dokumentów i ścieżki akceptacji. End-to-end oznacza tu, że reguły towarzyszą agentowi w całym procesie: od zapytania o brakujące dane, przez klasyfikację typu wydatku, po wybór kanału akceptacji i przygotowanie materiału audytowego.

• Typowe warunki: progi kwotowe, rodzaj kosztu (np. podróż, narzędzia, reprezentacja), termin rozliczenia, zgodność z budżetem lub projektem, wymóg załączników (faktura, potwierdzenie płatności), dopuszczalne waluty i kursy.
• Wyjątki: sytuacje awaryjne, koszty wymagające wstępnej zgody, odstępstwa wymagające uzasadnienia i wskazania alternatyw.
• Decyzje agenta: automatyczne zatwierdzenie w ramach limitu, przekazanie do akceptacji przełożonego lub właściciela budżetu, blokada i prośba o korektę danych.
• Różnica praktyczna: nacisk jest na spójność procesu i komplet dowodów — nawet gdy agent może wykonać część działań sam, musi pozostawić ślad uzasadniający, dlaczego wydatek mieści się w regułach.

Dostęp do danych

Polityki dostępu do danych są bardziej kontekstowe niż transakcyjne: liczy się nie tylko „kto” i „do czego”, ale też „w jakim celu”, „na jak długo”, „z jakiego środowiska” i „czy dane mogą opuścić granice systemu”. End-to-end oznacza, że agent nie tylko sprawdza uprawnienia, lecz także kontroluje przepływ informacji w trakcie rozmowy i działań (np. ogranicza ujawnienia, wymusza maskowanie, dobiera bezpieczne narzędzia).

• Typowe warunki: rola i zakres obowiązków, klasyfikacja danych (publiczne/wewnętrzne/poufne), cel przetwarzania, minimalizacja danych, zasada najmniejszych uprawnień, wymagania retencji i rejestrowania dostępu.
• Bezpieczeństwo w interakcji: polityka może wymuszać redakcję fragmentów, agregację wyników zamiast surowych rekordów, zakaz kopiowania poza określone kanały, a także ograniczenia dotyczące eksportu.
• Decyzje agenta: udzielenie odpowiedzi w formie „bezpiecznej” (np. statystyki zamiast detali), odmowa udostępnienia wrażliwych danych, skierowanie po formalny wniosek lub do właściciela danych.
• Różnica praktyczna: dominują reguły ciągłej kontroli ujawnień — agent musi pilnować polityki nie tylko przy „wejściu” (autoryzacji), ale też przy każdym kroku rozumowania i generowania odpowiedzi.

Działania wysokiego ryzyka

Wysokie ryzyko dotyczy działań, które są nieodwracalne, kosztowne, wpływają na bezpieczeństwo lub mają konsekwencje prawne. Polityki w tej domenie nie skupiają się na wygodzie, tylko na kontroli szkody: wstrzymywaniu automatyzacji, weryfikacji intencji, ograniczaniu zakresu i wymaganiu niezależnego potwierdzenia.

• Przykładowe cechy ryzyka: usuwanie danych, zmiany konfiguracji bezpieczeństwa, modyfikacje uprawnień, operacje na środowisku produkcyjnym, wysyłka informacji na zewnątrz, decyzje finansowe o dużej wartości.
• Typowe zabezpieczenia: dwustopniowe potwierdzenie, zasada „czterech oczu”, limit zakresu (np. tylko podgląd/tylko tryb symulacji), wymaganie wskazania planu przywrócenia lub procedury awaryjnej.
• Decyzje agenta: przejście w tryb „doradczy” zamiast wykonawczego, przygotowanie planu i checklisty zamiast realizacji, wymuszenie akceptacji przez uprawnioną osobę.
• Różnica praktyczna: reguły częściej są blokujące niż kierunkujące — agent ma preferować bezpieczne alternatywy i minimalizować powierzchnię błędu.

Eskalacje

Eskalacja to polityka „wyjścia awaryjnego” dla przypadków, gdy agent nie ma wystarczających podstaw do działania, ryzyko jest zbyt wysokie lub występuje konflikt wymagań. End-to-end oznacza, że reguły opisują nie tylko fakt eskalacji, ale też kiedy ma nastąpić, do kogo trafi sprawa i jakie informacje agent ma zebrać, by nie przerzucać ciężaru na człowieka.

• Typowe wyzwalacze: niejednoznaczność procedury, sprzeczne warunki, brak wymaganych danych, podejrzenie nadużycia, nietypowy kontekst (np. prośba o obejście standardu), przekroczenie limitów.
• Minimalny pakiet eskalacyjny: streszczenie intencji, wykryte ograniczenia, proponowane opcje zgodne z polityką, lista braków i pytań, oraz uzasadnienie, dlaczego automatyczne wykonanie jest wstrzymane.
• Różnica praktyczna: eskalacja jest elementem polityki jakości — ma zmniejszać ryzyko błędu i skracać czas decyzji po stronie człowieka dzięki ustrukturyzowanemu kontekstowi.

Wspólny mianownik i różnice między domenami

W każdym z powyższych obszarów polityki end-to-end powinny prowadzić agenta do jednego z przewidywalnych rezultatów: wykonaj, wykonaj częściowo w bezpiecznym trybie, poproś o dane, uzyskaj akceptację, albo eskaluj. Różnice wynikają z priorytetów:

• Wydatki: poprawność procesu i kompletność dowodów.
• Dane: kontrola ujawnień i zgodność z klasyfikacją oraz celem.
• Wysokie ryzyko: redukcja szkody, odwracalność, silna autoryzacja.
• Eskalacje: bezpieczne przerwanie automatyzacji i przekazanie sprawy z kontekstem.

Takie przykłady pomagają od początku projektować polityki jako coś więcej niż „lista zasad”: jako zestaw reguł, które agent stosuje konsekwentnie w dialogu, w planowaniu działań i w doborze narzędzi, aby utrzymać zgodność, bezpieczeństwo i audytowalność w praktyce.

Walidacja, audyt i zgodność: ślad decyzji, dowody egzekwowania, przeglądy zmian i zarządzanie wyjątkami

Traktowanie LLM jako „kompilatora polityk” ma sens tylko wtedy, gdy potrafimy udowodnić, że agent działa zgodnie z wymaganiami: wewnętrznymi procedurami, regulaminami, umowami i prawem. Walidacja i audyt nie są więc „dodatkiem”, ale warstwą, która zamienia reguły z deklaracji w egzekwowalną i kontrolowalną praktykę. W tej sekcji chodzi o to, jak organizacyjnie i technicznie podejść do zgodności: jak budować ślad decyzji, jak gromadzić dowody, jak przeglądać zmiany oraz jak obsługiwać wyjątki bez rozszczelnienia polityk.

Ślad decyzji: co agent powinien zostawiać po każdej akcji

Aby decyzje agenta były audytowalne, każda istotna akcja powinna pozostawiać spójny ślad decyzyjny (decision trace). Nie chodzi o pełny „transkrypt” rozmowy, tylko o minimalny, ale wystarczający zapis: jakie reguły były brane pod uwagę, które z nich zadziałały, jakie warunki zostały spełnione, a jakie zablokowały działanie. Taki ślad umożliwia później odtworzenie logiki: dlaczego doszło do zatwierdzenia, odmowy, eskalacji albo zastosowania ograniczeń.

Dobrą praktyką jest rozdzielenie dwóch perspektyw:

• Uzasadnienie operacyjne (dla użytkownika): zwięzłe, zrozumiałe, bez ujawniania wrażliwych detali.
• Uzasadnienie audytowe (dla kontrolerów i zespołów ryzyka): bardziej precyzyjne, z odniesieniami do reguł, wersji polityk i źródeł wymagań.

Dowody egzekwowania: jak pokazać, że reguły nie są „na papierze”

W zgodności liczy się nie tylko to, że reguła istnieje, ale że rzeczywiście ogranicza system. Dowody egzekwowania to artefakty, które potwierdzają, że agent nie mógł wykonać zakazanej czynności albo wykonał ją wyłącznie w dozwolonym trybie (np. po eskalacji, z dodatkowymi kontrolami). Praktycznie oznacza to zbieranie potwierdzeń z warstwy wykonawczej: jakie narzędzia zostały użyte, z jakimi uprawnieniami, w jakim kontekście i czy zastosowano wymagane kroki kontrolne.

Warto rozróżnić:

• Dowody prewencyjne: że blokady, limity i bramki decyzyjne działały (np. odmowa wykonania akcji, wymuszenie zatwierdzenia).
• Dowody detekcyjne: że monitorowanie wykrywa naruszenia i anomalie (np. alarmy, korelacje zdarzeń).
• Dowody korygujące: że organizacja potrafi zareagować (np. cofnięcie uprawnień, unieważnienie operacji, procedura incydentowa).

Przeglądy zmian: kontrola wersji polityk i ich wpływu

Polityki będą się zmieniać: z powodu nowych interpretacji, audytów, incydentów, zmian prawa lub procesu biznesowego. Żeby utrzymać zgodność, potrzebny jest kontrolowany cykl zmian obejmujący: uzasadnienie zmiany, ocenę wpływu oraz akceptację właściwych ról. Kluczowe jest, by dało się odpowiedzieć na pytanie: „która wersja polityki obowiązywała w dniu decyzji?” i „kto i dlaczego ją zmienił?”.

Zmiany polityk powinny być przeglądane nie tylko pod kątem „czy to działa”, ale też:

• czy nie tworzą nowych luk (np. niezamierzonych wyjątków),
• czy nie rozjeżdżają się z dokumentami źródłowymi,
• czy nie obniżają poziomu kontroli dla działań wysokiego ryzyka,
• czy nie zwiększają zbierania lub ujawniania danych w sposób niezgodny z zasadami.

Zarządzanie wyjątkami: gdy proces wymaga obejścia, ale system nie może się rozszczelnić

W realnych organizacjach wyjątki są nieuniknione: sytuacje awaryjne, działania krytyczne czasowo, prace serwisowe, nietypowe przypadki klientowskie. Problem polega na tym, że „ręczne obejście” jest jednym z głównych źródeł naruszeń. Dlatego wyjątki powinny być traktowane jako jawny mechanizm polityk, a nie nieformalna praktyka.

Dobrze zorganizowane zarządzanie wyjątkami obejmuje:

• Wąski zakres: wyjątek dotyczy konkretnej akcji, zasobu lub czasu, a nie „ogólnego pozwolenia”.
• Ograniczenie czasowe: wyjątek wygasa automatycznie (bez polegania na pamięci ludzi).
• Właściwą autoryzację: zatwierdza go rola odpowiedzialna za ryzyko, nie osoba „najbliżej problemu”.
• Rejestrowanie i rozliczalność: kto poprosił, kto zatwierdził, jaka była przesłanka oraz jaki był rezultat.
• Mechanizm powrotu do zgodności: co ma się wydarzyć po zastosowaniu wyjątku (np. uzupełnienie dokumentacji, korekta danych, retrospektywa).

W praktyce warto też pilnować, by wyjątki nie stawały się „trwałym stanem”. Jeżeli ten sam wyjątek pojawia się cyklicznie, to sygnał, że polityka lub proces wymaga rewizji, a nie kolejnych odstępstw.

Zgodność jako cecha systemu, nie jednorazowy projekt

Walidacja, audyt i zgodność w podejściu „LLM jako kompilator polityk” polegają na zamknięciu pętli: od wymagań, przez reguły, po wykonanie i dowód. Jeśli nie potrafimy odtworzyć decyzji agenta, wykazać egzekwowania oraz kontrolować zmian i wyjątków, to polityki pozostają deklaracją. Gdy te elementy są wbudowane, agent staje się nie tylko „użyteczny”, ale też kontrolowalny i rozliczalny w warunkach realnych audytów i wymogów zgodności.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Wykrywanie trendów i sezonowości bez ‘czarnej skrzynki’: STL i wizualne diagnostyki 20 kwietnia 2026

Analiza przeżycia (survival) w biznesie: churn, retencja i ‘czas do zdarzenia’ krok po kroku 18 kwietnia 2026