Czy Twój model jest legalny? Aspekty prawne trenowania modeli na cudzych danych

Po co w ogóle myśleć o legalności danych treningowych?

Trenowanie modeli na cudzych danych łączy w sobie dwa światy: bardzo szybki rozwój technologii i bardzo powolne, ale coraz bardziej restrykcyjne prawo. Technicznie da się „wciągnąć” do pipeline niemal wszystko: logi, social media, PDF-y klientów, publiczne serwisy, cudzy kod źródłowy. Prawnie część tych działań to proszenie się o kłopoty – od poważnych kar finansowych po zablokowanie produktu tuż przed komercyjnym startem.

Pierwsze ryzyko to odpowiedzialność za dane osobowe. Jeżeli w zbiorze treningowym znajdują się informacje pozwalające zidentyfikować osobę, wchodzisz na grunt RODO (lub innych regulacji ochrony danych, jeśli działasz poza UE). To oznacza potencjalne kary administracyjne, obowiązek zgłaszania naruszeń, a w skrajnych sytuacjach konieczność zatrzymania przetwarzania lub usunięcia modelu z produkcji. Dla projektu ML oznacza to nie tylko stres, ale realny koszt: przepisywanie pipeline, retrening na nowym zbiorze, renegocjacje z klientami.

Drugie pole minowe to prawa autorskie do danych treningowych. Treści, obrazy, kod, muzyka, dokumentacja – bardzo często są to utwory chronione prawem. Sam fakt, że coś jest publicznie dostępne w sieci, nie znaczy, że możesz tego legalnie skopiować, zapisać w dataset’cie i wykorzystać do trenowania modeli, szczególnie komercyjnych. W grę wchodzą roszczenia licencyjne, żądania odszkodowań, a przy głośniejszych projektach – także ryzyko reputacyjne.

Trzecia kwestia to prosty wpływ aspektów prawnych na budżet, roadmapę i wycenę projektu ML. Jeżeli temat legalności danych treningowych ignorujesz na początku, to:

• architektura pipeline’u bywa zbyt „luźna” (brak rozdzielenia danych osobowych, brak wersjonowania dataset’ów),
• umowy z klientami nie przewidują trenowania modeli na ich danych – a więc przeniesienie modelu na innych klientów robi się prawnie wątpliwe,
• brakuje dokumentacji przetwarzania, co podbija koszt ewentualnego audytu lub certyfikacji.

Znacznie taniej jest na starcie zdefiniować: jakiego typu dane będziesz mieć, z jakich źródeł, na jakiej podstawie prawnej, w jakim celu, z jakimi ograniczeniami. To nie musi być od razu 100-stronicowa polityka, wystarczy kilka świadomych decyzji i prosty zestaw dokumentów.

Różnica między „technicznie możliwe” a „prawnie dopuszczalne”

Machine learning jest kuszący, bo wiele przeszkód technicznych da się obejść: jeśli API ma limity, można scrapować; jeśli dostęp do danych jest płatny, można „pożyczyć” dataset od kogoś; jeśli klient nie do końca rozumie kwestie danych, można rozszerzyć użycie „po cichu”. Problem w tym, że prawo nie interesuje się kreatywnością inżyniera, tylko tym, czy masz podstawę do przetwarzania danych oraz szanujesz cudze prawa.

Przykładowo: technicznie możesz zbudować crawlera, który zaciągnie całą zawartość portalu ogłoszeniowego i wytrenuje na tym model do wyceny nieruchomości. Prawnie może to naruszać regulamin serwisu, prawa autorskie do opisów i zdjęć, a do tego – przy danych o osobach – RODO. W najlepszym przypadku skończy się blokadą IP lub konta, w gorszym pismami od prawników.

Podobnie z kodem z GitHuba: fakt, że widzisz repozytorium, nie oznacza, że możesz bezrefleksyjnie zasilić nim model generujący kod dla klientów korporacyjnych. Licencja może wymagać np. udostępnienia Twojego produktu na zasadach open source, jeśli okaże się, że korzysta on z dzieł objętych licencją copyleft.

Jak temat legalny wpływa na budżet i produkt

Z prawnego punktu widzenia każdy projekt ML ma trzy główne koszty: uzyskanie i utrzymanie legalnej podstawy przetwarzania danych, utrzymanie bezpieczeństwa i dokumentacji, oraz obsługę ewentualnych roszczeń. Z biznesowego punktu widzenia możesz te koszty zredukować, jeśli odpowiednio wcześnie zaprojektujesz proces:

• architektura techniczna – łatwo wydzielić dane osobowe, zastosować anonimizację, logować źródła i wersje danych, gdy pipeline powstaje od zera; dużo trudniej, gdy jest już produkcyjny i „posklejany” z wielu ad hoc rozwiązań,
• zakres danych – im mniej wrażliwych danych i im bardziej agregowane, tym niższe ryzyko prawne i niższy koszt zabezpieczenia (mniej polityk, mniej kontroli, mniej testów),
• umowy z klientami i partnerami – jeżeli od razu zapiszesz w nich możliwość trenowania modeli, masz jasny grunt pod rozwój produktu; jeśli pomijasz ten temat, każdy kolejny krok wymaga indywidualnych negocjacji.

Dla mniejszych firm i zespołów szczególnie ważne jest unikanie sytuacji, w której po pół roku pracy ktoś zgłasza, że nie wyraża zgody na użycie danych, a Ty nie masz jak „wyjąć” jego rekordu z już wytrenowanego modelu. Takie sytuacje bywają do zarządzenia, ale są kosztowne – czasowo, finansowo i PR-owo.

Proste scenariusze ryzyka – trzy typowe przypadki

Najczęściej w praktyce pojawiają się trzy sytuacje:

• Startup trenuje model na danych klienta B2B – np. system rekomendacji trenowany na danych sklepu internetowego. Jeśli umowa nie przewiduje użycia danych do trenowania modeli „dla innych” (np. modelu uniwersalnego SaaS), klient może zarzucić naruszenie zaufania lub przepisów RODO. Rozwiązanie: jasny zapis w umowie, kto jest administratorem danych, na jakiej podstawie i w jakim celu wolno trenować model.
• Model trenowany na danych z publicznego serwisu – np. crawler zbierający komentarze z forum w celu odczytywania sentymentu. Publiczność treści nie oznacza zgody na dowolne użycie, a wiele serwisów zakazuje scrapingu lub użycia danych do trenowania AI. Rozwiązanie: sprawdzać regulaminy, korzystać z oficjalnych API lub szukać dataset’ów z jasną licencją.
• Gotowy publiczny dataset z internetu – np. darmowy zbiór zdjęć do wykrywania obiektów. Nawet jeśli dataset jest dostępny na GitHubie, trzeba sprawdzić licencję: czy dopuszcza użycie komercyjne, czy wymaga atrybucji, czy nie ma ograniczeń dotyczących modelu produkcyjnego.

W każdym z tych przypadków koszt świadomego podejścia (kilkadziesiąt minut na weryfikację i prostą dokumentację) jest zwykle kilkanaście razy niższy niż koszt „naprawiania” sytuacji po fakcie.

Jakie dane w ML są „wrażliwe” z punktu widzenia prawa?

Rodzaje danych a różne reżimy prawne

Z perspektywy prawa nie wszystkie dane treningowe są równorzędne. Ten sam plik CSV może podlegać kilku zupełnie różnym reżimom prawnym. Praktycznie da się wyróżnić kilka kategorii:

• dane osobowe – wszystko, co pozwala zidentyfikować konkretną osobę (bezpośrednio lub pośrednio),
• dane szczególnej kategorii (wrażliwe) – np. zdrowotne, biometria, poglądy polityczne, przynależność związkowa, dane genetyczne,
• „zwykłe” dane nieosobowe – np. parametry techniczne urządzeń, anonimowe agregaty statystyczne, wyniki pomiarów bez możliwości powiązania z osobą,
• treści chronione prawem autorskim – teksty, zdjęcia, grafiki, muzyka, nagrania, kod źródłowy, dokumentacja,
• tajemnica przedsiębiorstwa – dane biznesowe, know-how, dokumenty wewnętrzne, których ujawnienie mogłoby zaszkodzić firmie.

Trenowanie modelu na każdej z tych kategorii uruchamia inny „zestaw” obowiązków i ryzyk. Dane osobowe podlegają RODO, dane wrażliwe – jeszcze ostrzejszym zasadom. Treści autorskie wymagają licencji lub innej podstawy zastosowania. Tajemnica przedsiębiorstwa obliguje do odpowiedniego zabezpieczenia technicznego i organizacyjnego (np. NDA, kontrola dostępu, audyt logów).

Jeśli dataset zawiera kilka rodzajów danych jednocześnie, trzeba sobie odpowiedzieć na pytanie: które z nich są prawnie „najdroższe” i jak możliwie szybko je zredukować lub odseparować. Zwykle najwięcej problemów sprawiają dane osobowe w połączeniu z treściami autorskimi (np. e-maile klientów, czaty supportowe, treści zgłoszeń do helpdesku). To idealny materiał do trenowania modeli NLP, ale również mieszanka większości wrażliwych aspektów prawnych naraz.

Kiedy informacja staje się daną osobową

W ML często pojawia się pokusa traktowania wszystkiego jako „surowych logów” albo „po prostu tekstu”. Problem w tym, że definicja danych osobowych jest szeroka: to każda informacja o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Nie chodzi więc tylko o imię, nazwisko i PESEL.

Przykłady danych, które z pozoru są techniczne, ale potrafią stać się danymi osobowymi:

• identyfikator użytkownika w aplikacji, jeśli można go powiązać z kontem,
• adres IP, szczególnie w połączeniu z datą, geolokalizacją lub informacją o urządzeniu,
• treść zapytania do wyszukiwarki wewnętrznej, jeśli zawiera imiona, konkretną sytuację życiową lub inne cechy identyfikujące,
• nagranie głosu – nawet bez imienia i nazwiska, ale z unikalnym timbre i kontekstem,
• zdjęcie, na którym twarz da się rozpoznać automatycznie (lub manualnie przy niewielkim wysiłku).

W projektach ML praktyczna zasada jest prosta: jeśli człowiek z zespołu, mając dostęp do surowych danych, jest w stanie połączyć rekord z konkretną osobą, to najpewniej masz do czynienia z danymi osobowymi. A wtedy trzeba mieć podstawę prawną przetwarzania, polityki bezpieczeństwa i cały „pakiet” obowiązków administratora lub podmiotu przetwarzającego.

Dane syntetyczne i zanonimizowane – co rzeczywiście wypada z RODO

Popularną strategią ograniczania ryzyka RODO jest korzystanie z danych syntetycznych albo „zanonimizowanych”. Problem w tym, że często jest to anonimizacja tylko z nazwy. Usunięcie imion i adresów nie wystarczy, jeśli na podstawie pozostałych pól wciąż można wrócić do osoby.

Anonimizacja oznacza trwałe usunięcie powiązania z osobą, w taki sposób, że identyfikacja nie jest możliwa żadnymi „rozsądnymi” środkami, jakimi dysponuje administrator lub ktoś inny. Taka operacja wyciąga dane spod RODO – ale jest trudna do zrobienia dobrze. W praktyce wymaga m.in.:

• usunięcia lub przekształcenia oczywistych identyfikatorów (ID, e-maile, numery telefonów),
• zastąpienia rzadkich kombinacji cech (np. połączenie stanowiska, miejsca pracy, wieku) bardziej ogólnymi klasami,
• sprawdzenia, czy połączenie wielu pól nie pozwala na „odgadnięcie” osoby.

Pseudonimizacja to sytuacja, w której dane nadal są powiązane z osobą, tylko identyfikatory zostały zastąpione innymi (np. losowym ID, hashem). Administrator wciąż może cofnąć ten proces i ustalić, o kogo chodzi; czasem może to zrobić również ktoś z zewnątrz, łącząc dane z innymi źródłami. Pseudonimizacja wciąż podlega RODO, ale obniża ryzyko i często łagodzi wymogi techniczne.

Dane syntetyczne, generowane na podstawie rzeczywistych, też nie są automatycznie bezpieczne prawnie. Jeśli algorytm generujący jest na tyle prosty, że potrafi „przeciekać” oryginalne rekordy (np. przez overfitting), albo jeśli da się odtworzyć charakterystyki pojedynczych osób, to mogą pojawić się wątpliwości. Przy projektach komercyjnych dobrze jest założyć konserwatywnie: jeśli dane syntetyczne mają podobne rozkłady i możliwe jest odtworzenie cech konkretnych osób, lepiej traktować je jak dane osobowe przy projektowaniu zabezpieczeń.

Macierz ryzyka vs. typ danych – co jest najtańsze w obsłudze

Pod kątem kosztów prawnych wygodnie jest spojrzeć na typ danych przez prostą „macierz ryzyka”. Nie chodzi o wyrafinowane modele, tylko o ocenę: gdzie będą największe wymagania dokumentacyjne i gdzie potencjalne kary są najwyższe.

RODO i dane osobowe w trenowaniu modeli – praktyczny przegląd

Administrator, procesor i „kto właściwie odpowiada za model”

Przy danych osobowych kluczowe jest ustalenie ról. Od tego zależy, kto ma obowiązki informacyjne, kto prowadzi rejestry, a kto musi podpisać umowę powierzenia.

• Administrator danych – podmiot, który decyduje o celach i sposobach przetwarzania. Jeśli firma produktowa buduje model na własnych danych użytkowników, zwykle to ona jest administratorem.
• Podmiot przetwarzający (procesor) – realizuje przetwarzanie „w imieniu” administratora, zgodnie z jego instrukcją. Typowy przypadek: software house, który trenuje model na danych klienta, lub dostawca chmurowego narzędzia ML.
• Współadministratorzy – sytuacja, gdy dwie strony realnie razem decydują o celu i sposobie użycia danych (np. wspólny projekt badawczo‑komercyjny).

Jeśli rola nie jest jasno określona, ryzyko zwykle ląduje tam, gdzie są „głębsze kieszenie” – czyli po stronie większej organizacji. Taniej jest poświęcić godzinę na spisanie, kto jest kim, niż potem tłumaczyć się przed klientem lub organem, że „tak nam to wyszło w praktyce”.

Podstawa prawna przetwarzania – zgoda to nie jedyna opcja

Trenowanie modeli na danych osobowych musi mieć podstawę z art. 6 RODO (dla danych zwykłych) albo art. 9 (dla szczególnych kategorii). W praktyce w ML najczęściej pojawiają się:

• realizacja umowy – np. personalizacja rekomendacji produktów dla zalogowanego użytkownika, jeśli jest to wyraźnym elementem usługi,
• prawnie uzasadniony interes administratora – optymalizacja działania systemu, poprawa jakości wyszukiwarki, wykrywanie nadużyć; wymaga przeprowadzenia testu równowagi,
• zgoda – rzadziej opłacalna przy core’owych funkcjach systemu, bardziej przy dodatkowych eksperymentach, beta‑funkcjach, testowaniu nowych modeli.

Najtańszy w utrzymaniu jest zwykle uzasadniony interes, ale tylko jeśli da się go racjonalnie obronić i udokumentować. Prosta, pisemna analiza (1–2 strony) z opisem celu, wpływu na użytkowników i środków minimalizujących ryzyko często wystarczy, by mieć „parasol” w razie pytań regulatora czy audytu klienta.

Obowiązek informacyjny – jak nie robić z tego projektu na miesiąc

Użytkownik musi wiedzieć, że jego dane służą do trenowania i ulepszania modeli. Nie oznacza to pisania eseju prawniczego. W praktyce sprawdza się podejście warstwowe:

• krótkie zdanie przy formularzu lub w ustawieniach – np. „Twoje dane mogą być wykorzystywane do ulepszania algorytmów i jakości usługi”,
• szczegóły w polityce prywatności – opis typów danych, celów trenowania, podstawy prawnej, okresu przechowywania, praw użytkownika.

Przy małych projektach zamiast dedykowanego „polityko‑potwora” zwykle wystarczy aktualizacja istniejącego dokumentu o 1–2 nowe sekcje. Kosztem kilku godzin pracy prawnika buduje się bufor bezpieczeństwa na lata rozwoju produktu.

Ocena skutków dla ochrony danych (DPIA) – kiedy naprawdę trzeba

DPIA (Data Protection Impact Assessment) to formalna analiza ryzyka, wymagana m.in. gdy przetwarzanie jest „na dużą skalę”, obejmuje dane wrażliwe albo wiąże się z systematycznym monitorowaniem. W ML temat często wychodzi przy:

• modelach profilujących zachowanie użytkowników,
• systemach scoringowych (np. ryzyko fraudu, wiarygodność płatnicza),
• przetwarzaniu dużych wolumenów danych zdrowotnych czy lokalizacyjnych.

Jeżeli projekt potencjalnie podpada pod DPIA, można podejść do tego dwutorowo:

• wariant „minimalistyczny” – szablon DPIA oparty na wytycznych organu, wypełniony przez product ownera z konsultacją prawnika,
• wariant „oszczędny, ale porządny” – jedna wspólna DPIA dla całej „rodziny” modeli (np. wszystkie modele rekomendacyjne), z okresowym update’em zamiast pisania od zera dla każdego pipeline’u.

W wielu firmach DPIA jest przedstawiana jako biurokratyczny potwór, a w praktyce przy rozsądnym podejściu można zmieścić się w 1–2 dniach pracy rozłożonych na kilka osób i mieć spokój przy nowych iteracjach modelu.

Przechowywanie danych a „model jako nowe przetwarzanie”

RODO nie odnosi się wprost do modeli, ale organy coraz częściej patrzą na to, czy:

• dane wykorzystywane do trenowania nie są trzymane „na wszelki wypadek” bez potrzeby,
• model nie pozwala zrekonstruować danych źródłowych (np. przechowywania pełnych rekordów w embeddingach),
• jest proces usuwania danych użytkownika również z pipeline’ów treningowych.

Praktyczny kompromis to:

• utrzymywanie odrębnych retention policy dla danych operacyjnych i treningowych,
• projektowanie pipeline’u tak, żeby dało się odciąć dane danego użytkownika przy retreningu (np. poprzez flagi „do usunięcia” lub okresowe pełne przebudowy modelu),
• unikanie przechowywania czystych tekstów użytkowników w parametrach modelu – szczególnie przy małych, prywatnych datasetach.

Pełna „unlearning” na żądanie bywa kosztowna, ale już samo skrócenie czasu życia surowych logów i regularny retraining znacznie obniża ryzyko naruszenia zasady minimalizacji.

Prawa autorskie a dane treningowe – kiedy wolno, a kiedy trzeba licencji

Model jako „urządzenie techniczne” a dozwolony użytek

W europejskim prawie autorskim pojawiły się przepisy o eksploracji tekstów i danych (TDM – text and data mining). Dla trenowania modeli istotne są dwie ścieżki:

• eksploracja do celów badawczych przez instytucje naukowe i kulturalne – szersze wyłączenia, ale zwykle nie dotyczą komercyjnych startupów,
• eksploracja do innych celów, w tym komercyjnych – dopuszczalna, o ile właściciel praw nie zastrzegł w sposób „odpowiedni” braku zgody (np. w regulaminie, metadanych, robots.txt).

To oznacza, że sama czynność „przepuszczenia” treści przez model nie zawsze wymaga licencji, o ile treści zostały pozyskane legalnie i nie ma skutecznego zastrzeżenia TDM. Problem w tym, że większość dużych serwisów internetowych takie zastrzeżenia już dodaje, często szerzej niż wymaga dyrektywa.

Licencje a wtórne wykorzystanie treści w modelu

Nawet jeśli eksploracja tekstów jest dopuszczalna, inaczej wygląda kwestia wykorzystywania efektów. Kłopoty pojawiają się w dwóch scenariuszach:

• model generuje treści, które są zbyt podobne do materiałów treningowych (prawie dosłowne cytaty, charakterystyczne fragmenty kodu),
• klient korzysta z modelu tak, jakby miał pełne prawa do wszystkich wyników, a część outputu faktycznie jest utworem zależnym.

Jeżeli trenowanie odbywa się na materiałach klienta (np. bazie artykułów lub dokumentacji), najtańszą ochroną jest prosty zapis w umowie, że klient gwarantuje posiadanie praw do treści, a dostawca ma prawo użyć ich do trenowania i eksploatacji modelu w ustalonym zakresie. To przesuwa znaczną część ryzyka na stronę, która ma realny wpływ na źródło danych.

„Fair use” vs. europejskie realia

Często powtarzany argument „w USA mają fair use, więc trenowanie jest OK” w UE ma ograniczone zastosowanie. W polskim (i unijnym) systemie nie ma tak szerokiej klauzuli generalnej. Działa konkretna lista wyjątków (dozwolony użytek, TDM, prawo cytatu). Wniosek z tego do projektowania rozwiązań ML jest pragmatyczny:

• przy treściach wewnętrznych (intranet, dokumentacja, materiały szkoleniowe) dużo można załatwić umową i politykami wewnętrznymi,
• przy treściach zewnętrznych, z internetu – bezpieczniejsza jest strategia „albo licencja, albo dataset z jasnymi warunkami, albo TDM bez reuse’u treści 1:1 w outputach”.

Próba oparcia produkcyjnego, komercyjnego systemu na „nie do końca wiadomo, ale może się uda” ma sens tylko wtedy, gdy potencjalne roszczenia są relatywnie małe, a łatwość wymiany modelu – duża.

Jak praktycznie ograniczyć ryzyko „przecieków” treści

Kilka prostych praktyk obniża prawdopodobieństwo, że model zacznie wypuszczać fragmenty chronionych materiałów:

• regularne testy generacji – proste prompty typu „wypisz mi pełną treść dokumentu X” lub „podaj listę wszystkich artykułów…” pozwalają wychwycić ewidentne overfittingi,
• ograniczenie kontekstu w narzędziach produkcyjnych – np. zamiast trenowania LLM na całości korpusu, stosowanie RAG (retrieval‑augmented generation) z kontrolą, co i na jakiej licencji trafia do bazy wektorowej,
• filtry na output – wykrywanie długich ciągów identycznych z materiałami źródłowymi (np. powyżej określonej liczby znaków) i blokowanie takich odpowiedzi.

Takie zabezpieczenia nie są cudownym lekiem, ale przy rozsądnych kosztach technicznych znacząco zmniejszają ryzyko sporu o „kopiowanie” treści przez model.

Web scraping i API jako źródło danych – granice legalności

Regulamin serwisu vs. „przecież to jest w internecie”

To, że strona jest publicznie dostępna, nie oznacza automatycznego prawa do scrapowania jej na potrzeby trenowania modeli. W grę wchodzą trzy porządki:

• prawo autorskie – treści na stronie są często chronione, a masowe kopiowanie może naruszać majątkowe prawa autorskie,
• prawo cywilne/umowne – regulamin może zakazywać scrapingu, użycia danych do AI lub ponownej publikacji,
• prawo ochrony danych – jeśli scrapujesz komentarze z danymi osobowymi, wracasz do wymogów RODO.

W praktyce kosztowny jest nie tylko potencjalny spór, ale też utrata dostępu do cennego źródła danych (ban IP, odcięcie API). Dlatego przy projektach, które mają żyć dłużej niż kilka sprintów, sensowniejsze jest szukanie trwałego źródła danych niż „partyzancki” scraping wszystkiego, co się da.

Scraping z szacunkiem do serwisu – minimalny standard

Jeżeli mimo wszystko scrapujesz, nawet na potrzeby prototypu, warto wdrożyć kilka tanich środków ostrożności:

• sprawdzenie regulaminu i polityki prywatności pod kątem zakazu scrapingu i wykorzystania danych w AI,
• respektowanie robots.txt i limitów zapytań, żeby nie przeciążać serwisu,
• anonimizacja lub pseudonimizacja danych osobowych jak najbliżej źródła (już na etapie pipeline’u scrapującego),
• wyraźne oznaczenie datasetu jako niekomercyjnego/prototypowego, jeżeli nie masz podstaw, żeby używać go w produkcji.

To nie gwarantuje pełnej zgodności z każdym możliwym regulaminem, ale zdecydowanie zmniejsza ryzyko poważnego konfliktu. Przy pierwszych sygnałach sprzeciwu (np. mail od administratora serwisu) najmniej kosztowne jest szybkie wycofanie datasetu niż walka o „prawo do scrapowania”.

API – mniej problemów, ale nie za darmo

Oficjalne API wielu serwisów (social media, sklepy, platformy treści) oferują znacznie klarowniejsze zasady niż scraping HTML. W zamian pojawiają się limity, opłaty i wymagania dotyczące sposobu użycia danych.

Przy wyborze źródła danych rozsądne pytania brzmią:

• czy warunki API wprost pozwalają na użycie danych do trenowania modeli,
• czy jest zakaz łączenia danych z innymi źródłami, tworzenia profili lub przechowywania poza określony czas,
• jakie są mechanizmy odwoływania dostępu (np. w razie zmian regulaminu).

API bywa droższe w sensie finansowym, ale zwykle tańsze od strony ryzyka prawnego i stabilności projektu. Szczególnie gdy mówimy o biznesie, który ma zależeć od tych danych przez dłuższy czas.

Dane od klienta, partnera, dostawcy – jak zabezpieczyć się umownie

Powierzenie przetwarzania vs. współadministrowanie

Gdy klient przekazuje dane do trenowania modelu, trzeba ustalić, czy:

• dostawca działa jako procesor – przetwarza dane wyłącznie na zlecenie klienta, w jego celach,

Ustalenie roli stron w praktyce ML

Rozjazd między teorią a praktyką pojawia się natychmiast po pierwszym warsztacie z klientem. Ten „chce model”, ale nie zawsze ma sprecyzowane, kto w jakim celu i na jakiej podstawie prawnej przetwarza dane.

• Procesor (podmiot przetwarzający) – sensowny model przy klasycznym scenariuszu: klient ma swój cel (np. automatyzacja obsługi klienta), ma dane, a dostawca tylko „obrabia” je technicznie – trenuje model, hostuje, serwisuje.
• Współadministrator – gdy dostawca realnie współdecyduje o celach (np. buduje wspólny produkt dla wielu klientów, uczy model na danych różnych podmiotów, żeby oferować „platformę AI”).

Im bardziej model jest „indywidualny” dla jednego klienta, tym łatwiej obronić status procesora. Im więcej reużycia i „platformowości”, tym bliżej do współadministrowania – a to oznacza więcej obowiązków po stronie dostawcy (np. współodpowiedzialność za realizację praw osób, które są w danych).

Z perspektywy budżetu projektowego taniej jest na starcie założyć prosty, przewidywalny model (procesor + standardowa umowa powierzenia) i dopiero przy realnej potrzebie wchodzić w eksperyment z „wspólnym” trenowaniem danych różnych klientów.

Kluczowe klauzule w umowach „data + model”

W umowie o trenowanie lub wdrożenie modelu na danych klienta kilka zapisów robi największą różnicę przy najmniejszym wysiłku negocjacyjnym. Zamiast tworzyć potężne załączniki, lepiej dopracować te kilka punktów:

• Gwarancja uprawnień klienta do danych – klient oświadcza, że ma podstawę prawną i prawa autorskie/licencje do wszystkiego, co przekazuje. Bez tego każda kontrola lub roszczenie może „przeskoczyć” na dostawcę.
• Zasady użycia danych do trenowania – jasno: czy dane są używane tylko do modelu dla danego klienta, czy też mogą zasilać modele ogólne (i np. w jakiej formie: surowe dane, embeddingi, zanonimizowane agregaty).
• Zakaz dalszego użycia po zakończeniu współpracy – jeśli biznes klienta jest wrażliwy, zwykle wymusi on, żeby po rozwiązaniu umowy dane treningowe i pochodne zostały usunięte lub zanonimizowane w określonym czasie.
• Odpowiedzialność i odszkodowanie – prosty mechanizm: jeśli roszczenie wynika z tego, że klient wrzucił „lewe” dane (bez praw, bez zgód), to klient pokrywa koszty obrony dostawcy w uzgodnionym limicie.
• Opis środków bezpieczeństwa – krótki, ale konkretny: szyfrowanie, kontrola dostępu, logowanie operacji. Bez katalogu wszystkich możliwych norm, które potem trzeba wdrażać.

Takie minimum kontraktowe można wdrożyć w każdym projekcie ML bez armii prawników. Zwykle najwięcej czasu zabiera uzgodnienie, czy dane mogą zasilać „wspólne” modele – i tu wchodzą kompromisy produktowo‑biznesowe.

Dane osobowe w kontraktach – co doprecyzować

Jeśli w danych klienta są dane osobowe, standardowa umowa powierzenia przetwarzania (DPA) powinna być uzupełniona o kilka specyficznych dla ML kwestii. Najczęściej brakuje w niej jasnej odpowiedzi na pytanie, co dzieje się z modelem i logami.

Przydatne są następujące doprecyzowania:

• Zakres operacji – wprost wpisać „trenowanie, fine‑tuning, ewaluacja, monitorowanie jakości modelu, logowanie interakcji użytkowników w celach diagnostycznych”. Bez tego przy pierwszej kontroli pada pytanie: „Na jakiej podstawie prawnej logujecie prompty i odpowiedzi?”.
• Czas przechowywania logów i datasetów treningowych – konkretny okres (np. X dni dla logów, Y miesięcy dla datasetów), a nie „tak długo, jak to konieczne” – inaczej zasada minimalizacji zostaje tylko na prezentacjach.
• Mechanizmy realizacji praw osób – opis, jak w praktyce „wyjmujesz” dane konkretnej osoby z pipeline’u: czy usuwasz z logów, czy dodatkowo oznaczasz próbki w datasetach, kiedy wpływa to na retraining.
• Podprocesorzy – jeżeli korzystasz z chmury lub zewnętrznych narzędzi MLOps, lepiej od razu to wymienić. Ukrywanie tego zazwyczaj kończy się długą wymianą maili przed startem projektu.

Rozsądne jest przygotowanie jednego, lekkiego wzorca DPA „pod ML” i konsekwentne stosowanie go w projektach, zamiast każdorazowo łatać ogólne szablony IT klauzulami o modelach i logach.

Modele współdzielone vs. „model prywatny” klienta

Z punktu widzenia kosztów wdrożenia dostawcy naturalnie ciąży w stronę jednego, współdzielonego modelu (niższe koszty infrastruktury, łatwiejszy rozwój). Z perspektywy ryzyka prawnego i zaufania klienta często bezpieczniejszy jest wariant „model prywatny”.

Można przyjąć kilka praktycznych wzorców:

• Model bazowy + prywatny fine‑tuning – wspólny jest tylko model bazowy (pre‑trained), natomiast fine‑tuning na danych klienta odbywa się w oddzielnym projekcie, bez mieszania datasetów. Klient wie, że jego dane nie „zasilają” innych.
• Wspólny model, ale z twardą anonimizacją – do trenowania wspólnego modelu trafiają wyłącznie dane po zanonimizowaniu/pseudonimizacji, bez bezpośrednich identyfikatorów i w możliwie dużej agregacji.
• Model jako usługa + RAG na danych klienta – dostawca nie trenuje modelu na danych klienta, tylko zapewnia runtime, a dane klienta trafiają jedynie do warstwy wyszukiwania (RAG). To mocno upraszcza rozmowę o prawach autorskich i reuse’ie danych.

Im wyraźniej rozdzielone są te scenariusze, tym łatwiej sprzedać usługę bez lawiny pytań od działu prawnego po stronie klienta.

Open data, open source i komercyjne dataset’y – co naprawdę wolno

„Darmowe” dane, które wcale nie są za darmo

Publiczne zbiory danych, otwarte repozytoria i open source kuszą, bo redukują koszty startu. Problem pojawia się wtedy, gdy etykieta „open” jest traktowana jak pełne „rób co chcesz”. Różne licencje dają zupełnie różne poziomy swobody.

Przed wrzuceniem datasetu do pipeline’u treningowego sensowne jest sprawdzenie trzech rzeczy:

• czy licencja obejmuje użycie komercyjne – licencje typu „non‑commercial” automatycznie zamykają drogę do produktu na rynku,
• czy są wymogi share‑alike – niektóre licencje (np. CC BY‑SA) wymagają udostępnienia pochodnych na tych samych warunkach, co może gryźć się z modelem biznesowym SaaS,
• czy wymogi atrybucji są realne do spełnienia – przy setkach źródeł nie da się sensownie wypisać każdego autora w GUI aplikacji, trzeba mieć prosty, realistyczny mechanizm (np. stronę „źródła danych” w dokumentacji).

W większości projektów wystarczy rozróżnić: „datasety do badań/prototypów” i „datasety produkcyjne”. To tania separacja, która pozwala testować różne źródła bez od razu wikłania ich w produkt komercyjny.

Open source a trenowanie modeli – kod, modele, pipeline’y

W obszarze ML „open source” dotyczy nie tylko kodu, ale też samych modeli i narzędzi do trenowania. Każdy element może mieć inną licencję, z innymi konsekwencjami.

Typowe przypadki:

• kod frameworków ML (PyTorch, TensorFlow, scikit‑learn) – zwykle licencje permissive (BSD, Apache 2.0) i bezpieczne dla biznesu, byle zachować noty licencyjne,
• open‑source’owe modele – tu spektrum jest szerokie: od bardzo liberalnych (możesz używać, fine‑tunować, sprzedawać) do mocno ograniczających (np. zakaz użycia w pewnych branżach, zakaz hostowania jako API dla third parties),
• pipeline’y i narzędzia MLOps – czasem łączą licencję open‑source (na core) z dodatkowymi płatnymi modułami lub ograniczeniami SaaS.

Upraszczając – open source jest świetnym sposobem na obniżenie kosztów startu, ale wymaga choćby podstawowego przeglądu licencji. Dobrą praktyką jest prosty rejestr: „z jakich modeli/kodów korzystamy” z linkiem do licencji i krótkim opisem, czy użycie komercyjne jest dozwolone.

Komercyjne dataset’y – kiedy opłaca się zapłacić

Płatne zbiory danych wydają się na początku „za drogie” w porównaniu z darmowym scrapowaniem. Po podliczeniu czasu devów, ryzyka prawnego i patchowania pipeline’u zwykle wychodzi, że jedno sensowne źródło z jasną licencją jest tańsze niż trzy pokrętne „darmowe”.

Przy zakupie datasetu kilka punktów decyduje, czy transakcja ma sens:

• jasna licencja na trenowanie i hosting modelu – najlepiej wprost napisane: „możesz użyć do trenowania komercyjnych modeli, hostować je jako usługę dla klientów”
• brak obowiązku share‑alike – komercyjne modele rzadko mogą sobie pozwolić na otwarcie pełnych wag i kodu tylko dlatego, że skorzystały z płatnego datasetu,
• prawo do utrzymania modelu po zakończeniu licencji – część dostawców próbuje przemycić zapis, że po końcu umowy trzeba usunąć nie tylko dane, ale i „modele wytrenowane na tych danych”, co w praktyce unieważnia większość inwestycji.

Najczęściej rozsądnym kompromisem jest zgoda na dalsze używanie już wytrenowanych modeli z zastrzeżeniem, że nie można ich dalej douczać na tych samych danych bez odnowienia licencji.

Open data administracji publicznej i NGO – specyfika

Dane udostępniane przez administrację publiczną, instytuty badawcze czy NGO zwykle mają klarowniejsze warunki i są mniej obciążone ryzykiem roszczeń indywidualnych podmiotów gospodarczych. Nie znaczy to jednak, że można z nich korzystać bezrefleksyjnie.

Przy pracy z open data przydaje się prosty checklist:

• sprawdzenie warunków ponownego wykorzystania (często zgodnych z PSI – reuse of public sector information),
• ocena, czy w danych są dane osobowe (np. mikro‑dane statystyczne, dane geolokalizacyjne),
• ustalenie, czy dana instytucja wymaga atrybucji lub informacji o przetwarzaniu danych w celach komercyjnych.

Część instytucji publicznych chętnie współpracuje z firmami na zasadzie „projektów pilotażowych”. To bywa tańsze niż kupno gotowego datasetu, a przy okazji porządkuje kwestię praw do danych w umowie o współpracy.

Mieszanie różnych źródeł danych – pułapki „koktajlu licencyjnego”

W realnym projekcie rzadko korzysta się z jednego, czystego źródła. Dane produkcyjne klienta mieszają się z open source, open data i czasem jeszcze z komercyjnymi datasetami. Z prawnego punktu widzenia to miks licencji, z których każda może mieć inny „stopień toksyczności”.

Żeby nie ugrzęznąć w analizach, praktycznie można zastosować trzy poziomy ostrożności:

1. Warstwa „wewnętrzna” – dataset do R&D, eksploracji, testowania hipotez. Tu mogą się pojawić bardziej „ryzykowne” źródła (np. licencje non‑commercial, eksperymentalny scraping), ale ta warstwa nigdy nie trafia do klienta.
2. Warstwa „produktowa” – tylko źródła z jasną zgodą na komercyjne użycie i trenowanie modeli. To z tej warstwy buduje się modele, które wychodzą na zewnątrz.
3. Warstwa „kliencka” – dane jednego konkretnego klienta, używane na jasno opisanych zasadach (powierzenie, licencja, brak reuse’u między klientami, chyba że jest na to osobna zgoda).

Taki podział nie wymaga rozbudowanych systemów prawnych – wystarczy, że zespół techniczny ma prostą tabelkę: „co z czego korzysta” i które komponenty są bezpieczne do włączenia w ofertę dla klienta. To mały koszt organizacyjny, a bardzo skutecznie ogranicza ryzyko, że przypadkiem w produkcie wylądują dane z datasetu tylko „do badań”.

Najczęściej zadawane pytania (FAQ)

Czy mogę legalnie trenować model na danych znalezionych w internecie?

Publiczna dostępność danych nie oznacza zgody na dowolne użycie. Jeśli zbierasz treści z serwisów (scraping, API, pobieranie plików), wchodzisz w obszar regulaminów, praw autorskich i często także RODO. Portal może wprost zakazywać trenowania modeli na swoich danych, a twórcy treści mają prawa autorskie do tekstów, zdjęć czy nagrań.

Najrozsądniej jest zawsze sprawdzić: regulamin serwisu, licencję datasetu lub API oraz to, czy w danych są informacje o osobach. Gdy masz wątpliwości, taniej bywa znaleźć gotowy dataset z jasną licencją niż później tłumaczyć się z nieuprawnionego scrapingu.

Czy dane publiczne (np. z forum, portalu ogłoszeniowego) podlegają RODO?

Tak, jeśli da się przez nie zidentyfikować konkretne osoby – bezpośrednio (imię, nazwisko, e‑mail) lub pośrednio (zestaw cech, który w praktyce wskazuje konkretną osobę). To, że ktoś coś napisał na publicznym forum, nie usuwa jego praw jako osoby, której dane są przetwarzane.

Jeśli trenujesz model na takich danych, powinieneś mieć podstawę prawną przetwarzania (np. uzasadniony interes, zgodę lub inną właściwą przesłankę) i przynajmniej rozważyć pseudonimizację lub anonimizację. Rezygnacja z części pól osobowych często znacząco obniża ryzyko przy niewielkim wpływie na jakość modelu.

Czy mogę użyć danych klienta B2B do trenowania uniwersalnego modelu SaaS?

Bez wyraźnego zapisu w umowie to ryzykowne. Klient może oczekiwać, że jego dane służą wyłącznie do świadczenia usługi na jego rzecz, a nie do budowy produktu dla całego rynku. Przy danych osobowych dochodzi jeszcze kwestia ról RODO (administrator / podmiot przetwarzający) i celu przetwarzania.

Praktyczne minimum to klauzule w umowie określające:

• kto jest administratorem danych i w jakim celu dane są przetwarzane,
• czy dostawca może używać danych do trenowania modeli dla innych klientów,
• jak dane są anonimizowane lub agregowane przed użyciem do trenowania.

Kilka precyzyjnych zapisów na starcie zwykle kosztuje mniej niż negocjowanie „po fakcie”, gdy produkt już działa.

Jak sprawdzić, czy gotowy dataset z internetu mogę wykorzystać komercyjnie?

Kluczowa jest licencja. To ona określa, czy możesz:

• używać danych komercyjnie,
• modyfikować je i łączyć z innymi zbiorami,
• trenować na nich modele, które potem sprzedajesz lub udostępniasz w SaaS.

Brak licencji lub ogólny zapis „free to use” nie zawsze wystarcza, szczególnie gdy w grę wchodzi produkt komercyjny.

Praktyczny workflow: sprawdź licencję w repozytorium / opisie, poszukaj wzmianki o „commercial use” i „AI/ML training”, zapisz źródło i datę pobrania w dokumentacji projektu. Jeśli dataset ma niejasny status, lepiej poszukać alternatywy z jasną licencją niż opierać na nim kluczowy model.

Jakie dane treningowe są najbardziej ryzykowne z punktu widzenia prawa?

Najwięcej obowiązków i potencjalnych kosztów generują:

• dane osobowe, szczególnie dane wrażliwe (zdrowie, biometria, poglądy polityczne itd.),
• treści chronione prawem autorskim (tekst, grafika, wideo, muzyka, kod),
• tajemnica przedsiębiorstwa (wewnętrzne dokumenty, know‑how, dane biznesowe).

Każda z tych kategorii uruchamia inny zestaw wymogów: od RODO i dodatkowych środków bezpieczeństwa po konieczność posiadania licencji lub NDA.

W praktyce opłaca się zidentyfikować w datasetach „najdroższe prawnie” elementy (np. konkretne pola osobowe czy fragmenty poufnych dokumentów) i możliwie wcześnie je usunąć, zanonimizować lub wydzielić do osobnych, lepiej chronionych pipeline’ów.

Czy muszę umożliwić „usunięcie” danych z wytrenowanego modelu, jeśli ktoś cofnie zgodę?

Przepisy ochrony danych dają osobom m.in. prawo do usunięcia danych lub sprzeciwu wobec przetwarzania. W praktyce cofnięcie zgody lub sprzeciw po treningu modelu są trudne technicznie do obsłużenia, ale regulatorów to nie interesuje – patrzą, czy masz proces i czy potrafisz wykazać, co się dzieje z tymi danymi.

Rozsądne podejście „na start”:

• minimalizować liczbę danych osobowych używanych do trenowania,
• projektować pipeline tak, by wiedzieć, z jakich zbiorów i wersji korzystał dany model,
• przy wrażliwych projektach rozważyć retraining na zaktualizowanym zbiorze zamiast „magicznego” usuwania wpływu pojedynczego rekordu.

To kosztuje, ale znacznie mniej niż tłumaczenie się klientowi lub organowi nadzoru, że „technicznie się nie da”.

Jak tanio zadbać o legalność danych treningowych w małym zespole ML?

Nie trzeba od razu pełnej machiny compliance. Sensowny, „budżetowy” zestaw na początek to:

• prosta inwentaryzacja źródeł danych (skąd, na jakiej licencji, z jaką podstawą prawną),
• rozsądne minimum dokumentacji: kto odpowiada za dane, jakie są cele przetwarzania, jakie typy danych wchodzą do pipeline’u,
• kilka reguł technicznych: wydzielenie danych osobowych, wersjonowanie datasetów, logowanie źródeł.

Takie minimum da się ogarnąć w kilka godzin pracy i znacząco obniża ryzyko, że po kilku miesiącach trzeba będzie zmieniać cały pipeline albo wycofywać model z produkcji z powodu prostego błędu formalnego.

Kluczowe Wnioski

• Technicznie da się wciągnąć do pipeline’u prawie wszystko, ale prawnie część takich działań grozi wysokimi karami, koniecznością retreningu modeli i blokadą wdrożenia tuż przed komercyjnym startem.
• Jeśli w danych treningowych pojawiają się dane osobowe, projekt automatycznie wchodzi w reżim RODO: trzeba mieć podstawę prawną, liczyć się z kontrolą, obowiązkami informacyjnymi i ryzykiem konieczności wycofania modelu z produkcji.
• Prawa autorskie do treści (tekst, obrazy, kod, muzyka) ograniczają swobodne „branie z internetu” – publiczny dostęp nie oznacza zgody na kopiowanie do datasetu ani na komercyjne trenowanie modeli.
• Najtańsze podejście to zaplanowanie legalności danych na starcie: zdefiniowanie typów danych, źródeł, podstawy prawnej i celu przetwarzania oraz spięcie tego prostym zestawem dokumentów zamiast gaszenia pożarów po fakcie.
• Dobra architektura techniczna (wydzielenie danych osobowych, anonimizacja, wersjonowanie i logowanie źródeł danych) zmniejsza koszty prawne i ułatwia reagowanie, gdy ktoś zażąda np. wycofania swoich danych.
• Umowy z klientami i partnerami muszą wprost regulować użycie ich danych do trenowania modeli – brak takiego zapisu utrudnia skalowanie produktu, utrzymuje zespół w szarej strefie prawnej i generuje drogie negocjacje ad hoc.

Bibliografia

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Podstawowe definicje danych osobowych, zasady i podstawy przetwarzania
• Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych. Dziennik Ustaw Rzeczypospolitej Polskiej (2018) – Implementacja RODO w Polsce, kompetencje organu nadzorczego
• Artificial Intelligence Act (AI Act) – przyjęty tekst aktu o sztucznej inteligencji. Parlament Europejski (2024) – Ramowe wymogi prawne dla systemów AI, ocena ryzyka i obowiązki dostawców
• Guidelines 07/2020 on the concepts of controller and processor in the GDPR. European Data Protection Board (2021) – Wyjaśnienie ról administratora i procesora, istotne przy projektach ML B2B
• Opinion 03/2013 on purpose limitation. Article 29 Data Protection Working Party (2013) – Interpretacja zasady ograniczenia celu, istotna dla ponownego użycia danych
• OECD Principles on Artificial Intelligence. Organisation for Economic Co-operation and Development (2019) – Zasady odpowiedzialnego AI, w tym zarządzanie danymi i przejrzystość
• Data Protection and Privacy in Machine Learning. European Union Agency for Cybersecurity (2021) – Analiza ryzyk ML dla prywatności, rekomendacje techniczne i organizacyjne