Open source a odpowiedzialność za AI: kto ponosi winę za szkodliwe działanie otwartego modelu?

Dlaczego odpowiedzialność za otwarte modele AI jest tak problematyczna?

Otwarte modele AI kontra zamknięte produkty SaaS

Otwarte modele AI fundamentalnie różnią się od zamkniętych usług SaaS, zarówno technicznie, jak i prawnie. W przypadku klasycznego rozwiązania SaaS (np. komercyjnego chatbota w chmurze) użytkownik ma dostęp jedynie do interfejsu – API lub aplikacji webowej. Cała logika, wagi modelu, dane treningowe i mechanizmy bezpieczeństwa pozostają pod kontrolą jednego dostawcy. To on utrzymuje infrastrukturę, wprowadza aktualizacje i może w każdej chwili zmienić sposób działania systemu.

Przy otwartym modelu sytuacja się odwraca. Wagi modelu i kod inferencji są publicznie dostępne, często do pobrania w jednym kliknięciu. Każdy może:

• uruchomić model lokalnie lub w swojej chmurze,
• zmodyfikować architekturę lub hiperparametry,
• przetrenować lub dostroić (fine-tuning) na własnych danych,
• wpiąć model w dowolny produkt lub usługę, bez wiedzy pierwotnego twórcy.

Brak centralnej kontroli jest zarazem zaletą (innowacja, niezależność, audytowalność), jak i źródłem ogromnych problemów z odpowiedzialnością. Gdy z otwartego modelu powstają setki pochodnych projektów, trudno wskazać jeden podmiot, który faktycznie „panuje” nad ryzykiem. W modelu SaaS granica jest prostsza: osoba lub firma kontrolująca serwery i oprogramowanie zwykle jest głównym adresatem roszczeń.

Wielość aktorów i rozmycie granic ról

Otwarte modele tworzą łańcuch wartości, w którym bierze udział wielu aktorów. Jeden projekt może przejść przez ręce:

• zespołu badawczego projektującego architekturę,
• podmiotów dostarczających dane treningowe,
• organizacji trenującej model bazowy (foundation model),
• fundacji lub społeczności utrzymującej repozytorium,
• platform dystrybucyjnych (np. Hugging Face),
• integratorów budujących produkty (start‑upy, software house’y),
• operatorów systemów wdrożonych u klientów (np. szpital, bank),
• użytkowników końcowych, którzy decydują, jak z narzędzia korzystać.

W praktyce te role często się nakładają. Uniwersytet może być twórcą modelu, jednocześnie jego pierwszym dostawcą i „marką” kojarzoną z bezpieczeństwem. Start‑up może być zarówno integratorem, jak i operatorem systemu oferowanego klientom B2B. Społeczność open source może nieformalnie podejmować decyzje, które mają realny wpływ na ryzyko (np. akceptując pull requesty z nowymi funkcjami).

Mit polega na przekonaniu, że skoro „wszyscy coś dodają”, to nikt nie ponosi odpowiedzialności. W rzeczywistości kilku aktorów może odpowiadać równolegle, każdy na swoim odcinku – za dane, za trening, za konfigurację, za sposób sprzedaży i za sposób użycia w konkretnym kontekście.

Mit: „open source = bez odpowiedzialności”

Popularna narracja brzmi: „to tylko open source, nie biorę za to odpowiedzialności”. W świecie prostych bibliotek open source bywało to częściowo akceptowane społecznie, choć już wtedy było wątpliwe prawnie. Przy modelach AI stawka jest znacznie wyższa. Błędne rekomendacje medyczne, szkodliwe porady prawne, generowanie deepfake’ów – to nie są abstrakcyjne ryzyka, lecz coraz częstsza praktyka.

Rzeczywistość prawna wygląda inaczej niż slogan: „open source zdejmuje odpowiedzialność”. Licencja open source reguluje głównie prawo autorskie i zakres uprawnień do korzystania z utworu. Odpowiedzialność za szkodę (cywilną, konsumencką, produktową) działa w oparciu o inne przepisy, których nie da się całkowicie wyłączyć prostym dopiskiem w licencji. Wyłączenie odpowiedzialności w stylu „AS IS, NO WARRANTY” ma ograniczoną skuteczność wobec norm bezwzględnie obowiązujących, jak ochrona konsumentów czy odpowiedzialność za rażące niedbalstwo.

Mit vs rzeczywistość: mit – „jak opublikuję model na MIT i dodam disclaimer, to nikt mnie nie pozwie”; rzeczywistość – można próbować ograniczyć roszczenia, ale pozostaje ryzyko pozwu, a sąd sam oceni, czy doszło do winy, zaniedbania lub naruszenia norm bezpieczeństwa.

Typowe scenariusze szkód powodowanych przez otwarte modele

Otwarte modele foundation models i ich pochodne mogą generować szkody bardzo różnego rodzaju. W praktyce pojawiają się m.in.:

• dezinformacja i manipulacja – masowe generowanie fałszywych wiadomości, treści politycznych, skoordynowanych kampanii spamowych,
• dyskryminacja i naruszenie praw człowieka – np. model rekrutacyjny faworyzujący określone płcie lub narodowości, chatbot udzielający uprzedzonych, rasistowskich lub mizoginicznych odpowiedzi,
• naruszenia praw autorskich – generowanie treści silnie podobnych do konkretnych dzieł, wykorzystanie chronionych danych treningowych bez podstawy prawnej,
• szkody fizyczne i materialne – błędne rekomendacje medyczne, instrukcje naprawy urządzeń prowadzące do uszkodzenia sprzętu lub wypadków, sugestie niebezpiecznych zachowań,
• naruszenia prywatności – odtwarzanie danych osobowych, łączenie poufnych informacji z publicznych źródeł i ich ujawnianie w odpowiedziach modelu.

Każdy z tych scenariuszy rodzi inne pytania o odpowiedzialność. W jednym przypadku w centrum znajdzie się projektant modelu (za błędną architekturę lub brak mechanizmów bezpieczeństwa), w innym – integrator, który zignorował przeznaczenie modelu i wpiął go w system krytyczny, a jeszcze w innym – użytkownik, który wykorzystał model z zamiarem wyrządzenia szkody.

Efekt domina: skala i reużywalność komponentów open source

W ekosystemie open source jeden pakiet lub model może zostać włączony do setek, a nawet tysięcy produktów. W przypadku AI to zjawisko jest jeszcze silniejsze, bo foundation model staje się „warstwą bazową” dla niezliczonych fine-tuningów i aplikacji. Jeden błąd lub toksyczny pattern zachowania może zostać odziedziczony przez całą rodzinę systemów.

Przykładowo: jeśli otwarty model językowy ma słabo zaimplementowane filtrowanie treści przemocowych, a setki firm użyją go do chatbotów obsługujących dzieci, konsekwencje rozlewają się na wielu operatorów i użytkowników. Z kolei integratorzy często polegają na renomie open source („skoro to pochodzi z dużej fundacji, to na pewno jest bezpieczne”), nie wykonując własnego due diligence.

Dlatego dyskusja o odpowiedzialności za AI open source jest tak drażliwa: granica między indywidualną winą a systemową podatnością ekosystemu open source bywa bardzo cienka. Prawo próbuje wypełnić tę lukę, ale nadąża za technologią z dużym opóźnieniem.

Kim są „aktorzy” w łańcuchu odpowiedzialności za otwartą AI?

Kluczowe role: od architekta modelu po użytkownika końcowego

Aby zrozumieć, kto i za co może odpowiadać, trzeba jasno rozrysować role w łańcuchu powstawania i wykorzystywania otwartego modelu AI. Najczęściej da się wyróżnić następujące kategorie:

• twórca architektury/modelu – projektuje strukturę sieci, mechanizmy uczenia, często publikuje pierwszą wersję modelu,
• dostawca danych – podmiot udostępniający zbiory danych treningowych (np. instytucje publiczne, firmy posiadające własne zbiory, platformy agregujące dane),
• trenator / fine-tuner – przeprowadza trening wstępny (pre‑training) lub dostrajanie (fine-tuning) na konkretnym zbiorze,
• maintainer repozytorium – osoba lub organizacja zarządzająca publikacją modelu, dokumentacją, wersjami, przyjmowaniem poprawek,
• dystrybutor / platforma – serwis udostępniający gotowe checkpointy modeli, np. w formie katalogu modeli,
• integrator – podmiot, który wbudowuje model w konkretny produkt, aplikację, usługę, dodając warstwę logiki biznesowej,
• operator systemu – organizacja, która realnie korzysta z aplikacji opartej na modelu, obsługując użytkowników (np. szpital, bank, sklep internetowy),
• użytkownik końcowy – osoba fizyczna lub firma korzystająca z narzędzia, podejmująca decyzje na podstawie wygenerowanych wyników.

W małym projekcie część z tych ról może pełnić ta sama osoba (np. niezależny badacz). W dużych systemach enterprise każda rola to inny dział lub nawet inna firma. Z punktu widzenia odpowiedzialności prawnej kluczowe są: kto ma kontrolę nad konkretnym ryzykiem, kto decyduje o kontekście użycia i kto odnosi korzyści komercyjne.

Zależności między aktorami i kontrola nad ryzykiem

Nie każdy aktor ma taki sam wpływ na bezpieczeństwo systemu. Dostawca danych kontroluje skład i jakość zbioru, ale nie decyduje, jak model będzie później wykorzystywany. Twórca architektury może przewidzieć mechanizmy kontroli, ale nie ma wpływu na to, czy integrator je włączy. Integrator i operator najczęściej decydują o:

• przeznaczeniu systemu (np. chatbot medyczny vs czat rozrywkowy),
• zakresie użytkowników (dzieci, pacjenci, konsumenci, specjaliści),
• procedurach nadzoru (human-in-the-loop, eskalacja do człowieka, logowanie decyzji),
• komunikatach ostrzegawczych i instrukcjach użycia.

Dlatego w praktyce roszczenia bardzo często będą kierowane przede wszystkim do integratora lub operatora, nawet jeśli rdzeń technologii jest open source i stworzony przez kogoś innego. Nie oznacza to jednak pełnego zwolnienia tamtych podmiotów z ryzyka – szczególnie, gdy ich zaniedbania są oczywiste (np. szkolenie na jawnie nielegalnych danych, ignorowanie sygnałów o poważnych błędach).

Jak na role patrzy AI Act: provider, deployer, importer, distributor

Unijne rozporządzenie AI Act wprowadza własny słownik ról, który trzeba umieć przełożyć na realia open source. Najważniejsze pojęcia to:

• provider (dostawca) – podmiot, który rozwija system AI lub zleca jego rozwój w celu wprowadzenia go na rynek UE lub oddania do użytku, pod własną nazwą lub znakiem towarowym,
• deployer (wdrażający / operator) – osoba lub organizacja wykorzystująca system AI w praktyce, w ramach swojej działalności zawodowej,
• importer – podmiot wprowadzający do UE system AI dostarczony przez organizację spoza UE,
• distributor – podmiot udostępniający system AI na rynku UE, bez jego modyfikacji.

W kontekście open source pojawia się kluczowy problem: czy publikacja modelu w repozytorium czyni autora „providerem” w rozumieniu AI Act? Projekt regulacji przewiduje pewne zwolnienia dla niekomercyjnych projektów open source, ale gdy tylko ktoś użyje modelu w celu komercyjnym, może sam stać się providerem dla swojego wariantu lub aplikacji. Co istotne, AI Act wyraźnie podkreśla, że foundation models o dużej skali będą objęte dodatkowymi obowiązkami, niezależnie od tego, czy są open source, czy zamknięte.

Przekładając to na praktykę: uniwersytet publikujący duży foundation model może być traktowany jako provider foundation modelu. Start‑up, który na jego bazie tworzy aplikację diagnostyczną, staje się providerem własnego systemu wysokiego ryzyka, a szpital korzystający z tej aplikacji będzie deployerem. Każdy z nich może ponosić odrębną odpowiedzialność regulacyjną.

Mit: „odpowiada ten, kto ostatni dotknął kodu”

W środowisku programistycznym często krąży przekonanie, że najwięcej ryzyka ponosi „ostatni commit” – osoba lub firma, która wprowadziła ostatnią zmianę. W prawie cywilnym i regulacyjnym takiej zasady nie ma. Odpowiedzialność może być równoległa, a czasami solidarna, obejmując zarówno twórcę pierwotnego, jak i późniejszych modyfikatorów.

Jeśli foundation model ma rażące błędy bezpieczeństwa (np. łatwo daje się nakłonić do generowania instrukcji samobójczych), to twórca może odpowiadać za brak należytej staranności już na etapie projektu. Integrator, który użyje go do aplikacji dla nastolatków, odpowiada dodatkowo za niewłaściwy dobór narzędzia i brak własnych zabezpieczeń. Finałowa szkoda może więc być efektem łańcucha zaniedbań, a nie pojedynczej decyzji ostatniego programisty.

Przykładowy łańcuch odpowiedzialności: model akademicki w aplikacji medycznej

Wyobraźmy sobie następujący scenariusz:

• Uniwersytet tworzy otwarty model językowy, trenując go m.in. na artykułach medycznych, i publikuje go jako foundation model.

Rozwój scenariusza: gdzie pojawia się szkoda i kto może odpowiadać?

Kontynuujmy przykład:

• Start‑up pobiera model z repozytorium i dostraja go (fine‑tuning) na małym, własnym zbiorze opisów przypadków klinicznych, po czym buduje z niego „asystenta diagnostycznego” dla lekarzy.
• Szpital kupuje licencję na korzystanie z aplikacji i integruje ją z własnym systemem elektronicznej dokumentacji medycznej.
• Lekarz używa asystenta, który w konkretnym przypadku generuje błędną, ale brzmiącą przekonująco rekomendację, co prowadzi do opóźnionej diagnozy i szkody u pacjenta.

W takiej sytuacji w grę może wchodzić odpowiedzialność kilku podmiotów jednocześnie:

• Uniwersytetu – jeżeli model od początku miał rażące braki (np. brak testów w domenie medycznej przy jednoczesnym promowaniu jako modelu „do zastosowań klinicznych”),
• start‑upu – za stworzenie systemu wysokiego ryzyka bez rzetelnej walidacji i bez jasnego komunikatu, że to narzędzie pomocnicze, a nie źródło wiążących diagnoz,
• szpitala – za zbytnią automatyzację decyzji, brak szkoleń dla personelu i brak nadzoru nad tym, jak lekarze korzystają z rekomendacji modelu,
• konkretnego lekarza – jeżeli wbrew standardom zawodowym bezrefleksyjnie przyjął rekomendację systemu, ignorując symptomy u pacjenta.

Mit, że „otwarty model = odpowiedzialność spada na użytkownika”, nie wytrzymuje zderzenia z takim scenariuszem. Odpowiedzialność jest rozłożona wzdłuż całego łańcucha, a sąd może uznać współwinę kilku podmiotów, zależnie od tego, kto zaniedbał własną działkę bezpieczeństwa.

Podstawy prawne odpowiedzialności za AI w UE i Polsce (z naciskiem na open source)

Trzy filary: odpowiedzialność cywilna, regulacyjna i karna

W dyskusjach o AI często miesza się różne rodzaje odpowiedzialności, co zaciemnia obraz. W praktyce trzeba rozróżnić co najmniej trzy płaszczyzny:

• odpowiedzialność cywilną – za szkodę wyrządzoną osobie lub przedsiębiorcy (odszkodowanie, zadośćuczynienie),
• odpowiedzialność regulacyjną (administracyjną) – za naruszenie obowiązków z AI Act, RODO czy innych aktów sektorowych (kary administracyjne, zakazy),
• odpowiedzialność karną – w sytuacjach skrajnych, gdy działanie lub zaniechanie spełnia znamiona przestępstwa (np. narażenie na niebezpieczeństwo, oszustwo).

Open source nie jest „parasolem” chroniącym przed żadną z tych form odpowiedzialności. To, że kod czy model są dostępne publicznie, nie oznacza automatycznie zwolnienia z wymogu zachowania należytej staranności przy ich tworzeniu czy stosowaniu.

AI Act: nowa warstwa obowiązków dla twórców i użytkowników modeli

AI Act nie jest klasyczną ustawą o odpowiedzialności odszkodowawczej – to raczej „kodeks bezpieczeństwa” dla systemów AI. Wprowadza:

• obowiązki ex ante – co trzeba zrobić zanim system trafi na rynek (ocena ryzyka, dokumentacja, testy),
• wymogi ciągłego nadzoru – monitorowanie działania systemu, zgłaszanie poważnych incydentów, aktualizacje,
• specjalne obowiązki dla foundation models i general‑purpose AI (GPAI) – m.in. dokumentacja techniczna, raportowanie zużycia mocy obliczeniowej, opisy zbiorów treningowych, zarządzanie bezpieczeństwem.

Mit, że „AI Act dotyczy tylko komercyjnych produktów SaaS”, jest mylący. Jeśli otwarty foundation model spełnia kryteria z rozporządzenia (np. skala, wpływ, zastosowania ogólnego przeznaczenia), to jego twórca może być traktowany jako provider z pełnym pakietem obowiązków – nawet jeśli kod jest na GitHubie i Hugging Face, a projekt ma charakter badawczy.

AI Liability Directive i zmiany w dyrektywie produktowej

Równolegle do AI Act UE pracuje nad AI Liability Directive, która ma ułatwić dochodzenie roszczeń cywilnych z tytułu szkód wyrządzonych przez systemy AI. Jej dwa kluczowe mechanizmy to:

• odwrócenie ciężaru dowodu w niektórych sytuacjach – jeśli podmiot nie wypełnił obowiązków z AI Act, sąd może domniemywać, że to naruszenie przyczyniło się do szkody,
• ułatwiony dostęp do dowodów – sąd może zobowiązać providerów do udostępnienia dokumentacji, logów, opisów działania systemu.

Dla otwartych modeli oznacza to jedno: transparentność przestaje być tylko „wartością społecznościową”, a staje się także narzędziem procesowym. Jeżeli model jest dobrze udokumentowany, z testami bezpieczeństwa i opisem ograniczeń, łatwiej wykazać, że twórca zachował należytą staranność. Brak dokumentacji może mu się odbić czkawką w sądzie.

Równocześnie zaktualizowana dyrektywa produktowa (Product Liability Directive) ma wprost uwzględniać oprogramowanie i systemy AI jako produkty. W przypadku komercyjnych wdrożeń o otwartym rodowodzie, integrator korzystający z open source może okazać się „producentem” w rozumieniu prawa produktowego – zwłaszcza gdy łączy różne komponenty w całość i oferuje je pod własną marką.

Prawo cywilne w Polsce: wina, należyta staranność i ryzyko działalności gospodarczej

Na gruncie polskiego Kodeksu cywilnego otwarty model AI nie jest osobną kategorią. Sąd patrzy przede wszystkim na:

• związek przyczynowy między działaniem/zaniechaniem a szkodą,
• bezprawność (naruszenie przepisu, zasad współżycia społecznego lub obowiązków zawodowych),
• winę (zamierzoną lub w postaci niedbalstwa),
• w przypadku przedsiębiorców – miernik należytej staranności profesjonalisty (art. 355 §2 k.c.).

Twórca lub maintainer otwartego modelu działający w ramach działalności gospodarczej będzie oceniany surowiej niż hobbysta publikujący eksperymentalny model bez jakichkolwiek zapewnień. Jeżeli firma promuje model jako „bezpieczny do zastosowań medycznych” bez minimalnych testów, trudno obronić tezę, że dochowała profesjonalnej staranności.

Mit „jeśli dam wyraźne zastrzeżenie as is, to nie odpowiadam za nic” jest mocno przesadzony. Klauzule tego typu mają znaczenie w relacji kontraktowej, ale w przypadku odpowiedzialności deliktowej (czyn niedozwolony) nie zneutralizują rażącego niedbalstwa ani świadomego wprowadzania w błąd.

RODO i dane osobowe w treningu otwartych modeli

Jeśli otwarty model był trenowany na danych osobowych, wchodzi w grę RODO. Dla open source szczególnie istotne są trzy kwestie:

• rola administratora danych – kto decydował o celach i sposobach przetwarzania danych w treningu,
• legalność pozyskania danych – czy zbiory pochodzą z legalnych źródeł, czy zawierają dane wrażliwe,
• efekt „rekonstrukcji danych” – czy model może odtwarzać dane osobowe z treningu (np. cytować mało znane posty z forów).

Administrator (najczęściej organizacja trenująca model) odpowiada za spełnienie przesłanek przetwarzania danych, przeprowadzenie oceny skutków (DPIA) i wdrożenie środków minimalizujących ryzyko. Jeżeli model wypłynie jako open source i inni będą go dalej trenować lub używać, ich rola może już być inna – często staną się odrębnymi administratorami dla kolejnych etapów przetwarzania.

Licencje open source a odpowiedzialność za szkody – co faktycznie robią, a czego nie

Standardowe klauzule „NO WARRANTY” i „AS IS”

Większość klasycznych licencji open source (MIT, Apache 2.0, BSD) zawiera wyraźne klauzule:

• braku gwarancji (NO WARRANTY) – autor nie gwarantuje, że oprogramowanie działa prawidłowo lub spełnia określone cele,
• dystrybucji „tak jak jest” (AS IS) – użytkownik bierze oprogramowanie na własne ryzyko.

Te klauzule dobrze chronią przed roszczeniami kontraktowymi ze strony osób, które po prostu pobrały i użyły oprogramowanie zgodnie z licencją. Nie są jednak magiczną tarczą przeciwko każdej odpowiedzialności. Jeżeli dojdzie do szkody na osobie i sąd stwierdzi rażące niedbalstwo (np. świadome publikowanie złośliwego kodu w bibliotece używanej w infrastrukturze krytycznej), klauzula „AS IS” może nie wystarczyć.

Specjalne licencje dla modeli AI: OpenRAIL, ML‑specyficzne warianty

W odpowiedzi na specyfikę modeli AI powstały licencje typu OpenRAIL czy różne „Responsible AI Licenses”. Dodają one ograniczenia co do zastosowań (np. zakaz użycia do nadzoru masowego, broni autonomicznej, dyskryminacji) i obowiązki w zakresie etycznego użycia.

Takie licencje mają dwa główne cele:

• normatywny – wyznaczenie granic akceptowalnych zastosowań,
• compliance’owy – pokazanie regulatorom i partnerom biznesowym, że twórca świadomie zarządza ryzykiem.

Ich skuteczność prawna jest jednak ograniczona:

• naruszenie zakazu (np. użycia do inwigilacji) daje twórcy głównie roszczenie wobec naruszyciela licencji,
• osoba trzecia poszkodowana takim użyciem (np. inwigilowany obywatel) raczej będzie pozywać podmiot faktycznie stosujący model niż oryginalnego twórcę.

W praktyce takie licencje są bardziej narzędziem kształtowania ekosystemu niż klasyczną ochroną przed odpowiedzialnością deliktową. Pokazują jednak, że twórca dostrzega konkretne ryzyka i próbuje im przeciwdziałać, co może być istotne przy ocenie należytej staranności.

Mit: „wystarczy dodać zakaz użycia w medycynie i sprawa załatwiona”

Częsty pomysł twórców modeli: dodać do licencji lub README zdanie typu „model nie może być używany w diagnostyce medycznej ani do podejmowania decyzji o leczeniu”. To krok w dobrą stronę, ale nie panaceum.

Jeżeli twórca:

• świadomie trenuje model na danych medycznych,
• promuje go w publikacjach i prezentacjach jako „przełom dla AI w medycynie”,
• daje gotowe przykłady kodu użycia w kontekście klinicznym,

to jeden zdawkowy zakaz w licencji będzie wyglądał na czysto formalne alibi. Sąd może uznać, że w rzeczywistości twórca liczył się i godził na medyczne zastosowania modelu, więc powinien był wdrożyć bardziej realne zabezpieczenia (np. ostrzeżenia w interfejsie, testy, materiały edukacyjne dla integratorów).

Dual licensing i zastrzeżenia w umowach komercyjnych

Wielu twórców otwartych modeli stosuje podejście dual licensing:

• model w wersji bazowej jest dostępny na otwartej licencji,
• wersja „enterprise” – z dodatkowymi funkcjami, wsparciem i gwarancjami – jest oferowana na zamkniętej, komercyjnej licencji.

W takim układzie najistotniejszym dokumentem z perspektywy odpowiedzialności są już nie tyle klauzule open source, ile umowy B2B z klientami. To w nich precyzuje się:

• zakres dopuszczalnych zastosowań,
• limity odpowiedzialności,
• wymogi co do monitoringu i testów po stronie klienta,
• procedury reagowania na incydenty.

Dla społecznościowego odbiorcy korzystającego z darmowej wersji obowiązują więc głównie ograniczenia open source, a dla korporacyjnego klienta – reżim kontraktowy. Oba mogą współistnieć, a roszczenia osób trzecich i tak będą oceniane na gruncie odpowiedzialności deliktowej oraz regulacyjnej.

Licencje a „due diligence”: jak dokumentacja może ograniczać ryzyko

Sam tekst licencji to za mało. Coraz większe znaczenie mają materiały towarzyszące publikacji modelu:

• karty modelu (model cards),
• karty danych (datasheets for datasets),
• opisy znanych ograniczeń, biasów i scenariuszy niepożądanych,
• przykładowe polityki użycia i ostrzeżenia dla użytkownika końcowego.

W razie sporu takie dokumenty pomagają pokazać, że twórca nie „wrzucił przypadkowego modelu do sieci”, ale świadomie informował o jego granicach, wskazywał bezpieczne i niebezpieczne zastosowania, sugerował dodatkowe testy. To nie wyklucza odpowiedzialności, ale może przesunąć jej ciężar na integratora, który zignorował wyraźne ostrzeżenia.

Twórca i maintainer otwartego modelu – jakie ryzyka realnie ponoszą?

Granica między „hobbystą na GitHubie” a profesjonalnym dostawcą

Z punktu widzenia odpowiedzialności kluczowy jest kontekst działania twórcy. Ten sam kod w repozytorium może być oceniony zupełnie inaczej, gdy stoi za nim:

• student wrzucający prototyp w ramach pracy dyplomowej,
• spółka technologiczna sprzedająca konsulting wokół modelu i występująca na konferencjach jako „lider rynku”.

W pierwszym przypadku sąd będzie się skłaniał do traktowania projektu jak eksperymentu badawczego, w którym odbiorca ma świadomość niedojrzałości rozwiązania. W drugim – jak profesjonalnego produktu lub usługi, co automatycznie podnosi próg staranności. Mit „to jest tylko repo na GitHubie, więc nie odpowiadam” jest niebezpieczny: jeżeli repo jest używane jako główny kanał dystrybucji przez firmę i towarzyszą mu materiały marketingowe, łatwo wykazać, że to element działalności komercyjnej.

Czego może się obawiać pojedynczy developer?

Indywidualny twórca pracujący po godzinach z reguły nie jest pierwszym celem roszczeń po spektakularnej wpadce AI. Głównym adresatem będzie:

• firma, która oparła swój produkt o model i sprzedaje go klientom,
• podmiot, który wdrożył rozwiązanie w wrażliwym środowisku (szpital, bank, administracja publiczna).

To jednak nie oznacza pełnej bezkarności. Ryzyka po stronie pojedynczego developera to głównie:

• roszczenia z tytułu naruszenia praw autorskich lub RODO przy nielegalnym treningu,
• odpowiedzialność za rażące niedbalstwo, gdy opublikowano model z oczywistymi, łatwymi do uniknięcia zagrożeniami,
• ryzyka reputacyjne – utrata wiarygodności w branży, utrudniona współpraca z uczelniami i firmami.

Rzadko dochodzi do tego, że indywidualny maintainer zostaje pozwany za każdą szkodę wyrządzoną przez model. Dużo częściej zostanie wezwany do udzielenia informacji, przekazania logów treningu, wyjaśnienia pochodzenia datasetów. To też obciążenie – prawne, czasowe i psychiczne.

Gdzie zaczyna się „profesjonalny maintainer”?

W środowisku open source często występuje podział ról: ktoś wrzuca pierwszy proof‑of‑concept, a ktoś inny przejmuje projekt i rozwija go w uporządkowany sposób. Ten drugi bywa już postrzegany jako faktyczny dostawca. Sygnałami „us-profesjonalnienia” są m.in.:

• regularne releasy z changelogiem,
• dedykowany zespół utrzymaniowy (choćby rozproszony),
• formalny governance projektu (komitet sterujący, roadmapa),
• komunikaty w stylu „ten model jest produkcyjnie używany przez X i Y”.

Jeśli maintainer świadomie akceptuje integracje w sektorach podwyższonego ryzyka, a jednocześnie nie wprowadza żadnych mechanizmów zarządzania ryzykiem (testów, disclaimerów, zaleceń), coraz trudniej bronić się narracją „to tylko open source, sami używacie na własne ryzyko”.

Ryzyka regulacyjne: gdy open source spotyka AI Act i sektorowe przepisy

AI Act (rozporządzenie UE w sprawie sztucznej inteligencji) wprowadza kategorię systemów wysokiego ryzyka i odrębne zasady dla ogólnych modeli (GPAI, foundation models). Twórca otwartego modelu może zostać objęty obowiązkami, nawet jeśli nie sprzedaje klasycznego „produktu”.

Potencjalne źródła ryzyka regulacyjnego:

• brak wymaganej dokumentacji technicznej, gdy model w praktyce pełni rolę general‑purpose AI w krytycznych zastosowaniach,
• nieudostępnienie informacji o treningu, parametrach czy ograniczeniach działania w zakresie wymaganym przez AI Act,
• zignorowanie nakazów organów nadzorczych (np. polecenia ograniczenia dalszej dystrybucji wersji powodującej systemowe szkody).

Mit „AI Act dotyczy tylko komercyjnych vendorów SaaS” jest fałszywy. Regulacja wyraźnie przewiduje odpowiedzialność także po stronie dostawców modeli ogólnego przeznaczenia, niezależnie od modelu biznesowego. Kluczem jest faktyczna rola w łańcuchu – nie to, czy kod jest na GitHubie, czy za paywallem.

Jak otwarte modele zmieniają próg „należytej staranności”

Upowszechnienie gotowych toolboxów dla AI powoduje, że pewne praktyki przestają być „nice to have”, a stają się standardem. Dla twórcy modelu bardzo trudno będzie obronić się stwierdzeniem, że:

• nie przeprowadził żadnych testów biasu,
• nie sprawdził reakcji modelu na oczywiste prompt injection,
• nie udokumentował nawet podstawowych parametrów treningu.

Gdy branża wypracuje de facto standardy (np. minimalny zestaw benchmarków bezpieczeństwa), sądy będą je traktować jako punkt odniesienia. Model udostępniony bez choćby śladu takich testów łatwo można zakwalifikować jako przygotowany z niedbalstwem. Tam, gdzie kiedyś wystarczało ostrzeżenie w README, dziś oczekuje się choćby prostej matrycy ryzyka i listy znanych ograniczeń.

Odpowiedzialność za „dzikie forki” i modyfikacje społeczności

Jedno z częstszych pytań twórców: czy odpowiadają za szkody wyrządzone przez zmodyfikowane wersje modelu? Co do zasady odpowiedzią jest rozdzielenie:

• oryginalnej wersji – za którą odpowiada twórca/maintainer,
• forków i fine‑tuningów – za które odpowiada podmiot dokonujący modyfikacji i udostępniający je dalej.

Jeśli jednak twórca aktywnie promuje konkretny fork, integruje go do oficjalnej dokumentacji („zalecamy użycie wariantu X autorstwa społeczności”) albo zapewnia infrastrukturę do jego masowej dystrybucji, jego rola staje się mniej jednoznaczna. W takim scenariuszu może zostać potraktowany jako współdostawca rozwiązania – przynajmniej w zakresie wiedzy o zagrożeniach.

Rzeczywistość jest więc bardziej złożona niż prosty schemat „za forki nie odpowiadam”. Jeżeli maintainer wie o krytycznych problemach bezpieczeństwa w popularnym forku i nic z tym nie robi (brak ostrzeżeń, brak sprostowań), nietrudno wyobrazić sobie argumentację o współprzyczynieniu się do szkody poprzez zaniechanie.

Ostrzeżenia, disclaimery i „contextual integrity”

Same ogólne disclaimery przestają wystarczać, gdy model jest realnie używany w środowiskach o podwyższonym ryzyku. Coraz większą rolę odgrywają ostrzeżenia kontekstowe, czyli takie, które odnoszą się do konkretnego scenariusza użycia.

Przykład z praktyki: zespół publikuje model do analizy obrazów medycznych, ale w dokumentacji precyzyjnie zapisuje, że:

• model jest przeznaczony do badań naukowych i szkoleń,
• wynik nie może być używany jako jedyne źródło decyzji klinicznej,
• integrator wdrażający model w systemie szpitalnym musi zapewnić dodatkową walidację na własnych danych.

Jeżeli szpital zignoruje te zalecenia i oprze decyzję terapeutyczną wyłącznie na wyniku modelu, będzie mu trudniej przerzucić odpowiedzialność na twórców. Z drugiej strony ogólnikowe „nie używać w medycynie” przy jednoczesnym marketingu w stylu „przełom w diagnostyce radiologicznej” wygląda na próbę przerzucenia ryzyka na innych w sposób mało wiarygodny.

Wewnętrzne procedury i audyt – tarcza nie tylko dla korporacji

Z procedurami compliance kojarzą się głównie duże firmy. Tymczasem nawet mały zespół open source może zyskać sporo, wprowadzając proste mechanizmy:

• checklistę przed publikacją nowej wersji (testy, dokumentacja, ostrzeżenia),
• wewnętrzny review zmian wpływających na bezpieczeństwo modelu,
• zasady reagowania na zgłoszenia społeczności (bug bounty na „prompty z piekła rodem”).

Nie chodzi o perfekcję, lecz o możliwość pokazania, że utrzymanie modelu nie jest chaotycznym hobby, tylko uporządkowaną działalnością. W razie problemów łatwiej wtedy udowodnić, że zespół działał w dobrej wierze, w granicach rozsądnych możliwości. To szczególnie istotne, gdy pojawia się zarzut rażącego niedbalstwa.

Ryzyka biznesowe: ubezpieczenia, inwestorzy i due diligence

Gdy projekt open source dojrzewa w kierunku startupu lub fundacji, pojawiają się dodatkowe wymiary odpowiedzialności. Inwestorzy i partnerzy zaczynają zadawać konkretne pytania:

• czy organizacja ma polisę odpowiedzialności cywilnej obejmującą błędy w oprogramowaniu i AI,
• czy prowadzi rejestr datasetów i ich licencji,
• czy istnieje proces oceny ryzyka przy dodawaniu nowych źródeł danych.

Mit „ubezpieczyciel i tak tego nie zrozumie” szybko upada w zderzeniu z praktyką – rynek polis dla firm technologicznych rośnie, a brokerzy coraz lepiej rozumieją specyfikę AI. Problemem nie jest brak produktów, lecz często brak minimalnego porządku po stronie twórców: nieudokumentowany pipeline, niejasne pochodzenie danych, brak logów treningu. Bez tego trudno zawrzeć sensowną polisę i przekonać inwestorów, że ryzyko prawne jest pod kontrolą.

Transparentność a ekspozycja na odpowiedzialność

Część twórców obawia się, że zbyt duża transparentność (szczegółowe model cards, pełne datasheets) wystawi ich na większe roszczenia: „skoro sami przyznaliście, że model ma bias, to wiedzieliście i mimo to opublikowaliście”. To przekonanie jest tylko częściowo trafione.

Z jednej strony przyznanie się do znanych ograniczeń może być użyte przeciwko twórcy, jeśli równolegle promuje on model do zastosowań, w których te ograniczenia są krytyczne. Z drugiej – brak jakiejkolwiek dokumentacji zostawia pole do zarzutu, że twórcy nie przeprowadzili nawet podstawowej analizy ryzyka. Dla sądu i regulatora sytuacja, w której:

• twórca zidentyfikował ryzyka,
• poinformował o nich w sposób zrozumiały,
• ograniczył rekomendowane zastosowania,

zwykle wygląda lepiej niż całkowita cisza. Transparentność nie znosi odpowiedzialności, ale pozwala pokazać, że ryzyko było świadomie zarządzane, a nie ignorowane.

Gdzie przebiega rozsądna linia obrony twórcy?

Twórca lub maintainer otwartego modelu nie obroni się narracją „to tylko kod” ani prostym przerzuceniem winy na użytkownika. Rozsądna linia obrony budowana jest dużo wcześniej, poprzez:

• przemyślane komunikaty o przeznaczeniu modelu i jego ograniczeniach,
• minimalny, ale realny zestaw testów bezpieczeństwa i jakości,
• jasne rozdzielenie odpowiedzialności w licencji i dokumentacji,
• reakcję na zgłoszenia społeczności zamiast ich ignorowania.

Model otwarty nie jest wolny od odpowiedzialności, ale też nie oznacza automatycznej odpowiedzialności za każde jego użycie. Kluczowe jest to, czy twórca przyczynił się do powstania szkody poprzez działanie lub zaniechanie, które – biorąc pod uwagę jego rolę, wiedzę i realne możliwości – można uznać za nierozsądne. Właśnie w tym punkcie rozstrzyga się, kto ponosi winę za szkodliwe działanie otwartego modelu.

Najczęściej zadawane pytania (FAQ)

Kto ponosi odpowiedzialność za szkody wyrządzone przez otwarty model AI?

W praktyce odpowiedzialność może być rozłożona na kilka podmiotów jednocześnie. Inne obowiązki ma twórca modelu bazowego, inne integrator wpinający model w produkt, a jeszcze inne operator systemu (np. szpital czy bank), który udostępnia narzędzie użytkownikom końcowym.

Prawo nie zna prostego hasła „winny jest open source”. Sąd bada, kto miał realny wpływ na ryzyko: czy model został zaprojektowany lub udostępniony w sposób rażąco nieodpowiedzialny, czy integrator użył go niezgodnie z przeznaczeniem, czy operator zignorował ostrzeżenia i nie wdrożył zabezpieczeń. Możliwe jest więc współistnienie kilku odpowiedzialnych podmiotów za ten sam incydent.

Czy licencja open source (np. MIT, Apache) zwalnia z odpowiedzialności za AI?

Licencja open source reguluje głównie prawa autorskie i to, co wolno zrobić z kodem lub modelem (kopiowanie, modyfikacja, dalsza dystrybucja). Klauzule typu „AS IS, NO WARRANTY” ograniczają odpowiedzialność tylko w pewnym zakresie i nie nadpisują przepisów o ochronie konsumentów, odpowiedzialności za produkt czy o rażącym niedbalstwie.

Mit brzmi: „dam licencję MIT, dodam disclaimer i jestem bezpieczny”. Rzeczywistość jest taka, że licencja może zmniejszyć ryzyko lub ułatwić obronę w sądzie, ale nie zablokuje samej możliwości pozwu. Jeśli np. model jest oczywiście niebezpieczny (brak jakichkolwiek zabezpieczeń w oczywiście ryzykownym zastosowaniu), klauzula w licencji nie ochroni przed oceną sądu.

Jaka jest różnica w odpowiedzialności między otwartym modelem AI a zamkniętą usługą SaaS?

W modelu SaaS kontrola jest scentralizowana: jeden dostawca zarządza infrastrukturą, wagami modelu, aktualizacjami i bezpieczeństwem. To on zwykle jest głównym adresatem roszczeń, bo faktycznie „trzyma w rękach” cały system i decyduje o jego konfiguracji.

Przy otwartym modelu wagi i kod są publicznie dostępne. Każdy może je pobrać, zmodyfikować, dostroić i wykorzystać w zupełnie innym kontekście. Odpowiedzialność się rozprasza: twórca odpowiada za to, co sam zrobił (projekt, trening, ostrzeżenia), integrator – za sposób użycia modelu w produkcie, a operator – za eksploatację w konkretnym środowisku (np. system medyczny). Im więcej aktorów w łańcuchu, tym trudniej wskazać jeden „podmiot winny wszystkiemu”.

Czy udostępnienie otwartego modelu do pobrania (np. na Hugging Face) oznacza pełną odpowiedzialność twórcy?

Samo hostowanie modelu nie oznacza automatycznie pełnej odpowiedzialności za wszystkie jego późniejsze użycia. Twórca lub maintainer odpowiada przede wszystkim za sposób przygotowania i udostępnienia modelu: czy zadbał o minimalne bezpieczeństwo, jasną dokumentację, ostrzeżenia dotyczące ryzyk i przeznaczenia.

Jeżeli ktoś pobierze model, przerobi go i wykorzysta np. do tworzenia deepfake’ów czy kampanii dezinformacyjnej, część odpowiedzialności może przejść na tego użytkownika lub integratora. Mit „jak tylko wrzucę model do katalogu, wszystko co dalej to nie moja sprawa” jest zbyt wygodny. Sąd będzie patrzył, czy ryzykowne skutki dało się przewidzieć i czy twórca zachował minimalną staranność.

Kto odpowiada, gdy otwarty model AI zaszkodzi w krytycznym zastosowaniu (np. medycyna, finanse)?

W zastosowaniach wysokiego ryzyka na pierwszy plan często wychodzi integrator i operator systemu. Jeśli ktoś bierze ogólny model open source i bez dodatkowych testów, certyfikacji czy nadzoru włącza go np. do systemu diagnostyki medycznej, to właśnie ta decyzja biznesowa i projektowa może być uznana za zaniedbanie.

Twórca modelu może mieć udział w odpowiedzialności, jeśli np. reklamował model jako „gotowy do zastosowań medycznych”, mimo że nie spełniał on standardów bezpieczeństwa. Z kolei lekarz lub doradca finansowy, który ślepo polega na odpowiedziach systemu, może odpowiadać zawodowo za zignorowanie swojej roli eksperta. W krytycznych obszarach nie ma „magicznego przerzucenia winy na AI”.

Czy użytkownik końcowy może być pociągnięty do odpowiedzialności za szkodliwe użycie otwartego modelu?

Tak. Jeśli użytkownik celowo wykorzystuje otwarty model do wyrządzenia szkody – np. generuje fałszywe oskarżenia, instrukcje przestępstw, kampanie nienawiści – może ponosić odpowiedzialność karną lub cywilną, niezależnie od tego, że narzędzie było „za darmo” i „dla wszystkich”. Narzędzie nie znosi odpowiedzialności za intencje i działania człowieka.

Mit „to tylko narzędzie, więc winny jest model/twórca” działa na krótką metę. W praktyce prawo od lat radzi sobie z podobnymi sytuacjami: młotek, edytor tekstu czy serwis społecznościowy również mogą być użyte szkodliwie, ale to nie usuwa odpowiedzialności osoby, która świadomie wybrała taki sposób działania.

Jak ograniczyć ryzyko prawne przy korzystaniu z otwartych modeli AI w firmie?

Podstawą jest traktowanie otwartego modelu jak komponentu o potencjalnie wysokim ryzyku, a nie jak „darmowego gadżetu”. W praktyce oznacza to m.in. audyt modelu (testy jakości i bezpieczeństwa), sprawdzenie licencji i dokumentacji, świadome dobranie zastosowań (np. nieużywanie niesprawdzonego modelu w procesach krytycznych), a także wdrożenie własnych filtrów, logów i nadzoru ludzkiego.

Warto też jasno opisać w regulaminach i umowach, do czego służy system, jakie ma ograniczenia i w jakich obszarach nie należy na nim polegać bez dodatkowej weryfikacji. Praktyczny test: jeśli twoja organizacja „ufa modelowi na słowo”, bo pochodzi z dużego repozytorium open source, to ryzyko jest prawdopodobnie niedoszacowane.

Kluczowe Wnioski

• Otwarte modele AI radykalnie różnią się od zamkniętych usług SaaS – brak centralnej kontroli nad wagami, kodem i wdrożeniem sprawia, że trudno wskazać jednego „właściciela ryzyka”, mimo że skutki działania modelu są bardzo realne.
• W ekosystemie open source uczestniczy wiele podmiotów (twórcy architektury, dostawcy danych, trenerzy modelu, platformy, integratorzy, operatorzy, użytkownicy) i każdy z nich może ponosić równoległą odpowiedzialność za swój fragment łańcucha.
• Mit, że „open source = brak odpowiedzialności”, rozpada się w zderzeniu z prawem – licencje regulują głównie prawa autorskie, natomiast odpowiedzialność za szkodę (cywilną, konsumencką, produktową) wynika z odrębnych przepisów, których nie da się skasować samym disclaimerem.
• Kilka linijek w stylu „AS IS, NO WARRANTY” albo licencja MIT nie gwarantują bezkarności – sąd i tak może ocenić, czy doszło do zaniedbania, rażącego niedbalstwa lub naruszenia podstawowych norm bezpieczeństwa, zwłaszcza gdy w grę wchodzą konsumenci.
• Otwarte modele mogą generować bardzo różne szkody: od dezinformacji i kampanii manipulacyjnych, przez dyskryminację i naruszenia praw autorskich, po błędne porady medyczne czy techniczne prowadzące do realnych strat fizycznych lub finansowych.
• Odpowiedzialność przesuwa się w zależności od scenariusza – raz bliżej projektanta modelu (brak zabezpieczeń), innym razem integratora (bezrefleksyjne użycie w systemie krytycznym) albo użytkownika (świadome, szkodliwe wykorzystanie narzędzia).

Bibliografia i źródła

• AI Liability Directive (AILD) – Proposal for a Directive on adapting non-contractual civil liability rules to artificial intelligence. European Commission (2022) – Projekt dyrektywy UE o odpowiedzialności cywilnej za systemy AI
• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). European Union (2024) – Akt o sztucznej inteligencji; definicje systemu AI, obowiązki dostawców i użytkowników
• Directive 85/374/EEC on liability for defective products. Council of the European Communities (1985) – Podstawy odpowiedzialności za produkt niebezpieczny w prawie UE
• Guidelines on the liability of online intermediaries. European Union Agency for Fundamental Rights (2021) – Analiza odpowiedzialności pośredników cyfrowych, analogie do platform AI
• OECD Principles on Artificial Intelligence. OECD (2019) – Zasady odpowiedzialnego rozwoju i wdrażania systemów AI
• Open Source Software: A Legal Guide. Harvard University, Berkman Klein Center (2005) – Analiza licencji open source i ograniczeń klauzul wyłączenia odpowiedzialności
• The Law of Artificial Intelligence and Smart Machines. American Bar Association (2019) – Przegląd odpowiedzialności cywilnej i produktowej w kontekście AI