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. „AI się pomyliło” nie jest linią obrony. Odpowiedzialność wymaga architektury z jasnym zakresem, rejestrem działań, przekazaniem spraw i minimalnymi uprawnieniami.
Wobec klienta i prawa odpowiada firma, która agenta stosuje. Odpowiedzialność buduje się w architekturze: zakres, rejestr działań, przekazanie spraw i minimalne uprawnienia.
Syntalith
Za decyzję agenta AI wobec Twojego klienta i wobec prawa odpowiada firma, która agenta stosuje, czyli Ty. Model i dostawca modelu nie przejmują tej roli. „AI się pomyliło” opisuje zdarzenie. Nie stanowi linii obrony. Sensowne pytanie brzmi: jak zbudować agenta tak, żeby nie mógł zrobić rzeczy, za którą nie chcesz odpowiadać.
Odpowiedzialność za decyzję agenta AI
Odpowiada firma, która agenta stosuje. To najkrótsza odpowiedź. Kiedy agent wyśle klientowi błędną informację, zmieni rekord w systemie albo podejmie decyzję w Twoim imieniu, Twój klient rozlicza Ciebie. Dostawca modelu i wykonawca wdrożenia mają odrębne zobowiązania umowne.
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 ustalone warunki 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.
Dalsze decyzje wynikają z tego faktu. Ryzyko zostaje przy Tobie, więc kupujesz rozwiązanie z zakresem i zabezpieczeniami. Sama „inteligencja” nie wystarczy.
„AI się pomyliło” nie jest linią obrony
To zdanie nie chroni firmy, bo prawo i klient oceniają działanie organizacji. Model nie ma podmiotowości: nie zawiera umów ani 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ą. Gdy Twój pracownik pomyli się przy fakturze, odpowiedzialność nie przechodzi na kalkulator. 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 kontroli szybko podnosi koszt.
Stąd praktyczny wniosek. „AI się pomyliło” niczego nie wyjaśnia, więc zapytaj, co model może zrobić w Twoim systemie. Zaufanie wynika z architektury, którą wokół niego zbudujesz.
Cztery elementy architektury odpowiedzialności
Odpowiedzialność wobec klienta jest Twoja, więc buduje się ją inżyniersko. Cztery elementy porządkują projekt.
Zakres działania agenta. Zanim ustalisz, co agent robi, ustalasz czynności wymagające człowieka. Wysyłka do klienta, zmiana danych w produkcji i decyzja finansowa są bramkami. Nie są akcjami domyślnymi. Zakres zapisany w konfiguracji działa także 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.
Co oznacza historia o skasowanej bazie danych
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. Przyczyną był brak kontroli uprawnień.
Rozwiązaniem 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.
Mapa odpowiedzialności
Tabela porządkuje typowe sytuacje. Nie zastępuje umowy ani opinii prawnika. Pokazuje, gdzie realnie leży odpowiedzialność przed rozmową o zapisach.
| 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 warunki 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ą
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 zapisany wprost: co agent robi oraz jakie czynności wymagają człowieka, na poziomie konfiguracji i umowy.
- Rejestr działań jako deliverable: kompletny, odtwarzalny zapis działań jest częścią odbioru i pomaga rozliczać skutki.
- 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 zakres i rejestr działań służą przede wszystkim Twojej organizacji. Jeśli chcesz uporządkować ten obraz na jednym procesie, zacznij od audytu procesów AI.
AI Act i podział obowiązków
Rozporządzenie o AI (AI Act) nakłada obowiązki na dostawców systemów AI i na podmioty, które je stosują. Stosując agenta, jesteś stroną z własnymi obowiązkami oraz 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ą budujesz z powodów operacyjnych (zakres, rejestr działań, nadzór człowieka), odpowiada także oczekiwaniom regulacji.
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 bez możliwości cofnięcia, potrzebuje udziału człowieka jako bramki. Pełna automatyzacja nie pasuje do takiego skutku.
- 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, na skanie wskażemy właściwy pierwszy krok przed wydaniem pieniędzy.
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 usunąć lub skasować firmową bazę danych?
Może tylko wtedy, gdy ma do tego uprawnienia. Historie o skasowanej bazie zwykle znaczą, że komuś dano szeroki dostęp bez kontroli. Agent działający na osobnym koncie technicznym nie ma dostępu do produkcji. Akcje nieodwracalne wykonuje wyłącznie za zgodą człowieka, więc baza pozostaje poza jego możliwościami. To kwestia projektu uprawnień. Samo zaufanie do modelu nie wystarczy.
Co powinno być w umowie wdrożeniowej dotyczącej odpowiedzialności?
Zapisany zakres i warunki (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.
Odpowiedzialność przed uruchomieniem
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, jaki warunek 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
Powiązane artykuły
Bezpłatny skan procesów
Zacznij od bezpłatnego skanu procesów.
- 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.
0 zł
30 minut · pisemne podsumowanie w 2 dni robocze
Terminy zobaczysz w swojej strefie czasowej.
Wolisz napisać? Opisz proces