Oprogramowanie jako produkt wadliwy od grudnia 2026 – kiedy producent może odpowiadać za szkodę wywołaną aktualizacją albo brakiem poprawki bezpieczeństwa?

Od 9 grudnia 2026 r. spór o wadliwą aplikację, firmware, system operacyjny czy system AI nie będzie już musiał zaczynać się od pytania, czy oprogramowanie w ogóle może być „produktem”. Nowa dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/2853 w sprawie odpowiedzialności za produkty wadliwe odpowiada wprost: może. Co ważniejsze, odpowiedzialność producenta nie musi kończyć się w chwili sprzedaży urządzenia albo udostępnienia pierwszej wersji programu.

To zmiana szczególnie istotna przy produktach stale połączonych z internetem. Aktualizacja może poprawić bezpieczeństwo, ale równie dobrze może wprowadzić błąd do sterownika samochodu, zmienić zachowanie urządzenia medycznego albo otworzyć lukę w systemie inteligentnego domu. Jeszcze ciekawsza jest sytuacja odwrotna: producent zna podatność, technicznie może ją usunąć, ale nie dostarcza poprawki bezpieczeństwa. Jeżeli właśnie ta podatność doprowadzi później do szkody, argument „produkt był bezpieczny w dniu sprzedaży” może przestać wystarczać.

Granica jest jednak wyraźna. Nowe przepisy nie zamieniają każdej awarii programu w sprawę odszkodowawczą. Program, który działa wolniej po aktualizacji, zgubił ustawienia użytkownika albo stracił wygodną funkcję, nie staje się automatycznie produktem wadliwym w rozumieniu odpowiedzialności za szkodę. Wadliwość dotyczy przede wszystkim bezpieczeństwa, a poszkodowany nadal musi wykazać rzeczywistą szkodę i jej związek z produktem.

Od 9 grudnia 2026 r. software jest produktem, ale zwykły bug jeszcze nie wystarczy

Dyrektywa 2024/2853 obejmuje produkty wprowadzone do obrotu lub oddane do użytku po 8 grudnia 2026 r., czyli w praktyce od 9 grudnia 2026 r. Państwa członkowskie mają czas na wdrożenie jej do prawa krajowego do 9 grudnia 2026 r.

W Polsce zmiana będzie szczególnie widoczna, ponieważ dotychczasowy model kodeksowy odpowiedzialności za produkt niebezpieczny został zbudowany przede wszystkim wokół rzeczy materialnych. Wpisany 25 sierpnia 2026 r. do wykazu prac Rady Ministrów projekt UC163 przewiduje przebudowę regulacji Kodeksu cywilnego i Kodeksu postępowania cywilnego. Założenia obejmują wprost rozszerzenie pojęcia produktu na oprogramowanie, systemy wykorzystujące software oraz systemy sztucznej inteligencji.

Unijna definicja jest szeroka. Produktem może być między innymi:

• aplikacja mobilna,

• program komputerowy,

• system operacyjny,

• firmware urządzenia,

• system AI,

• oprogramowanie działające jako komponent urządzenia,

• program dostarczany przez sieć lub środowisko chmurowe.

Sposób dystrybucji nie przesądza sprawy. Oprogramowanie nie przestaje być produktem tylko dlatego, że użytkownik nie otrzymał go na fizycznym nośniku.

Istnieją jednak ważne wyłączenia. Darmowe oprogramowanie open source rozwijane lub dostarczane poza działalnością handlową nie jest objęte tym reżimem. Nie oznacza to automatycznego wyłączenia każdego projektu open source. Jeżeli oprogramowanie staje się elementem działalności komercyjnej, sytuacja wymaga już osobnej oceny.

Jeszcze ważniejsze jest rozróżnienie między wadą funkcjonalną a wadą bezpieczeństwa.

Produkt będzie wadliwy, jeżeli nie zapewnia bezpieczeństwa, którego użytkownik ma prawo oczekiwać albo którego wymagają przepisy unijne lub krajowe. Przy ocenie bierze się pod uwagę nie tylko pierwotny projekt, lecz także między innymi:

• sposób prezentowania produktu i instrukcje producenta,

• rozsądnie przewidywalne użycie,

• współpracę z innymi urządzeniami i programami,

• zdolność systemu do dalszego uczenia się lub uzyskiwania nowych funkcji,

• wymagania cyberbezpieczeństwa,

• aktualizacje i późniejsze modyfikacje,

• czas, przez jaki produkt pozostaje pod kontrolą producenta.

To oznacza, że sam fakt wydania nowszej, lepszej wersji programu nie dowodzi wadliwości starej wersji. Podobnie sama publikacja aktualizacji bezpieczeństwa nie jest automatycznym przyznaniem: „poprzednia wersja była wadliwa”.

Praktyczna granica wygląda tak: aktualizacja aplikacji, która przesuwa przycisk albo zwiększa zużycie baterii, może być kiepskim produktem, ale nie musi tworzyć odpowiedzialności za produkt wadliwy. Inaczej, gdy ta sama aktualizacja powoduje, że elektroniczny zamek otwiera drzwi bez prawidłowego uwierzytelnienia albo urządzenie medyczne zaczyna podawać nieprawidłową dawkę leku.

Aktualizacja może stworzyć wadę już po sprzedaży i producent nadal może za nią odpowiadać

Stary, wygodny model obrony producenta można było sprowadzić do zdania: „gdy produkt opuszczał fabrykę albo trafiał na rynek, był bezpieczny”. Przy produktach cyfrowych takie podejście przestało odpowiadać rzeczywistości.

Nowa regulacja wprowadza pojęcie kontroli producenta. Producent może odpowiadać również za wadliwość powstałą później, jeśli jej źródłem jest software pozostający pod jego kontrolą. Dotyczy to między innymi aktualizacji i upgrade’ów.

Kontrola nie oznacza wyłącznie sytuacji, w której producent własnymi pracownikami pisze kod i sam wysyła paczkę aktualizacyjną. Może istnieć również wtedy, gdy:

• producent dostarcza aktualizację przez podmiot zewnętrzny,

• zezwala stronie trzeciej na dostarczanie komponentu lub aktualizacji,

• przedstawia zewnętrzną usługę jako element swojego produktu,

• ma możliwość zapewnienia aktualizacji samodzielnie albo za pomocą innego podmiotu.

To szczególnie istotne w samochodach, sprzęcie IoT, telewizorach, urządzeniach medycznych i systemach smart home. Produkt materialny coraz częściej jest tylko obudową dla kilku warstw oprogramowania pochodzącego od różnych dostawców.

Wyobraźmy sobie termostat sterujący ogrzewaniem. Po automatycznej aktualizacji pojawia się błąd powodujący niekontrolowane grzanie. Instalacja przegrzewa się i dochodzi do pożaru. Jeżeli aktualizacja pozostawała pod kontrolą producenta, trudno będzie obronić się samym argumentem, że urządzenie działało poprawnie dwa lata wcześniej, gdy trafiło na rynek.

Podobnie może być z aktualizacją samochodu instalowaną przez internet. Jeżeli zmiana algorytmu wpływa na funkcję bezpieczeństwa i doprowadzi do szkody na osobie, moment sprzedaży auta nie zamyka automatycznie odpowiedzialności.

Producent nie odpowiada jednak za wszystko, co użytkownik później zainstaluje. Sam fakt, że urządzenie technicznie pozwala na instalowanie programów innych firm, nie oznacza jeszcze, że każdy taki program pozostaje pod kontrolą producenta sprzętu. Znaczenie ma rzeczywista integracja, autoryzacja albo zgoda na dostarczenie komponentu, a nie samo pozostawienie technicznej możliwości instalacji.

W praktyce spór będzie więc często dotyczył nie samego kodu, lecz łańcucha decyzyjnego: kto zatwierdził aktualizację, kto kontrolował jej dystrybucję, kto mógł ją zatrzymać i kto odpowiadał za testy bezpieczeństwa.

Istotna zmiana dotyczy także dowodów. Poszkodowany nadal powinien wykazać:

1. wadliwość produktu,

2. szkodę,

3. związek przyczynowy między wadą a szkodą.

Przy systemach cyfrowych nie zawsze będzie jednak musiał samodzielnie rozgryźć tysiące linii kodu i architekturę produktu.

Nowe przepisy przewidują możliwość żądania ujawnienia przez pozwanego odpowiednich dowodów. Jeżeli przedsiębiorca nie zastosuje się do obowiązku ich ujawnienia, możliwe jest zastosowanie domniemania wadliwości produktu. Domniemania mogą pojawić się również wtedy, gdy naruszono obowiązkowe wymagania bezpieczeństwa albo gdy szkoda wynika z oczywistego nieprawidłowego działania produktu w zwykłych warunkach.

Szczególnie istotne będzie to przy oprogramowaniu i AI. Jeżeli ze względu na techniczną lub naukową złożoność sprawy udowodnienie wady albo związku przyczynowego jest nadmiernie trudne, sąd może zastosować ułatwienia dowodowe, jeżeli poszkodowany wykaże wystarczające prawdopodobieństwo swojego twierdzenia.

To realna zmiana procesowa. Do tej pory jednym z najdroższych elementów podobnego sporu mogło być ustalenie, co dokładnie wydarzyło się wewnątrz zamkniętego systemu, do którego dokumentacji użytkownik nie miał dostępu.

Brak poprawki bezpieczeństwa może być wadą, ale użytkownik też ma obowiązki

Największą praktyczną zmianą nie jest odpowiedzialność za zepsutą aktualizację. Jest nią możliwość powiązania wadliwości produktu z brakiem aktualizacji albo upgrade’u niezbędnego do utrzymania bezpieczeństwa.

Producent nie będzie mógł automatycznie uwolnić się od odpowiedzialności, twierdząc, że luka pojawiła się dopiero po sprzedaży produktu, jeżeli wada wynika z braku koniecznej aktualizacji bezpieczeństwa, a dostarczenie jej pozostawało pod jego kontrolą.

Trzeba jednak uważać na jeden ważny szczegół: dyrektywa 2024/2853 sama w sobie nie tworzy ogólnego obowiązku aktualizowania każdego produktu przez określoną liczbę lat. Reguluje odpowiedzialność za skutki wadliwego produktu. Obowiązek dostarczenia poprawki może natomiast wynikać z innych przepisów, wymagań bezpieczeństwa, zobowiązań wobec konsumenta albo regulacji właściwych dla konkretnej kategorii produktów.

Coraz większe znaczenie będzie miał tu również unijny Cyber Resilience Act, rozporządzenie (UE) 2024/2847. Jego główne wymagania dla producentów produktów z elementami cyfrowymi zaczną być stosowane 11 grudnia 2027 r. Co do zasady producent będzie musiał określić okres wsparcia odpowiadający przewidywanemu okresowi używania produktu; standardowo okres ten ma wynosić co najmniej pięć lat, chyba że przewidywany czas używania produktu jest krótszy. Sam reżim odpowiedzialności za produkt wadliwy zacznie jednak działać wcześniej.

W sprawie dotyczącej braku patcha trzeba więc sprawdzić w tej kolejności:

• czy istniała rzeczywista podatność wpływająca na bezpieczeństwo;

• kiedy producent dowiedział się albo powinien był móc ją wykryć przy ówczesnym stanie wiedzy technicznej;

• czy poprawka była technicznie możliwa;

• czy dostarczenie aktualizacji pozostawało pod kontrolą producenta;

• czy inne przepisy wymagały utrzymania określonego poziomu bezpieczeństwa;

• czy właśnie ta podatność doprowadziła do szkody.

Producent nadal dysponuje mechanizmami obrony. Może na przykład wykazywać, że obiektywny stan wiedzy naukowej i technicznej w czasie, gdy produkt znajdował się pod jego kontrolą, nie pozwalał wykryć wady.

Jest też drugi przypadek, o którym użytkownicy łatwo zapominają. Producent przygotował poprawkę, jasno oznaczył ją jako aktualizację bezpieczeństwa i umożliwił jej instalację, ale właściciel przez kilka miesięcy ignorował komunikaty. Następnie dokładnie ta podatność została wykorzystana.

W takiej sytuacji pozycja poszkodowanego wyraźnie słabnie. Jeżeli jego własne zaniedbanie przyczyniło się do szkody, odpowiedzialność przedsiębiorcy może zostać odpowiednio zmniejszona, a w określonych warunkach nawet wyłączona.

Nie oznacza to jednak, że każdy brak aktualizacji automatycznie obciąża użytkownika. Producent powinien być w stanie wykazać, że poprawka rzeczywiście została udostępniona, była przeznaczona dla konkretnego produktu, można ją było poprawnie zainstalować i miała usunąć zagrożenie.

W praktyce duże znaczenie będą miały logi dystrybucji, numery wersji, daty publikacji, komunikaty bezpieczeństwa, polityka wsparcia oraz informacje o urządzeniach, do których patch faktycznie dotarł.

Trzeba również odróżnić odpowiedzialność za produkt wadliwy od reklamacji samego programu.

Jeżeli aktualizacja „ucegli” smartfon i jedyną szkodą jest uszkodzenie właśnie tego wadliwego urządzenia, nowy reżim odpowiedzialności za produkt wadliwy nie jest oczywistą drogą do odzyskania ceny telefonu. Uszkodzenie samego wadliwego produktu jest wyłączone z katalogu szkód objętych dyrektywą. Nadal mogą natomiast działać prawa konsumenckie, odpowiedzialność kontraktowa i inne przepisy krajowe.

Inaczej, gdy wadliwa aktualizacja telefonu usuwa prywatne zdjęcia, których odzyskanie wymaga płatnej usługi specjalistycznej. Dyrektywa obejmuje zniszczenie lub uszkodzenie danych nieużywanych zawodowo, a koszt ich odzyskania może stanowić rzeczywistą stratę.

Jeżeli jednak skasowana została baza klientów przedsiębiorcy albo kod projektu zawodowego, ten konkretny reżim jest znacznie mniej użyteczny. Dane wykorzystywane zawodowo zostały wyłączone. Podobnie sama utrata przychodu z powodu kilkugodzinnego przestoju programu, bez innej objętej dyrektywą szkody, nie staje się automatycznie szkodą produktową. Trzeba wtedy badać przede wszystkim umowę, SLA, odpowiedzialność kontraktową i pozostałe podstawy odszkodowawcze.

Ten podział będzie w praktyce irytujący. Ten sam błąd synchronizacji może usunąć prywatne zdjęcia i pliki firmowe z jednego dysku, ale oba rodzaje danych mogą podlegać innemu reżimowi odpowiedzialności.

Sama kradzież danych również nie jest tym samym co ich zniszczenie lub uszkodzenie. Naruszenia prywatności i wycieki danych nadal trzeba analizować między innymi na gruncie RODO.

Znaczenie ma też działanie cyberprzestępcy. Jeżeli atakujący wykorzysta podatność, obecność osoby trzeciej w łańcuchu zdarzeń nie powinna sama przez się uwolnić producenta od odpowiedzialności, gdy produkt był wadliwy i właśnie ta wada umożliwiła powstanie szkody.

FAQ

Czy producent będzie odpowiadał za każdy błąd w aplikacji?
Nie. Reżim produktu wadliwego dotyczy przede wszystkim bezpieczeństwa. Błąd kosmetyczny, wolniejsze działanie czy brak wygodnej funkcji nie wystarczą bez wadliwości w rozumieniu przepisów i szkody objętej tym reżimem.

Czy wadliwa automatyczna aktualizacja może powodować odpowiedzialność producenta?
Tak. Jeżeli aktualizacja pozostawała pod kontrolą producenta, spowodowała wadliwość produktu i doprowadziła do objętej przepisami szkody, odpowiedzialność może powstać również wtedy, gdy pierwotna wersja produktu była bezpieczna.

Czy brak patcha do znanej luki bezpieczeństwa wystarczy do uzyskania odszkodowania?
Nie sam w sobie. Trzeba połączyć brak wymaganej aktualizacji z wadliwością produktu, konkretną szkodą i związkiem przyczynowym. Znaczenie ma też to, czy dostarczenie poprawki pozostawało pod kontrolą producenta.

Czy dyrektywa nakazuje producentowi aktualizować każdy program przez pięć lat?
Nie. Dyrektywa o odpowiedzialności za produkty wadliwe nie ustanawia takiego ogólnego obowiązku. Minimum pięcioletniego okresu wsparcia pojawia się co do zasady w Cyber Resilience Act, którego główne wymagania zaczną być stosowane 11 grudnia 2027 r.; dla produktów o przewidywanym okresie używania krótszym niż pięć lat okres wsparcia może odpowiadać temu krótszemu czasowi.

Co jeśli użytkownik nie zainstalował dostępnej poprawki bezpieczeństwa?
Jeżeli brak instalacji przyczynił się do szkody, odszkodowanie może zostać zmniejszone, a w odpowiednich okolicznościach odpowiedzialność może zostać wyłączona. Producent musi jednak móc wykazać, że odpowiednia poprawka rzeczywiście była dostępna.

Czy można dochodzić odszkodowania za utracone dane?
Tak, gdy doszło do zniszczenia lub uszkodzenia danych nieużywanych zawodowo i powstała rzeczywista strata, na przykład koszt ich odzyskania. Dane zawodowe są z tego konkretnego reżimu wyłączone.

Czy za wadliwy system AI odpowiada sam algorytm?
Nie. System AI nie jest podmiotem odpowiedzialności. Producentem może być podmiot rozwijający lub produkujący software, a w zależności od łańcucha dostaw odpowiedzialność może dotyczyć również producenta komponentu oraz innych podmiotów wskazanych w przepisach.

Jak długo można dochodzić roszczenia?
Dyrektywa przewiduje zasadniczo 3 lata od chwili, gdy poszkodowany dowiedział się albo powinien był dowiedzieć się o szkodzie, wadliwości i tożsamości podmiotu mogącego odpowiadać. Co do zasady prawo do odszkodowania wygasa po 10 latach od wprowadzenia wadliwego produktu do obrotu lub oddania go do użytku. Przy wolno ujawniających się szkodach na osobie graniczny okres może wynieść 25 lat.

Czy producent może wyłączyć tę odpowiedzialność w regulaminie aplikacji?
Nie można skutecznie wyłączyć odpowiedzialności przewidzianej tym reżimem prostym zapisem typu „użytkownik korzysta na własne ryzyko”. Dyrektywa zakłada, że odpowiedzialność wobec poszkodowanego nie może zostać umownie ograniczona ani wyłączona.

Pierwszy krok po szkodzie powinien być techniczny, nie prawniczy: zabezpiecz wersję oprogramowania, dokładną datę aktualizacji, logi urządzenia, komunikaty producenta i informację o dostępnych patchach. Nie aktualizuj ponownie urządzenia i nie przywracaj go od razu do ustawień fabrycznych, jeżeli grozi to skasowaniem dowodów. Dopiero potem ustal, czy szkoda dotyczy osoby, innego mienia lub prywatnych danych i czy przyczyną był błąd aktualizacji, znana podatność albo brak poprawki. Najgorszy błąd to rozpoczęcie sporu od ogólnego stwierdzenia „program był wadliwy” bez zachowania informacji pozwalających wskazać konkretną wersję, podatność i moment powstania szkody.

Więcej informacji na: https://takieprawo.pl