Polityki zamiast promptów

W chwili, w której agentowi wolno cokolwiek zmienić, instrukcja w jego promptcie przestaje być granicą, a staje się sugestią. Prompt to tekst, który model interpretuje; polityka to reguła, którą system egzekwuje, zanim akcja dotrze do świata. Każde poważne pytanie o pozwolenie agentom na działanie jest w istocie pytaniem o to, które z tych dwóch zbudowałeś.

Dlaczego „nigdy nie wolno ci” nie jest kontrolą

Prompt systemowy mówiący, że agent nigdy nie może wystawić zwrotu powyżej progu, nie jest kontrolą — z trzech powodów, które nie mają nic wspólnego ze złym zachowaniem modelu.

Da się go źle odczytać: język naturalny jest wieloznaczny, a instrukcje konkurują ze sobą pod presją. Da się go wyprzeć: wystarczająco dużo kontekstu, długa rozmowa albo przekonująco sformułowany dokument wypchną ograniczenie poza efektywną uwagę modelu. I nie zostawia dowodu: gdy coś pójdzie nie tak, nie ma zapisu odrębnego od rozmowy, który pokazywałby, gdzie w tamtym momencie przebiegała granica.

Nic z tego nie czyni agentów bezużytecznymi. Czyni prompt złym miejscem na granicę.

Co musi wyrażać warstwa polityk

Silnik polityk wart tej nazwy odpowiada na pięć pytań przy każdej akcji, którą agent mógłby wykonać — i odpowiada na nie poza modelem.

Kto działa. Nie „asystent”, tylko który agent, w czyim imieniu i z jakim delegowanym upoważnieniem. Tożsamość jest tym, na czym wisi cała reszta.

Jakiej klasy jest ta akcja. Czytanie to nie pisanie. Redagowanie to nie wysyłanie. Przygotowanie płatności to nie jej wykonanie. Większość użytecznej pracy agentów siedzi na bezpiecznym końcu tego zakresu, a zlanie tych różnic w jedno jest powodem, dla którego zespoły kończą zbyt przestraszone, żeby wdrożyć cokolwiek.

W jakich granicach. Kwoty, liczby, okna czasowe, którzy klienci, które konta, które regały. Limity są nudne i to w nich rozgrywa się cała gra.

Z jakimi dowodami. Co agent musiał przeczytać, sprawdzić albo uzgodnić, zanim akcja stanie się dozwolona. To miejsce, w którym silnik polityk po cichu podnosi jakość, zamiast tylko ograniczać.

Za czyim potwierdzeniem. Niczyim, wskazanego człowieka, dwóch ludzi, albo człowieka i okresu na ochłonięcie. Gradient, nie przełącznik.

Gradient jest sednem

Dyskusję o autonomii agentów zwykle ustawia się wokół zaufania: ufasz mu czy nie. Takie ramowanie produkuje złe systemy, bo wymusza jedną decyzję dla skrajnie różnych akcji.

Znacznie lepszym modelem jest zasłużony zakres, per proces. Agent zaczyna w trybie tylko do odczytu. Proponuje, człowiek rozstrzyga, a i propozycja, i wynik zostają zapisane. Kiedy zapis pokazuje, że w tym konkretnym procesie ma rację wystarczająco długo, granica się przesuwa — tylko dla tego procesu, z doklejonym limitem i z możliwością cofnięcia.

To nie jest stanowisko filozoficzne wobec inteligencji maszyn. Tak wdrożyłbyś zdolnego nowego pracownika, i to z tych samych powodów.

Audyt jako produkt uboczny, nie projekt

Oto argument, który zwykle wygrywa budżet. Jeśli polityka mieszka w promptcie, to odpowiedź na pytanie „dlaczego system zrobił to w marcu” oznacza odtwarzanie rozmowy — o ile jeszcze ją masz — i wnioskowanie o intencji z tekstu.

Jeśli polityka jest obiektem pierwszej kategorii, odpowiedź jest zapytaniem: ta wersja polityki, te wejścia, ta ewaluacja, ten wynik, to potwierdzenie człowieka. Dowody, o które poprosi regulator albo audytor, powstają jako efekt uboczny poprawnego działania systemu, a nie są sklejane w panice kwartał przed kontrolą.

Niewygodna konsekwencja dla projektu produktu

Silnika polityk nie da się dokleić. Musi siedzieć pod tym, co wykonuje akcję, a to znaczy, że jego miejsce jest w systemie operacyjnym, a nie w każdej aplikacji z osobna — inaczej dostajesz jedenaście modeli uprawnień, które się ze sobą nie zgadzają, czyli dokładnie sytuację, którą mamy dzisiaj, tylko z agentami w środku.

To jest argument za umieszczeniem agentów w systemie operacyjnym, a nie w produkcie. Nie dlatego, że brzmi poważniej. Dlatego, że granica jest granicą tylko wtedy, gdy istnieje dokładnie jedno miejsce, w którym da się ją wyegzekwować.