Odpowiedzialność za wadliwe oprogramowanie i AI: co przygotować przed grudniem 2026?

01

Fakty: od kiedy i do jakich produktów stosuje się nowe zasady?

Dyrektywa (UE) 2024/2853 zastępuje starszą dyrektywę 85/374/EWG i wymaga od państw członkowskich przyjęcia przepisów wdrażających do 9 grudnia 2026 r. Sprostowanie opublikowane w Dzienniku Urzędowym UE 7 maja 2026 r. doprecyzowało art. 2 ust. 1: nowe zasady dotyczą produktów wprowadzonych do obrotu lub oddanych do użytku po 8 grudnia 2026 r., czyli od 9 grudnia 2026 r.

Nie oznacza to automatycznej odpowiedzialności każdej firmy informatycznej. W konkretnej sprawie nadal liczą się między innymi rola podmiotu w łańcuchu, wada produktu, szkoda, związek przyczynowy, moment wprowadzenia produktu oraz ostateczne przepisy krajowe.

Materiał zweryfikowano 29 października 2026 r. Ma charakter informacyjny i procesowy, a nie indywidualnej porady prawnej. Przed decyzją dotyczącą konkretnego produktu należy sprawdzić uchwaloną polską ustawę, umowy, model dystrybucji i faktyczny zakres kontroli nad oprogramowaniem.

02

Fakty: software, AI, SaaS i chmura mieszczą się w definicji produktu

Dyrektywa wyjaśnia, że oprogramowanie jest produktem niezależnie od sposobu dostarczenia lub używania. Obejmuje to programy, aplikacje, systemy operacyjne, systemy AI oraz oprogramowanie udostępniane przez sieć, chmurę albo w modelu software-as-a-service. Dostawca lub twórca systemu AI może być traktowany jako producent.

Sama informacja, treść pliku cyfrowego i kod źródłowy jako taki nie są produktem. Inaczej może być z cyfrowym plikiem produkcyjnym zawierającym informacje funkcjonalne potrzebne do wytworzenia materialnego przedmiotu, na przykład plikiem sterującym drukiem 3D.

Wyłączenie dla wolnego i otwartego oprogramowania dotyczy rozwiązań rozwijanych lub dostarczanych poza działalnością handlową. Integracja komponentu open source z produktem komercyjnym nie daje producentowi gotowego produktu automatycznego zwolnienia z odpowiedzialności za rezultat tej integracji.

03

Fakty: wada może wiązać się z aktualizacją albo jej brakiem

Ocena wadliwości ma uwzględniać bezpieczeństwo, którego osoba może zasadnie oczekiwać, a także wymagania prawne i cyberbezpieczeństwo. Liczyć mogą się przewidywalny sposób użycia, prezentacja produktu, zdolność uczenia się po wdrożeniu, współdziałanie z innymi produktami oraz moment, w którym produkt znajdował się pod kontrolą producenta.

Dyrektywa przewiduje, że producent nie może powołać się na późniejsze powstanie wady, jeżeli wada wynika z usługi powiązanej, oprogramowania — w tym aktualizacji lub ulepszenia — braku aktualizacji bezpieczeństwa potrzebnej do zachowania bezpieczeństwa albo istotnej modyfikacji, a element pozostawał pod jego kontrolą.

Dla produktu cyfrowego premiera nie kończy więc odpowiedzialności procesowej. Ważne stają się zasady wsparcia, data zakończenia aktualizacji, obsługa podatności, kompatybilność, komunikaty dla klientów oraz dowód, dlaczego aktualizację wydano, odroczono albo uznano za zbędną.

04

Fakty: sąd może zarządzić ujawnienie dowodów i zastosować domniemania

Po przedstawieniu przez poszkodowanego faktów i dowodów wystarczających do uprawdopodobnienia roszczenia sąd może nakazać pozwanemu ujawnienie istotnych dowodów znajdujących się w jego dyspozycji. Ujawnienie ma być konieczne i proporcjonalne, a sąd powinien chronić informacje poufne i tajemnice przedsiębiorstwa.

Co do zasady poszkodowany wykazuje wadę, szkodę oraz związek przyczynowy. Dyrektywa wprowadza jednak sytuacje, w których wada lub związek mogą być domniemywane — między innymi przy niewykonaniu nakazu ujawnienia, naruszeniu obowiązkowych wymogów bezpieczeństwa, oczywistym wadliwym działaniu albo nadmiernej złożoności technicznej lub naukowej po spełnieniu warunków wskazanych w przepisach.

To kolejny powód, aby dokumentacja była zrozumiała, dostępna i powiązana z konkretną wersją. Wielki katalog logów bez właściciela, kontekstu i retencji nie jest równoznaczny z użytecznym dowodem.

05

Fakty: polski projekt UC163 nie jest jeszcze obowiązującą ustawą

W wykazie prac legislacyjnych Kancelarii Prezesa Rady Ministrów projekt UC163 przewiduje zmianę Kodeksu cywilnego i Kodeksu postępowania cywilnego w celu wdrożenia dyrektywy. Opis projektu wskazuje między innymi rozszerzenie pojęcia produktu na oprogramowanie, reguły dotyczące AI, szerszy krąg podmiotów odpowiedzialnych, ujawnianie dowodów oraz domniemania mające ograniczyć asymetrię informacyjną.

Według karty projektu jego przyjęcie przez Radę Ministrów planowano na IV kwartał 2026 r. Na dzień weryfikacji jest to plan i projekt, nie podstawa do przedstawiania finalnych polskich przepisów jako przesądzonych. Treść, numeracja i procedura mogą się zmienić w toku prac.

Przygotowanie operacyjne można rozpocząć już teraz, ponieważ porządkowanie wersji, testów, aktualizacji i dostawców poprawia jakość niezależnie od ostatecznego brzmienia ustawy. Ocenę prawną konkretnego modelu biznesowego należy pozostawić po potwierdzeniu finalnego tekstu.

06

Rekomendacja WEBee: zdefiniuj produkt, wersję i okres kontroli

Zacznij od rejestru produktów cyfrowych, a nie od ogólnej listy systemów. Dla każdego produktu określ producenta, podmioty w łańcuchu, użytkowników, zastosowanie, środowisko, model dostarczenia, komponenty oraz usługę powiązaną. Wskaż też, które elementy firma może zmieniać po wdrożeniu.

Każde wydanie powinno mieć jednoznaczny identyfikator, datę, zakres zmian, obsługiwane konfiguracje i okres wsparcia. Jeśli SaaS zmienia się bez instalacji po stronie klienta, zapis wersji produkcyjnej i historii wdrożeń jest szczególnie ważny.

• właściciel produktu i osoby zatwierdzające wydanie;
• wersja kodu, konfiguracji, modelu AI i danych referencyjnych;
• biblioteki, API, modele zewnętrzne i komponenty open source;
• usługi powiązane potrzebne do bezpiecznego działania;
• warunki wsparcia, aktualizacji i zakończenia życia produktu;
• kanał informacji o zmianach dla klienta i użytkownika.

07

Rekomendacja WEBee: zbuduj pakiet dowodowy dla każdego wydania

Pakiet dowodowy powinien pozwalać osobie spoza zespołu odtworzyć, co miało działać, co sprawdzono, jakie ryzyka znano i kto zaakceptował rezultat. Nie musi oznaczać ciężkiej biurokracji: najważniejsze jest konsekwentne połączenie wymagań, zmian, testów i decyzji.

Dla funkcji AI zapisz przeznaczenie, dane i wersję modelu, scenariusze testowe, wyniki, znane ograniczenia, nadzór człowieka oraz zachowanie po przekroczeniu granic jakości. Samo stwierdzenie, że model jest usługą zewnętrzną, nie wyjaśnia jakości całego produktu.

• wymagania funkcjonalne, bezpieczeństwa i prywatności;
• analiza ryzyka i scenariusze przewidywalnego niewłaściwego użycia;
• plan testów, wyniki, błędy, odstępstwa i decyzja o wydaniu;
• lista komponentów, zależności i istotnych zmian dostawców;
• instrukcje, ostrzeżenia, ograniczenia i informacje dla użytkownika;
• plan wdrożenia, monitorowania, wycofania i odtworzenia wersji.

08

Rekomendacja WEBee: połącz podatności, aktualizacje i komunikację

Ustal jedno wejście dla zgłoszeń podatności, błędów i incydentów. Każde zgłoszenie powinno uzyskać właściciela, ocenę wpływu, decyzję, termin oraz powiązanie z wydaniem. Rejestruj zarówno wydane poprawki, jak i uzasadnione decyzje o ich niewydaniu.

Określ, jak firma informuje klientów o aktualizacji bezpieczeństwa, wymaganej czynności i skutkach braku instalacji. Dla SaaS zapisz moment wdrożenia, zakres użytkowników, monitorowanie po zmianie i możliwość bezpiecznego wycofania. Dla instalacji lokalnej kontroluj także to, czy i jak klient może pobrać poprawkę.

09

Rekomendacja WEBee: kontroluj dostawców, open source i modele AI

Dla kluczowych komponentów przechowuj źródło, wersję, licencję, warunki wsparcia, historię zmian i kontakt do dostawcy. Umowa powinna pomagać uzyskać informacje potrzebne do analizy wady, poprawki i incydentu, ale nie zastąpi testów integracyjnych po stronie producenta gotowego produktu.

Zmiana modelu AI, biblioteki, API lub parametru może zmienić zachowanie całej aplikacji. Wprowadź ocenę zmiany, regresję, akceptację i możliwość powrotu. Nie zakładaj, że komponent open source albo zewnętrzna usługa automatycznie przenosi odpowiedzialność poza firmę.

10

Plan przygotowania w 60 dni

W pierwszych dwóch tygodniach utwórz rejestr produktów i wskaż właścicieli. W tygodniach 3–4 wybierz jeden produkt o wysokim wpływie i odtwórz pakiet dowodowy ostatniego wydania. W tygodniach 5–6 uporządkuj aktualizacje, podatności i dostawców. Ostatnie dwa tygodnie przeznacz na próbę: od zgłoszenia wady przez zabezpieczenie danych do decyzji i komunikacji.

WEBee może pomóc zmapować cykl życia produktu, ułożyć rejestr wersji i zależności, zaprojektować ścieżkę akceptacji, testów i aktualizacji oraz połączyć dane z repozytorium, systemu zgłoszeń i monitoringu. Celem jest sprawny i mierzalny proces jakości — nie automatyczne wydanie opinii prawnej.

• wybierz właściciela procesu i zastępstwo;
• ustal minimalny pakiet dowodowy i retencję;
• przetestuj odtworzenie wersji z konkretnego dnia;
• sprawdź źródła komponentów i warunki wsparcia;
• przeprowadź próbę obsługi wady i zabezpieczenia dowodów;
• zaplanuj ponowną ocenę po uchwaleniu polskiej ustawy.