Spis treści
- adw. TOMASZ SOWA, LL.M.
- +48 22 243 34 75
- kancelaria@sowaip.pl
Przez dziesięciolecia odpowiedzialność za produkt niebezpieczny kojarzyła się z fizycznymi wadami: hamulcami w samochodzie, przegrzewającą się baterią czy wadliwym sprzętem medycznym. Oprogramowanie traktowano jako „usługę”, co dawało producentom software’u szerokie pole do wyłączania odpowiedzialności w kontraktach. Ten świat właśnie się zmienia. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2024/2853 z dnia 23 października 2024 r. (PLD – Product Liability Directive) wywraca stolik, stawiając znak równości między fizycznym produktem a oprogramowaniem.
Kluczowe zmiany: Co musisz wiedzieć na start?
Zanim przejdziemy do szczegółów, oto trzy najważniejsze filary nowej regulacji:
- Software to oficjalnie „produkt” – niezależnie od tego, czy jest na dysku, w chmurze (SaaS), czy napędza robota przemysłowego.
- Utrata danych to szkoda – uszkodzenie lub utrata plików prywatnych daje prawo do odszkodowania na równi ze zniszczeniem mienia.
- Ułatwienia dla poszkodowanych – w skomplikowanych sprawach AI to producent będzie musiał udowadniać, że jego system był bezpieczny, a nie ofiara, że był wadliwy.
Software przestaje być wyłącznie usługą
Zgodnie z art. 4 nowej dyrektywy, definicja produktu obejmuje teraz oprogramowanie i systemy sztucznej inteligencji. Przykładem mogą być systemy nawigacji w samochodach, systemy CRM, ERP, asystenci głosowi czy zdalne aktualizacje urządzeń IoT (fizyczne przedmioty wyposażone w czujniki, oprogramowanie i moduły łączności, które zbierają, wymieniają dane i łączą się z Internetem).
Fundamentalne zmiany:
- Aktualizacje i poprawki: Producent odpowiada za wadliwość wynikającą z późniejszych aktualizacji lub ich braku (jeśli były niezbędne do bezpieczeństwa).
- Systemy SaaS i Cloud: Rozwiązania chmurowe, które sterują funkcjami urządzeń lub przetwarzają dane, wchodzą w reżim odpowiedzialności za produkt.
- Wyłączenie Open Source: Dobra wiadomość dla społeczności – oprogramowanie rozwijane niekomercyjnie pozostaje poza zakresem PLD (chyba że staje się elementem płatnego produktu).
PLD a AI Act – dwie strony tego samego medalu
Warto pamiętać, że Dyrektywa PLD działa w tandemie z Aktem o Sztucznej Inteligencji (AI Act). Podczas gdy AI Act określa wymogi techniczne i administracyjne (co musisz zrobić, by wejść na rynek), Dyrektywa PLD określa, kto i ile zapłaci, gdy system AI wyrządzi komuś szkodę.
Kiedy software zostanie uznany za „wadliwy”?
Wadliwość w świecie IT nie oznacza już tylko „buga”. Sąd przy ocenie bezpieczeństwa weźmie pod uwagę:
- Możliwość samouczenia się AI: Czy producent przewidział, jak model może ewoluować?
- Cyberbezpieczeństwo: Czy brak poprawki (patcha) naraził użytkownika na atak?
- Interoperacyjność: Czy błąd wynika z interakcji z innymi systemami, które producent powinien był przewidzieć?
Zmiana filozofii: produkt jest bezpieczny tylko wtedy, gdy producent zarządza jego cyklem życia (aktualizacje, interakcje, uczenie się) także po tym, jak klient go kupił. Jeśli producent traci kontrolę nad tymi elementami, prawo uznaje, że dostarczył produkt wadliwy
Uwaga: Ocena będzie dokonywana z perspektywy uzasadnionych oczekiwań użytkownika, a nie tylko suchych zapisów w dokumentacji technicznej czy pliku README.
Nowa kategoria szkody: Utrata danych
To rewolucja dla dostawców usług cyfrowych. Nowa dyrektywa wprost przewiduje możliwość dochodzenia odszkodowania za utratę lub uszkodzenie danych, o ile nie są one wykorzystywane wyłącznie do celów zawodowych.
Przykład: Jeśli błąd w aplikacji chmurowej doprowadzi do bezpowrotnego usunięcia bazy prywatnych zdjęć użytkownika, producent może zostać pociągnięty do odpowiedzialności odszkodowawczej w ramach reżimu produktu niebezpiecznego.
Rewolucja procesowa: Odwrócenie ciężaru dowodu
Dla prawników i działów compliance to najtrudniejszy orzech do zgryzienia. Dyrektywa wprowadza mechanizmy ułatwiające wygranie sprawy przez konsumenta:
- Obowiązek ujawnienia dowodów (Disclosure): Sąd może nakazać producentowi wydanie wewnętrznej dokumentacji technicznej, jeśli powód uprawdopodobni swoje roszczenie.
- Domniemanie wadliwości: Jeśli produkt jest wysoce złożony (np. zaawansowany model LLM), a powód wykaże szkodę, sąd może przyjąć domniemanie, że produkt był wadliwy. To producent będzie musiał udowodnić swoją niewinność.
Kalendarz wdrożeń: Zostało niewiele czasu
Dyrektywa weszła w życie 9 grudnia 2024 r., natomiast państwa członkowskie mają obowiązek wdrożyć jej postanowienia do 9 grudnia 2026 r. Jednocześnie uchylona zostanie dotychczasowa dyrektywa 85/374/EWG, która przez niemal cztery dekady stanowiła podstawę odpowiedzialności za produkt niebezpieczny w Unii Europejskiej. Nowe przepisy będą stosowane do produktów wprowadzonych do obrotu po dacie implementacji krajowej. Oznacza to, że firmy technologiczne mają relatywnie krótki czas na dostosowanie procedur projektowych i dokumentacyjnych do nowych wymogów.
Jak przygotować firmę? Checklista dla Zarządów i działów IT
Aby zminimalizować ryzyko po grudniu 2026 roku, rekomendujemy podjęcie następujących kroków:
- Rewizja polis ubezpieczeniowych: Sprawdź, czy Twoje OC zawodowe (Professional Indemnity) pokrywa szkody na mieniu i osobie wynikające z wad oprogramowania w nowym reżimie PLD.
- Dokumentacja „by design”: Popraw procedury dokumentowania testów, procesu uczenia modeli AI i decyzji projektowych. Będą one Twoją główną linią obrony w sądzie. Ma to szczególne znaczenie dla PM’ów.
- Zarządzanie cyklem życia produktu: Opracuj strategię wsparcia bezpieczeństwa (security updates) na wiele lat po premierze – odpowiedzialność może trwać od 10 do nawet 25 lat (w przypadku szkód na osobie).
- Audyt łańcucha dostaw: Jako producent końcowy odpowiadasz za komponenty open source lub API osób trzecich wbudowane w Twoje rozwiązanie. Upewnij się, że masz nad nimi kontrolę.
Podsumowanie
Dyrektywa PLD 2024/2853 usuwa lukę w odpowiedzialności za software. Firmy, które już teraz zaczną traktować oprogramowanie z taką samą starannością jak inżynierię mechaniczną, zyskają nie tylko bezpieczeństwo prawne, ale i przewagę konkurencyjną budowaną na zaufaniu klientów.
