Cel osób sięgających po legalny scraping danych do AI
Osoby projektujące systemy AI oparte na danych z internetu zwykle chcą dwóch rzeczy: jak najszerszego, możliwie taniego dostępu do treści oraz możliwie niskiego ryzyka prawnego. Granica między dozwolonym użyciem treści a naruszeniem praw autorskich, regulaminów i RODO bywa jednak znacznie mniej oczywista niż wynikałoby to z marketingowych prezentacji dostawców danych czy gotowych modeli.
Scraping i trenowanie modeli AI wchodzą w obszar, w którym krzyżuje się kilka reżimów prawnych: prawo autorskie, ochrona baz danych, prawo umów (regulaminy), prawo ochrony danych osobowych, a coraz częściej także regulacje sektorowe i „AI-kowe”. Bez ich zrozumienia łatwo podjąć decyzję, która w krótkim terminie przyspiesza rozwój projektu, ale w średnim terminie generuje trudne do opanowania ryzyka.
Czym jest legalny scraping danych w kontekście AI
Scraping technicznie a scraping w oczach prawa
Od strony technicznej scraping to zautomatyzowane pobieranie treści z serwisów internetowych i zapisywanie ich w uporządkowanej formie (np. w bazie danych lub plikach). Z perspektywy programisty jest to głównie kwestia:
wysłania żądań HTTP do serwera,
parsowania HTML, JSON lub innego formatu,
ekstrakcji wybranych elementów (np. tytułów artykułów, opisów produktów, komentarzy),
zapisania ich w lokalnym repozytorium.
Dla prawa to jednak nie tylko „pobieranie danych”, ale przede wszystkim kopiowanie i utrwalanie cudzych przejawów twórczości lub fragmentów baz danych. W wielu sytuacjach każde takie działanie traktowane jest jako „korzystanie z utworu” w rozumieniu prawa autorskiego, a w przypadku zorganizowanych zbiorów – jako potencjalne naruszenie prawa do bazy danych.
Inaczej ocenia się też jednorazowe pobranie jednej strony, a inaczej zmasowane, zautomatyzowane pozyskiwanie setek tysięcy podstron pod kątem trenowania modelu AI. Ten drugi scenariusz zbliża się do eksploatacji na skalę komercyjną, nawet jeśli służy tylko do „wewnętrznego treningu” modelu, a nie do dalszego rozpowszechniania treści wprost.
Masowe pozyskiwanie danych a ryzyko prawne
Skala scrapingu kluczowo wpływa na to, jak postrzegają go właściciele serwisów i regulatorzy. Jednorazowe pobranie kilkudziesięciu artykułów w celu analizy porównawczej może mieścić się w granicach dozwolonego użytku, zwłaszcza na potrzeby nauki i analizy krytycznej. Masowe zgrywanie setek tysięcy stron do budowy korpusu treningowego dla komercyjnego modelu LLM już znacznie trudniej obronić tym samym argumentem.
W praktyce progiem alarmowym zwykle jest moment, w którym:
pobierasz znaczne części serwisu (np. całe archiwum),
dochodzisz do poziomu, w którym Twoja aktywność obciąża infrastrukturę serwisu,
zaczynasz zastępować funkcję rynkową dostawcy (np. budujesz alternatywę dla płatnego portalu treściowego lub bazy danych),
wykorzystujesz dane w modelu, którego działanie pośrednio konkuruje z twórcą (np. model generujący obrazy na podstawie stylu konkretnych artystów).
Takie działania łatwiej uznać za „eksploatację na szkodę uprawnionego” niż za neutralne technicznie kopiowanie. To nie znaczy, że każdy masowy scraping jest nielegalny, ale że wymaga bardziej precyzyjnego oparcia w przepisach lub w licencjach.
Główne obszary ryzyka przy scrapingu do AI
Przy projektowaniu procesu scrapingu do trenowania AI przecinają się co najmniej cztery duże obszary prawne:
prawo autorskie – ochrona treści jako utworów (teksty, zdjęcia, grafiki, filmy);
ochrona baz danych – tzw. prawo sui generis do baz danych w UE, obejmujące także niektóre „suche” zbiory danych;
regulaminy i umowy licencyjne – ograniczenia narzucone przez właścicieli serwisów, API, dostawców datasetów;
prawo ochrony danych osobowych (RODO) – gdy wśród pozyskiwanych treści znajdują się dane identyfikowalne osób fizycznych.
Do tego dochodzą jeszcze regulacje sektorowe (np. w finansach, medycynie) oraz wchodzące w życie przepisy dotyczące sztucznej inteligencji (AI Act w UE), które pośrednio wpływają na standardy pozyskiwania i dokumentowania danych treningowych.
Dlaczego trenowanie AI wyostrza problem legalności scrapingu
Gdy mowa o trenowaniu modeli AI, w grę wchodzi nie tylko kopiowanie treści, ale także ich wtórne wykorzystanie na dużą skalę. To właśnie odróżnia training dataset od prywatnego zrzutu kilku stron:
modele ogólne (np. duże modele językowe, generatory obrazów) uczone są na miliardach tokenów/obrazów, często z wielu serwisów naraz,
efekt treningu może mieć znaczący wpływ na rynek – wypieranie usług informacyjnych, stocków zdjęć, serwisów Q&A, kursów online,
coraz więcej sporów dotyczy tego, czy model nie „przyswaja” stylu konkretnych twórców i nie replikuje treści zbyt dosłownie.
Dlatego operatorzy modeli coraz częściej stają się stroną sporów sądowych, a nie tylko „cichym użytkownikiem internetu”. Legalność scrapingu do AI to nie jest wyłącznie kwestia technicznego dostępu do stron, ale przede wszystkim późniejszej eksploatacji korpusu i wniosków, które z niego wynikają.
Podstawy prawne: prawo autorskie, bazy danych i regulacje sektorowe
Co jest chronione: utwór, baza danych i elementy pozbawione ochrony
W kontekście scrapingu do trenowania AI kluczowe jest rozróżnienie między:
utworem – przejawem działalności twórczej o indywidualnym charakterze (np. artykuł, zdjęcie, grafika, fragment kodu, wpis blogowy),
baza danych – zbiorem danych lub materiałów, posiadającym określoną strukturę i ułożenie, który może być chroniony:
jako utwór (jeśli ma twórczą strukturę), oraz/lub
prawem sui generis (jeśli ktoś poniósł istotny nakład inwestycyjny na jej stworzenie, choć sam układ nie jest twórczy),
elementami niechronionymi – faktami, prostymi informacjami, danymi statystycznymi, które same w sobie nie stanowią utworu.
Scraping, który pozyskuje wyłącznie nagie fakty (np. notowania giełdowe, kursy walut, proste parametry techniczne produktów) z reguły wiąże się z mniejszym ryzykiem z punktu widzenia prawa autorskiego. Problem pojawia się tam, gdzie pobierasz:
pełne teksty (artykuły, opisy produktów, recenzje),
zorganizowane bazy, które mają wartość same z siebie (np. katalog firm, zestawienia rankingowe).
Nawet jeśli pojedynczy opis jest krótki, całokształt bazy może być chroniony jako baza danych. Scraping większych fragmentów takiej bazy – a tym bardziej jej całkowite zgranie – może naruszać prawo sui generis, niezależnie od tego, czy poszczególne wpisy są utworami.
Kiedy kopiowanie staje się „korzystaniem z utworu”
Pytanie, które często pada w kontekście trenowania AI: czy techniczne kopiowanie treści do zbioru danych to już korzystanie z utworu? W większości przypadków odpowiedź brzmi: tak, bo:
dochodzi do utrwalenia utworu na innym nośniku (serwer, baza danych),
tworzona jest kopia (choćby tymczasowa) wykorzystywana później przez system,
rezultat (wytrenowany model) powstał wskutek analizy tych kopii.
Wyjątkiem są sytuacje, w których kopiowanie mieści się w szczególnych przepisach o dozwolonym użytku lub jest objęte licencją (np. otwartą licencją datasetu). Sama „techniczność” operacji nie czyni jej jeszcze neutralną prawnie. Argument typu „nasz system tylko analizuje słowa, niczego nie przechowujemy wprost” ma ograniczoną siłę, zwłaszcza gdy zbiór treningowy istnieje w postaci łatwej do rekonstrukcji.
Dodatkowo w prawie autorskim liczy się nie tylko to, czy docelowy użytkownik widzi kopiowany utwór, ale także to, czy podmiot gospodarczy wykorzystuje cudzy utwór w procesie swojej działalności (nawet „wewnętrznej”). Trenowanie modelu na cudzych treściach ma znamiona takiego wykorzystania.
Najważniejsze źródła prawa dla scrapingu i trenowania AI w UE
Przy projektach realizowanych w Polsce i w Unii Europejskiej punktem odniesienia są przede wszystkim:
ustawa o prawie autorskim i prawach pokrewnych (wdraża dyrektywy unijne, określa dozwolony użytek, utwór, pola eksploatacji),
dyrektywa DSM (2019/790) – wprowadza wyjątki dla text and data mining (TDM), zarówno dla podmiotów badawczych, jak i komercyjnych,
dyrektywa o ochronie baz danych (96/9/WE) – ustanawia prawo sui generis do baz danych, zakazując m.in. pobierania „istotnej części” bazy bez zgody,
RODO / GDPR – reguluje przetwarzanie danych osobowych, istotne przy scrapingu tekstów, profili użytkowników, komentarzy,
przepisy branżowe – w zależności od danych: np. prawo bankowe, prawo rynku kapitałowego, tajemnica zawodowa (medycyna, prawnicy).
Na to nakładają się regulaminy serwisów internetowych, które często ostro ograniczają możliwość automatycznego pobierania danych lub wykorzystania ich do trenowania modeli AI. Naruszenie takich regulaminów nie zawsze jest równoznaczne z naruszeniem prawa autorskiego, ale może prowadzić do odpowiedzialności kontraktowej lub – w niektórych jurysdykcjach – do zarzutów nieautoryzowanego dostępu.
Regulaminy jako dodatkowe ograniczenie sposobu korzystania
Regulaminy serwisów (Terms of Service, Terms of Use) pełnią rolę umowy między użytkownikiem a właścicielem serwisu. Zwykle zawierają postanowienia typu:
zakaz scrapingu lub korzystania z botów,
zakaz tworzenia datasetów lub trenowania AI na treściach z serwisu,
zastrzeżenie praw autorskich i praw do baz danych,
warunki korzystania z treści (np. wyłącznie do użytku osobistego).
Jeśli scraping odbywa się z konta użytkownika, który akceptował regulamin (np. przy logowaniu lub zakładaniu konta), złamanie zakazu scrapingu może być uznane za naruszenie umowy. Nawet jeśli sama operacja pobrania treści mieściłaby się w granicach dozwolonego użytku, regulamin może skutecznie zawęzić to, na co użytkownik się zgodził. To odrębny od prawa autorskiego reżim odpowiedzialności.
W projektach AI opartych na scrapingu trzeba więc równolegle analizować: czy dane można pobrać w świetle prawa autorskiego i ochrony baz danych, oraz czy sposób pobrania i wykorzystania nie narusza ToS. Oba poziomy mogą generować różne rodzaje roszczeń.
Źródło: Pexels | Autor: Google DeepMind
Dozwolony użytek i wyjątki text and data mining – na czym naprawdę polega „legalny scraping”
Dozwolony użytek w polskim prawie: granice i złudzenia
Dozwolony użytek (fair dealing, nie mylić z amerykańskim fair use) to zespół wyjątków od monopolu autorskiego, pozwalający na korzystanie z cudzych utworów bez zgody uprawnionego w ściśle określonych przypadkach. W polskim prawie obejmuje m.in.:
użytek osobisty (korzystanie w gronie rodziny i znajomych),
prawo cytatu,
korzystanie dla celów dydaktycznych, naukowych, informacyjnych,
tworzenie kopii tymczasowych w procesach technicznych.
Dla scrapingu do trenowania AI najbardziej kusząca jest interpretacja, że „skoro robimy analizę treści, a model nie cytuje dosłownie, to mieści się to w dozwolonym użytku badawczym”. To jednak poważne uproszczenie. Polskie przepisy i dyrektywy unijne rozciągają dozwolony użytek na konkretne podmioty i cele, a nie obejmują blankietowo „wszelkich zastosowań AI”.
Projekt komercyjnego modelu LLM trenowanego na hurtowo scrapowanych artykułach prasowych trudno podciągnąć pod klasyczny dozwolony użytek naukowy, zwłaszcza jeśli jest prowadzony przez spółkę prawa handlowego i nastawiony na zysk. Od tego rodzaju zastosowań oddzielono specjalne wyjątki TDM, które mają własne warunki i ograniczenia.
Wyjątki TDM w dyrektywie DSM: badawczy vs komercyjny
Dyrektywa DSM wprowadziła w UE dwa poziomy wyjątków dla text and data mining:
Zakres wyjątku badawczego TDM (art. 3 DSM)
Wyjątek z art. 3 dyrektywy DSM obejmuje text and data mining prowadzone przez instytucje badawcze i instytucje dziedzictwa kulturowego (np. uczelnie, instytuty PAN, biblioteki, archiwa, muzea) działające w celach badawczych. Kilka elementów ma tu znaczenie praktyczne:
musi istnieć uprawniony dostęp do treści – np. legalna subskrypcja, dostęp w ramach licencji instytucjonalnej, otwarty dostęp,
uprawniony podmiot może:
pobierać i utrwalać utwory oraz inne materiały w zakresie niezbędnym do TDM,
przechowywać kopie tak długo, jak to konieczne do celów badań naukowych (w tym replikowalności),
nie jest wymagane wynagrodzenie dla uprawnionych z tytułu samego TDM, choć licencje dostępu do treści mogą być płatne,
uprawniony nie traci ochrony z art. 3 tylko dlatego, że współpracuje z podmiotem komercyjnym, o ile to on pozostaje głównym podmiotem prowadzącym badania.
Pułapka pojawia się przy projektach typu „spin-off akademicki” lub „laboratorium badawcze wewnątrz korporacji”. Sam fakt, że prace wykonują naukowcy, nie przesądza jeszcze o statusie instytucji badawczej w rozumieniu DSM. Kluczowa jest definicja z dyrektywy i jej implementacja krajowa (m.in. brak komercyjnego celu głównego).
W praktyce oznacza to, że uniwersytet może pozyskać duży korpus artykułów naukowych od wydawcy w ramach licencji i przeprowadzić na nim TDM pod kątem badań nad modelami językowymi. Natomiast „podpięcie” spółki komercyjnej pod ten projekt po to, aby docelowo wykorzystać model w produkcie SaaS, tworzy już strefę ryzyka – zwłaszcza gdy udział spółki jest dominujący, a model ma być zasadniczo aktywem komercyjnym, nie zaś efektem badań publikowanych w otwartym obiegu.
Wyjątek komercyjny TDM (art. 4 DSM) i mechanizm opt-out
Drugi wyjątek – z art. 4 – dotyczy wszystkich podmiotów, w tym komercyjnych, ale w znacznie bardziej ograniczonej formie. Umożliwia on:
kopiowanie treści w celu TDM przez jakikolwiek podmiot posiadający legalny dostęp,
utrwalanie i ekstrakcję danych niezbędnych do analizy,
wykorzystanie wyników analizy (w tym modeli) na własne potrzeby.
Ten wyjątek nie jest jednak „blankietową zgodą” na scraping wszystkiego, co się da. Istnieją dwa zasadnicze „bezpieczniki”:
Opt-out uprawnionego – posiadacz praw może „zastrzec” swoje treści przed TDM w sposób machine-readable (np. w metadanych, plikach konfiguracyjnych typu robots.txt, licencjach API). Jeżeli takie zastrzeżenie jest wdrożone w rozsądnie czytelny sposób, wyjątek z art. 4 nie działa. Wtedy scraping pod kątem trenowania AI wymaga zgody (licencji).
Zakres i czas przechowywania kopii – w przeciwieństwie do art. 3, kopie utworów wykonane w ramach TDM komercyjnego nie mogą być przechowywane „bezterminowo” dla samej wygody. Po zakończeniu procesu analizy podmiot powinien zredukować utrwalone treści do poziomu niezbędnego do udokumentowania badań lub musi je usunąć.
Spór często dotyczy tego, czy wytrenowany model sam w sobie jest „kopią” utworu, czy jedynie zbiorem wag i parametrów. Argumentacja dostawców modeli: po usunięciu surowego datasetu przechowywany jest wyłącznie abstrakcyjny rezultat analizy, więc obowiązek usunięcia „kopii” został spełniony. Część doktryny i właścicieli praw odpowiada: jeżeli model odtwarza dłuższe fragmenty lub charakterystyczne elementy utworów, nie można mówić o „czystej abstrakcji”, a proces TDM jest faktycznie ekwiwalentem trwałego utrwalenia.
Co realnie oznacza „machine-readable opt-out”
Dyrektywa DSM nie definiuje szczegółowo, jak ma wyglądać techniczne zastrzeżenie opt-out. W efekcie powstało sporo nieporozumień. Kilka scenariuszy, z którymi zespoły AI stykają się najczęściej:
robots.txt z zakazem scrapingu – jeśli strona jednoznacznie blokuje boty indeksujące lub konkretną kategorię botów (np. „GPTBot”), bardzo trudno obronić później tezę, że TDM prowadzone wbrew temu zastrzeżeniu mieści się w art. 4. Nawet jeśli literalnie robots.txt dotyczy „indeksowania”, kontekst i praktyka przemawiają za traktowaniem go jako formy opt-out.
nagłówki HTTP / meta tagi – pojawiają się rozwiązania typu: „noai”, „noimageai”, „notrain” w meta tagach lub nagłówkach odpowiedzi serwera. Nie ma jeszcze jednolitej praktyki sądowej, ale łącząc wymóg machine-readable i zasadę dobrej wiary, ignorowanie takich sygnałów będzie ryzykowne, zwłaszcza dla dużych komercyjnych graczy.
zastrzeżenia licencyjne w API – jeśli dane pobierane są przez oficjalne API z warunkami zakazującymi TDM lub trenowania AI, nie można „przeskoczyć” tych warunków powołując się na art. 4 DSM. W tym kontekście „machine-readable” oznacza raczej łatwo identyfikowalną, programowalną granicę dostępu (np. limit endpointów), niekoniecznie sam plik robots.txt.
Przy dużych projektach treningowych praktyczne podejście jest takie: system zbierający dane musi projektowo uwzględniać i respektować sygnały opt-out. Dodawanie filtrów „po fakcie” lub uznawanie, że „i tak nikt nas nie pozwie”, jest bardziej strategią hazardową niż compliance.
Granica między TDM a „zwykłym” kopiowaniem treści
Text and data mining to nie jest każde wykorzystanie treści przez system informatyczny. Istotą TDM jest analiza w celu wydobycia wzorców, korelacji lub informacji, a nie zastępowanie pierwotnego utworu w obrocie. Typowe pytania, jakie pojawiają się przy ocenie projektu:
czy wynik procesu ma charakter zagregowany, statystyczny (np. wektory, parametry modelu, rozkłady prawdopodobieństw), czy raczej jest repozytorium pełnych tekstów dostępnych w nowym interfejsie,
czy użytkownik końcowy otrzymuje w praktyce substytut oryginalnych treści (np. zbiór artykułów prasowych w chatbotcie),
czy projekt jest tak zaprojektowany, aby minimalizować dosłowne replikacje treści w odpowiedziach modelu (filtry, ograniczanie długości outputu, deduplikacja datasetu).
Im bardziej rezultat przypomina „nowy kanał dystrybucji” cudzych utworów, tym słabsze są argumenty, że chodzi jedynie o TDM. Dotyczy to zwłaszcza wyspecjalizowanych modeli szkolonych na jednym typie treści (np. kompletna baza podręczników medycznych) i później udostępnianych w formie, która de facto umożliwia odtworzenie znacznych partii tych podręczników.
Regulaminy serwisów, robots.txt i „warunki dostępu” – co realnie wiąże scrapera
Moment związania regulaminem i „niewidzialne” zgody
W praktyce AI-korporacyjnej często pada argument: „nasz crawler nie zakłada konta, więc nie akceptuje regulaminu, a tym samym nie może go naruszyć”. W relacji B2C taki pogląd bywa kuszący, ale w relacji między profesjonalistami nie jest szczególnie bezpieczny. W grę wchodzi kilka warstw:
regulamin akceptowany explicite – logowanie, rejestracja, zamówienie API; tutaj wiązanie jest oczywiste,
regulamin dostępny i wyraźnie powiązany z usługą – przy korzystaniu z serwisu bez logowania sądy często przyjmują, że profesjonalny użytkownik miał możliwość zapoznania się z ToS i korzystając, go akceptuje,
praktyka branżowa – w niektórych sektorach (np. finansowym) przyjmuje się, że korzystanie z kanałów danych oznacza zgodę na standardowe warunki, nawet jeśli użytkownik nie kliknął „akceptuję”.
Dla scrapera kluczowe jest, że brak konta nie jest automatycznie brakiem umowy. Jeżeli serwis publiczny komunikuje wyraźnie: „zakaz automatycznego pobierania danych, zakaz wykorzystania do AI”, a mimo to system masowo zbiera dane, ryzyko sporu kontraktowego i deliktowego wciąż istnieje. Nawet jeśli argumentacja będzie opierała się nie na klasycznym naruszeniu ToS, to na zarzucie czynu nieuczciwej konkurencji lub bezprawnego zakłócania działalności.
Scraping a przepisy o nieuprawnionym dostępie
Osobnym, często pomijanym wątkiem jest prawo karne i przepisy o nieuprawnionym dostępie do systemów informatycznych. W polskim porządku prawnym w grę mogą wchodzić m.in. przepisy o przełamywaniu zabezpieczeń lub zakłócaniu pracy systemu. Co zwykle nie jest traktowane jako przestępstwo:
pobieranie publicznie dostępnych stron bez obchodzenia technicznych zabezpieczeń (paywalle, logowanie, tokeny),
umiarkowane obciążenie serwisu (crawl rate), które nie prowadzi do faktycznego sparaliżowania usługi.
Ryzyko wzrasta tam, gdzie bot:
omija paywalle, captche, tokeny sesyjne,
podszywa się pod „oficjalne” boty (np. fałszuje user-agenta wyszukiwarki),
w sposób stały generuje nadmierny ruch, zbliżony do ataku DDoS.
Projekty AI często traktują kwestię „wydajnościową” jako problem DevOps, a nie compliance. Z perspektywy prawa przekroczenie pewnego progu ingerencji w infrastrukturę drugiej strony może jednak przejść z kategorii „naruszenie regulaminu” do kategorii „czyn zabroniony”. Połączenie masowego scrapingu treści chronionych i silnego obciążenia serwera to scenariusz wyjątkowo niewdzięczny w sporze.
API jako „sterowany” kanał dostępu do danych
Coraz więcej serwisów zamiast całkowicie blokować scraping, oferuje płatne lub ograniczone API. Z punktu widzenia podmiotu trenującego AI pojawia się dylemat: używać oficjalnego API na restrykcyjnych warunkach, czy scrapować „od frontu” na własną rękę. Kilka stałych motywów:
API często wprost zakazuje tworzenia datasetów treningowych lub wykorzystania danych do trenowania modeli,
limit zapytań i zakres pól jest w API znacznie węższy niż to, co można pozyskać przez scrapowanie HTML,
warunki API bywają powiązane z klauzulami audytu lub prawem do kontroli sposobu przetwarzania danych.
Rezygnacja z API i przejście na „dziki” scraping nie oznacza automatycznie obejścia prawa, ale utrudnia obronę w razie sporu. Pytanie, które sąd zapewne zada: dlaczego wybrano technicznie bardziej inwazyjną drogę, skoro istniał ucywilizowany kanał dostępu z jasnymi warunkami? Sam fakt istnienia API bywa interpretowany jako sygnał, że właściciel serwisu dopuszcza gospodarowanie danymi wyłącznie w tym reżimie, a obchodzenie go może zostać uznane za działanie w złej wierze.
Robots.txt: standard techniczny czy źródło obowiązków prawnych?
Robots.txt formalnie jest konwencją techniczną, nie normą prawną. Nie ma przepisu, który wprost stwierdza: „naruszenie robots.txt jest bezprawne”. Mimo to w kilku obszarach nabiera on znaczenia quasi-normatywnego:
może być dowodem, że właściciel serwisu wprost wyraził swoją wolę ograniczenia dostępu dla botów,
może pełnić funkcję realizacji opt-out TDM (art. 4 DSM),
ignorowanie robots.txt przez profesjonalnego scrapera może być potraktowane jako działanie sprzeczne z uczciwymi praktykami rynkowymi.
Model „legalny scraping = zawsze respektujemy robots.txt” jest zbyt prosty – są przypadki, w których plik jest wadliwy, przestarzały albo skonfigurowany tylko pod kątem indeksacji SEO. Natomiast przy projektach AI o dużej skali świadome i systemowe ignorowanie robots.txt jest trudne do pogodzenia z koncepcją odpowiedzialnego TDM. Minimum ostrożności to:
parsowanie robots.txt i logowanie decyzji scrapera,
wyraźne rozróżnienie ruchu „AI-train” od ruchu „SEO-crawl”,
mechanizm globalnego „kill switcha” na domeny, które zgłoszą sprzeciw.
Dane osobowe w zbiorach do trenowania AI: RODO, anonimizacja i pseudonimizacja
Czy dataset treningowy zawiera dane osobowe?
Punkt wyjścia jest prozaiczny: czy w zbieranych treściach da się zidentyfikować osobę fizyczną, bezpośrednio lub pośrednio? Jeżeli tak, RODO się stosuje, niezależnie od tego, że projekt dotyczy „tylko” treningu modelu. Typowe źródła danych osobowych w scrapingach do AI:
fora, komentarze, social media – nicki, imiona i nazwiska, zdjęcia profilowe,
Źródła danych a ryzyko „ukrytych” danych osobowych
W scrapingu do AI często zakłada się, że jeśli projekt „nie celuje” w dane osobowe, to temat RODO jest poboczny. Z punktu widzenia regulatora liczy się jednak efekt, nie intencja. Dane osobowe pojawiają się w datasetach treningowych nie tylko w oczywistych miejscach:
ogłoszenia, profile biznesowe, rejestry – dane kontaktowe, historia zatrudnienia, numery licencji zawodowych,
artykuły prasowe i raporty – nazwiska menedżerów, polityków, lekarzy opisanych w kontekście konkretnych decyzji lub zarzutów,
dokumenty „technicze” – logi, issue trackery, commit messages, w których autorzy podpisują się pełnym imieniem i nazwiskiem,
datasety „curated” – zbiory rzekomo „public domain” lub „open data”, które w praktyce zawierają bogate informacje o konkretnych osobach.
Szczególnie myląca bywa kategoria open data. Otwarty charakter licencji nie oznacza automatycznie, że dane są poza zakresem RODO. Możliwa jest sytuacja, w której licencja wolno-licencyjna pozwala na dowolne wykorzystanie treści, ale reżim ochrony danych osobowych nadal wymaga podstawy prawnej, informacji dla osób i respektowania ich praw.
Administrator, procesor i współadministrator w projektach treningowych
Przy dużych projektach AI, gdzie uczestniczy kilka podmiotów (dostawca danych, integrator, podmiot trenujący model, klient końcowy), kluczowe jest rozróżnienie ról w rozumieniu RODO:
administrator danych – decyduje o celach i sposobach przetwarzania (np. „trenujemy model językowy na publicznych forach w celu tworzenia narzędzi do moderacji treści”),
podmiot przetwarzający (procesor) – działa wyłącznie na udokumentowane polecenie administratora (np. firma, która technicznie hostuje i trenowała model na danych dostarczonych przez klienta),
współadministrator – gdy dwie strony realnie współdecydowują o tym, do czego finalnie dane zostaną użyte (np. platforma udostępniająca dane + podmiot rozwijający algorytm wspólnie projektują usługę rekomendacyjną).
W praktyce AI często próbuje się „zepchnąć” rolę administratora na klienta lub na bliżej nieokreślonych „użytkowników”, przyjmując, że dostawca modelu jest tylko neutralnym podmiotem przetwarzającym. Organy nadzorcze coraz częściej podważają takie założenia. Jeżeli to dostawca modelu decyduje o architekturze, zbiorach referencyjnych, czasie przechowywania i profilowaniu, trudno obronić tezę, że nie jest administratorem co najmniej w części operacji.
Podstawa prawna przetwarzania danych osobowych przy scrapingu
Kiedy dataset treningowy obejmuje dane osobowe, podstawowa łamigłówka brzmi: na jakiej podstawie prawnej opiera się przetwarzanie? Zgoda użytkownika jest w masowych projektach scrapingu praktycznie niewykonalna (oraz odwoływalna), dlatego w grę wchodzą inne konstrukcje:
uzasadniony interes administratora (art. 6 ust. 1 lit. f RODO) – najczęściej stosowana podstawa, ale wymagająca:
jasno zdefiniowanego interesu (np. rozwój i testowanie systemów wykrywania spamu, a nie „ogólny postęp AI”),
testu równowagi uwzględniającego skalę, wrażliwość treści i oczekiwania użytkowników,
mechanizmów opt-out i realnej możliwości sprzeciwu.
wypełnienie obowiązku prawnego lub zadania w interesie publicznym – raczej wyjątek, typowy dla instytucji badawczych, regulatorów, ośrodków akademickich działających na podstawie szczególnych ustaw,
umowa – użyteczna, gdy dane pochodzą od podmiotu, który sam jest administratorem i przekazuje je w ramach uzgodnionej współpracy B2B (ale to nie zastępuje podstawy pierwotnego zebrania danych od osób).
Argument „dane są publiczne, więc można je dowolnie przetwarzać” nie jest samodzielną podstawą z perspektywy RODO. Publiczny charakter źródła wpływa raczej na ocenę testu równowagi (jak bardzo osoba mogła się spodziewać danego typu przetwarzania) niż na sam fakt legalności.
Obowiązek informacyjny wobec osób, których dane dotyczą
Przy scrapingu dużych zbiorów danych osobowych pojawia się pytanie, czy i jak realizować obowiązki informacyjne wobec setek tysięcy czy milionów osób. RODO przewiduje wyjątki, ale są one interpretowane raczej wąsko. Zwykle analizuje się trzy ścieżki:
informowanie przy pozyskaniu – w praktyce nierealne w typowym scrapingu, chyba że dane pozyskuje się z systemu, który sam wyświetla odpowiednią klauzulę (np. rejestr publiczny z modułem dla API),
informowanie „pośrednie” – komunikaty na stronie projektu, w dokumentacji API, w polityce prywatności, z dodatkowymi kanałami kontaktu (formularz żądania usunięcia, e-mail),
korzystanie z wyjątku z art. 14 ust. 5 RODO – nieproporcjonalny wysiłek lub niemożność przekazania informacji, pod warunkiem zastosowania odpowiednich środków ochrony i upublicznienia części informacji w inny sposób.
Regulatorzy chętnie pytają o to, co konkretnego zrobiono, aby ograniczyć zakres danych, ułatwić osobom znalezienie informacji o przetwarzaniu i zrealizować ich prawa w praktyce. Samo powołanie się na „nieproporcjonalny wysiłek” bez jakichkolwiek kompensujących środków (np. bez publicznej polityki, bez kanału żądań) bywa oceniane krytycznie.
Anonimizacja, pseudonimizacja i „reidentyfikowalność” modeli
W projektach AI pojęcia anonimizacji i pseudonimizacji są często mylone lub traktowane jako kwestie czysto techniczne. Z perspektywy RODO:
anonimizacja – stan, w którym identyfikacja osoby jest praktycznie niemożliwa, biorąc pod uwagę rozsądnie dostępne środki i kontekst (w tym inne zbiory, którymi dysponują typowi uczestnicy rynku),
pseudonimizacja – dane nadal są powiązane z osobą, ale identyfikatory zostały zastąpione innymi (np. hashami, losowymi ID), a klucz powiązania jest przechowywany osobno.
W AI dochodzi jeszcze kwestia „wyciekania” danych z modelu. Nawet jeśli w datasetach zastosowano pseudonimizację, trening dużych modeli generatywnych na danych wysokiego ryzyka (np. dane medyczne, korespondencja prywatna) może prowadzić do sytuacji, w której model odtwarza fragmenty tekstów lub bardzo szczegółowe opisy osoby. Organy nadzorcze coraz częściej interesują się nie tylko tym, co jest w datasetach, ale również tym, jak zachowuje się sam model:
czy wdrożono testy ekstrakcji treningu (model inversion, membership inference),
czy odpowiedzi modelu są filtrowane pod kątem ujawniania danych osobowych,
czy istnieje możliwość „wyłączenia” danych danej osoby z kolejnych rund treningu lub fine-tuningu.
Przy ocenie, czy dane w modelu są nadal danymi osobowymi, kluczowa jest realna możliwość powiązania odpowiedzi modelu z konkretną osobą, a nie jedynie zamiar projektantów. Jeżeli model jest w stanie po zapytaniu „podaj dane kontaktowe X” zwrócić konkretne dane osobowe, trudno argumentować, że te dane zostały skutecznie zanonimizowane.
Prawa osób, których dane dotyczą, wobec datasetów treningowych i modeli
Poza obowiązkami informacyjnymi na administratorze ciąży także respektowanie praw osób, których dane dotyczą. W kontekście scrapingu dla AI najbardziej problematyczne są:
prawo dostępu – osoba może zażądać informacji, jakie jej dane są przetwarzane i w jakim celu; przy masowych datasetach odpowiedź wymaga co najmniej opisania kategorii źródeł, logiki przetwarzania i ewentualnego wpływu na wnioski lub profile generowane przez model,
prawo do sprostowania – trudne do wdrożenia tam, gdzie dane są już „wtopione” w parametry modelu; często sprowadza się do korekty danych w bazach towarzyszących (np. tablicach lookup), a nie w samym modelu,
prawo do usunięcia („bycia zapomnianym”) – najbardziej konfliktowe; techniczne „unlearning” modeli jest wciąż rozwijające się i kosztowne, a usunięcie danych ze źródła (np. forum) nie powoduje automatycznego „wymazania” ich z kopii treningowych,
prawo do sprzeciwu – w przypadku przetwarzania na podstawie uzasadnionego interesu administratora sprzeciw może wymagać wstrzymania dalszego wykorzystania danych danej osoby, chyba że administrator wykaże nadrzędność swoich interesów.
Przy projektowaniu pipeline’u scrapingu i trenowania modeli opłaca się z góry przewidzieć, w jaki sposób będą obsługiwane takie żądania – czy istnieje mapa powiązań między źródłem, zbiorem pośrednim a konkretną wersją modelu, czy jest choćby możliwość wyłączenia danych z kolejnych iteracji treningu.
Ocena skutków dla ochrony danych (DPIA) w projektach AI
Trenowanie modeli na masowo scrapowanych danych osobowych często spełnia kryteria przetwarzania „wysokiego ryzyka”, szczególnie gdy obejmuje profilowanie, łączenie wielu źródeł i dużą skalę geograficzną. W takich przypadkach pojawia się obowiązek przeprowadzenia oceny skutków dla ochrony danych (DPIA). Typowe elementy rzetelnej DPIA:
opis przepływu danych od momentu scrapingu do wykorzystania modelu (w tym okresy retencji i anonimizacji),
identyfikacja kategorii danych (wrażliwe, szczególne kategorie, dane dzieci),
analiza ryzyka rekonstrukcji danych osobowych z modelu oraz ryzyka profilowania „wysokiego wpływu” (np. ocena predyspozycji zdrowotnych, scoring kredytowy),
opis zastosowanych środków technicznych (pseudonimizacja, minimalizacja, kontrola dostępu) i organizacyjnych (polityki, audyty, umowy powierzenia),
ocena konieczności konsultacji z organem nadzorczym, jeśli mimo środków ochrony ryzyko nadal jest wysokie.
DPIA nie jest jedynie „papierem do szuflady”. Organy nadzorcze coraz częściej żądają jej przedstawienia przy kontrolach projektów AI, a jej brak w sytuacjach, gdy była wymagana, bywa traktowany jako osobne naruszenie.
Trenowanie AI na danych z internetu a prawo autorskie – kluczowe spory i linie argumentacji
Czy parametry modelu „zawierają” utwory chronione?
Jednym z centralnych sporów jest pytanie, czy wytrenowany model – rozumiany jako zestaw wag, parametrów i architektura – stanowi odwzorowanie utworów objętych prawem autorskim. W uproszczeniu pojawiają się dwie linie argumentacji:
model jako forma nieodwracalnej abstrakcji – twierdzenie, że proces trenowania przekształca treść tak, iż oryginalne utwory nie są już dostępne, a jedynie wpływają na rozkłady prawdopodobieństwa (analogia do tego, że człowiek czytający książki nie „kopiuje” ich w głowie w sposób prawnie relewantny),
model jako sprasowana kopia – argument, że przy odpowiednio dużej pojemności modelu i specyficznych zapytaniach dochodzi do reprodukcji istotnych części utworów, więc w sensie funkcjonalnym mamy do czynienia z utrwaleniem utworów w innej postaci.
Rzeczywistość prawna będzie prawdopodobnie kształtować się gdzieś pośrodku. Organy i sądy interesują głównie konkretne skutki: czy model, w typowych lub łatwo osiągalnych scenariuszach użycia, umożliwia dostęp do utworów bez zgody ich twórców. Jeżeli tak, trudno ograniczać analizę tylko do „czysto technicznego” opisu wag.
Analogie: wyszukiwarki, cache, kopie tymczasowe
Obecne argumenty wokół trenowania AI mocno nawiązują do wcześniejszych sporów o legalność wyszukiwarek i mechanizmów cache’owania. Kilka często przywoływanych analogii:
wyszukiwarki internetowe – trybunały europejskie uznały, że tworzenie indeksów i miniatur jest co do zasady dopuszczalne, ale pojawiają się obowiązki reakcji na zgłoszenia naruszeń (notice & takedown),
kopie tymczasowe (np. w pamięci RAM, buforach) – art. 5 ust. 1 dyrektywy InfoSoc uznał niektóre techniczne, efemeryczne kopie za neutralne z punktu widzenia prawa autorskiego, jeżeli spełnione są określone warunki (tymczasowość, integralność procesu transmisji),
systemy rekomendacyjne – orzecznictwo dotyczące serwisów hostujących treści użytkowników i rekomendujących je (platformy wideo) poszerzyło zasięg obowiązków „aktywnych” pośredników.
Zwolennicy swobodnego trenowania modeli na publicznych treściach argumentują, że LLM-y pełnią podobną funkcję jak wyszukiwarki: pomagają odnaleźć i przetworzyć informacje, a nie zastąpić oryginalne źródła. Krytycy odpowiadają, że różnica polega na tym, iż model nie tylko wskazuje na treści, ale generuje nowe „opakowanie” oparte na cudzym wkładzie, często bez możliwości dotarcia do oryginalnych autorów i ich wynagrodzenia.
Prawo cytatu i inspiracja twórcza a generatywne AI
Najczęściej zadawane pytania (FAQ)
Czy scraping treści z internetu do trenowania AI jest w Polsce legalny?
Scraping sam w sobie nie jest ani z definicji legalny, ani nielegalny. Wszystko zależy od tego, jakie treści pobierasz, w jakiej skali, w jakim celu oraz na jakiej podstawie prawnej (licencja, dozwolony użytek, zgoda właściciela, otwarte dane). Technicznie to tylko zautomatyzowane pobieranie stron, prawnie – kopiowanie i utrwalanie cudzych utworów lub baz danych.
Przy małej skali, na potrzeby badań czy analizy krytycznej, część zastosowań może mieścić się w dozwolonym użytku. Przy masowym zgrywaniu całych serwisów dla komercyjnego modelu AI ryzyko naruszenia praw autorskich, praw do baz danych, regulaminów i RODO gwałtownie rośnie. Kluczowa jest więc nie sama technologia scrapera, ale sposób i zakres wykorzystania danych.
Co można „bezpieczniej” scrapować do AI, a co jest szczególnie ryzykowne?
Najmniej ryzykowne z punktu widzenia prawa autorskiego są tzw. nagie fakty i proste dane: notowania giełdowe, kursy walut, podstawowe parametry techniczne produktów, surowe liczby statystyczne. Same fakty nie są chronione jako utwory, choć ich konkretne zestawienie w bazę może już korzystać z ochrony bazy danych.
Znacznie wyższe ryzyko pojawia się przy scrapowaniu pełnych tekstów (artykułów, blogów, recenzji), materiałów wizualnych (zdjęcia, grafiki, bannery) oraz zorganizowanych katalogów czy rankingów. Nawet jeśli pojedynczy opis jest krótki, masowe zgrywanie całej struktury serwisu może naruszać prawo do bazy danych sui generis. Im bardziej „gotowy produkt” zastępujesz swoją kopią, tym łatwiej mówić o eksploatacji na szkodę uprawnionego.
Czy do trenowania modelu AI wystarczy, że dane są publicznie dostępne w internecie?
Publiczna dostępność treści nie oznacza zgody na dowolne wykorzystanie. To, że strona jest widoczna w przeglądarce lub w Google, oznacza co najwyżej zgodę na odczyt w ramach zwykłego korzystania z serwisu, a nie automatycznie na masowe kopiowanie treści w celu trenowania komercyjnego modelu AI.
Liczy się to, co wynika z prawa autorskiego, ochrony baz danych, regulaminów serwisu i – przy danych osobowych – z RODO. W praktyce może się okazać, że: utwór jest chroniony, baza ma ochronę sui generis, regulamin zakazuje scrapingu, a dodatkowo przetwarzasz dane osobowe bez podstawy prawnej. „Publiczny dostęp” to więc dopiero punkt startu analizy, a nie zielone światło do trenowania modeli.
Czy można powołać się na dozwolony użytek przy scrapingu do AI?
Dozwolony użytek bywa przydatny, ale ma wąski zakres. Zwykle nie obejmuje on masowego scrapingu treści na potrzeby komercyjnego modelu ogólnego przeznaczenia. Wyjątki dotyczą m.in. użytku prywatnego, cytatu, działalności naukowej lub dydaktycznej – i każdy z nich ma swoje warunki oraz ograniczenia co do skali i celu wykorzystania.
Dodatkową komplikacją są przepisy o eksploracji tekstów i danych (text and data mining), które w UE wprowadzają pewne uprawnienia, ale też pozwalają właścicielom treści wyłączać się z tego reżimu (np. w regulaminie lub w metadanych). Opieranie całej strategii pozyskiwania danych do komercyjnej AI wyłącznie na „dozwolonym użytku” jest z reguły ryzykowne, szczególnie przy datasetach budowanych z tysięcy czy milionów stron.
Czy kopiowanie danych tylko „do treningu” modelu to już korzystanie z utworu?
W zdecydowanej większości przypadków tak. Z prawnego punktu widzenia ważne jest, że utwór lub istotna część bazy danych jest utrwalana, kopiowana i wykorzystywana w procesie działalności gospodarczej – nawet jeśli użytkownik końcowy nie widzi tych treści wprost. Argument, że „system tylko analizuje słowa, nic nie przechowujemy” ma ograniczoną siłę, gdy w praktyce tworzysz i utrzymujesz korpus treningowy.
Wyjątki mogą wynikać np. z tymczasowego charakteru kopii ściśle technicznie niezbędnych do transmisji albo z wyraźnej licencji obejmującej trening AI. Bez takiej podstawy techniczne „przemielenie” treści przez model jest zazwyczaj kwalifikowane jako korzystanie z utworu lub bazy danych.
Czy regulamin strony lub API może zakazać scrapingu do trenowania AI?
Tak. Regulaminy serwisów i warunki korzystania z API są umowami, które określają, co wolno zrobić z treściami i danymi. Coraz częściej pojawiają się w nich wprost zapisy zakazujące scrapingu, budowy zbiorów treningowych czy użycia danych do trenowania modeli AI. Złamanie regulaminu może prowadzić nie tylko do zablokowania dostępu, ale też do roszczeń kontraktowych.
Nawet jeśli z punktu widzenia prawa autorskiego Twoje działanie mieściłoby się w granicach dozwolonego użytku, naruszenie jasno sformułowanego zakazu w regulaminie otwiera zupełnie nowy front ryzyka. Dlatego przy projektowaniu pipeline’u danych do AI trzeba patrzeć nie tylko na przepisy ustaw, ale też na to, co konkretnie podpisałeś lub zaakceptowałeś jako użytkownik serwisu czy klient API.
Jak RODO wpływa na legalność scrapingu danych do trenowania AI?
Jeśli wśród scrapowanych treści znajdują się dane osób fizycznych (imiona, maile, profile, komentarze pozwalające na identyfikację), wchodzisz w obszar RODO. Oprócz praw autorskich i regulaminów musisz wtedy mieć odpowiednią podstawę prawną przetwarzania, zrealizować obowiązki informacyjne i respektować prawa osób, których dane dotyczą (np. sprzeciw wobec przetwarzania, żądanie usunięcia danych).
Trenowanie modelu na danych osobowych bez jasnej podstawy (np. uzasadnionego interesu właściwie zrównoważonego z prawami jednostki, przepisu szczególnego, zgody) może być trudne do obrony – szczególnie przy masowej skali. Dodatkowo nowe regulacje dotyczące AI (np. AI Act w UE) wzmacniają oczekiwania co do przejrzystości, dokumentowania datasetów i możliwości śledzenia źródeł danych treningowych, co jeszcze bardziej uwidacznia problemy z niekontrolowanym scrapingiem.
