Bounded Autonomy: Jak kontrolować agentów AI

Pełna autonomia AI świetnie wygląda na slajdzie. Na produkcji ktoś potem gasi pożary. Sukces z AI to balans między swobodą a kontrolą. Nazywam to Bounded Autonomy.

Co to jest Bounded Autonomy?

Bounded Autonomy to framework oparty na zasadach NIST AI Risk Management Framework. Agent AI dostaje jasno wytyczone granice. W ich obrębie ma pełną swobodę. Poza nimi zatrzymuje się i oddaje sprawę człowiekowi (human-in-the-loop).

To jak dać nastoletniemu synowi kluczyki do samochodu. Mówisz mu: "Możesz jeździć po mieście, ale nie na autostradę. W domu masz być przed 22."

4 filary Bounded Autonomy

Audit trail ma sens tylko wtedy, gdy każdy cichy retry i fallback zostawia policzalny ślad. Inaczej logi pokazują same sukcesy. Więcej o cichych awariach pisałem osobno.

Operational Limits w praktyce

Przykład dla agenta obsługi klienta:

Escalation Matrix

Nie wszystkie eskalacje są równe. Stwórz matrycę:

• Poziom 1 (Soft Escalation): Agent działa dalej, ale oznacza sprawę do sprawdzenia później
• Poziom 2 (Human Review): Agent czeka na akceptację, zanim coś wykona
• Poziom 3 (Full Handoff): Człowiek przejmuje całkowicie
• Poziom 4 (Emergency Stop): Agent zatrzymany, zgłaszamy incydent

Poziom 3 kończy się przekazaniem sprawy, ale nie mówi, co człowiek ma z nią dalej zrobić. Ten podział pracy opisują cztery wzorce hybrydowe, od pełnego handoffu po AI, które tylko podpowiada.

"Bounded Autonomy buduje zaufanie, a zaufanie pozwala skalować. Agentowi z jasnymi granicami możesz dać więcej swobody. Wiesz, że nie przekroczy linii."

Governance Agents

Najbardziej zaawansowane firmy idą o krok dalej. Mają agentów AI, którzy pilnują innych agentów. Governance Agent sprawdza:

• • Czy decyzje są zgodne z polityką firmy?
• • Czy nie ma anomalii w zachowaniu?
• • Czy performance nie degraduje się?
• • Czy eskalacje są obsługiwane na czas?

Agenci pilnujący agentów to warstwa techniczna. Organizacyjną, czyli inventory systemów, klasyfikację ryzyka i jasne ownership, opisałem przy AI governance.

Bounded, constrained, controlled czy governed autonomy: czym się różnią

Branża używa tych nazw zamiennie. Nikt ich nie znormalizował. Poniżej podział, którego używam u klientów, oparty na mechanizmach opisanych wyżej.

• Bounded autonomy: granice siedzą w samym agencie. Agent wie, czego mu nie wolno, i w tych ramach decyduje sam. Projektujesz to przy jednym agencie.
• Constrained autonomy: ograniczenie działa na przestrzeń akcji i sprawdza się przy każdej decyzji, więc bliżej mu do reguły w kodzie niż do zapisu w polityce. Sięgasz po nie wtedy, gdy agent nie może wykonać danej akcji nawet przez pomyłkę.
• Governed autonomy: to Governance Agents z poprzedniej sekcji, tyle że w skali organizacji. Polityki, właściciel, audyt, raportowanie. Obejmuje całą flotę.
• Controlled autonomy: tu uczciwa odpowiedź brzmi „nic konkretnego". Fraza krąży po materiałach dostawców i nikt nie zdefiniował jej inaczej niż dwóch powyższych. Kiedy ją usłyszysz, dopytaj, o który mechanizm chodzi.

Praktyczna różnica jest prosta. Bounded projektujesz przy jednym agencie, governed wdrażasz raz dla wszystkich. Firmy, które zaczynają od governance, mają gotowe polityki i zero agentów na produkcji.

AI autonomy controls, czyli kontrola autonomii AI, to zbiorcza nazwa na cztery filary z początku wpisu. Lista dozwolonych akcji, triggery eskalacji, audit log i kill switch. Kiedy ktoś pyta o kontrolę nad agentem, pyta właśnie o nie.

Zostaje bounded automation. Branża tego terminu nie ustaliła, a ludzie i tak go wpisują, więc powiedzmy wprost: automatyzacja wykonuje ustalony przepływ i niczego nie wybiera. Agent wybiera akcję w granicach, które mu wyznaczyłeś. Jeśli twój proces niczego nie wybiera, ten framework nic ci nie da. Potrzebujesz dobrego workflow.

Implementacja: Krok po kroku

1. 1. Spisz wszystkie akcje które agent może wykonać
2. 2. Dla każdej akcji określ: auto, review, lub forbidden
3. 3. Zdefiniuj triggery eskalacji (wartość, ryzyko, sentiment)
4. 4. Zbuduj audit log dla każdej decyzji
5. 5. Przetestuj scenariusze edge-case
6. 6. Ustaw alerting dla anomalii