Odpowiedzialność za decyzje AI: kto odpowiada

Kiedy automatyczna decyzja kogoś skrzywdzi — odmówi kredytu, odrzuci podanie o pracę, zablokuje konto, naliczy wyższą składkę — bardzo szybko pojawia się zdanie, które brzmi jak wyjaśnienie, a w istocie nim nie jest: „tak zdecydował algorytm“. To zdanie ma jedną funkcję. Rozprasza odpowiedzialność tak skutecznie, że na końcu nie zostaje nikt, kogo dałoby się o cokolwiek zapytać. System jest „obiektywny“, dostawca tylko dostarczył narzędzie, pracownik tylko kliknął, a osoba, której decyzja dotyczy, zostaje sama wobec wyniku, którego nikt nie potrafi ani wyjaśnić, ani cofnąć.

Ten artykuł rozkłada ten mechanizm na części. Pokazuje, dlaczego prawo — z artykułem 22 RODO na czele — nie pozwala, by odpowiedzialność wyparowała, jak biegnie łańcuch od danych przez model aż do firmy, która faktycznie używa systemu, gdzie kończy się dopuszczalna autonomia automatu i co musi być prawdą, żeby kontrola człowieka była realna, a nie tylko wpisana w procedurę. To filar klastra o ryzyku, etyce i odpowiedzialności — punkt wyjścia, do którego wracają bardziej szczegółowe teksty zebrane w obszarze o ryzyku i etyce AI.

Kto odpowiada, gdy automatyczna decyzja zawodzi?

Za skutki decyzji podjętej przez system AI odpowiada człowiek i organizacja, które ten system wdrożyły i użyły — a nie sam system. Algorytm nie jest podmiotem prawa: nie ma woli, majątku ani zdolności do bycia pozwanym. Odpowiedzialność spoczywa na konkretnych ogniwach łańcucha: na tym, kto dostarczył dane, kto zbudował model, a przede wszystkim na tym, kto zdecydował się go użyć wobec realnej osoby. RODO nazywa tę ostatnią rolę administratorem danych, a AI Act — podmiotem wdrażającym. Żadne z tych ogniw nie może zasłonić się „autonomią“ systemu, bo prawo przypisuje odpowiedzialność ludziom stojącym za decyzją, a nie narzędziu, które ją wykonało.

Innymi słowy: „algorytm tak zdecydował“ nie jest odpowiedzią na pytanie „kto odpowiada“, tylko próbą uniknięcia tego pytania. Decyzja zawsze ma autora — choćby był nim zarząd, który zatwierdził wdrożenie bez sprawdzenia, jak system działa na trudnych przypadkach. Im bardziej automatyczny jest proces, tym staranniej trzeba z góry rozpisać, kto za co odpowiada, bo inaczej w momencie błędu okaże się, że odpowiedzialność rozeszła się po całym łańcuchu i nigdzie nie osiadła.

Reszta tekstu pokazuje, jak ten łańcuch zbudować tak, żeby trzymał — i co o tym mówi prawo, które już dziś obowiązuje.

Czym jest decyzja „wyłącznie automatyczna“ w rozumieniu artykułu 22 RODO?

Artykuł 22 RODO to przepis, od którego trzeba zacząć każdą rozmowę o odpowiedzialności za decyzje AI w Europie. Mówi on, że osoba ma prawo nie podlegać decyzji, która opiera się wyłącznie na zautomatyzowanym przetwarzaniu — w tym profilowaniu — i która wywołuje wobec niej skutki prawne lub w podobny sposób istotnie na nią wpływa. To nie jest ozdobnik. To prawo podmiotowe, które przewraca domyślne założenie wielu wdrożeń: że skoro decyzję da się zautomatyzować, to wolno ją zautomatyzować w całości.

Kluczowe jest słowo „wyłącznie“. Przepis nie zakazuje używania AI do przygotowania decyzji. Zakazuje — co do zasady — oddania całej decyzji maszynie tam, gdzie stawka jest wysoka. Granica przebiega więc nie między „z AI“ a „bez AI“, tylko między „człowiek realnie współdecyduje“ a „człowiek został z procesu usunięty“. I właśnie wokół tej granicy toczą się dziś najpoważniejsze spory.

Kiedy decyzja jest „wyłącznie“ automatyczna, a kiedy nie?

Tu pojawia się pułapka, w którą wpada wiele firm. Wstawiają człowieka na końcu procesu — formalnie ktoś „zatwierdza“ wynik — i uznają, że artykuł 22 ich nie dotyczy, bo decyzja nie jest już „wyłącznie“ automatyczna. To złudzenie. Jeśli pracownik widzi tylko końcowy werdykt, nie ma czasu, danych ani uprawnień, żeby go zmienić, i w praktyce zawsze klika „akceptuj“, to jego obecność jest dekoracją. Decyzja pozostaje wyłącznie automatyczna w sensie, który liczy się dla prawa, mimo że na papierze przewinął się przez nią człowiek.

Żeby udział człowieka „odautomatyzował“ decyzję, musi być znaczący. Osoba zatwierdzająca powinna mieć kompetencje i uprawnienia do zmiany wyniku, dostęp do danych, na których oparł się system, oraz realny wpływ na rozstrzygnięcie — a nie jedynie rolę punktu, przez który wynik przechodzi w drodze do skutku. To dokładnie ta różnica, którą rozwija osobny tekst o tym, czym jest rzeczywista kontrola człowieka nad AI. Dopóki ta kontrola jest pozorna, firma działa w reżimie artykułu 22 ze wszystkimi jego konsekwencjami, choćby była przekonana, że jest inaczej.

Warto też pamiętać, że „istotny wpływ“ to nie tylko skutki prawne w ścisłym sensie. Trybunał Sprawiedliwości UE w wyroku z 7 grudnia 2023 roku w sprawie SCHUFA (C-634/21) uznał, że samo wyliczenie przez biuro kredytowe wskaźnika punktowego — scoringu — może być „zautomatyzowaną decyzją w indywidualnym przypadku“ w rozumieniu artykułu 22, jeżeli od tej wartości w decydującym stopniu zależy, czy bank zawrze z klientem umowę. Innymi słowy: podmiot, który tylko „liczy punkty“, a formalną decyzję zostawia komuś innemu, nie ucieka tak łatwo od odpowiedzialności, jeśli to jego wynik faktycznie przesądza sprawę. To ważny sygnał dla wszystkich, którzy budują systemy oceniające ludzi „tylko pomocniczo“.

Jakie prawa daje osobie artykuł 22?

Artykuł 22 nie poprzestaje na zakazie. Tam, gdzie decyzja wyłącznie automatyczna jest dopuszczalna — bo jest niezbędna do zawarcia lub wykonania umowy, dozwolona przepisami prawa albo oparta na wyraźnej zgodzie osoby — RODO nakazuje wdrożyć właściwe zabezpieczenia. Wśród nich wymienia trzy konkretne uprawnienia osoby: prawo do uzyskania interwencji człowieka ze strony administratora, prawo do wyrażenia własnego stanowiska oraz prawo do zakwestionowania decyzji.

Te trzy prawa mają wspólny mianownik: zakładają, że po drugiej stronie jest ktoś, kto potrafi decyzję wyjaśnić, ponownie rozważyć i — jeśli trzeba — odwrócić. Nie da się zapewnić „interwencji człowieka“, jeśli nikt w organizacji nie rozumie, dlaczego system orzekł tak, a nie inaczej. Nie da się rzetelnie rozpatrzyć sprzeciwu, jeśli proces nie zostawił po sobie śladu pozwalającego odtworzyć przesłanki. Dlatego artykuł 22 jest w praktyce nie tylko przepisem o decyzjach, ale i o dokumentowaniu oraz o tym, by w firmie istniał konkretny, osiągalny człowiek odpowiedzialny za rozstrzygnięcie.

Dlaczego „algorytm tak zdecydował“ nie jest odpowiedzią?

Kiedy odpowiedzialność rozkłada się na wielu uczestników, każdy z nich ma naturalną pokusę, by wskazać na sąsiednie ogniwo. Dostawca modelu mówi, że tylko udostępnił narzędzie i to klient decyduje, jak go użyć. Wdrażająca firma mówi, że zaufała renomowanemu dostawcy i działała zgodnie z instrukcją. Pracownik mówi, że tylko obsługiwał system zgodnie z procedurą. Dostawca danych mówi, że dane były „takie, jakie były“. Na końcu tej sekwencji stoi osoba poszkodowana, której nikt nie potrafi odpowiedzieć wprost, kto i dlaczego zdecydował o jej sprawie.

To zjawisko bywa nazywane rozmyciem albo wyparowaniem odpowiedzialności i jest najgroźniejszym efektem ubocznym automatyzacji decyzji. Nie bierze się ze złej woli — bierze się z tego, że nikt z góry nie rozpisał, kto odpowiada za co. Każde ogniwo odpowiada tylko za swój wycinek i szczerze uważa, że zrobiło, co do niego należało. Problem w tym, że suma poprawnie wykonanych wycinków potrafi dać krzywdzącą całość, za którą — przy braku jasnego przypisania ról — formalnie nie odpowiada nikt.

Prawo reaguje na to dwoma ruchami. Po pierwsze, nie pozwala traktować systemu jako podmiotu: algorytm nie ma osobowości prawnej, więc odpowiedzialność musi spaść na kogoś z ludzi lub organizacji w łańcuchu. Po drugie, przypisuje role z góry — RODO wskazuje administratora jako tego, kto odpowiada za zgodność przetwarzania, a AI Act dzieli obowiązki między dostawcę i podmiot wdrażający. Dzięki temu pytanie „kto odpowiada“ ma odpowiedź jeszcze zanim cokolwiek się zepsuje. Reszta to kwestia rzetelnego odwzorowania tych ról wewnątrz firmy.

Jak biegnie łańcuch odpowiedzialności — od danych do wdrażającego?

Żeby odpowiedzialność nie wyparowała, trzeba zobaczyć ją jako łańcuch, w którym każde ogniwo ma własny, nazwany zakres. Decyzja AI nie powstaje w jednym punkcie — jest wynikiem ciągu wyborów: jakie dane zebrano, jak zbudowano model, jak go skonfigurowano, w jakim kontekście użyto i kto zatwierdził skutek. Błąd może wejść na każdym z tych etapów, więc na każdym musi siedzieć ktoś, kto za niego odpowiada.

Ogniwo	Kto to	Za co odpowiada	Typowy błąd na tym etapie
Źródło danych	Dostawca lub zbierający dane	Jakość, legalność i reprezentatywność danych treningowych	Dane obciążone historycznym uprzedzeniem, niekompletne, zebrane bez podstawy prawnej
Twórca modelu	Dostawca systemu AI (provider)	Sposób budowy, testy, dokumentacja, ograniczenia i instrukcja użycia	Brak informacji o granicach stosowania, niedotestowane przypadki brzegowe
Wdrażający	Firma używająca systemu (administrator / podmiot wdrażający)	Decyzja o użyciu, kontekst, nadzór człowieka, reakcja na skargi	Użycie systemu poza jego przeznaczeniem, pozorny nadzór, brak ścieżki odwołania
Operator	Pracownik obsługujący decyzję	Rzetelna ocena konkretnego przypadku w granicach swoich uprawnień	Mechaniczne zatwierdzanie, ignorowanie własnej trafnej wątpliwości
Osoba, której decyzja dotyczy	Klient, kandydat, pacjent	— (to strona chroniona, nie ogniwo odpowiedzialności)	—

Najważniejsza obserwacja z tej tabeli jest taka: punkt ciężkości leży po stronie wdrażającego. To firma, która decyduje się użyć systemu wobec realnej osoby, najczęściej jest administratorem danych w rozumieniu RODO i to ona ponosi główną odpowiedzialność wobec poszkodowanego. Nie znaczy to, że dostawca jest bezkarny — odpowiada za swoje ogniwo, za jakość modelu, dokumentację i rzetelną instrukcję. Ale wobec osoby, której odmówiono kredytu, pierwszym adresatem pytań jest ten, kto tej odmowy faktycznie dokonał, a nie autor narzędzia użytego do jej przygotowania.

AI Act dokłada do tego własną siatkę pojęć. Rozróżnia dostawcę (provider), który system tworzy i wprowadza na rynek, oraz podmiot wdrażający (deployer), który go używa w swojej działalności. Obie role mają osobne obowiązki, a w pewnych sytuacjach — na przykład gdy firma istotnie modyfikuje cudzy system albo używa go pod własną marką — wdrażający może przejąć obowiązki dostawcy. To nie jest akademickie rozróżnienie: od tego, kim jesteś w łańcuchu, zależy, co musisz udokumentować i za co odpowiesz. Szerzej rozwija to obszar o AI Act i nadzorze człowieka.

Gdzie leżą granice autonomii systemu?

Autonomia systemu nie jest cechą techniczną, którą się odkrywa — jest decyzją organizacyjną, którą się świadomie podejmuje. To człowiek ustala, jak dużą część rozstrzygnięcia oddać maszynie, i ten wybór sam w sobie jest aktem, za który się odpowiada. Dlatego pytanie „ile autonomii“ nie powinno padać na końcu, jako techniczny szczegół konfiguracji, tylko na początku, jako decyzja o rozkładzie ryzyka.

Rozsądna granica autonomii zależy od dwóch rzeczy: jak poważne są skutki błędu i jak odwracalne. Tam, gdzie pomyłka jest tania i da się ją natychmiast cofnąć — podpowiedź wyszukiwarki, wstępne sortowanie zgłoszeń, sugestia kolejności w skrzynce — pełna automatyzacja bywa rozsądna. Tam, gdzie błąd uderza w czyjeś prawa, zdrowie albo środki do życia i jest trudny do odwrócenia — odmowa kredytu, wykluczenie z rekrutacji, decyzja medyczna, zamknięcie konta firmie — autonomia musi się kończyć przed momentem nieodwracalnego skutku. To właśnie tam trzeba wyznaczyć moment, w którym rozstrzyga człowiek, o czym szczegółowo traktuje przewodnik po podstawach człowieka w pętli.

Jest też granica, której nie wyznacza ryzyko biznesowe, tylko prawo. Artykuł 22 RODO to sztywna granica: w decyzjach o istotnym wpływie na osobę pełna autonomia jest co do zasady wykluczona, niezależnie od tego, jak dobry jest model. Firma może być przekonana, że jej system myli się rzadziej niż ludzie — i może mieć rację — a mimo to nie wolno jej oddać takiej decyzji w całości maszynie bez podstawy prawnej i zabezpieczeń. Jakość modelu nie przesuwa tej granicy. Przesuwa ją tylko prawo, zgoda osoby albo niezbędność umowna — i to w wąsko zakreślonych ramach.

Najczęstszy błąd polega na myleniu pewności systemu z prawem do autonomii. Wysoka skuteczność statystyczna to argument za tym, żeby systemowi ufać przy rutynowych przypadkach — nie za tym, żeby zdjąć z procesu człowieka tam, gdzie pojedyncza pomyłka jest dla kogoś katastrofą. Im rzadziej system się myli, tym trudniej wyłapać ten jeden błędny wynik, bo czujność operatora słabnie wraz z jakością narzędzia. Paradoksalnie więc lepszy model bywa argumentem za mocniejszym, a nie słabszym nadzorem nad przypadkami o wysokiej stawce.

Czym jest rzeczywista kontrola człowieka, a czym tylko jej pozór?

Skoro prawo wymaga „znaczącego“ udziału człowieka, trzeba umieć odróżnić kontrolę prawdziwą od dekoracyjnej. Różnica nie leży w tym, czy człowiek jest w procesie — leży w tym, czy ma czym i po co tam być. Trzy warunki muszą być spełnione naraz: wiedza, czas i moc. Brak któregokolwiek z nich zamienia nadzór w przyklepywanie.

Wiedza oznacza, że operator rozumie, co system zrobił i na jakiej podstawie — widzi nie tylko werdykt, ale i przesłanki, którymi system się kierował, oraz zna jego ograniczenia. Czas oznacza, że ma realną przestrzeń, by sprawę ocenić — proces nie wymusza na nim tempa, przy którym jedyną możliwą reakcją jest zgoda. Moc oznacza, że jego sprzeciw coś znaczy: może zmienić wynik, a nie tylko zgłosić zastrzeżenie, które i tak nie wstrzyma skutku. Dopiero te trzy elementy razem tworzą kontrolę, którą prawo uzna za znaczącą.

Łatwo rozpoznać pozór po objawach. Jeśli operator zatwierdza dziesiątki decyzji na godzinę, jeśli premiuje się go za tempo, a nie za wychwycone błędy, jeśli interfejs pokazuje tylko wynik bez kontekstu potrzebnego do sprzeciwu, jeśli odrzucenie rekomendacji systemu jest organizacyjnie kłopotliwe i wymaga tłumaczeń — to nie jest nadzór, to scenografia. I co istotne dla odpowiedzialności: wina za przyklepywanie prawie nigdy nie leży po stronie operatora, tylko po stronie tych, którzy tak zaprojektowali proces, że sprzeciw stał się praktycznie niemożliwy. Odpowiedzialność wędruje wtedy w górę — do projektantów procesu i do zarządu, który go zatwierdził.

Jak przypisać odpowiedzialność, żeby nie wyparowała?

Teoria jest jasna: odpowiada wdrażający, dostawca odpowiada za swoje ogniwo, kontrola człowieka musi być realna. Praktyka rozstrzyga się jednak w szczegółach organizacyjnych — w tym, czy w firmie istnieje konkretna osoba z nazwiskiem, która w razie błędu nie może się zasłonić systemem. Oto co odróżnia organizacje, w których odpowiedzialność trzyma się procesu, od tych, w których wyparowuje.

Po pierwsze, wyznacz właściciela decyzji, zanim ją zautomatyzujesz. Każdy zautomatyzowany proces decyzyjny musi mieć przypisaną osobę lub rolę, która odpowiada za jego skutki — nie za działanie techniczne systemu, tylko za to, że wolno go używać w danym kontekście i że osoby poszkodowane mają do kogo się zwrócić. Jeśli na pytanie „kto odpowiada za ten proces“ nie pada nazwisko, to znaczy, że odpowiedzialność już wyparowała, zanim cokolwiek się zepsuło.

Po drugie, dokumentuj przesłanki, nie tylko wyniki. Żeby zapewnić wymaganą przez RODO interwencję człowieka i rozpatrzenie sprzeciwu, trzeba móc odtworzyć, dlaczego system orzekł tak, a nie inaczej. To oznacza zapisywanie nie tylko końcowego werdyktu, ale i danych wejściowych oraz głównych czynników, które przeważyły. Bez tego śladu „prawo do wyjaśnienia“ jest pustą obietnicą, a firma nie udźwignie ciężaru dowodu, gdy decyzję ktoś zakwestionuje.

Po trzecie, zbuduj ścieżkę odwołania, która prowadzi do człowieka z mocą sprawczą. Osoba niezadowolona z decyzji musi trafić nie do kolejnego automatu, tylko do kogoś, kto sprawę ponownie rozważy i może ją odwrócić. Ścieżka odwołania, która kończy się tą samą zautomatyzowaną odpowiedzią, łamie sens artykułu 22. To także najtańszy sposób wychwytywania błędów systemu, zanim urosną do skali, na której zaczyna interesować się nimi regulator.

Po czwarte, rozpisz role w umowach z dostawcami. Jeśli korzystasz z cudzego systemu, granica odpowiedzialności między tobą a dostawcą powinna być zapisana, a nie domniemana. Kto odpowiada za jakość modelu, kto za jego użycie w twoim kontekście, kto za aktualizacje, kto za zgłoszenia incydentów — to wszystko musi być rozstrzygnięte zawczasu. Brak takich zapisów to dokładnie sytuacja, w której w momencie błędu każde ogniwo wskazuje na sąsiednie.

Po piąte, traktuj nadzór jako pracę, a nie jako formalność. Jeśli wymagasz, by człowiek zatwierdzał decyzje, musisz dać mu na to czas, kontekst i jednoznaczne prawo do powiedzenia „nie“ bez konsekwencji organizacyjnych. Nadzór, który konkuruje z presją wskaźników wydajności, zawsze przegra — a wtedy formalna obecność człowieka tylko stworzy złudzenie kontroli i przesunie ryzyko prawne z powrotem na firmę.

Co poza RODO kształtuje odpowiedzialność za decyzje AI?

RODO jest fundamentem, ale nie jedynym filarem. Drugim jest unijny AI Act, który podchodzi do sprawy od strony ryzyka samego systemu, a nie tylko ochrony danych. Dla systemów uznanych za wysokiego ryzyka — a do tej kategorii trafiają typowe decyzje o wysokiej stawce, jak ocena zdolności kredytowej czy selekcja kandydatów do pracy — przewiduje obowiązek zapewnienia skutecznego nadzoru człowieka. To słynny artykuł 14, który wymaga, by system dało się rzeczywiście nadzorować: by człowiek rozumiał jego możliwości i ograniczenia, potrafił właściwie odczytać wynik i mógł go zignorować, odrzucić albo przerwać działanie systemu.

Tu potrzebna jest precyzja co do dat, bo wokół AI Act narosło sporo nieporozumień. Obowiązki dotyczące przejrzystości — w tym oznaczanie treści generowanych przez AI, regulowane artykułem 50 — zaczynają obowiązywać od 2 sierpnia 2026 roku. Natomiast pełne wymagania dla systemów wysokiego ryzyka, w tym artykuł 14 o nadzorze człowieka, zostały przesunięte pakietem Digital Omnibus: ostatecznie przyjęty przez Parlament Europejski 16 czerwca 2026 i zatwierdzony przez Radę UE 29 czerwca 2026, przenosi ich stosowanie na 2 grudnia 2027 roku (a dla AI wbudowanej w produkty regulowane — na 2 sierpnia 2028 roku). To już zamknięta, obowiązująca zmiana prawa, nie kierunek prac. Odpowiedzialność wynikająca z RODO obowiązuje niezależnie od tego harmonogramu — artykuł 22 działa już dziś.

Trzecim filarem jest klasyczna odpowiedzialność cywilna. Niezależnie od przepisów o danych i o AI, firma, która swoją decyzją wyrządza komuś szkodę, odpowiada za nią na zasadach ogólnych — a fakt, że decyzję przygotował automat, nie jest okolicznością wyłączającą tę odpowiedzialność. Przeciwnie: skoro to organizacja wybrała narzędzie i sposób jego użycia, to ona ponosi konsekwencje jego błędów wobec poszkodowanego. „Algorytm tak zdecydował“ nie jest linią obrony w sporze o szkodę — jest co najwyżej opisem tego, jak do szkody doszło.

Jak praktycznie ułożyć odpowiedzialność w swojej organizacji?

Najkrótsza droga od teorii do praktyki to kilka pytań, które warto zadać przy każdym zautomatyzowanym procesie decyzyjnym — zanim wejdzie on w życie, a nie po pierwszej skardze. Jeśli na którekolwiek z nich nie ma jasnej odpowiedzi, to właśnie tam czai się ryzyko, że odpowiedzialność wyparuje.

Czy ten proces podejmuje decyzje wyłącznie automatyczne o istotnym wpływie na osoby — a jeśli tak, na jakiej podstawie prawnej? Czy udział człowieka jest znaczący, to znaczy czy operator ma wiedzę, czas i moc, by zmienić wynik? Czy istnieje nazwana osoba lub rola odpowiedzialna za skutki tego procesu? Czy potrafimy odtworzyć, dlaczego system orzekł tak, a nie inaczej? Czy osoba niezadowolona z decyzji trafi do człowieka, który może ją odwrócić? Czy granice odpowiedzialności między nami a dostawcą są spisane? Czy wiemy, gdzie kończy się dopuszczalna autonomia systemu i dlaczego akurat tam?

Te pytania nie są listą zgodności do odhaczenia raz na zawsze. To raczej stały rytm kontroli, bo systemy się zmieniają, dane się starzeją, a procesy z czasem cicho dryfują w stronę większej autonomii — najczęściej dlatego, że nadzór człowieka okazuje się kosztowny, a pokusa, by go skrócić, jest nieustanna. Organizacja, która traktuje odpowiedzialność za decyzje AI jako żywy proces, a nie jednorazowy projekt prawny, jest tą, w której zdanie „tak zdecydował algorytm“ nigdy nie zamyka rozmowy — tylko ją otwiera, prowadząc do konkretnego człowieka, który potrafi decyzję wyjaśnić i za nią odpowiedzieć.

To jest sedno odpowiedzialnego wdrażania AI: nie chodzi o to, by maszyna nigdy się nie myliła — to niewykonalne — tylko o to, by w momencie błędu było jasne, kto go naprawi i kto za niego odpowie. Reszta to inżynieria tej jasności.