Od 9 grudnia oprogramowanie jest produktem. Jeśli dotrenowaliście cudzy model i wypuściliście go dalej, jesteście jego producentem — bez winy, bez progu i bez limitu kwotowego

Dlaczego ten termin jest inny niż wszystkie poprzednie

Ostatnie dwa lata przyzwyczaiły firmy do kalendarza, w którym co kilka miesięcy wchodzi nowy obowiązek dokumentacyjny: polityka, rejestr, szkolenie, oznaczenie, zgłoszenie. 9 grudnia nie jest kolejnym punktem z tej listy, bo nie dodaje obowiązku, który można odhaczyć. Zmienia podstawę, na której ktoś może pozwać Waszą firmę o odszkodowanie — i robi to w obszarze, w którym do tej pory czuliście się bezpiecznie, bo sprzedawaliście „oprogramowanie”, a nie „produkt”.

Różnica jest praktyczna. Obowiązek administracyjny ma termin, formularz i organ, który go sprawdza. Odpowiedzialność cywilna nie ma terminu — ujawnia się wtedy, gdy coś się komuś stanie, czyli w momencie, którego nie planujecie. Pojawia się za rok albo za osiem lat, w postępowaniu, w którym zapytają Was o dokumenty sprzed trzech wersji modelu. To dlatego przygotowanie do tej daty polega przede wszystkim na porządkowaniu dokumentacji i umów, a nie na wysłaniu zgłoszenia.

Skala jest przy tym większa, niż sugerują rozmowy o „wdrożeniach AI” jako o czymś rzadkim. GUS opublikował 21 października 2026 roku dane, z których wynika, że sztuczną inteligencję wykorzystuje 17,8% przedsiębiorstw w Polsce — o 9,1 punktu procentowego więcej niż rok wcześniej, czyli w ciągu dwunastu miesięcy odsetek się podwoił. Najczęściej w marketingu i sprzedaży (11,1% firm) oraz w pracach biurowych i procesach zarządczych związanych z podejmowaniem decyzji (9,6%). Istotne jest tempo: większość tych wdrożeń powstała w ostatnich kilkunastu miesiącach, więc była projektowana wtedy, gdy nikt nie zakładał, że efekt końcowy będzie oceniany miarką odpowiedzialności za produkt.

Co dziś mówi polskie prawo — i dlaczego branża IT mogła je ignorować

Warto zacząć od stanu obecnego, bo bez niego nie widać rozmiaru zmiany. Odpowiedzialność za produkt niebezpieczny jest w Polsce uregulowana w art. 449(1)–449(10) Kodeksu cywilnego i opiera się na czterech filarach, z których każdy w grudniu albo zniknie, albo przestanie Was chronić.

Pierwszy: definicja. Produktem jest rzecz ruchoma, choćby została połączona z inną rzeczą, a także zwierzęta i energia elektryczna. Program nie mieści się w tej definicji, chyba że jest wbudowany w urządzenie i oceniany łącznie z nim. Drugi: szkoda na mieniu. Producent odpowiada za nią tylko wtedy, gdy zniszczona rzecz jest zwykle przeznaczona do osobistego użytku, a poszkodowany korzystał z niej przede wszystkim w ten sposób. Trzeci: próg. Zgodnie z art. 449(7) § 2 odszkodowanie za szkodę na mieniu nie przysługuje, jeśli szkoda nie przekracza równowartości 500 euro — co w praktyce odcina drobne sprawy. Czwarty: przedawnienie — trzy lata od dowiedzenia się o szkodzie i osobie zobowiązanej, nie dłużej niż dziesięć lat od wprowadzenia do obrotu.

Dwie rzeczy z dzisiejszego stanu prawnego zostają i warto o nich pamiętać, bo bywają mylone z nowością. Odpowiedzialność jest niezależna od winy — nie trzeba wykazywać niedbalstwa producenta, wystarczy wada, szkoda i związek przyczynowy. I nie można jej wyłączyć ani ograniczyć umownie: art. 449(9) mówi to wprost. Oba te przepisy istnieją od lat; nowe jest to, że od grudnia zaczną dotyczyć oprogramowania.

Zastrzeżenie, które trzeba postawić raz i wyraźnie: to jest tekst o konsekwencjach operacyjnych i o tym, co warto przygotować we własnej firmie, a nie porada prawna. Ocena konkretnego produktu, umowy i roli w łańcuchu dostaw wymaga prawnika, który zobaczy dokumenty.

Nowa definicja produktu: co wchodzi, a co zostaje poza

Dyrektywa 2024/2853 przyjmuje definicję, w której sposób dostarczenia nie ma znaczenia. Produktem jest oprogramowanie zapisane na urządzeniu, pobrane przez sieć, działające w chmurze i udostępniane w modelu abonamentowym. Obejmuje to systemy operacyjne, aplikacje, firmware, systemy sztucznej inteligencji oraz cyfrowe pliki produkcyjne — na przykład projekt przeznaczony do wydruku 3D albo do sterowania maszyną. Produktem jest też energia elektryczna i surowce.

Rozszerzenie idzie dalej i to jest fragment, który najczęściej umyka. Usługa powiązana, bez której produkt nie wykonywałby przynajmniej jednej ze swoich funkcji, jest traktowana jako jego część. Czujnik, który sam nie podejmuje decyzji, bo klasyfikacja dzieje się w Waszym API, nie jest urządzeniem z osobną usługą — jest jednym produktem, za który odpowiadacie łącznie. Ta sama logika obejmuje maszynę, która bez połączenia z serwerem nie uruchomi trybu automatycznego, i aplikację mobilną, która bez modelu w chmurze jest pustym ekranem.

Poza zakresem zostaje mniej, niż część firm zakłada. Sama informacja — treść, e-book, plik medialny, kod źródłowy jako taki — nie jest automatycznie produktem. Wolne i otwarte oprogramowanie rozwijane lub dostarczane poza działalnością gospodarczą jest wyłączone, a publikacja w otwartym repozytorium nie jest sama z siebie wprowadzeniem do obrotu. Tylko że to wyłączenie przestaje działać dokładnie w tym momencie, w którym staje się dla firmy interesujące: jeżeli komponent open source zostaje wbudowany w produkt wprowadzany do obrotu w ramach działalności gospodarczej, odpowiada ten, kto ten produkt wprowadza. Wymienienie biblioteki w pliku z licencjami nie przenosi odpowiedzialności na jej autorów.

Dla firm pracujących na modelach o otwartych wagach wniosek jest prosty i niewygodny: fakt, że model jest darmowy i czyjś, nie zmienia tego, kto odpowiada za produkt, w którym ten model pracuje. Kiedy on-premise ma sens, a kiedy nie, rozpisaliśmy osobno w tekście o lokalnym modelu AI w firmie — ten rachunek od grudnia zyskuje dodatkową pozycję po stronie kosztów.

Istotna modyfikacja, czyli przepis dla integratorów

Najważniejszy przepis tej dyrektywy dla polskiego rynku wdrożeń nie dotyczy twórców modeli. Dotyczy firm, które biorą cudze oprogramowanie, przerabiają je i wypuszczają dalej — a to jest opis większości wdrożeń AI realizowanych dziś w Europie.

Konstrukcja jest następująca. Kto istotnie modyfikuje produkt poza kontrolą jego pierwotnego producenta i następnie udostępnia go na rynku albo oddaje do użytku, jest traktowany jako producent produktu zmodyfikowanego. Czy modyfikacja jest istotna, ocenia się najpierw według przepisów o bezpieczeństwie produktów. Gdy te nie dają progu, modyfikacja jest istotna wtedy, gdy zmienia działanie, przeznaczenie albo rodzaj produktu w sposób nieprzewidziany w pierwotnej ocenie ryzyka i jednocześnie zmienia lub zwiększa charakter zagrożenia.

Przełóżmy to na rzeczy, które robi się w projektach wdrożeniowych. Dotrenowanie modelu na własnych danych i udostępnienie go klientom. Zmiana przeznaczenia — narzędzie opisane przez dostawcę jako wsparcie redakcyjne zostaje wpięte w proces, w którym wpływa na decyzje dotyczące zdrowia, pieniędzy albo bezpieczeństwa. Obejście albo wyłączenie mechanizmów zabezpieczających, w tym filtrów treści i ograniczeń odpowiedzi. Zintegrowanie oprogramowania z nowym sprzętem, którego producent nie przewidywał. Każda z tych czynności może sprawić, że z integratora stajecie się producentem, a dostawca modelu przestaje być pierwszym adresatem roszczenia.

Po drugiej stronie jest granica, która chroni zwykłe wdrożenia: korzystanie z ustawień i konfiguracji przewidzianych przez producenta nie powinno samo z siebie czynić Was producentem. Zmiana temperatury, własny prompt systemowy w zakresie, w jakim narzędzie to przewiduje, podłączenie własnej bazy wiedzy przez udokumentowany mechanizm — to jest używanie produktu zgodnie z jego przeznaczeniem. Problem polega na tym, że granica między „konfiguracją” a „modyfikacją” w projektach AI jest cienka i prawie nigdy nie jest zapisana. Dlatego najtańsza rzecz, jaką możecie zrobić w listopadzie, to spisać dla każdego wdrożenia, co dokładnie zmieniliście wobec tego, co dał dostawca, i na jakiej podstawie w jego dokumentacji.

Jest jeszcze konsekwencja, która zaskakuje nawet firmy przygotowane: istotna modyfikacja — w tym wynikająca z istotnej aktualizacji oprogramowania — jest traktowana jak wprowadzenie produktu do obrotu w momencie jej dokonania. Dziesięcioletni termin biegnie wtedy od nowa. Produkt utrzymywany w ciągłym rozwoju nigdy nie „wychodzi” z okresu odpowiedzialności, bo każda duża aktualizacja resetuje zegar.

Czego dyrektywa nie da Wam, jeśli to Wasza firma jest poszkodowana

Tu trzeba odwrócić perspektywę, bo wiele firm czyta te przepisy z nadzieją, że wreszcie będzie jak dochodzić szkód od dostawcy AI, który obiecał za wiele. Nie będzie. Dyrektywa jest instrumentem ochrony osób fizycznych i jej zakres szkody jest wąsko zakrojony.

Naprawieniu podlega śmierć i uszkodzenie ciała, w tym medycznie potwierdzona szkoda na zdrowiu psychicznym, szkoda na mieniu — z wyłączeniem samego wadliwego produktu oraz mienia wykorzystywanego wyłącznie do celów zawodowych — oraz nowa kategoria: zniszczenie lub utrata danych, które nie są wykorzystywane do celów zawodowych, wraz z rozsądnymi kosztami ich odzyskania. Poza zakresem pozostaje czysta szkoda majątkowa: utracone korzyści, przestój linii, koszt ponownego wykonania pracy, kara umowna zapłacona Waszemu klientowi, utrata kontraktu.

Praktyczny wniosek jest jednoznaczny: jako firma nie dostaniecie z tego reżimu nic. Jeśli model podał błędną liczbę, agent wysłał złą ofertę, a integracja wywaliła produkcję na cztery godziny, Waszym jedynym narzędziem jest umowa — poziomy usługi, limity odpowiedzialności, procedura reklamacyjna, prawo wyjścia. Jak taką umowę napisać i o co pytać dostawcę, zanim coś podpiszecie, rozpisaliśmy w tekście o umowie z dostawcą AI. Grudniowa zmiana nie poprawia Waszej pozycji w tej rozmowie ani o jotę — poprawia pozycję osoby fizycznej, która zostanie poszkodowana przez to, co sprzedaliście.

Druga strona tej asymetrii jest tym, co trzeba przeliczyć na ryzyko. Znika próg 500 euro dla szkody na mieniu. Znika możliwość wprowadzenia górnego limitu odpowiedzialności za śmierć i uszkodzenie ciała, która w starym reżimie pozwalała państwom ustalić pułap nie niższy niż 70 mln euro. Wyłączenie dotyczy tylko mienia używanego wyłącznie zawodowo, więc laptop albo samochód używany służbowo i prywatnie pozostaje w zakresie. Roszczenie może dochodzić nie tylko poszkodowany, ale też ubezpieczyciel wstąpiwszy w jego prawa oraz podmioty działające na rzecz grupy poszkodowanych w ramach powództw przedstawicielskich — czyli ten sam mechanizm, który w innych obszarach zamienia wiele małych spraw w jedną dużą.

Domniemania i ujawnienie dowodów: koniec obrony „to czarna skrzynka”

Największa zmiana nie jest w definicji produktu, tylko w rozkładzie ciężaru dowodu. Dotychczas poszkodowany musiał wykazać wadę, szkodę i związek przyczynowy. Przy systemie opartym na modelu uczonym maszynowo było to zadanie w praktyce niewykonalne — i to właśnie była cicha ochrona branży. Dyrektywa likwiduje ją dwoma narzędziami.

Pierwsze to sądowy obowiązek ujawnienia dowodów. Jeżeli powód przedstawi fakty i dowody wystarczające do uprawdopodobnienia roszczenia, sąd może zobowiązać pozwanego do ujawnienia dowodów, którymi ten dysponuje — w formie przystępnej i zrozumiałej. W sprawach dotyczących AI chodzi o konkretny zestaw: logi systemowe, dokumentację walidacji modelu, informacje o danych treningowych, analizę ryzyka, dokumentację cyberbezpieczeństwa, historię wersji i aktualizacji, dane o działaniu algorytmu. Nakaz musi być konieczny i proporcjonalny, a sąd ma obowiązek chronić tajemnicę przedsiębiorstwa i informacje poufne — ale punktem wyjścia jest założenie, że ta dokumentacja istnieje i da się ją pokazać.

Drugie to domniemania. Wadliwość można domniemywać, gdy pozwany nie wykona nakazu ujawnienia, gdy produkt nie spełnia obowiązkowych wymogów bezpieczeństwa chroniących przed danym rodzajem szkody albo gdy szkoda wynikła z oczywistej nieprawidłowości działania przy normalnym użyciu. Dodatkowo — i to jest przepis napisany wprost z myślą o takich systemach jak Wasze — gdy złożoność techniczna lub naukowa sprawia, że wykazanie wady albo związku przyczynowego byłoby dla poszkodowanego nadmiernie trudne, wystarczy uprawdopodobnienie, a sąd może domniemywać jedno albo drugie. Domniemania są wzruszalne, ale ciężar ich wzruszenia leży po Waszej stronie.

Konsekwencja operacyjna jest nieoczywista i warto ją nazwać wprost: od grudnia dokumentacja techniczna przestaje być kosztem zgodności, a zaczyna być materiałem dowodowym. Zestaw testowy, wyniki walidacji, wersjonowanie modelu i promptów, zapis tego, kto i kiedy co zmienił — to są rzeczy, których brak nie będzie neutralny. Będzie podstawą domniemania przeciw Wam. Jak zbudować taki zestaw i jakie progi akceptacji ma sens ustalać, opisaliśmy w tekście o testowaniu wdrożenia AI; to samo dotyczy logów i monitoringu z tekstu o utrzymaniu AI po wdrożeniu. Oba te artykuły pisaliśmy o jakości. Teraz mają drugie uzasadnienie.

Brak aktualizacji bezpieczeństwa jest wadą produktu

Dyrektywa po raz pierwszy wiąże bezpieczeństwo produktu z cyberbezpieczeństwem w sposób, który tworzy odpowiedzialność odszkodowawczą. Luka w zabezpieczeniach może czynić produkt wadliwym. Odpowiedzialność może też powstać wtedy, gdy producent nie dostarczył aktualizacji potrzebnej do usunięcia znanej podatności — czyli zaniechanie po wprowadzeniu do obrotu jest samodzielną podstawą.

To jest zmiana sposobu myślenia o cyklu życia wdrożenia. Dotychczas „wdrożone i działa” oznaczało koniec projektu. Teraz oznacza początek okresu, w którym trzeba obserwować podatności w komponentach, które wzięliście od innych, i reagować na nie. Przy stosie AI ta lista jest dłuższa, niż większość firm sobie wyobraża: biblioteka do osadzeń, baza wektorowa, serwer pośredniczący, framework agentowy, wtyczka do przeglądarki, SDK dostawcy modelu.

Nie jest to przy tym obowiązek, który pojawia się w izolacji. Akt o cyberodporności nałożył na producentów produktów z elementami cyfrowymi obowiązki raportowe już od 11 września 2026 roku: wczesne ostrzeżenie w 24 godziny, raport w 72 godziny, raport końcowy w 14 dni dla aktywnie wykorzystywanych podatności i poważnych incydentów. Pełne stosowanie przychodzi 11 grudnia 2027 roku i obejmuje wymóg wsparcia produktu przez okres przewidywanej eksploatacji, nie krótszy niż pięć lat, z karami do 15 mln euro albo 2,5% światowego obrotu za naruszenie wymogów zasadniczych. Zbieżność tych reżimów jest wygodna w jedną stronę: proces zarządzania podatnościami, który budujecie pod akt o cyberodporności, jest tym samym procesem, który od grudnia zdejmuje z Was ryzyko odszkodowawcze.

Osobnym tematem jest klasa podatności, której w tej dyskusji prawie nikt nie uwzględnia, bo nie wygląda jak błąd w kodzie. Agent, który czyta maile, faktury i strony, nie odróżnia polecenia od treści — i to jest cecha architektury, nie usterka jednej wersji. Jeżeli Wasz produkt pozwala, by tekst z zewnątrz wydał mu polecenie z dostępem do danych klienta, jest to podatność w rozumieniu, które właśnie zyskało skutki cywilnoprawne. Opisaliśmy ten mechanizm i obrony przed nim w tekstach o prompt injection oraz o obowiązkach z NIS2 i ustawy o krajowym systemie cyberbezpieczeństwa.

Model, który zmienia się po wdrożeniu

Klasyczna obrona producenta brzmiała: w chwili wprowadzenia do obrotu produkt był bezpieczny, a wada ujawniła się później. Przy oprogramowaniu i modelach uczących się ta obrona została wyraźnie zawężona. Przy ocenie wadliwości uwzględnia się zdolność produktu do dalszego uczenia się i nabywania nowych cech po wprowadzeniu do obrotu, a także to, że producent zachowuje nad produktem kontrolę — przez aktualizacje, zmiany parametrów i usługi powiązane. Jeżeli wada wynika z czegoś, co pozostawało pod Waszą kontrolą, powoływanie się na to, że „wtedy działało”, nie pomoże.

Obrona oparta na ryzyku rozwoju zostaje w systemie: można wykazywać, że obiektywny stan wiedzy naukowej i technicznej nie pozwalał wykryć wady. Ale mierzy się ją najbardziej zaawansowaną dostępną wiedzą, a nie tym, co wiedzieliście Wy — i nie obejmuje sytuacji, w których wada pochodzi z aktualizacji, z braku aktualizacji albo z usługi powiązanej, którą kontrolujecie.

To ma bezpośredni skutek na trzy decyzje projektowe, które zwykle podejmuje się bez udziału prawnika. Czy model ma się douczać na danych produkcyjnych, czy stoi na zamrożonej wersji. Czy aktualizacje wchodzą automatycznie, czy przez akceptację klienta. Czy zmiana wersji modelu u dostawcy jest u Was zdarzeniem rejestrowanym i testowanym, czy dzieje się po cichu. Każde „automatycznie i bez zapisu” jest po grudniu droższe niż było, bo zwiększa zakres rzeczy pod Waszą kontrolą, których nie umiecie udokumentować.

Jak to się spina z AI Act

Pierwotny plan Komisji Europejskiej przewidywał trzy filary: AI Act jako regulację prewencyjną, dyrektywę o odpowiedzialności za AI jako reżim roszczeniowy i nową dyrektywę produktową jako jego dopełnienie. Projekt dyrektywy o odpowiedzialności za AI został wycofany. Zostały dwa filary — i to oznacza, że rolę reżimu odszkodowawczego dla systemów AI przejmuje w praktyce dyrektywa produktowa plus krajowe prawo deliktowe.

Połączenie między nimi działa przez jedno z domniemań. Jeżeli poszkodowany wykaże, że produkt nie spełniał obowiązkowych wymogów bezpieczeństwa ustanowionych w celu ochrony przed danym rodzajem szkody, wadliwość się domniemywa. Przy systemach AI najbliższymi kandydatami są wymogi dotyczące właściwości samego produktu: dokładności, odporności i cyberbezpieczeństwa, zarządzania danymi oraz przejrzystości. Z obowiązkami proceduralnymi — systemem zarządzania ryzykiem, dokumentacją, nadzorem człowieka, monitoringiem po wprowadzeniu do obrotu — sprawa jest mniej oczywista, bo ich naruszenie niekoniecznie czyni produkt niebezpiecznym, i to jest obszar, w którym orzecznictwa jeszcze nie ma. Uczciwa wersja tej tezy brzmi więc tak: naruszenie AI Act nie przekłada się automatycznie na wadliwość, ale daje poszkodowanemu najkrótszą drogę do domniemania, a Wam obowiązek je wzruszyć.

Daty z AI Act warto trzymać obok grudniowej, bo tworzą jeden kalendarz ryzyka. Od 28 października 2026 roku Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji uzyskuje uprawnienia operacyjne: kontrole, żądanie dokumentacji, skargi, kary. Od 2 grudnia 2027 roku obowiązują wymogi dla systemów wysokiego ryzyka z załącznika III, przesunięte z pierwotnego sierpnia 2026. Niezależnie od tych przesunięć obowiązują już zakazy z artykułu 5 i obowiązek zapewnienia kompetencji AI z artykułu 4. Całość rozpisaliśmy w tekstach o AI Act w małej firmie i o RODO przy wdrożeniu AI — ten drugi reżim, przypomnijmy, obowiązuje w pełni i dotyczy Was wcześniej oraz szerzej niż cokolwiek z powyższych.

Kogo to realnie dotyczy — sześć sytuacji

Nie każda firma używająca AI ma tu nowe ryzyko. Linia podziału nie przebiega według branży ani wielkości, tylko według jednego pytania: czy to, w czym pracuje model, opuszcza Waszą firmę i trafia do osób fizycznych. Poniższe sytuacje są po tej gorszej stronie linii.

• Sprzedajecie oprogramowanie albo aplikację z funkcją AI — własną albo opartą na cudzym modelu. Jesteście producentem, a jeśli udostępniacie produkt pod swoją marką, także wtedy, gdy wytworzył go ktoś inny.
• Budujecie maszyny, urządzenia albo instalacje, w których decyzję podejmuje model: kontrola wizyjna, sterowanie, utrzymanie predykcyjne, systemy bezpieczeństwa. Oprogramowanie i usługa chmurowa są częścią produktu, nie odrębnym dodatkiem.
• Dotrenowujecie albo istotnie przerabiacie cudzy model i udostępniacie wynik klientom. To jest podręcznikowa istotna modyfikacja — z nowym dziesięcioletnim terminem liczonym od tej zmiany.
• Prowadzicie usługę, w której model rozmawia z konsumentem i wpływa na jego decyzje dotyczące zdrowia, bezpieczeństwa albo pieniędzy. Aplikacje wellness, doradztwo, kwalifikacja medyczna, konfiguratory techniczne.
• Sprzedajecie w kanale cyfrowym i wbudowaliście AI w ścieżkę zakupową albo w obsługę po sprzedaży — tu dochodzą jeszcze obowiązki dotyczące oznaczania interakcji z AI, o których pisaliśmy przy sklepie gotowym na agenty AI i przy treściach AI w marketingu.
• Wasi pracownicy zbudowali narzędzie, które wyszło na zewnątrz. Aplikacja napisana w kilka godzin przez osobę bez działu IT, która trafiła do klientów, jest produktem na tych samych zasadach co kupiony system — a skany takich aplikacji pokazują, jak często mają problemy bezpieczeństwa. Ten scenariusz opisaliśmy przy vibe codingu w firmie.

Czego nie zapiszecie już w umowie — i co trzeba zapisać

Zakaz umownego wyłączania i ograniczania odpowiedzialności wobec poszkodowanego nie jest nowością: art. 449(9) Kodeksu cywilnego mówi to od lat, a dyrektywa utrzymuje tę zasadę. Nowe jest to, czego ona od grudnia dotyczy. Klauzula limitująca odpowiedzialność do wartości rocznego abonamentu, standardowa w umowach SaaS, nie zadziała wobec osoby fizycznej dochodzącej szkody z wadliwego produktu. Nie zadziała też wyłączenie odpowiedzialności za szkody następcze w zakresie, w jakim dotyczą tej podstawy.

To nie znaczy, że umowy przestają mieć znaczenie — przenosi tylko ich ciężar z ograniczania odpowiedzialności na jej rozdzielanie. Odpowiedzialność jest solidarna, więc poszkodowany pozwie tego, kogo łatwiej znaleźć, a to w łańcuchu dostaw AI zwykle oznacza polskiego integratora, nie zamorskiego dostawcę modelu. Dlatego w umowach z dostawcami warto mieć trzy rzeczy: prawo regresu i obowiązek współdziałania przy obronie, zobowiązanie do wydania dokumentacji technicznej na żądanie sądu w rozsądnym terminie, oraz zapis, co jest konfiguracją przewidzianą przez dostawcę, a co wychodzi poza nią. Trzecia pozycja wygląda na drobiazg, a jest dowodem w sporze o to, czy dokonaliście istotnej modyfikacji.

Czwarta rzecz, która zwykle wypada z zakresu projektu: ubezpieczenie. Polisa odpowiedzialności cywilnej z wyłączeniem szkód związanych z oprogramowaniem albo z brakiem rozszerzenia na odpowiedzialność za produkt jest po grudniu w firmie sprzedającej AI polisą w dużej mierze dekoracyjną. To jest rozmowa na jedno spotkanie z brokerem i warto ją odbyć przed, a nie po.

Co zrobić do 9 grudnia

Zakres pracy zależy od tego, po której stronie linii z poprzedniej sekcji jesteście. Jeżeli AI pracuje wyłącznie wewnątrz firmy, wystarczy świadomość i punkt pierwszy. Jeżeli coś z AI opuszcza firmę, poniższa kolejność daje się przejść w siedem tygodni bez wstrzymywania wdrożeń.

1. Zrób inwentaryzację: lista produktów i usług, które zawierają oprogramowanie albo model, z datą wprowadzenia do obrotu i informacją, czy trafiają do osób fizycznych. Przy produktach wprowadzonych do 8 grudnia 2026 włącznie zostaje stary reżim — dlatego data jest tu informacją o wartości pieniężnej, nie formalnością.
2. Określ swoją rolę dla każdej pozycji: producent, podmiot pod własną marką, importer, dystrybutor, podmiot modyfikujący. Jedna firma ma zwykle kilka różnych roli jednocześnie i każda daje inny zakres odpowiedzialności.
3. Spisz, co zmieniliście wobec tego, co dostarczył dostawca, i wskaż miejsce w jego dokumentacji, które na to pozwala. To jest Wasza linia obrony w sporze o istotną modyfikację i powstaje w pół dnia na wdrożenie.
4. Uporządkuj dokumentację dowodową: wersjonowanie modeli, promptów i konfiguracji, zestaw testowy z wynikami, analiza ryzyka, historia aktualizacji, logi z retencją adekwatną do dziesięcioletniego terminu. Sprawdź jedną rzecz praktycznie: czy umiecie dziś odtworzyć, jaka wersja odpowiadała na zapytanie sprzed pół roku.
5. Zbuduj proces obsługi podatności: skąd przychodzą informacje, kto decyduje o aktualizacji, w jakim czasie, jak informujecie klientów. Ten sam proces obsługuje obowiązki raportowe z aktu o cyberodporności, które działają od 11 września 2026.
6. Przejrzyj umowy z dostawcami i z klientami pod kątem regresu, obowiązku wydania dokumentacji i granicy konfiguracji. Oddzielnie przejrzyj polisę.
7. Ustal, kto w firmie jest właścicielem tego tematu. Nie dział prawny sam i nie IT sam — bo pytania, które przyjdą, brzmią „którą wersję modelu mieliśmy w maju” i wymagają obu kompetencji w jednym miejscu.

Status polskiej implementacji i co z tego wynika praktycznie

Dyrektywa wymaga zmian w Kodeksie cywilnym i Kodeksie postępowania cywilnego: nowej definicji produktu, przepisów o ujawnianiu dowodów, domniemań, usunięcia progu 500 euro i zmiany zakresu szkody. Projekt implementacji przygotowuje Komisja Kodyfikacyjna Prawa Cywilnego — temat ten był przedmiotem jej trzydziestego pierwszego posiedzenia plenarnego 22 kwietnia 2026 roku, z celem przyjęcia projektu in pleno. Dalszy przebieg zależy od procesu legislacyjnego, a na trzy tygodnie przed datą stosowania ustawy w Dzienniku Ustaw nie ma.

Dla firmy ma to jedną konsekwencję, którą warto rozumieć, zanim ktoś wyciągnie z opóźnienia pocieszający wniosek. Data stosowania dyrektywy nie przesuwa się z powodu spóźnienia krajowego ustawodawcy. Spóźnienie tworzy natomiast okres niepewności: sądy sięgają po wykładnię prounijną obowiązujących przepisów, a przeciwko państwu możliwe są roszczenia odszkodowawcze za wadliwą implementację. Nieprzyjęcie ustawy w terminie nie jest więc dla Was ochroną — jest zamianą jasnego ryzyka na nieprzewidywalne.

Druga rzecz do zapamiętania przy czytaniu projektu, gdy się pojawi: dyrektywa pozostawia państwom pewien zakres swobody, w tym możliwość wyłączenia obrony opartej na ryzyku rozwoju dla określonych kategorii produktów. Ostateczny kształt polskich przepisów trzeba będzie przeczytać, a nie wywnioskować z dyrektywy.

Kiedy to Was nie dotyczy

Warto postawić tę granicę jawnie, bo nadmiarowa ostrożność kosztuje w tym obszarze równie realnie jak jej brak. Jeżeli AI pracuje wyłącznie wewnątrz firmy — streszcza spotkania, pomaga w mailach, czyta umowy przychodzące, odpowiada na pytania pracowników do bazy wiedzy — nowy reżim Was nie dotyczy, bo nie ma produktu wprowadzanego do obrotu ani osoby fizycznej po drugiej stronie. Wasze ryzyka są tam zupełnie inne i opisaliśmy je osobno: wyciek danych, shadow AI, jakość danych, zgodność z RODO.

Nie dotyczy Was również wtedy, gdy korzystacie z narzędzia dostawcy w sposób, który on przewidział, bez przerabiania go i bez udostępniania wyniku dalej jako własnego produktu. Konfiguracja nie jest produkcją. Problem zaczyna się dopiero wtedy, gdy nikt nie jest w stanie powiedzieć, czy to, co zrobiliście, było konfiguracją — a to jest stan domyślny w projekcie, w którym nie prowadzono dokumentacji zmian.

I ostatnia rzecz, warta powiedzenia wprost: żaden z tych przepisów nie jest argumentem przeciw wdrażaniu AI. Jest argumentem przeciw wdrażaniu jej bez zapisu tego, co zrobiliście. Różnica w kosztach między projektem udokumentowanym a nieudokumentowanym jest dziś niewielka — rzędu kilku procent budżetu, co pokazywaliśmy w tekście o tym, ile kosztuje wdrożenie AI. Po grudniu ta sama różnica decyduje o tym, po której stronie domniemania stoi Wasza firma.

Od czego zacząć

Najtańszy pierwszy krok zajmuje jedno spotkanie i nie wymaga prawnika: wypiszcie wszystko, co Wasza firma sprzedaje i co zawiera oprogramowanie albo model, a potem przy każdej pozycji odpowiedzcie na dwa pytania — czy używa tego osoba fizyczna i czy zmieniliśmy w tym cokolwiek wobec tego, co dał dostawca. Jeżeli lista wyjdzie pusta, temat Was nie dotyczy i wracacie do pracy. Jeżeli coś na niej zostanie, macie już zakres i wiecie, czego dokumentacji szukać, póki jest jeszcze czas na jej uzupełnienie.

Tak prowadzimy takie projekty: najpierw audyt tego, gdzie w firmie model wpływa na decyzje i co z tego wychodzi na zewnątrz, potem uporządkowanie dokumentacji, wersjonowania i testów, potem umowy i proces obsługi podatności. Zakres konsultingu i wdrożeń AI opisaliśmy osobno, stawki znajdziecie w cenniku, a jeśli chcecie sprawdzić, czy to, co sprzedajecie, jest od 9 grudnia produktem w nowym rozumieniu — umówcie bezpłatną konsultację.