Twoi agenci AI potrzebują opisów stanowisk, a nie lepszych promptów

Zapytaj firmę, co wolno robić nowej analityczce ds. zobowiązań, a otrzymasz precyzyjną odpowiedź. Pracuje w tych systemach, współpracuje z tymi dostawcami, a każda kwota przekraczająca limit akceptacji, powiedzmy 10 000 USD, trafia do jej przełożonego do podpisu. Przez pierwszych kilka miesięcy jest na okresie próbnym. Wszystkie te informacje zwykle znajdują się w tabeli delegacji uprawnień, którą co roku sprawdza audyt wewnętrzny.

Zapytaj tę samą firmę, co wolno robić jej nowemu agentowi do obsługi faktur, a często dostaniesz zrzut ekranu z promptem.

Ta luka niepokoi mnie bardziej niż jakikolwiek wynik testu porównawczego modeli. Zatrudniamy cyfrową kadrę, nie mając systemu zarządzania, który przez stulecie budowaliśmy dla ludzi: nikt nie określa na piśmie jej uprawnień, nikt nie sprawdza jej osądu przed rozpoczęciem pracy i nikt nie ćwiczył jej wyłączania.

Dlaczego prompt nie wystarczy

Prompt opisuje intencję. Określa, do czego służy agent. Rzadko jednak mówi, czego agentowi nie wolno robić, gdzie przebiegają jego granice ani kiedy ma się zatrzymać i przekazać decyzję człowiekowi.

A nawet jeśli prompt określa te kwestie, nic nie zapewnia ich egzekwowania. Polecenie, by agent nie zwracał kwot przekraczających 500 USD, to jedynie prośba skierowana do systemu probabilistycznego. Żaden audytor nie zaakceptowałby stwierdzenia „grzecznie poprosiliśmy analityczkę” jako kontroli dotyczącej człowieka, więc nie rozumiem, dlaczego uznajemy je za wystarczające w przypadku oprogramowania.

Specjaliści ds. bezpieczeństwa mają już nazwę na takie zjawisko. W zestawieniu OWASP Top 10 for LLM Applications nadmierna sprawczość (Excessive Agency) została wskazana jako jedno z kluczowych zagrożeń, wynikające z nadmiernej funkcjonalności, nadmiernych uprawnień lub nadmiernej autonomii. Mówiąc wprost, to tak, jakby pierwszego dnia pracy dać pracownikowi klucze do wszystkiego. Zalecenia OWASP przypominają listę kontrolną dobrego menedżera: udostępniaj agentowi tylko potrzebne narzędzia, ograniczaj jego uprawnienia, wymagaj ludzkiej akceptacji działań o poważnych skutkach i egzekwuj autoryzację w systemach niższego poziomu zamiast ufać, że model sam będzie pilnował przestrzegania zasad.

Podkreśliłbym tę ostatnią kwestię. Przyznane uprawnienia muszą obowiązywać tam, gdzie dochodzi do działania: w tożsamości usługi przypisanej samemu agentowi, w jego uprawnieniach do narzędzi oraz w limicie wydatków ustawionym na bramie API. Uruchamianie agentów na wspólnym koncie usługi przypomina sytuację, w której pięć osób korzysta z jednej przepustki. Gdy coś pójdzie nie tak, w dzienniku audytowym widnieje konto usługi, a ty musisz zgadywać, który agent wykonał działanie.

Anulowane projekty to problem z zarządzaniem

Gartner przewiduje, że do końca 2027 roku zostanie anulowanych ponad 40% projektów agentowej AI, wskazując na rosnące koszty, niejasną wartość biznesową i niewystarczające mechanizmy kontroli ryzyka.

Hype i niedojrzałe produkty to część tego obrazu. Spróbujmy jednak spojrzeć na te trzy przyczyny oczami dyrektora operacyjnego. Koszty rosną, gdy nikt nie ustalił budżetu. Wartość pozostaje niejasna, gdy nikt nie zapisał, jakie efekty miała przynieść praca. Mechanizmy kontroli ryzyka zawodzą, gdy nie ma ograniczeń ani przeglądów i nikt nie ponosi jasno określonej odpowiedzialności. Gartner nie przedstawia tego w ten sposób — to moja interpretacja. Dzieje się to samo, co wtedy, gdy ludziom pozwala się działać bez systemu zarządzania, a ten problem istniał na długo przed pojawieniem się AI.

Ramy postępowania wskazują na tę samą lukę. Ramy zarządzania ryzykiem związanym z AI NIST traktują funkcję Govern jako nadrzędną wobec funkcji Map, Measure i Manage, a Profil generatywnej AI rozszerza to podejście na systemy generatywne. Ramy nie zapewniają jednak operacyjnych mechanizmów — przyznawania uprawnień, testów i przeglądów, z których zespół faktycznie korzysta na co dzień. Bez nich zarządzanie pozostaje dokumentem PDF na współdzielonym dysku.

Jak przełożyć tradycyjne narzędzia zarządzania na agentów

Zacznij od opisu stanowiska, który w przypadku agenta przyjmuje formę określenia zakresu uprawnień. Zanim agent uzyska dostęp do działającego systemu, ktoś powinien móc przygotować jednostronicowy dokument określający, co agent może robić, czego nie wolno mu robić, jakie obowiązują progi akceptacji, kto za niego odpowiada i kto może rozszerzyć jego uprawnienia. W macierzy RACI za rozliczalność odpowiada konkretna osoba. Jeśli nie potrafisz przygotować takiego dokumentu, stanowisko nie jest gotowe do obsadzenia — powiedziałbyś to samo o zatrudnianiu człowieka.

Dwie tradycyjne zasady delegowania uprawnień mają tu bezpośrednie zastosowanie. Nie można delegować uprawnień, których się samemu nie posiada, dlatego podagent nigdy nie powinien otrzymać szerszych uprawnień niż agent, który go uruchomił. Nadal obowiązuje też rozdział obowiązków. Agent, który może zarówno dodać dostawcę, jak i mu zapłacić, stanowiłby ten sam problem wykryty podczas audytu, co w przypadku człowieka.

Pozostaje jeszcze test rekrutacyjny. Agentów sprawdzamy głównie tak, jak sprawdzalibyśmy kalkulator — weryfikując, czy podaje prawidłową odpowiedź. Test pracownika sprawdzałby, czy działał w granicach przyznanych mu uprawnień, poprosił o akceptację, gdy było to wymagane, eskalował sprawę, gdy wykraczała poza zakres jego obowiązków, i zatrzymał się, kiedy powinien.

W ramach własnych badań opracowuję test porównawczy obejmujący 50 scenariuszy dotyczących dokładnie takich błędów: przekraczania progów akceptacji, działania na podstawie nieaktualnych danych, wykonywania wstrzykniętych instrukcji rozszerzających zakres uprawnień oraz zachowywania dostępu po zmianie roli. Jak dotąd sprawdziłem go wyłącznie na agentach skryptowych, by potwierdzić, że scenariusze działają zgodnie z założeniami, więc nie mam wyników dotyczących modeli, które mógłbym przedstawić. Podczas ich opracowywania zaskoczyło mnie, jak bardzo są zwyczajne. To typowe sposoby, w jakie pracownicy odchodzą od wyznaczonego zakresu obowiązków, tyle że przeniesione do świata oprogramowania. Większość publicznych rankingów nadal ocenia wykonanie zadania, a bardzo niewiele sprawdza, czy agent przestrzegał przyznanych mu uprawnień.

Okres próbny i awans przekładają się na agentów dość bezpośrednio. W przypadku ludzi zaczynamy od wąskiego zakresu obowiązków i rozszerzamy go, gdy udowodnią, że potrafią podejmować trafne decyzje. Agenci mogą zdobywać większy zakres uprawnień w ten sam sposób — wykazując, że działają w wyznaczonych granicach, odpowiednio eskalują problemy i prawidłowo się zatrzymują. Taka historia może równie dobrze uzasadniać ograniczenie przyznanych im uprawnień.

W przypadku agentów pojawia się dodatkowa komplikacja, której nie ma przy ludziach. Gdy dostawca aktualizuje model bazowy, w praktyce dostajesz nowego pracownika noszącego starą plakietkę. Potraktowałbym to jako zmianę wymagającą ponownego sprawdzenia, zanim uprawnienia zostaną przeniesione na nowy model.

Zakończenie pracy agenta trzeba przećwiczyć, zanim zajdzie taka potrzeba. Czy gdyby trzeba było zatrzymać tego agenta i odebrać mu dostęp w ciągu najbliższej godziny, bylibyście w stanie to zrobić? Kto ma prawo podjąć taką decyzję o 2:00 w nocy? Co przestanie działać w dalszych etapach procesu i które zobowiązania będące w toku ktoś będzie musiał ręcznie wycofać? Jeśli nikt nie przećwiczył takiego scenariusza, pozostaje mieć nadzieję, że wyłącznik awaryjny zadziała.

Można pociągnąć pracownika do odpowiedzialności. Nie można pociągnąć agenta do odpowiedzialności za cokolwiek — i na tym kończy się to porównanie. Dlatego też przyznane uprawnienia muszą być egzekwowane przez systemy, a każdy agent musi mieć wskazaną osobę, która za niego odpowiada. Tak czy inaczej, ktoś poniesie odpowiedzialność. Zwykle jest to osoba, która wyraziła zgodę, niezależnie od tego, czy wiedziała, na co się zgadza.

O co zapyta analiza incydentu

Niektóre z tych agentów prędzej czy później zrobią coś, czego nie powinny. Gdy tak się stanie, analiza po incydencie obejmie te same pytania, które zadaje się w przypadku ludzi. Co agent mógł robić i gdzie to zapisano? Kto zatwierdził rozszerzenie jego uprawnień? Ile czasu zajęło jego zatrzymanie? Kto za niego odpowiadał?

Jeśli szczere odpowiedzi brzmią: „w poleceniu”, „nikt nie pamięta”, „godziny” i „nie wiadomo”, lepszy model by cię nie uratował.

Gdzie ostatecznie powstaje przewaga

Modele stają się wynajmowanymi zasobami, które dostawcy wymieniają i ulepszają według własnego harmonogramu. Dwie firmy mogą korzystać z tego samego modelu, a mimo to znaleźć się w zupełnie różnych sytuacjach. Jedna ma agentów z budżetami, limitami i opiekunami, a także ścieżką audytu rejestrującą każde działanie o istotnych konsekwencjach. Druga ma kosztowny pilotaż, który zasili czyjeś statystyki anulowanych projektów.

Różnicę stanowi system zarządzania zbudowany wokół modelu. Powstaje on powoli, głównie dzięki ludziom, którzy wcześniej zarządzali organizacjami.

Gdyby jutro twój najnowszy agent przekroczył swoje uprawnienia, czy ktokolwiek w firmie by to zauważył? I czy potrafilibyście na piśmie wykazać audytorowi, gdzie przebiegała granica?