Policy as Code w systemach AI

Policy as Code, czyli polityka jako kod, oznacza zapisanie reguł biznesowych, bezpieczeństwa lub zgodności w formie, którą system może automatycznie ocenić. Zamiast pozostawić w prompcie zdanie „nie wysyłaj niczego bez zgody”, definiujesz sprawdzalną decyzję: narzędzie wysyłki jest niedostępne bez pola approvalId, a kwota powyżej ustalonego limitu wymaga zatwierdzenia przez konkretną rolę. W systemach AI to ważne, ponieważ model językowy interpretuje instrukcje probabilistycznie. Reguła egzekwowana poza modelem jest deterministyczną bramką między sugestią AI a działaniem w CRM, poczcie, płatnościach lub bazie danych.

Nie chodzi o to, aby każdą decyzję biznesową zamienić w skomplikowany język programowania. Celem jest oddzielenie pytania „co wolno zrobić?” od pytania „jak workflow wykonuje krok?”. Open Policy Agent opisuje ten wzorzec jako oddzielenie podejmowania decyzji o polityce od jej egzekwowania. Aplikacja przekazuje uporządkowane dane wejściowe, na przykład rolę użytkownika, typ rekordu, źródło danych i planowaną akcję, a silnik polityk zwraca decyzję. Wynik może brzmieć nie tylko tak lub nie, lecz także „dozwolone po redakcji danych”, „wymagana akceptacja” albo „zablokuj i zapisz powód”.

Dla ekspertki lub solopreneura najprostsza wersja Policy as Code może żyć w jednym małym kroku przed działaniem. Wyobraź sobie agenta, który przygotowuje follow-upy do leadów. Agent może pobrać ofertę i napisać szkic, ale reguła blokuje wysyłkę, jeśli kontakt nie ma zgody marketingowej, wiadomość zawiera dane wrażliwe albo rekord jest już w stanie „nie kontaktować”. Reguła sprawdza fakty w danych, nie styl odpowiedzi modelu. Dopiero gdy warunki są spełnione, workflow przekazuje wiadomość do wysyłki lub do kolejki akceptacji.

Dobra polityka ma jasny zakres, wejście i skutek. Zacznij od listy działań o realnych konsekwencjach: wysłanie wiadomości, zapis lub usunięcie rekordu, zmiana ceny, eksport danych oraz publikacja. Przy każdym zapisz, kto lub jaki proces może je wykonać, na jakich danych i z jakim dowodem. Następnie stwórz reguły odmawiające dostępu domyślnie. Zasada „domyślnie blokuj, potem dodaj minimalny wyjątek” jest bezpieczniejsza niż lista sytuacji, których agentowi nie wolno. Łączy się z RBAC i zasadą najmniejszych uprawnień, ale ich nie zastępuje.

Polityki trzeba wersjonować i testować tak samo jak prompty albo kod workflowu. Każda zmiana powinna wskazywać problem, właściciela i przypadki graniczne: poprawny lead, lead bez zgody, klient z flagą zakazu kontaktu oraz błąd integracji. Test nie musi wymagać dużej platformy. Wystarczy tabela wejść i oczekiwanych decyzji uruchamiana przed publikacją zmiany. Dzięki temu nowy warunek nie zablokuje przez przypadek całej sprzedaży ani nie otworzy dostępu do danych, które wcześniej były chronione.

Policy as Code nie jest zamiennikiem dla człowieka w pętli, monitoringu ani bezpiecznego projektowania narzędzi agenta. Reguła może stwierdzić, że dozwolona jest wysyłka po akceptacji, ale nie oceni automatycznie, czy oferta jest sensowna dla konkretnej osoby. Model może też próbować użyć narzędzia w sposób, którego nie przewidziałeś. Dlatego polityka powinna ograniczać uprawnienia, walidować parametry i zostawiać ślad decyzji, a proces musi mieć log, alert i drogę eskalacji. Przy ryzykownych akcjach nadal potrzebujesz osoby, która może zatrzymać proces.

Najczęstszy błąd to ukrycie polityki wyłącznie w długim prompcie. Taki zapis jest trudny do audytu, łatwy do nadpisania przez późniejszy kontekst i nie daje wiarygodnego dowodu, że akcja została zablokowana. Drugi błąd to tworzenie ogólnej, nieczytelnej polityki bez właściciela. Zacznij od jednego procesu, w którym błąd byłby kosztowny, na przykład publikacji, kontaktu z klientem lub dostępu do plików. Zdefiniuj kilka prostych decyzji, przetestuj je na realnych przypadkach i dopiero potem rozszerzaj zakres. System AI staje się wtedy mniej efektowny w demie, ale znacznie bezpieczniejszy w codziennej pracy.