Błąd w kodzie jako wada produktu! Nowe zasady odpowiedzialności za oprogramowanie i AI

Błąd w kodzie może przestać być wyłącznie problemem technicznym albo podstawą reklamacji. Jeżeli doprowadzi do szkody, może zostać potraktowany jak wada produktu.

Dotychczas pojęcie produktu kojarzyło się przede wszystkim z rzeczą materialną – urządzeniem, maszyną, samochodem lub sprzętem medycznym. Rozwój oprogramowania, systemów sztucznej inteligencji i produktów stale połączonych z internetem sprawił jednak, że taki podział przestał odpowiadać rzeczywistości.

Coraz częściej to nie element mechaniczny, lecz kod decyduje o bezpieczeństwie produktu. Błędna aktualizacja może unieruchomić urządzenie, luka w zabezpieczeniach umożliwić przejęcie nad nim kontroli, a nieprawidłowo działający system AI doprowadzić do podjęcia niebezpiecznej decyzji.

Odpowiedzią na te ryzyka jest dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/2853 w sprawie odpowiedzialności za produkty wadliwe, określana jako nowa Product Liability Directive – PLD. Dyrektywa zastępuje regulację z 1985 r. i dostosowuje zasady odpowiedzialności produktowej do gospodarki cyfrowej, sztucznej inteligencji i nowych łańcuchów dostaw.

Oprogramowanie staje się produktem

Jedną z najważniejszych zmian jest jednoznaczne objęcie pojęciem produktu również oprogramowania.

Nowe zasady mogą dotyczyć m.in.:

• systemów operacyjnych;
• aplikacji mobilnych;
• oprogramowania układowego;
• programów komputerowych;
• systemów sztucznej inteligencji;
• oprogramowania udostępnianego w chmurze;
• rozwiązań działających w modelu SaaS;
• cyfrowych plików produkcyjnych sterujących maszynami lub drukarkami 3D.

Sposób dostarczenia oprogramowania nie będzie miał decydującego znaczenia. Może ono być zapisane bezpośrednio na urządzeniu, pobierane z internetu, udostępniane przez chmurę albo świadczone jako usługa. Twórca lub producent oprogramowania, w tym dostawca systemu AI w rozumieniu AI Act, może być traktowany jak producent produktu.

Dyrektywa nie obejmuje jednak każdej treści cyfrowej. Sama informacja, e-book, plik multimedialny czy sam kod źródłowy nie są automatycznie produktem. Szczególną kategorią są natomiast cyfrowe pliki produkcyjne zawierające instrukcje pozwalające maszynie wytworzyć rzecz materialną. Wadliwy projekt wykorzystywany przez drukarkę 3D może zatem prowadzić do odpowiedzialności, jeżeli wykonany na jego podstawie przedmiot spowoduje szkodę.

Nie każdy błąd w kodzie oznacza wadę produktu

Nieprawidłowe działanie programu nie zawsze będzie równoznaczne z wadliwością produktu w rozumieniu nowych przepisów.

Produkt jest wadliwy, gdy nie zapewnia bezpieczeństwa, którego dana osoba ma prawo oczekiwać albo które jest wymagane przez prawo unijne lub krajowe. Przy ocenie bierze się pod uwagę m.in.:

• przeznaczenie produktu;
• sposób jego prezentacji;
• instrukcje i ostrzeżenia;
• racjonalnie przewidywalny sposób używania;
• grupę użytkowników, dla której jest przeznaczony;
• zdolność produktu do dalszego uczenia się;
• wpływ innych produktów współpracujących z systemem;
• wymagania bezpieczeństwa i cyberbezpieczeństwa;
• moment wprowadzenia produktu do obrotu;
• oczekiwany okres jego użytkowania.

Sama niedogodność, wolniejsze działanie aplikacji albo brak obiecanej funkcji mogą nadal stanowić przede wszystkim problem kontraktowy. Odpowiedzialność produktowa koncentruje się na braku bezpieczeństwa i szkodzie wywołanej przez produkt.

Przykład

Aplikacja do zarządzania zadaniami wyświetla błędną godzinę spotkania. Może to świadczyć o niewykonaniu lub nienależytym wykonaniu umowy, ale nie musi jeszcze oznaczać wady produktu w rozumieniu PLD.

Inaczej należy ocenić błąd oprogramowania sterującego pompą insulinową, maszyną przemysłową albo systemem bezpieczeństwa pojazdu. Jeżeli nieprawidłowy kod powoduje ryzyko dla zdrowia lub mienia, może zostać uznany za wadę produktu.

System AI może być wadliwy także przez sposób uczenia się

W przypadku systemów sztucznej inteligencji ocena nie będzie ograniczała się do pierwotnej wersji programu.

Producent może odpowiadać również za wady powstałe w wyniku:

• aktualizacji lub modernizacji pozostającej pod jego kontrolą;
• dalszego uczenia się systemu AI;
• zmian parametrów wprowadzanych po rozpoczęciu użytkowania;
• braku odpowiedniej aktualizacji bezpieczeństwa;
• współdziałania systemu z innym produktem lub usługą cyfrową.

Jeżeli system AI po wdrożeniu nadal uczy się, a proces ten pozostaje pod kontrolą producenta, odpowiedzialność nie kończy się w chwili pierwszego udostępnienia systemu.

Przykład

System AI wspomagający diagnostykę medyczną zostaje zaktualizowany przez dostawcę. Po aktualizacji zaczyna pomijać określony rodzaj zmian widocznych na obrazach diagnostycznych.

Jeżeli nieprawidłowe działanie prowadzi do szkody pacjenta, dostawca nie zawsze będzie mógł bronić się argumentem, że pierwotna wersja systemu działała prawidłowo. Znaczenie będzie miało to, kto kontrolował aktualizację, dane, dalsze uczenie systemu i sposób jego wdrożenia.

Jednocześnie pojedyncza błędna odpowiedź modelu generatywnego nie musi automatycznie oznaczać wady produktu. Konieczne jest zbadanie przeznaczenia systemu, sposobu przedstawiania jego możliwości, instrukcji, przewidywalnego wykorzystania i poziomu bezpieczeństwa, którego użytkownik miał prawo oczekiwać.

Brak aktualizacji bezpieczeństwa również może prowadzić do odpowiedzialności

Nowe przepisy szczególnie podkreślają znaczenie cyberbezpieczeństwa.

Produkt może zostać uznany za wadliwy z powodu luki bezpieczeństwa. Odpowiedzialność może powstać również wtedy, gdy producent nie dostarczył aktualizacji lub modernizacji zabezpieczeń potrzebnych do usunięcia znanej podatności.

Sprzedaż urządzenia albo udzielenie licencji nie zawsze kończy więc obowiązki producenta. Jeżeli produkt pozostaje pod jego kontrolą, a producent odpowiada za aktualizacje, powinien monitorować zagrożenia i reagować na wykryte podatności.

Może to dotyczyć m.in.:

• systemów smart home;
• urządzeń IoT;
• inteligentnych zabawek;
• maszyn podłączonych do sieci;
• urządzeń medycznych;
• systemów samochodowych;
• aplikacji sterujących fizycznym produktem.

Przykład

Producent inteligentnego zamka otrzymuje informację o luce umożliwiającej osobie trzeciej zdalne otwarcie drzwi, ale nie publikuje aktualizacji.

Jeżeli podatność zostanie wykorzystana i doprowadzi do szkody, brak odpowiedniej reakcji może być jednym z elementów przemawiających za wadliwością produktu.

Usługa cyfrowa może stać się częścią produktu

Nowa dyrektywa obejmuje także określone usługi cyfrowe powiązane z produktem.

Chodzi o usługi zintegrowane z produktem lub połączone z nim w taki sposób, że bez nich produkt nie mógłby wykonywać przynajmniej jednej ze swoich funkcji.

Przykładem może być:

• usługa nawigacyjna niezbędna do działania autonomicznego pojazdu;
• usługa chmurowa sterująca urządzeniem;
• system monitorowania niezbędny do funkcjonowania wyrobu medycznego;
• zdalna usługa przetwarzania danych wykorzystywana przez maszynę.

Jeżeli taka usługa została zintegrowana pod kontrolą producenta, może być analizowana jako element całego produktu. Nie każda usługa dostępna obok produktu będzie jednak objęta odpowiedzialnością produktową. Musi istnieć odpowiednio ścisły związek między usługą a funkcjonowaniem produktu.

Odpowiedzialność niezależna od winy

Odpowiedzialność przewidziana przez PLD opiera się na zasadzie odpowiedzialności niezależnej od winy.

Osoba poszkodowana nie musi wykazywać, że producent działał umyślnie albo niedbale. Co do zasady powinna natomiast udowodnić:

1. wadliwość produktu;
2. powstanie szkody;
3. związek przyczynowy między wadą a szkodą.

Oznacza to, że nawet przedsiębiorca, który dochował staranności przy tworzeniu oprogramowania, może odpowiadać, jeżeli produkt okazał się wadliwy i spowodował szkodę.

Nie wyłącza to możliwości dochodzenia roszczeń na innych podstawach, np. z umowy, gwarancji, odpowiedzialności deliktowej albo przepisów o ochronie danych osobowych. Różne reżimy odpowiedzialności mogą funkcjonować równolegle.

Kto odpowie za wadliwe oprogramowanie?

W pierwszej kolejności odpowiedzialność może ponosić producent produktu, w tym twórca lub producent oprogramowania oraz dostawca systemu AI.

Odpowiedzialność może dotyczyć także:

• producenta wadliwego komponentu;
• przedsiębiorcy oferującego produkt pod własną nazwą lub marką;
• podmiotu, który istotnie zmodyfikował produkt;
• importera produktu spoza UE;
• upoważnionego przedstawiciela producenta;
• dostawcy usług realizacji zamówień, jeżeli brak jest innych odpowiedzialnych podmiotów w UE;
• dystrybutora lub platformy internetowej – po spełnieniu warunków określonych w dyrektywie.

Celem nowych przepisów jest zapewnienie, aby w przypadku produktu pochodzącego spoza Unii poszkodowany mógł dochodzić roszczeń od podmiotu znajdującego się na terenie UE.

Odpowiedzialność za modyfikację systemu

Firma korzystająca z cudzego oprogramowania może przejąć odpowiedzialność producenta, jeżeli dokona w nim istotnej modyfikacji, a następnie udostępni zmodyfikowany produkt na rynku lub odda go do użytku.

Może to mieć znaczenie, gdy przedsiębiorca:

• zmienia przeznaczenie systemu;
• ingeruje w mechanizmy bezpieczeństwa;
• modyfikuje model AI;
• integruje oprogramowanie z nowym urządzeniem;
• wprowadza własne aktualizacje;
• oferuje zmieniony system pod własną marką.

Samo korzystanie z dostępnych ustawień lub konfiguracja przewidziana przez producenta nie powinna automatycznie oznaczać przejęcia jego odpowiedzialności. Kluczowy będzie zakres ingerencji oraz jej wpływ na bezpieczeństwo produktu.

Łatwiejszy dostęp do dowodów

W sprawach dotyczących oprogramowania i AI jedną z największych trudności jest nierównowaga informacyjna.

Poszkodowany zwykle nie ma dostępu do:

• kodu i dokumentacji technicznej;
• danych treningowych;
• historii aktualizacji;
• rejestrów działania systemu;
• wyników testów;
• informacji o wykrytych podatnościach;
• wewnętrznych analiz ryzyka.

Dyrektywa przewiduje możliwość zobowiązania pozwanego przez sąd do ujawnienia dowodów znajdujących się w jego posiadaniu, jeżeli poszkodowany przedstawi fakty i dowody wystarczające do wykazania wiarygodności roszczenia.

Ujawnienie powinno ograniczać się do informacji niezbędnych i proporcjonalnych. Sąd ma jednocześnie chronić tajemnicę przedsiębiorstwa i inne informacje poufne.

Dla przedsiębiorców oznacza to, że brak właściwej dokumentacji może mieć bezpośrednie konsekwencje procesowe. Nie wystarczy twierdzić, że system został prawidłowo przetestowany. Firma powinna być w stanie wykazać, jakie testy, kontrole i działania rzeczywiście przeprowadzono.

Domniemania przy skomplikowanych systemach AI

Co do zasady to poszkodowany powinien udowodnić wadę, szkodę i związek przyczynowy. Nowa dyrektywa wprowadza jednak domniemania, które mają ułatwić dochodzenie roszczeń w sprawach skomplikowanych technicznie.

Wadliwość produktu może być domniemywana m.in., gdy:

• pozwany nie ujawni wymaganych dowodów;
• produkt narusza obowiązkowe wymagania bezpieczeństwa chroniące przed danym rodzajem szkody;
• szkoda została wywołana oczywistym nieprawidłowym działaniem produktu podczas przewidywalnego używania.

Sąd może również zastosować domniemanie wadliwości albo związku przyczynowego, gdy poszkodowany napotyka nadmierne trudności dowodowe wynikające ze złożoności technicznej lub naukowej, a jednocześnie wykaże prawdopodobieństwo istnienia wady lub związku ze szkodą. Domniemania te pozostają wzruszalne – pozwany może przedstawiać dowody przeciwne.

Rozwiązanie to może mieć szczególne znaczenie w przypadku tzw. systemów „black box”, których dokładnego procesu decyzyjnego nie da się łatwo odtworzyć.

Jakie szkody mogą podlegać naprawieniu?

Dyrektywa obejmuje szkody wyrządzone osobom fizycznym przez produkty wadliwe.

Odszkodowanie może dotyczyć w szczególności:

• śmierci lub szkody na osobie;
• medycznie potwierdzonej szkody na zdrowiu psychicznym;
• uszkodzenia lub zniszczenia określonego mienia;
• zniszczenia albo uszkodzenia danych niewykorzystywanych do celów zawodowych;
• wynikających z tych szkód uszczerbków niemajątkowych, jeżeli przewiduje je prawo krajowe.

Nowością jest wyraźne uwzględnienie szkody dotyczącej danych. Przykładowo wadliwe oprogramowanie może doprowadzić do trwałego zniszczenia prywatnych zdjęć, dokumentów lub innych plików należących do użytkownika.

Dyrektywa nie stanowi natomiast ogólnej podstawy do naprawienia każdej straty gospodarczej przedsiębiorstwa. Utracone przychody, przestój produkcji albo szkoda dotycząca danych zawodowych mogą wymagać dochodzenia na podstawie umowy lub innych przepisów krajowych.

Oprogramowanie open source – ważny wyjątek

Dyrektywa nie ma co do zasady zastosowania do wolnego i otwartego oprogramowania opracowanego lub dostarczonego poza działalnością handlową.

Wyjątek nie będzie jednak obejmował każdej sytuacji, w której wykorzystano kod open source.

Jeżeli przedsiębiorca integruje takie oprogramowanie z komercyjnym produktem i wprowadza go na rynek, może odpowiadać za bezpieczeństwo całego produktu. Podobnie zastosowanie dyrektywy może wchodzić w grę, gdy oprogramowanie jest udostępniane odpłatnie albo w zamian za dane osobowe wykorzystywane w celach wykraczających poza bezpieczeństwo, kompatybilność i interoperacyjność programu.

Samo wskazanie w dokumentacji, że system wykorzystuje komponent open source, nie przenosi więc automatycznie odpowiedzialności na społeczność jego twórców.

Kiedy nowe przepisy zaczną obowiązywać?

Państwa członkowskie mają wdrożyć dyrektywę do prawa krajowego i stosować nowe przepisy od 9 grudnia 2026 r.

Nowy system ma dotyczyć produktów wprowadzonych do obrotu lub oddanych do użytku od tej daty. Do produktów wprowadzonych wcześniej nadal będą stosowane zasady wynikające z dotychczasowej dyrektywy.

W Polsce wdrożenie będzie wymagało przede wszystkim zmian w Kodeksie cywilnym, który obecnie reguluje odpowiedzialność za produkt niebezpieczny. Prace nad implementacją są prowadzone przez Komisję Kodyfikacyjną Prawa Cywilnego. 22 kwietnia 2026 r. Komisja poinformowała o przyjęciu projektu implementacji dyrektywy in pleno. Ostateczny kształt polskich przepisów będzie jednak zależał od dalszego procesu legislacyjnego.

Jak powinny przygotować się firmy technologiczne?

Przedsiębiorcy nie powinni traktować nowej dyrektywy wyłącznie jako zmiany dotyczącej sporów sądowych. PLD wpływa na cały cykl życia oprogramowania.

Przygotowania powinny objąć przede wszystkim:

1. Ustalenie roli przedsiębiorcy
   Należy określić, kto jest producentem systemu, producentem komponentu, importerem, dystrybutorem albo podmiotem dokonującym modyfikacji.
2. Udokumentowanie przeznaczenia produktu
   Umowy, instrukcje i materiały marketingowe powinny jasno określać dopuszczalne zastosowania systemu oraz jego ograniczenia.
3. Prowadzenie dokumentacji testów
   Firma powinna móc wykazać testy bezpieczeństwa, walidację, ocenę ryzyka, wyniki audytów i reakcje na wykryte nieprawidłowości.
4. Kontrolę aktualizacji
   Konieczne jest określenie, kto odpowiada za przygotowanie, zatwierdzanie, wdrażanie i wycofywanie aktualizacji.
5. Monitorowanie produktu po wdrożeniu
   Należy wdrożyć procedury przyjmowania zgłoszeń, analizowania incydentów oraz reagowania na błędy i podatności.
6. Zarządzanie dostawcami komponentów
   Umowy powinny zapewniać dostęp do dokumentacji, informacji o błędach, aktualizacji, logów oraz pomocy w razie roszczeń.
7. Zabezpieczenie materiału dowodowego
   Trzeba ustalić okresy przechowywania logów, wersji modeli, dokumentacji aktualizacji oraz danych dotyczących działania systemu.
8. Weryfikację ubezpieczenia
   Polisa powinna uwzględniać odpowiedzialność za oprogramowanie, AI, szkody cybernetyczne i koszty postępowań.
9. Aktualizację umów
   Ograniczenie odpowiedzialności w umowie B2B nie zawsze zabezpieczy firmę przed roszczeniami osoby poszkodowanej wynikającymi z bezwzględnie obowiązujących przepisów odpowiedzialności produktowej.

Kod staje się częścią bezpieczeństwa produktu

Nowa dyrektywa potwierdza zmianę, która od dawna zachodzi w praktyce: bezpieczeństwo produktu nie zależy już wyłącznie od jego konstrukcji fizycznej.

Może zależeć również od:

• jakości kodu;
• danych wykorzystywanych przez system;
• sposobu uczenia modelu;
• aktualizacji;
• zabezpieczeń cybernetycznych;
• informacji przekazanych użytkownikowi;
• reakcji producenta na wykryte zagrożenia.

Dla producentów oprogramowania i systemów AI oznacza to większe ryzyko odpowiedzialności, ale również większe znaczenie dokumentacji, testów i procedur utrzymania produktu.

Błąd w kodzie nie zawsze będzie wadą produktu. Jeżeli jednak pozbawi system bezpieczeństwa, którego użytkownik miał prawo oczekiwać, może prowadzić do odpowiedzialności niezależnie od tego, czy producentowi można przypisać winę.