Autonomia agenta AI: 4 poziomy swobody i jak ustawić hamulce, żeby nie stracić kontroli 

Autonomia agenta AI da się opisać czterema poziomami swobody: od systemu, który robi dokładnie to, co mu się kazało, po agenta, który sam decyduje, kiedy użyć narzędzia i kiedy oddać Ci kontrolę. Hamulce ustawia się nie w instrukcji pisanej do agenta, tylko w warstwie technicznej ponad nim - limitach uprawnień, progach kwot i bramkach, które wymagają Twojego zatwierdzenia. Różnica między agentem, któremu możesz zaufać, a takim, po którym zostaje sprzątanie, polega właśnie na tej warstwie.

Czym jest autonomia agenta AI i dlaczego nie ma jednego standardu

Agent AI to program, który nie tylko odpowiada na pytanie, ale też sięga po narzędzia: wyszukuje w internecie, czyta pliki, wysyła maile, zmienia wpisy w systemie. Autonomia mówi o tym, ile z tych decyzji podejmuje sam, bez pytania Ciebie o zgodę. Im więcej, tym mniej Twojego czasu agent potrzebuje. Im mniej, tym mniejsze ryzyko, że zrobi coś, czego nie chciałeś.

Nie ma jednego oficjalnego spisu poziomów i warto powiedzieć to wprost. Anthropic w badaniu z lutego 2026 roku zaczyna od zdania, że nie ma uzgodnionej definicji tego, czym jest agent. Zamiast poziomów firma używa skali od 1 do 10, gdzie niska wartość oznacza, że agent wykonuje jawne polecenia człowieka, a wysoka - że działa samodzielnie.

Inni producenci liczą inaczej. NVIDIA stosuje cztery poziomy ponumerowane od 0 do 3, Docusign opisuje cztery poziomy autonomii umów od 1 do 4, firma Swarmia publikuje pięć poziomów pracy agenta programistycznego, a czeska platforma FlowHunt wyróżnia trzy typy agentów według rodzaju nadzoru. Zanim zaczniesz porównywać te tabele, warto zobaczyć, co agenci realnie robią w typowych zadaniach biznesowych.

Poziom 0 i Poziom 1 - pełna determinacja, czyli „zero swobody"

Poziom 0 - Inference API. Jedno zlecenie użytkownika przekłada się dokładnie na jedno wywołanie modelu. Nie ma pętli, nie ma wyboru, nie ma drugiego kroku. To zwykłe zapytanie do modelu językowego, tyle że w formie usługi.

Poziom 1 - Deterministic system. Wywołań jest więcej niż jedno, ale ich kolejność jest ustalona z góry i nie zależy ani od odpowiedzi modelu, ani od tego, co wpisał człowiek. System zawsze robi to samo, krok po kroku, za każdym razem tak samo.

Na tych dwóch poziomach nie potrzebujesz żadnych zabezpieczeń, bo agent nie decyduje. Może wyjść, że jest awaria albo że nic nie robi, ale nie wyśle nikomu e-maila przez pomyłkę. NVIDIA zaleca tutaj jedno: standardowe zabezpieczenia API - klucze w zmiennych środowiskowych, HTTPS, kontrola dostępu. Trudno o czymś bardziej zwięzłym.

Warto znać granicę między poziomem 1 a 2, bo przemysł często ją przekracza nieświadomie. Firma Swarmia opisuje to tak: jeśli potrafisz opisać zadanie jednym zdaniem bez żadnych wyjątków, agent prawdopodobnie obsłuży je bez Twojego nadzoru. Jeśli nie potrafisz - potrzebujesz się w pętli. Prosty czat z nawigacją po repozytorium to poziom 2. Różnica między zwykłym przepływem a agentem często sprowadza się właśnie do tego, czy kolejność kroków jest z góry ustalona.

Poziom 2 - agent decyduje, ale tylko w ustalonych punktach

Poziom 2 - Weakly autonomous system. Model sam decyduje, czy i jak użyć dodatkowego narzędzia albo wykonać dodatkowe wywołanie, ale robi to wyłącznie w punktach decyzyjnych, które ktoś wcześniej oznaczył. Nie wymyśli nowego kroku, nie wróci do poprzedniego - cały przepływ da się rozpisać w grafie skierowanym bez pętli i wszystkie ścieżki da się policzyć z góry.

To jest poziom, na którym warto się zatrzymać w większości firm. Agent daje radę zdecydować, czy odpowiedź wymaga sprawdzenia w bazie, czy wystarczy wiedza modelu, ale nadal krąży w granicach, które mu wyznaczono. Dla NVIDIA zalecana kontrola na tym poziomie brzmi: wypisz przepływy danych, znajdź te, w których mogą pojawić się dane z zewnątrz, i rozważ zatwierdzanie ręczne w chwili użycia dla działań wrażliwych.

Poziom 3 - pełna autonomia i wykładniczy problem kontroli

Poziom 3 - Fully autonomous system. Model sam decyduje, kiedy i jak użyć narzędzi lub innych modeli, może swobodnie zmieniać własny plan i sam decyduje, kiedy oddać Ci kontrolę. NVIDIA jako przykłady podaje autonomiczne pętle typu BabyAGI i agentów typu „computer use".

Powód, dla którego na tym poziomie wszystko staje się trudne, jest matematyczny, nie organizacyjny. Liczba możliwych ścieżek wykonania rośnie wykładniczo wraz z liczbą kroków. Przy poziomie 2 wszystkie ścieżki da się policzyć przed uruchomieniem. Przy poziomie 3 jest to „generalnie niewykonalne" - z samej definicji nie da się wypisać kompletnej listy możliwych zachowań agenta.

Z tego wynika praktyczna wniosek, który NVIDIA stawia wprost: wyższy poziom autonomii nie oznacza automatycznie wyższego ryzyka - oznacza mniejszą przewidywalność. W pełni autonomiczny system, który nie ma dostępu do wrażliwych narzędzi, może być mniej ryzykowny niż system deterministyczny z dostępem do płatności. Ryzyko w tym układzie siedzi nie w poziomie, tylko w katalogu narzędzi udostępnionych agentowi. To stoi w pewnej sprzeczności z popularnym poglądem i warto ją znać, bo zmienia decyzję: zamiast „obniżać autonomię", często wystarczy odebrać agentowi jedno wrażliwe narzędzie.

Co mówią dane z realnych wdrożeń

Tu warto zobaczyć, jak autonomia wygląda w praktyce, bo liczby są mniej różowe niż podpowiedzi produktów. Anthropic przeanalizował 998 481 wywołań narzędzi z własnego publicznego API oraz 500 000 interaktywnych sesji Claude Code.

• 80% wywołań narzędzi pochodziło od agentów z co najmniej jednym zabezpieczeniem - ograniczonymi uprawnieniami albo wymaganiem zatwierdzenia przez człowieka.
• 73% miało człowieka w pętli w jakiejś formie.
• Tylko 0,8% akcji było nieodwracalnych, czyli takich, których nie da się cofnąć - wysłania e-maila do klienta i podobnych.
• Mediana jednej tury pracy agenta to około 45 sekund, z wahaniami między 40 a 55 sekundami w kolejnych miesiącach.
• 99,9. percentyl czasu tury w ciągu trzech miesięcy niemal się podwoił: z poniżej 25 minut na ponad 45 minut.

Ciekawe są dwie liczby, które wyglądają sprzecznie, a pokazują realną zmianę zachowania. Osoby z niewielkim doświadczeniem (około 10 sesji) przerywały pracę agentowi w 5% tur, a doświadczeni użytkownicy w około 9%. Równocześnie nowi użytkownicy włączali pełne automatyczne zatwierdzanie w około 20% sesji, a przy 750 sesjach już w ponad 40%. Przerwań przybywa razem z automatyzacją, bo strategia zmienia się z „zatwierdzam każdą akcję" na „puszczam i wchodzę, gdy coś pójdzie nie tak".

Anthropic podkreśla przy tym, że w domyślnych ustawieniach Claude Code każda akcja wymaga ręcznej akceptacji. To dobrze wiedzieć, bo dużo artykułów na ten temat sugeruje, że agenci działają z domysłu bez kontroli - nie, domyślnie jest odwrotnie. Przy okazji: w tych samych danych średnia liczba interwencji człowieka na sesję spadła z 5,4 do 3,3, a skuteczność na najtrudniejszych zadaniach wewnętrznych się podwoiła.

Dla porównania - autonomiczny system testów w Uberze. W ciągu sześciu miesięcy odtworzył 798 z 1115 niestabilnych testów, przygotował poprawki dla 380 z nich, a 197 faktycznie trafiło do kodu po akceptacji programistów. To mniej więcej co piąty test doczekał się naprawy, którą ktoś zatwierdził, i to przy systemie, który podejmował decyzje sam.

Sześć hamulców, które ustawia się raz

Najczęstszy błąd polega na pisaniu reguł w instrukcji agenta. „Nie usuwaj plików", „nie wysyłaj maili bez pytania" - to nie jest hamulec, tylko prośba. Atlassian ujmuje to wprost: nie da się uczynić agenta bezpiecznym przez instruowanie go, bo instrukcje można zapomnieć, źle odczytać albo nadpisać. Prawdziwy hamulec siedzi ponad agentem, w jego środowisku. Inaczej: niechciana akcja nie jest możliwa, a tylko odradzana.

Dlatego hamulce ustawia się jako ograniczenia w kodzie i w konfiguracji, nie w tekście promptu. W praktyce wystarczy sześć mechanizmów.

1. Zakres uprawnień, czyli least privilege

Agent dostaje konto z uprawnieniami dokładnie takimi, jakie dostałby nowy pracownik pierwszego dnia, i ani jednym więcej. NVIDIA określa to wprost: ogranicz dostęp do plików, dostępu do sieci, narzędzi, zakresu danych. W praktyce agencja może też dać agentowi własne konto, wtedy jego dostęp nie zależy od jednej osoby i znika razem z odejściem pracownika.

2. Bramka na ryzykowne wywołania

Wysokie ryzyko znaczy zatwierdzenie człowieka, średnie - powiadomienie, niskie - brak interwencji. Atlassian podaje to wprost: niech praca niskiego ryzyka leci sama (aktualizacja zależności), o średnim daj znać człowiekowi (zmiana wspólnej konfiguracji), a o wysokim lub nieodwracalnym wymagaj zgody (dotknięcie produkcji albo usunięcie danych).

3. Limit wydatków i liczby kroków

Agenci potrafią zużywać tokeny i budżet w sposób nieprzewidywalny, więc budżet traktuje się jak każdy inny zasób firmowy. Jako praktyczny próg warto wziąć ten z projektu, który rozważałeś: agent może przyjąć zwrot do 100 dolarów, a każdy powyżej progu idzie do człowieka. Dwa praktyczne progi, które sprawdzają się w automatyzacjach: eskalacja przy wartości powyżej 99. percentyla historycznych transakcji oraz maksymalnie jedno użycie danego narzędzia w jednym przebiegu.

4. Audyt, z którym da się wrócić do początku

Każda akcja agenta ląduje w historii zadania wraz z informacją, kto ją zatwierdził. Atlassian: każda akcja agenta trafia do historii zadania, powiązana z osobą, która ją zatwierdziła. Bez tego po pierwszym wpadce nie odtworzysz, co poszło nie tak.

5. Wymagane zatwierdzenie dla czterech klas działań

NVIDIA wylicza działania, które z definicji są wrażliwe: dokonanie zakupu, wysłanie e-maila oraz działania fizyczne, jak przestawienie robota albo ustawienie termostatu. Zasada ogólna: wszystko, co robi coś w imieniu człowieka i wymaga jego upoważnienia, traktujesz jako wrażliwe. Uzupełnienie w praktyce: płatności, zmiany kont, wdrożenia na produkcję i komunikacja wrażliwa.

6. Wyłącznik awaryjny, którego agent nie wyłączy

Awaryjny stop natychmiast kończy wykonanie, odcina dostęp do narzędzi i zostawia logi do analizy po fakcie. Zasada jest tu bezwzględna: agent nie powinien być w stanie go wyłączyć. Przy okazji, jak to zorganizować w praktyce przy pamięci, narzędziach i człowieku w pętli, opisałem osobno, bo to najczęstsze miejsce, w którym automatyzacje się sypią.

Prompt injection: dlaczego filtry nie wystarczą

Najczęstsza metoda ataku na agenta nie wygląda jak atak. W skrajnym przypadku to zwykły dokument z instrukcją, która wygląda jak zwykły tekst i właśnie dlatego model ją wykonuje. Dlatego NVIDIA zaleca na poziomie 3 śledzenie zanieczyszczenia danych, czyli oznaczanie przepływu wykonania, który otrzymał dane z zewnątrz, a potem blokowanie użycia wrażliwych narzędzi albo wymaganie ponownej autoryzacji ręcznej. Problem polega na tym, że na najwyższym poziomie autonomii to śledzenie staje się praktycznie niewykonalne - z powodu pętli.

Atlassian odpowiada na to uczciwie, zamiast obiecywać złoto: filtrowanie pomaga, ale nic nie łapie wszystkiego. Jira nie próbuje zablokować prompt injection, tylko ogranicza szkodę, gdy coś przejdzie. To właściwe podejście, bo obietnica, że filtr zatrzyma każdy atak, sama w sobie jest bramką, której nie da się utrzymać.

Skala problemu jest mierzalna. ESET przeanalizował ponad 60 000 rozszerzeń typu „skill" (paczki instrukcji i kodu, które agent instaluje i używa). 72% z nich było nowych, a reszta to aktualizacje już istniejących. Wśród zachowań oznaczonych jako ryzykowne: 33% komunikowało się przez internet bez żadnych sprawdzeń i ograniczeń, 23% wykonywało polecenia w systemie użytkownika, 18% modyfikowało pliki na dysku, a 2,4% zmieniało polityki bezpieczeństwa skryptów. Poniżej 1% wysyłało zebrane dane na zewnętrzny adres. Jedno ciekawe zastrzeżenie z tego raportu: ataków typu ransomware przez skills nie zaobserwowano.

Przykłady z tego raportu dobrze pokazują, o co chodzi. Jeden „skill" udawał prognozę pogody i pozwalał odpytywać darmową usługę, a pod spodem zbierał tokeny sesji i klucze API, żeby je wysłać na serwer atakującego. Inny pobierał pieniądze, wyświetlając komunikat „funkcja w trakcie wdrażania", więc jedynym efektem była opłata. Są też takie, które biorą kartę kredytową z limitem wydatków - autor może w dowolnej chwili zmienić zachowanie i przekierować zakupy do siebie.

Wniosek operacyjny z ESET brzmi: traktuj skills jak oprogramowanie, a nie jak prompty. Sprawdzaj uprawnienia i pytaj, czy są konieczne dla deklarowanej funkcji - jeśli wydają się nadmierne, to prawdopodobnie są. W praktyce konkretne zabezpieczenia prompt injection sprowadzają się właśnie do tego i do ograniczenia uprawnień agenta.

Od czego zacząć: jedno zadanie, odwracalne, z bramką

Najbezpieczniejszy pierwszy projekt to zadanie powtarzalne, odwracalne i tanie w naprawie, jeśli agent się pomyli. Atlassian podaje dokładnie taki przykład: niestabilny test albo aktualizacja zależności. Reszta kroków też ma sensowną kolejność.

Po pierwsze, uruchamiasz agenta z dostępem na poziomie nowego kolegi, nie więcej, niż samo zadanie wymaga. Po drugie, wstawiasz zgodę człowieka jako przejście w przepływie, żeby nikt nie odebrał wyniku bez akceptacji. Po trzecie, sprawdzasz rezultat normalnym przeglądem, tak jak robisz to przy każdej zmianie. Po czwarte, upewniasz się, że akcja jest zapisana w historii. Wdrożenie w takim układzie nie wymaga osobnej wiedzy technicznej - wystarczy świadoma zgoda przed tym, co agent zrobi.

Dwie liczby z Atlassian warto zapamiętać, bo dotyczą jakości, a nie autonomii: kontekst podany agentowi podniósł jakość odpowiedzi o 44% i jednocześnie zmniejszył zużycie tokenów o 48%. Zanim dorzucisz agentowi kolejne uprawnienia, upewnij się, że ma właściwe dane we właściwym miejscu. Jeśli architektura ma osobne gałęzie dla klasyfikacji, ekstrakcji i ścieżki z człowiekiem w pętli, opisałem to w osobnym tekście o pięciu wzorcach architektury w n8n.

Kiedy NIE warto podnosić poziomu autonomii

To jest sekcja, którą pomijają materiały sprzedażowe, a warto ją znać przed podpisaniem czegokolwiek.

Wyższy poziom to nie zawsze lepszy. Autor klasyfikacji Swarmia pisze wprost, że to nie jest ranking i że wyżej nie zawsze znaczy lepiej. Jego powód jest praktyczny: gdy Twój proces przeglądu zmian jest już wąskim gardłem, agencja na poziomie 3 najpierw to wąskie gardło powiększy. Większe paczki zmian i dłuższy czas przeglądu to raport DORA 2025, który pokazał związek między wysokim użyciem AI a większymi pull requestami i dłuższym przeglądem kodu. AI wzmacnia to, co już działa - także to, co działa źle.

Drugi powód to rachunek. Najwyższy poziom w praktyce oznacza eksperyment, nie strategię: opis jednego z takich projektów mówi o bilionach tokenów i milionach dolarów, ponad milion linii kodu w tysiącu plików, 30 tysiącach commitów i nawet 2000 agentów równolegle przez tydzień. To liczby z eksperymentu jednej firmy, nie z podręcznika. Do zastosowania w Twojej firmie mają się nie zachować.

Są też sytuacje, w których autonomię świadomie zostawia się niską, a automatyzację robi się zwykłym przepływem. Jeśli zadanie da się rozpisać deterministycznie, przepływ z warunkami będzie tańszy, przewidywalniejszy i łatwiejszy w naprawie niż agent. Agenta warto tam, gdzie kolejność kroków zależy od danych, których nie da się wcześniej przewidzieć.

Na koniec jedna rzecz, którą warto odhaczyć osobno: decyzja, ile swobody dać agentowi, nie jest czysto techniczna. Zanim włączysz autonomię, warto mieć odpowiedź na pytanie, jakie dane w ogóle mogą do niego trafić i co się stanie, jeśli wyjdą. Pełna lista kontroli przed włączeniem AI w zespole jest w artykule o bezpieczeństwie firmy z AI, a sama strona RODO przy wdrożeniu agentów to temat, który ma osobną stronę - linki są na dole.

Jeśli chcesz przejść przez to ze mną krok po kroku, napisz - odpowiadam zwykle tego samego dnia. Najpierw robimy przegląd, co u Ciebie faktycznie jest powtarzalne, potem zakres i wycenę na piśmie. Zwykle wychodzi, że najwięcej odzyskasz czasu tam, gdzie agent działa na poziomie 1, a nie tam, gdzie wydaje się najbardziej imponująco.