Kto odpowiada za błąd agenta — odpowiedzialność projektuje się przed incydentem

przez Łukasz | lip 8, 2026

Odpowiedzialność za działania agenta AI zawsze spoczywa na ludziach i organizacji — agent nie ma osobowości prawnej ani zdolności ponoszenia konsekwencji. Governance agentów nie polega więc na rozstrzyganiu, czy ktoś odpowiada, tylko na rozstrzygnięciu z góry, kto konkretnie — zanim będzie za co.

To czwarta gałąź huba i domknięcie łańcucha, który budowaliśmy od początku: tożsamość mówi, kto działał; flota i cykl życia mówią, kto pozwolił mu istnieć; ta strona mówi, kto wstaje z krzesła, gdy agent zrobi coś, czego nikt nie chciał.

Dzień, w którym to przestaje być teorią

Agent od obsługi klienta wysłał do trzystu odbiorców maila z poufnym cennikiem przeznaczonym dla jednego. Agent porządkujący dysk uznał folder projektu za duplikat i go usunął. Agent zakupowy złożył zamówienie na podstawie cennika, który źle odczytał. Żaden z tych scenariuszy nie wymaga złej woli, włamania ani wadliwego modelu — wystarczy autonomia zderzona z niejednoznacznym światem. To jest normalny koszt posiadania agentów, tak jak błędy ludzkie są normalnym kosztem posiadania pracowników.

Różnica ujawnia się minutę po incydencie. Gdy błąd popełnia człowiek, organizacja odruchowo wie, co robić: jest przełożony, jest procedura, jest rozmowa. Gdy błąd popełnia agent, w nieprzygotowanej organizacji zapada charakterystyczna cisza — wszyscy patrzą po sobie. Właściciel biznesowy pokazuje na IT („wy to wdrażaliście”), IT na dostawcę („to ich model zdecydował”), dostawca na konfigurację („uprawnienia nadaliście sami”). Każdy ma trochę racji i właśnie dlatego nie odpowiada nikt.

Ta cisza ma nazwę: rozproszenie odpowiedzialności — i jest domyślnym stanem każdej organizacji, która nie zaprojektowała odpowiedzialności zawczasu. Agent bez przypisanego właściciela nie jest „niczyj”. Jest wszystkich — czyli, w praktyce incydentu, niczyj.

Cztery pytania incydentu — i co musi istnieć wcześniej, żeby miały odpowiedzi

Każdy incydent z agentem sprowadza się do czterech pytań. Sęk w tym, że odpowiedź na każde z nich powstaje przedincydentem albo nie powstaje wcale:

Co dokładnie agent zrobił? Odpowiada: log podpisany tożsamością agenta. Jeśli agent działał na koncie pracownika — a to, jak pisaliśmy, najczęstszy stan faktyczny — to pytanie nie ma odpowiedzi: w logach nie sposób odróżnić agenta od człowieka, na którego koncie żył.

Dlaczego to zrobił? Odpowiada: zapis trajektorii — nie tylko co agent wykonał, ale jaką drogą do tego doszedł: co przeczytał, co wywnioskował, które narzędzie wywołał w którym kroku. W anatomii agenta opisaliśmy ewaluację trajektorii jako narzędzie twórcy; w Agentic Enterprise ten sam zapis staje się materiałem dowodowym organizacji. Bez trajektorii sekcja zwłok incydentu kończy się na „model tak zdecydował” — czyli na niczym.

Kto pozwolił, żeby mógł to zrobić? Odpowiada: udokumentowana decyzja o uprawnieniach. Agent usunął folder, bo miał prawo usuwać foldery — i pytanie brzmi, kto to prawo nadał i czy świadomie. Jeśli uprawnienia wzięły się z dziedziczenia po właścicielu „bo tak szybciej”, odpowiedź jest kompromitująca, ale przynajmniej pouczająca.

Kto teraz działa? Odpowiada: właściciel z rejestru — człowiek, który zatrzymuje agenta, ocenia szkody, komunikuje, naprawia. Nie dlatego, że jest winny, lecz dlatego, że jest odpowiedzialny — a to są dwie różne rzeczy, i pomylenie ich to najkrótsza droga do zabicia całego systemu.

Odpowiedzialność to nie wina — i dlaczego to rozróżnienie decyduje o wszystkim

Jeśli właścicielstwo agenta oznacza w firmie „ty wiszisz, jak agent coś zepsuje”, stanie się rzecz przewidywalna: nikt nie będzie chciał być właścicielem niczego. Agenci trafią do rubryki „zespołowe”, rejestr wypełni się fikcją, a prawdziwe agenty zejdą do podziemia — shadow agents hodowane strachem, nie wygodą.

Dojrzały model rozdziela dwie rzeczy. Wina dotyczy zaniedbania: właściciel odpowiada dyscyplinarnie tylko wtedy, gdy zignorował procedurę — nadał uprawnienia bez zatwierdzenia, zlekceważył alerty, pominął przegląd. Odpowiedzialnośćdotyczy roli: właściciel jest osobą, która działa w incydencie i odpowiada na pytania po nim — nawet gdy zrobił wszystko dobrze, a agent i tak zbłądził. Błąd agenta przy zachowanych procedurach to koszt technologii, obciążający organizację, nie człowieka — dokładnie tak, jak błąd rzetelnego pracownika obciąża firmę, nie jego pensję.

To rozróżnienie warto zapisać wprost w polityce agentowej, bo intuicja korporacyjna domyślnie skleja obie rzeczy w jedno — i tym sklejeniem zatruwa cały rejestr.

Autonomia jako pokrętło, nie przełącznik

Drugi filar governance to zasada proporcjonalności: poziom autonomii agenta ma odpowiadać wadze nieodwracalności jego działań. Agent, który czyta i podsumowuje, może być w pełni autonomiczny — jego najgorszy błąd to złe podsumowanie. Agent, który wysyła, usuwa, płaci albo podpisuje, potrzebuje progów: kwotowych (do X samodzielnie, powyżej — człowiek zatwierdza), zakresowych (wewnątrz firmy sam, na zewnątrz z akceptacją), albo pełnego human-in-the-loop dla działań nieodwracalnych.

Te progi to nie hamulec dla technologii, lecz mechanizm odpowiedzialności w czystej postaci: każdy próg to z góry podjęta decyzja, które błędy organizacja godzi się ponosić automatycznie, a które chce mieć podpisane ludzką ręką. Incydent z agentem, który przekroczył próg — to awaria systemu. Incydent z agentem, któremu progów nie ustawiono — to awaria zarządu.

I trzeci filar, po cichu najważniejszy: wyłącznik. Dla każdego agenta musi istnieć znana właścicielowi procedura zatrzymania — natychmiastowego, bez szukania człowieka, który „wie, jak to się wyłącza”, bo akurat jest na urlopie. Pięć minut z testu gotowości to nie była metafora.

Karta agenta — cała governance na jednej stronie

W praktyce wszystko powyższe mieści się w jednym dokumencie na agenta — nazwijmy go kartą agenta. Osiem rubryk: kto jest właścicielem (imiennie); do czego agent służy (jednym zdaniem); co mu wolno (uprawnienia z datą i podpisem zatwierdzającego); czego mu nie wolno nigdy (czerwone linie); progi autonomii (co sam, co z akceptacją); jak go zatrzymać (procedura kill-switch); kogo powiadomić przy incydencie (ścieżka eskalacji); kiedy przegląd (data następnej rewizji).

Karta agenta jest tym, czym zakres obowiązków dla pracownika — i podobnie jak on, jest nudna dokładnie do dnia, w którym przestaje być nudna. Organizacja, która ma karty dla wszystkich agentów z rejestru, przechodzi incydent w godziny. Organizacja bez kart spędza pierwsze dni incydentu na ustalaniu rzeczy, które powinny były być zapisane rok wcześniej.

Osobna, krótka uwaga o warstwie prawnej: regulacje — od ochrony danych po nadchodzące przepisy o AI — konsekwentnie traktują działania agenta jako działania organizacji, która go używa. „To agent zdecydował” nie jest linią obrony przed niczym; jest co najwyżej wyjaśnieniem mechanizmu. Szczegóły różnią się między branżami i jurysdykcjami — to temat dla warstwy Industry słownika i dla prawników, nie dla tej strony — ale kierunek jest jednoznaczny i warto go znać, zanim ktoś w firmie wypowie to zdanie na poważnie.

Karta agenta AI

Karta agenta AI

Od czego zacząć

Od jednego pytania zadanego dziś, na spokojnie, bez incydentu w tle: gdyby jutro rano nasz najbardziej autonomiczny agent zrobił najgorszą rzecz, do której ma uprawnienia — kto by o tym wiedział, kto by go zatrzymał i kto odpowiadałby na pytania zarządu?

Jeśli odpowiedź na którykolwiek człon brzmi „nie wiadomo” — właśnie znalazłeś swój pierwszy brak w governance, i to w wariancie tanim, bo papierowym. Droga naprawa zaczyna się dopiero wtedy, gdy to samo pytanie zadaje się po fakcie.

Została ostatnia droga, którą agenci wchodzą do organizacji z pominięciem wszystkiego, co opisaliśmy w tym hubie — tożsamości, rejestru, kart i progów. Wchodzą bocznymi drzwiami, zakładani przez pracowników w dobrej wierze i poza jakąkolwiek kontrolą. Shadow agents — następna gałąź huba.