- Kto podpisze się pod błędem AI? Odpowiedzialność w projektach wspieranych przez sztuczną inteligencję - 20 maja 2026
- Integracja z KSeF w Twoim CRM – jak zyskać kontrolę nad fakturami - 27 kwietnia 2026
- AI w Creatio - 2 kwietnia 2026
System rekomendacyjny zintegrowany z CRM sugeruje handlowcowi złożenie oferty klientowi z segmentu premium. Oferta jest błędna – model nie uwzględnił aktualnych warunków kontraktu. Klient rezygnuje. Firma traci kilkaset tysięcy złotych przychodu.
Kto odpowiada?
Dostawca modelu AI, który go wytrenował? Firma wdrożeniowa, która go zintegrowała z systemem? Czy organizacja, której pracownik zatwierdził rekomendację jednym kliknięciem?
To pytanie zadaje sobie coraz więcej firm, które wdrożyły AI i zorientowały się – zazwyczaj w najmniej odpowiednim momencie – że nie mają na nie odpowiedzi w żadnym ze swoich dokumentów.
AI nie ma osobowości prawnej – więc kto odpowiada?
To punkt wyjścia, który warto mieć jasno za sobą: żaden system AI nie ponosi odpowiedzialności prawnej. Algorytm nie jest stroną umowy, nie można go pozwać, nie nałoży się na niego kary. Odpowiedzialność zawsze spada na człowieka lub podmiot, który ma realny wpływ na to, jak system działa.
Unijny prawodawca – w projektowanej dyrektywie AILD (Artificial Intelligence Liability Directive) – posługuje się w tym kontekście pojęciem operatora systemu AI. Rozróżnia dwa typy:
Podział wydaje się przejrzysty, dopóki nie wejdzie między te dwie strony trzecia – firma wdrożeniowa. A ona prawie zawsze tam jest.
Trzy warstwy odpowiedzialności w projekcie AI
Typowy projekt wdrożeniowy z komponentem AI nie jest transakcją dwustronną. Składa się z trzech stron, z których każda odpowiada za inny fragment całości.
Vendor – dostawca modelu lub platformy. Odpowiada za jakość algorytmu, poprawność danych treningowych, dokumentację techniczną i spełnienie wymogów regulacyjnych po stronie produktu. Jeśli model był stronniczy, źle wytrenowany albo podatny na znany typ błędu – to jego obszar.
Firma wdrożeniowa – implementer. Odpowiada za to, jak technologia została osadzona w procesach klienta: mapowanie wymagań, konfigurację, integrację z istniejącymi systemami, testy akceptacyjne. Jeśli model działa poprawnie, ale wdrożono go w kontekście, do którego nie był przeznaczony – odpowiedzialność przesuwa się w tę stronę.
Klient – operator end-user. Odpowiada za dane, których dostarcza systemowi, za sposób korzystania z rekomendacji AI i za nadzór człowieka nad decyzjami o wysokiej stawce. Jeśli pracownicy zatwierdzają wyniki modelu bez weryfikacji albo firma zasila system nieaktualnymi danymi – ryzyko jest po jej stronie.
Problem polega na tym, że większość umów wdrożeniowych nie opisuje tego podziału wprost. Zapisuje ogólne klauzule o „zgodności z wymaganiami” i „staranności przy wdrożeniu”, a gdy coś idzie nie tak, każda strona wskazuje na pozostałe.
Gdzie w praktyce leży granica?
Trzy scenariusze, które pokazują, jak ta granica przebiega w konkretnych sytuacjach.
Scenariusz 1: Błędna predykcja sprzedażowa. System CRM z modułem predykcji prognozuje zamknięcie dealu z prawdopodobieństwem 87%. Handlowiec nie podejmuje działań interwencyjnych. Deal odpada. Analiza pokazuje, że dane CRM były niekompletne – historyczne notatki ze spotkań nie były wprowadzane regularnie od sześciu miesięcy. Model pracował na złym materiale. Odpowiedzialność jest po stronie klienta – to on dostarczał dane.
Scenariusz 2: Bias w module oceny pracowników. System HCM z funkcją AI-scoringu kandydatów systematycznie obniża oceny osób z określonymi cechami demograficznymi. Firma traci sprawę o dyskryminację. Dochodzenie wykazuje, że model był trenowany na historycznych danych rekrutacyjnych, które odzwierciedlały istniejące nierówności. Algorytm nie był poddany audytowi przed wdrożeniem. Odpowiedzialność jest po stronie vendora – to wada technologiczna, nie błąd użytkowania.
Scenariusz 3: Automatyzacja z pominięciem edge case’ów. Workflow automatyzacji obsługi klienta eskaluje określony typ zgłoszeń do działu technicznego zamiast do obsługi. Przez trzy miesiące kilkadziesiąt reklamacji zostaje nieprawidłowo obsłużonych. Analiza pokazuje, że na etapie wdrożenia nie przetestowano przypadków granicznych dla kategorii mieszanych. Odpowiedzialność jest po stronie implementera – błąd wynika z niekompletnej analizy wymagań.
SaaS kontra wdrożenie custom – to nie to samo ryzyko
To rozróżnienie jest ważne i często pomijane, gdy firmy porównują oferty.
W modelu SaaS klient kupuje dostęp do gotowego produktu z wbudowanym AI. Vendor zarządza modelem, infrastrukturą i aktualizacjami. Odpowiedzialność za działanie algorytmu jest tu bardziej skoncentrowana po stronie dostawcy – ale umowy SaaS prawie zawsze zawierają rozbudowane klauzule ograniczające odpowiedzialność, wyłączenia dla specyficznych zastosowań i limity kwotowe odszkodowań. Klient kupuje narzędzie, nie gwarancję wyników. Jeśli używa go w sposób wykraczający poza przewidziane zastosowanie, ryzyko przechodzi na niego.
W modelu custom – gdy AI jest budowane lub konfigurowane pod konkretne potrzeby organizacji – granica odpowiedzialności przebiega inaczej. Im więcej klient wpływa na kształt modelu (dane treningowe, parametry, logika decyzyjna), tym więcej odpowiedzialności operacyjnej bierze na siebie. Jednocześnie rośnie rola implementera: to on zazwyczaj definiuje architekturę rozwiązania, dobiera komponenty i odpowiada za zgodność z wymaganiami. W projekcie custom każda z trzech stron ma większy udział w ryzyku – i tym bardziej kluczowe jest, żeby umowa to odzwierciedlała.
Praktyczna różnica: firma korzystająca z gotowego modułu AI w SugarAI i firma budująca własny model predykcji churnu na danych CRM mają zupełnie inny profil ryzyka prawnego. Traktowanie ich tak samo w kontrakcie to błąd.
AI Act i co z tego wynika dla firm
AI Act wszedł w życie w sierpniu 2024 roku, ale jego stosowanie jest rozłożone w czasie. Dla większości firm kluczowe są dwie daty: sierpień 2026 – pełne zastosowanie przepisów wobec dostawców modeli ogólnego przeznaczenia, oraz sierpień 2027 – przepisy dla systemów wysokiego ryzyka.
Co do zasady, im bardziej system AI wpływa na decyzje dotyczące ludzi, tym wyższy poziom ryzyka mu przypisano. W praktyce biznesowej w kategorię wysokiego ryzyka mogą wpaść moduły oceniające pracowników lub kandydatów do pracy, systemy scoringu kredytowego lub oceny wiarygodności klientów, narzędzia wpływające na dostęp do usług o krytycznym znaczeniu.
Kary za naruszenia sięgają 15 milionów euro lub 3% rocznego światowego obrotu – w zależności od tego, która kwota jest wyższa. Co ważne, sankcje mogą być nakładane nie tylko za aktywne naruszenia, ale też za brak wymaganej dokumentacji i niemożność wykazania, jak system działał w momencie incydentu.
Dla firm korzystających z systemów AI oznacza to jedno: nieposiadanie dokumentacji samo w sobie staje się ryzykiem regulacyjnym.
Co musi znaleźć się w umowie wdrożeniowej
Umowy na wdrożenie systemów z AI wciąż wyglądają często jak kontrakty na dostawę oprogramowania sprzed dekady. Nie regulują obszarów, które w przypadku AI są krytyczne.
Minimalne zagadnienia, które powinny być explicite opisane w kontrakcie:
Praktyczne minimum przed podpisaniem kontraktu
Zanim organizacja podpisze umowę na wdrożenie systemu z komponentem AI, warto zadać sobie – i dostawcy – kilka konkretnych pytań.
Czy ten system kwalifikuje się jako system wysokiego ryzyka według AI Act? Nie każde wdrożenie AI wymaga tego samego poziomu dokumentacji i nadzoru. Warto wiedzieć, z którą kategorią ma się do czynienia.
Jak umowa reguluje odpowiedzialność za dane? Jeśli klient dostarcza dane historyczne, a umowa milczy na temat ich jakości – ryzyko jest po jego stronie, nawet jeśli tego nie podejrzewa.
Kto po wdrożeniu monitoruje model? Modele dryfują – ich skuteczność spada w czasie, gdy rzeczywistość odbiega od danych treningowych. Kontrakt powinien wskazywać, kto jest za to odpowiedzialny i co oznacza „brak nadzoru” z prawnego punktu widzenia.
Co konkretnie wyłącza odpowiedzialność vendora? W umowach SaaS klauzule ograniczające odpowiedzialność są standardem. Warto je przeczytać przed incydentem, nie po.
Czy umowa wdrożeniowa dzieli odpowiedzialność między vendora a implementera? Jeśli nie – w przypadku sporu obie strony będą wskazywać na klienta.
Podsumowanie
Temat odpowiedzialności za błędy AI nie znika przez to, że się go nie porusza na etapie negocjacji. Wręcz przeciwnie – brak jasnego podziału w dokumentach sprawia, że każdy błąd staje się droższy: nie tylko przez bezpośrednie koszty, ale przez czas i energię potrzebne do ustalenia, kto i za co odpowiada.
Firmy, które wchodzą w projekty AI z przemyślanym podziałem odpowiedzialności, lepszymi umowami i udokumentowanym nadzorem nad systemem, nie eliminują ryzyka błędu. Eliminują ryzyko, że błąd zamieni się w kryzys prawny.
I to jest wystarczająco dobry powód, żeby zająć się tym, zanim system trafi na produkcję.
Jesteś gotowy na prowadzenie dużego projektu wdrożeniowego w Twojej firmie?
Wiesz, o co zapytać dostawcę? Jak przygotować własny zespół? Jak stworzyć skuteczne zapytanie ofertowe? Jaką metodykę wybrać? Na co zwrócić uwagę negocjując umowę wdrożeniową i serwisową?
Specjalnie dla Ciebie stworzyliśmy darmowy kurs mailowy przygotowujący do prowadzenia wdrożeń.
Codziennie przez dwa tygodnie otrzymasz od nas na swoją skrzynkę kolejną dawkę wiedzy, która pozwoli odnaleźć Ci się w tym skomplikowanym procesie.
Darmowy kurs mailowy
- Kto podpisze się pod błędem AI? Odpowiedzialność w projektach wspieranych przez sztuczną inteligencję - 20 maja 2026
- Integracja z KSeF w Twoim CRM – jak zyskać kontrolę nad fakturami - 27 kwietnia 2026
- AI w Creatio - 2 kwietnia 2026
