Kto odpowiada za decyzje agenta AI? Odpowiedzialność za błąd w 2026
Kto odpowiada za decyzje agenta AI? Wobec klienta i prawa odpowiada firma, która agenta stosuje, nie model i nie dostawca modelu. „AI się pomyliło” nie jest linią obrony. Skoro odpowiedzialność jest Twoja, potrzebujesz architektury odpowiedzialności: granic, śladu, eskalacji i minimalnych uprawnień.
Za decyzję agenta AI wobec Twojego klienta i wobec prawa odpowiada firma, która agenta stosuje, czyli Ty. Nie model i nie dostawca modelu. „AI się pomyliło” nie jest linią obrony, tylko opisem zdarzenia. Skoro odpowiedzialność jest Twoja, jedyne sensowne pytanie brzmi: jak zbudować agenta tak, żeby nie mógł zrobić rzeczy, za którą nie chcesz odpowiadać.
Kto właściwie odpowiada za decyzję agenta AI
Odpowiada firma, która agenta stosuje. To najkrótsza uczciwa odpowiedź. Kiedy agent wyśle klientowi błędną informację, zmieni rekord w systemie albo podejmie decyzję w Twoim imieniu, Twój klient rozlicza Ciebie, nie dostawcę modelu i nie wykonawcę wdrożenia.
Warto rozdzielić trzy poziomy, bo mieszają się w rozmowach:
- Dostawca modelu (twórca modelu językowego) odpowiada za model na warunkach swojej umowy licencyjnej, zwykle z szerokimi wyłączeniami odpowiedzialności za sposób użycia.
- Wykonawca wdrożenia odpowiada za jakość tego, co zbudował: czy system działa zgodnie z ustaleniami, czy granice zostały zaimplementowane, czy ślad jest kompletny.
- Firma stosująca odpowiada za skutek wobec swojego klienta i za zgodność z prawem. Tej odpowiedzialności nie da się scedować żadnym zapisem, bo to Twoja marka wysłała maila i Twój proces zmienił dane.
Cała reszta tekstu wynika z tego jednego faktu. Skoro ryzyko zostaje przy Tobie, nie kupujesz „inteligencji”, tylko zestaw granic wokół niej.
„AI się pomyliło” nie jest linią obrony
To zdanie nie chroni firmy, bo prawo i klient nie pytają, co zrobił model, tylko czego nie zrobiła firma. Model nie ma podmiotowości: nie zawiera umów, nie ponosi kosztów, nie staje przed klientem. Odpowiada ten, kto zdecydował go użyć w danym procesie i na danych warunkach.
To działa dokładnie tak, jak z każdym innym narzędziem czy podwykonawcą. Jeśli Twój pracownik pomyli się przy fakturze, nie mówisz klientowi „to wina kalkulatora”. Odpowiadasz za wynik i za to, jakie zabezpieczenia miałeś na miejscu. Z agentem AI jest tak samo, z jedną różnicą: agent działa szybciej i na większą skalę, więc brak granic kosztuje szybciej.
Stąd wniosek, który zmienia całą rozmowę. Skoro „AI się pomyliło” nic nie broni, przestań pytać, czy modelowi można ufać, a zacznij pytać, co model w ogóle może zrobić w Twoim systemie. Zaufanie nie jest cechą modelu. Jest właściwością architektury, którą wokół niego zbudujesz.
Architektura odpowiedzialności: cztery elementy
Odpowiedzialność wobec klienta jest Twoja, więc buduje się ją inżyniersko, nie deklaracją. Cztery elementy robią całą robotę.
Granice: czego agent nie może zrobić sam. Zanim ustalisz, co agent robi, ustalasz, czego nie robi bez człowieka. Wysyłka do klienta, zmiana danych w produkcji, decyzja finansowa: to są bramki, nie akcje domyślne. Granica zapisana w konfiguracji jest warta więcej niż granica w instrukcji dla modelu, bo działa nawet wtedy, gdy model się pomyli.
Ślad: co się stało i dlaczego, odtwarzalnie. Jeśli po fakcie nie da się odtworzyć, co agent zrobił, na jakich danych i dlaczego, to nie jest agent, tylko ruletka z ładnym interfejsem. Ślad to nie luksus, tylko warunek, żeby w ogóle móc odpowiedzieć za skutek: bez niego nie ustalisz, czy błąd był Twój, dostawcy czy danych wejściowych.
Eskalacje: kiedy agent staje i woła człowieka. Dobry agent wie, czego nie wie. Przy niskiej pewności, nietypowym przypadku albo akcji o dużym skutku zatrzymuje się i przekazuje sprawę człowiekowi, zamiast zgadywać. To nie jest słabość systemu, tylko jego najdroższa i najważniejsza część.
Minimalne uprawnienia. Agent dostaje dokładnie tyle dostępu, ile potrzebuje do zadania, i ani jednego uprawnienia więcej: osobne konto techniczne, brak dostępu do środowiska produkcyjnego, akcje nieodwracalne tylko za zgodą. To najskuteczniejsza tarcza, bo działa niezależnie od tego, jak dobry albo zły jest model danego dnia. Więcej o technikach ograniczania błędów piszemy w tekście o halucynacjach AI i sposobach ich ograniczania, a o atakach na uprawnienia w tekście o prompt injection w pracy agentów.
„Agent AI skasował bazę danych”: co ta historia naprawdę znaczy
Ta sama historia krąży pod różnymi hasłami: agent AI skasował bazę danych, agent AI usunął firmową bazę danych. Takie historie prawie nigdy nie znaczą, że model jest zły. Znaczą, że komuś dano szerokie uprawnienia bez granic. Agent, który skasował bazę, miał do niej pełny dostęp na koncie z prawem usuwania i nikt nie postawił bramki na akcji nieodwracalnej. Model był tu ostatnim ogniwem, nie przyczyną.
Odpowiedzią nie jest zapewnienie „nasz model tego nie zrobi”, bo to obietnica bez pokrycia. Odpowiedzią jest projekt, w którym takie skasowanie jest technicznie niemożliwe:
- agent działa na osobnym koncie technicznym z uprawnieniami tylko do odczytu tam, gdzie to wystarczy,
- nie ma dostępu do środowiska produkcyjnego, tylko do warstwy, którą wolno mu zmieniać,
- akcje nieodwracalne (usunięcie, masowa zmiana, przelew) wymagają wyraźnej zgody człowieka albo są zablokowane w ogóle.
Agent, który po prostu nie MOŻE skasować bazy, nigdy jej nie skasuje, niezależnie od tego, co „wymyśli”. To jest różnica między uspokajaniem a inżynierią. Kupujesz to drugie.
Kto odpowiada za co: krótka mapa
Poniższa tabela porządkuje typowe sytuacje. Nie zastępuje umowy ani opinii prawnika, tylko pokazuje, gdzie realnie leży odpowiedzialność, zanim usiądziesz do zapisów.
| Decyzja lub incydent | Kto odpowiada wobec Twojego klienta | Co to znaczy w praktyce |
|---|---|---|
| Agent wysłał klientowi błędną odpowiedź | Firma stosująca (Ty) | Potrzebna bramka wysyłki i ślad; „to model” nie broni |
| Agent zmienił zły rekord w CRM/ERP | Firma stosująca (Ty) | Uprawnienia minimalne i walidacja wyjątków ograniczają skutek |
| Agent skasował dane, bo miał do tego dostęp | Firma stosująca, ale to błąd projektu uprawnień | Brak dostępu do produkcji i zgoda na akcje nieodwracalne |
| System nie działał zgodnie z ustaleniami | Wykonawca wdrożenia (jakość dzieła) | Zakres i granice muszą być zapisane, żeby dało się to rozliczyć |
| Model zwrócił wynik zgodny z licencją, ale słaby | Dostawca modelu na warunkach umowy | Architektura wokół modelu (ślad, eskalacja) łapie skutek |
Podział odpowiedzialności z wykonawcą: co zapisać w umowie
Skoro odpowiedzialność wobec klienta zostaje przy Tobie, umowa wdrożeniowa ma jasno rozdzielić to, co można rozdzielić. Cztery rzeczy powinny się w niej znaleźć:
- Zakres i granice zapisane wprost: co agent robi, a czego nie robi bez człowieka, na poziomie konfiguracji, nie obietnicy.
- Ślad jako deliverable: kompletny, odtwarzalny zapis działań jest częścią odbioru, a nie miłym dodatkiem.
- Utrzymanie i reakcja na incydent: kto reaguje, w jakim czasie i co się dzieje, gdy coś pójdzie nie tak po starcie. Rozkładamy to na czynniki w tekście o utrzymaniu agenta AI po wdrożeniu.
- Dostęp do systemów: na jakich kontach i uprawnieniach agent pracuje, kto je nadaje i odbiera.
Czego żaden wykonawca nie przejmie uczciwie: odpowiedzialności wobec Twojego klienta. Wykonawca odpowiada za jakość dzieła. Za to, że Twój proces działa i Twoja marka nie zawiodła klienta, odpowiadasz Ty, dlatego granice i ślad są w Twoim interesie, a nie wykonawcy. Jeśli chcesz najpierw uporządkować cały ten obraz na jednym procesie, zaczyna się to od audytu procesów AI.
AI Act: co nakłada i na kogo, bez paniki
Rozporządzenie o AI (AI Act) nakłada obowiązki na dwie strony naraz: na dostawców systemów AI i na podmioty, które je stosują. To ważne, bo utrwala dokładnie ten podział, o którym mówi cały ten tekst: stosując agenta, jesteś stroną z własnymi obowiązkami, nie tylko odbiorcą cudzego narzędzia.
Kilka faktów, które warto znać, i jedno zdanie ostrożności:
- Obowiązek kompetencji AI (art. 4), czyli zapewnienia, że osoby obsługujące systemy AI rozumieją ich działanie i ryzyka, obowiązuje od 2 lutego 2025.
- Systemy zakwalifikowane jako wysokiego ryzyka mają dodatkowe wymogi: nadzoru człowieka, dokumentacji i zarządzania ryzykiem, z okresami przejściowymi rozłożonymi w czasie.
- Większość pozostałych obowiązków ogólnych wchodzi etapami do 2026 i później.
To nie jest porada prawna. Traktuj te punkty jako wsad do własnej dokumentacji i skonsultuj konkretny przypadek z prawnikiem. Cel jest praktyczny: architektura odpowiedzialności, którą i tak budujesz z powodów operacyjnych (granice, ślad, nadzór człowieka), jest jednocześnie tym, czego takie regulacje oczekują. Robisz jedną pracę, nie dwie.
Kiedy NIE automatyzować
Uczciwie: część procesów nie powinna trafić do agenta, choćby dało się to technicznie zrobić.
- Skutki nieodwracalne bez możliwości przeglądu. Jeśli decyzja kasuje coś na stałe, przesyła pieniądze albo zmienia dane, których nie da się cofnąć, i nie zmieści się w niej człowiek jako bramka, nie automatyzuj jej w pełni.
- Proces bez nazwanych reguł. Jeśli zasady żyją w czyjejś głowie i zmieniają się co tydzień, agent tylko utrwali chaos. Najpierw spisz proces, potem go automatyzuj.
- Szukasz systemu, „za który nikt nie odpowiada”. Taki system nie istnieje. Ktoś zawsze odpowiada wobec klienta, a jeśli tym kimś nie chcesz być Ty, to znaczy, że nie chcesz jeszcze tego procesu automatyzować.
Jeśli któryś punkt pasuje do Twojej sytuacji, powiemy to wprost na skanie, zanim wydasz złotówkę.
FAQ
Kto odpowiada za decyzje agenta AI?
Wobec Twojego klienta i wobec prawa odpowiada firma, która agenta stosuje, czyli Ty. Dostawca modelu odpowiada za model na warunkach swojej umowy, a wykonawca wdrożenia za jakość tego, co zbudował, ale odpowiedzialności za skutek wobec Twojego klienta żaden z nich za Ciebie nie przejmie. Dlatego „AI się pomyliło” nie jest linią obrony, tylko opisem zdarzenia.
Czy agent AI może sam skasować bazę danych?
Może tylko wtedy, gdy ma do tego uprawnienia. Historie o skasowanej bazie zwykle znaczą, że komuś dano szeroki dostęp bez granic. Agent, który działa na osobnym koncie technicznym, nie ma dostępu do produkcji, a akcje nieodwracalne wykonuje wyłącznie za zgodą człowieka, po prostu nie MOŻE skasować bazy. To kwestia projektu uprawnień, nie zaufania do modelu.
Co powinno być w umowie wdrożeniowej dotyczącej odpowiedzialności?
Zapisany zakres i granice (czego agent nie może zrobić sam), ślad działań jako deliverable, zasady utrzymania i reakcji na incydent oraz warunki dostępu do systemów. Wykonawca odpowiada za jakość tego, co zbudował. Odpowiedzialności wobec Twojego klienta nie da się scedować na wykonawcę żadnym zapisem.
Co AI Act mówi o odpowiedzialności za agenta AI?
Rozporządzenie nakłada obowiązki zarówno na dostawców systemów, jak i na podmioty je stosujące, a systemy wysokiego ryzyka mają wymogi nadzoru człowieka i dokumentacji. Obowiązek kompetencji AI (art. 4) obowiązuje od 2 lutego 2025. To nie jest porada prawna: potraktuj te materiały jako wsad do własnej dokumentacji i skonsultuj je z prawnikiem.
Jak zacząć
Najtańszy sensowny pierwszy krok to nazwać jeden proces i sprawdzić, gdzie realnie leży w nim ryzyko.
- Wypisz jeden proces, który chcesz oddać agentowi, i zaznacz w nim akcje nieodwracalne.
- Dla każdej z nich odpowiedz: kto odpowiada wobec klienta, jaka granica ją zatrzymuje, jaki ślad zostaje.
- Sprawdź, czy agent działa na osobnym koncie i czy nie ma dostępu do produkcji.
- Umów rozmowę, na której przejdziemy to razem i powiemy uczciwie, co warto, a czego nie.
Umów bezpłatny skan procesów | Audyt procesów AI | Utrzymanie