Dlaczego menedżer, a nie dostawca, odpowiada za błędy AI Act?

🎯 Nowe przepisy o sztucznej inteligencji przenoszą ciężar odpowiedzialności z dostawcy technologii na menedżera, który ją wdrożył i nadzoruje. Przepisy te nie wprowadzają fikcji prawnej, w której algorytm ponosi konsekwencje własnych błędów. Odpowiedzialność zawsze spoczywa na człowieku lub organizacji, która wdrożyła system i wykorzystuje go w praktyce. To oznacza, że przedsiębiorca lub menedżer decydujący o zastosowaniu AI w obsłudze klienta czy zarządzaniu personelem odpowiada za skutki jego działania zarówno wobec klientów, jak i pracowników. Artykuł 26 AI Act wprost nakłada na podmioty wdrażające obowiązek stosowania systemu zgodnie z instrukcjami dostawcy oraz zapewnienia kompetentnego nadzoru ludzkiego.[5][6]

📕 Zainteresowany/a tematem – czytaj dalej… ➡️

Kto płaci, kiedy algorytm się myli

Od 2 sierpnia 2026 roku w Unii Europejskiej obowiązują wymogi transparentności wobec systemów AI określone w rozporządzeniu 2024/1689, znanym jako AI Act, obejmujące m.in. obowiązek oznaczania treści syntetycznych i ujawniania interakcji z chatbotami.[1] Pełne wymogi dla systemów wysokiego ryzyka z Załącznika III – takich jak systemy stosowane w rekrutacji, ocenie kredytowej czy zarządzaniu personelem – zostały jednak przesunięte na mocy przyjętego w 2026 roku tzw. Digital Omnibus na 2 grudnia 2027 roku, a dla systemów wbudowanych w produkty regulowane (Załącznik I) na 2 sierpnia 2028 roku.[2][3] Nie oznacza to jednak, że temat traci na aktualności: organizacje, które wdrażają dziś algorytmy w opiece zdrowotnej czy obsłudze klienta, powinny już teraz budować mechanizmy nadzoru, ponieważ obserwuję, że systemy AI bywają wciąż traktowane jak standardowe narzędzia IT, podczas gdy przepisy jednoznacznie wyznaczają wdrażającemu rolę punktu odpowiedzialności prawnej [6]. To moje obserwacja, a nie wynik badania ilościowego, dlatego traktuję ją bardziej jako sygnał ostrzegawczy, a nie twardą statystykę.

Paradoks autonomii systemu

Im bardziej samodzielny wydaje się algorytm, tym większa presja prawna spada na osobę, która go nadzoruje. To pozornie sprzeczne z intuicją, ale logika regulacji jest konsekwentna: skoro system może działać bez stałej ludzkiej ingerencji, prawo wymaga, by ktoś konkretny odpowiadał za to, że ta autonomia nie wymknie się spod kontroli. Artykuł 14 AI Act określa to jako wymóg „human oversight” (nadzoru ludzkiego) – nadzoru sprawowanego przez osoby fizyczne, które muszą w pełni rozumieć możliwości i ograniczenia systemu, monitorować jego działanie, potrafić zignorować lub unieważnić jego wynik oraz interweniować lub zatrzymać system, gdy zajdzie taka potrzeba.[7][8]

To nie jest wymóg dokumentacyjny, lecz projektowy i operacyjny jednocześnie. Dostawca systemu musi zbudować narzędzie technicznie umożliwiające taki nadzór, natomiast wdrażająca organizacja musi faktycznie z tych możliwości korzystać, a nie jedynie posiadać politykę deklarującą taki nadzór na papierze. Dla systemów zdalnej identyfikacji biometrycznej wymienionych w punkcie 1(a) Załącznika III, artykuł 14 ustęp 5 AI Act idzie dalej i wprost wymaga, by żadna decyzja lub działanie oparte na wyniku identyfikacji nie zostały podjęte bez odrębnej weryfikacji i potwierdzenia przez co najmniej dwie osoby fizyczne posiadające niezbędne kompetencje, przeszkolenie i uprawnienia.[7][8]

Menedżer jako punkt odpowiedzialności

Dlaczego to menedżer, a nie dział IT

Odpowiedzialność za działanie systemu AI obejmuje cały jego cykl życia – od projektowania, przez wdrożenie, aż po wykorzystanie w konkretnych procesach decyzyjnych. W praktyce oznacza to, że dział IT lub dostawca technologii odpowiada za to, czy narzędzie spełnia wymogi techniczne, natomiast menedżer operacyjny, który decyduje o użyciu systemu w konkretnym procesie biznesowym, odpowiada za to, jak ten system jest faktycznie wykorzystywany na co dzień.[9]

Artykuł 26 ustęp 2 AI Act nakłada na wdrażających obowiązek przypisania nadzoru ludzkiego osobom posiadającym niezbędne kompetencje, przeszkolenie i uprawnienia do skutecznego działania. To rodzi konkretne pytania kontrolne dla każdej organizacji: czy istnieje wyznaczona funkcja nadzorcza dla każdego systemu wysokiego ryzyka, czy osoba nadzorująca ma udokumentowane kompetencje i przeszkolenie w zakresie danego systemu, oraz czy posiada organizacyjne uprawnienia do unieważnienia wyniku algorytmu. Brak jednoznacznej odpowiedzi na te pytania oznacza realną lukę w zgodności z przepisami.[10][6]

Automation bias jako pułapka prawna

Jednym z najpoważniejszych ryzyk operacyjnych jest zjawisko nazywane automation bias (błąd automatyzacji) – skłonność do nadmiernego polegania na rekomendacji algorytmu bez krytycznej weryfikacji. Wymóg nadzoru ludzkiego z artykułu 14 AI Act, analizowany w literaturze przedmiotu, sugeruje, że osoby nadzorujące powinny być świadome tej tendencji oraz potencjalnych błędów systemu, a nie jedynie wiedzieć o samym istnieniu narzędzia AI. Menedżer, który automatycznie zatwierdza rekomendacje systemu bez realnej analizy, nie spełnia więc – w duchu tego przepisu – wymogu nadzoru, nawet jeśli formalnie „przejrzał” decyzję.[11]

Praktyczne wdrożenie tego wymogu oznacza wyznaczenie konkretnej, nazwanej osoby odpowiedzialnej za przegląd każdej kategorii decyzji wspieranych przez AI – na przykład menedżera HR weryfikującego wyniki oceny kandydatów czy specjalisty ds. ryzyka kredytowego analizującego rekomendacje systemu oceny punktowej. W praktyce oznacza to, że przegląd wyników AI powinien być traktowany jako odrębna funkcja zawodowa z przypisanym czasem pracy, a nie dodatkowe zadanie nakładane na już obciążonego pracownika – tak, by nadzór był realny, a nie iluzoryczny.[8]

Co musi zawierać dokumentacja decyzyjna

Dostęp do logiki decyzji

Zanim osoba nadzorująca zatwierdzi decyzję wspartą przez AI, musi mieć dostęp do wyniku systemu, kluczowych danych wejściowych, które ten wynik wygenerowały, poziomu pewności lub oznaczenia niepewności wyniku, udokumentowanych trybów awarii i znanych błędów systemu oraz populacji porównawczej użytej przez algorytm. Bez tych elementów formalne „zatwierdzenie” decyzji przez człowieka jest fikcją nadzoru, a nie realnym mechanizmem kontrolnym.[8]

Dokumentacja techniczna dostarczana przez dostawcę powinna wyjaśniać, jak nadzór ludzki ma być realizowany w praktyce, opisywać znane tryby awarii systemu oraz to, na co powinni zwracać uwagę ludzcy recenzenci, a także określać, jakiego przeszkolenia potrzebują recenzenci, aby sprawować sensowny nadzór. Organizacja wdrażająca system, która nie żąda tej dokumentacji od dostawcy, sama naraża się na odpowiedzialność za brak zgodności.[8]

Mechanizm unieważnienia i logowanie decyzji

Decyzja o unieważnieniu rekomendacji algorytmu musi być dostępna bezpośrednio w głównym procesie pracy, a nie ukryta w ustawieniach systemu wymagających specjalistycznego dostępu. Każde unieważnienie powinno zostać zarejestrowane wraz z uzasadnieniem, a dane o takich przypadkach powinny zasilać proces monitorowania systemu po jego wdrożeniu. To tworzy ślad dowodowy, który w razie kontroli lub sporu sądowego może chronić menedżera – pokazuje, że nadzór był rzeczywisty, a nie deklaratywny.[9][8] Organizacje powinny prowadzić dziennik wskazujący, które wyniki zostały zweryfikowane przez człowieka, przez kogo i kiedy, rejestrować decyzje o unieważnieniu wraz z przyczynami oraz zapewniać eksportowalne zapisy audytowe na potrzeby kontroli zgodności. Przepisy wymagają również przechowywania plików logów przez co najmniej sześć miesięcy. Poniższa tabela porządkuje kluczowe elementy dokumentacji decyzyjnej wymagane w praktyce.[6][8]

Sankcje i ryzyko osobiste

Konsekwencje braku zgodności nie są symboliczne. Kary za naruszenie obowiązków dotyczących systemów wysokiego ryzyka mogą sięgać nawet 15 milionów euro lub 3 procent globalnego rocznego obrotu przedsiębiorstwa, w zależności od tego, która wartość jest wyższa.[12] Dla dużych organizacji, przy globalnych obrotach liczonych w miliardach euro, próg 3 procent może w praktyce przewyższać nawet górną granicę 15 milionów euro [12], a dla menedżera odpowiedzialnego za wdrożenie oznacza to realne ryzyko odpowiedzialności zawodowej i reputacyjnej, niezależnie od formalnej odpowiedzialności finansowej spółki.

Warto pamiętać, że przesunięcie terminów przez Digital Omnibus – opisane wcześniej – dotyczy wyłącznie obowiązków związanych z systemami wysokiego ryzyka, a nie oznacza, że organizacje mogą odłożyć przygotowania: budowa realnych mechanizmów nadzoru, dokumentacji i rejestrów wymaga czasu, a te firmy, które zaczną z opóźnieniem, i tak znajdą się pod presją, gdy nadejdzie nowy termin. Komentarze prawne dotyczące wdrożenia Digital Omnibus podkreślają, że przesunięcie terminów nie powinno usypiać czujności organizacji – traktowanie wymogu nadzoru ludzkiego jako formalności dokumentacyjnej, bez wbudowania go w rzeczywiste procesy operacyjne, nie spełnia intencji przepisu.[3][13]

Co konkretnie grozi menedżerowi

Ryzyko prawne dla osoby nadzorującej wdrożenie AI ma kilka wymiarów praktycznych. Po pierwsze, brak udokumentowanego, realnego nadzoru może zostać uznany za niedopełnienie obowiązków wynikających z artykułu 26 AI Act, co naraża organizację na sankcje administracyjne. Po drugie, w przypadku szkody wyrządzonej klientowi lub pracownikowi przez błędną decyzję algorytmu, brak dokumentacji decyzyjnej utrudnia menedżerowi wykazanie, że dochował należytej staranności, co zwiększa ryzyko odpowiedzialności cywilnej wobec poszkodowanego. Po trzecie, reputacyjne konsekwencje ujawnienia braku nadzoru mogą być trwalsze niż sama kara finansowa, szczególnie w sektorach regulowanych, takich jak ochrona zdrowia czy usługi finansowe.[5][6]

Dlaczego to szansa, a nie tylko obciążenie

Dobrze zaprojektowana dokumentacja decyzyjna działa w dwie strony. Chroni menedżera przed zarzutem zaniedbania, ale jednocześnie porządkuje proces decyzyjny w sposób, który w metodyce Lean nazwalibyśmy standaryzacją pracy – jasno określa, kto, kiedy i na jakiej podstawie podejmuje decyzję, a to eliminuje jedno z najczęstszych źródeł marnotrawstwa: niejasność odpowiedzialności. Organizacje, które już teraz budują te mechanizmy, zyskują przewagę nie tylko regulacyjną, ale i operacyjną – szybciej wykrywają błędy systemu, ponieważ mają ustrukturyzowany proces ich rejestrowania.

Wymóg oceny proporcjonalnej do ryzyka, poziomu autonomii i kontekstu użycia systemu oznacza również, że nie każdy proces wymaga tego samego poziomu formalności. Mniej krytyczne zastosowania AI mogą mieć uproszczony mechanizm nadzoru, podczas gdy systemy wpływające bezpośrednio na prawa lub zdrowie ludzi wymagają pełnej dokumentacji i podwójnej weryfikacji. Rozpoznanie tej różnicy pozwala uniknąć nadmiernej biurokratyzacji tam, gdzie nie jest ona konieczna.[9]

Wdrożenie AI do decyzji operacyjnych przenosi ciężar odpowiedzialności prawnej na osobę nadzorującą system, dlatego warto już teraz wyznaczyć imiennego recenzenta dla każdej kategorii decyzji wspieranej przez algorytm.

Praktyczna droga do ochrony zaczyna się od trzech kroków: zbudowania rejestru przeglądów i unieważnień decyzji AI, zapewnienia recenzentom realnego dostępu do logiki i ograniczeń systemu, oraz regularnego audytu, czy nadzór jest faktycznie wykonywany, a nie jedynie zadeklarowany w procedurze. Jeśli jesteś liderem zespołu wdrażającego AI, sprawdź jeszcze w tym tygodniu, czy istnieje udokumentowany ślad decyzji dla ostatnich dziesięciu rekomendacji algorytmu w Twoim procesie.

🤔 Czy Twoja organizacja potrafiłaby dziś wykazać kontrolerowi, kto i dlaczego zatwierdził konkretną decyzję systemu? Podziel się w komentarzach, jak u Was wygląda nadzór nad decyzjami AI – to temat, który dopiero zaczyna się w polskich firmach na poważnie. ✍️

📕 Zajrzyj do doskonałej książki Stowarzyszenia SLMP – Historie Leanem Pisane – i poznaj moją – Od Zera do Lean Six Sigma Managera 👊