Web scraping a prawo: kiedy można skanować cudze strony, a kiedy zaczyna się ryzyko?

Web scraping bywa przedstawiany jako zwykłe „automatyczne pobieranie danych ze strony internetowej”. W praktyce to jednak nie tylko zagadnienie techniczne, lecz także prawne. Programista, analityk danych, founder startupu czy zespół AI bardzo często patrzą na scraping przez pryzmat jednego pytania: „czy to, że dane są publicznie dostępne, oznacza, że mogę je legalnie pobrać i dalej wykorzystać?”. Odpowiedź brzmi: nie zawsze. Sam fakt, że treść jest widoczna w przeglądarce, nie oznacza jeszcze pełnej swobody kopiowania, masowego pobierania, agregowania i komercjalizacji. W polskim i unijnym porządku prawnym legalność scrapingu zależy jednocześnie od kilku warstw: regulaminu danej strony, prawa autorskiego, ochrony baz danych, przepisów o danych osobowych, a czasem także od sposobu technicznego prowadzenia scrapingu. 

To właśnie dlatego pytanie „czy web scraping jest legalny?” jest zbyt ogólne. Bardziej precyzyjnie należałoby pytać: co dokładnie pobieram, z jakiej strony, w jakim celu, w jakiej skali, czy zaakceptowałem regulamin, czy pobierane dane stanowią utwór albo bazę danych, czy zawierają dane osobowe, czy właściciel serwisu zastrzegł zakaz eksploracji tekstów i danych, a także czy moje działanie ingeruje w normalne korzystanie z serwisu. Dopiero złożenie tych elementów daje realną odpowiedź o poziomie ryzyka prawnego. 

Dla czytelnika technicznego najważniejsze jest zrozumienie jednej rzeczy: prawo nie ocenia wyłącznie samego „skryptu”. Ocenia rezultat prawny i gospodarczy całego procesu. Inaczej będzie ocenione sporadyczne pobranie kilku informacji z publicznej strony w celu testowym, inaczej budowa komercyjnej wyszukiwarki kopiującej systematycznie znaczną część cudzego serwisu, a jeszcze inaczej trenowanie modeli na masowo pobieranych zasobach zawierających utwory, bazy danych i dane osobowe. 

Zacznijmy od podstaw: web scraping nie jest z definicji ani legalny, ani nielegalny

W polskim prawie nie istnieje jeden przepis, który wprost mówiłby: „web scraping jest dozwolony” albo „web scraping jest zakazany”. To oznacza, że scraping trzeba oceniać przez zastosowanie ogólnych i szczególnych reżimów prawnych. Takimi reżimami są przede wszystkim prawo autorskie, ustawa o ochronie baz danych, RODO, ewentualnie prawo zobowiązań i odpowiedzialność kontraktowa wynikająca z regulaminu, a w niektórych przypadkach także przepisy dotyczące zwalczania nieuczciwej konkurencji lub ochrony infrastruktury informatycznej. 

To bardzo ważne, bo w praktyce wielu inżynierów zakłada, że skoro przeglądarka potrafi wyświetlić stronę, to bot może ją „czytać” dokładnie tak samo jak człowiek. Z technicznego punktu widzenia często jest to prawda. Z prawnego punktu widzenia już niekoniecznie. Dostępność treści w sieci oznacza dostęp faktyczny, ale nie zawsze pełne uprawnienie do kopiowania, zwielokrotniania, dalszego przetwarzania i wtórnego wykorzystania na dowolnych polach eksploatacji. Prawo autorskie przyznaje twórcy co do zasady wyłączne prawo korzystania z utworu i rozporządzania nim, a wyjątki muszą wynikać z ustawy. 

Już na tym etapie warto odróżnić trzy sytuacje. Po pierwsze: pobieranie samych faktów lub prostych danych, które nie są utworem. Po drugie: pobieranie treści chronionych prawem autorskim, takich jak opisy, artykuły, zdjęcia, recenzje czy struktura treści. Po trzecie: pobieranie zawartości bazy danych, która może korzystać z odrębnej ochrony jako baza chroniona prawem sui generis, nawet wtedy, gdy poszczególne rekordy same w sobie nie są utworami. To rozróżnienie jest absolutnie kluczowe dla oceny legalności scrapingu. 

Regulamin strony: czy zakaz scrapingu w Terms of Service naprawdę działa?

W praktyce pierwszym miejscem, do którego powinien zajrzeć każdy planujący scraping, jest regulamin serwisu, warunki korzystania, API Terms, robots instructions i inne komunikaty właściciela strony. Bardzo często znajdują się tam postanowienia zakazujące automatycznego pobierania danych, użycia botów, crawlowania, kopiowania zawartości, budowy mirrorów, komercyjnej agregacji albo trenowania modeli na treściach z serwisu. Tego typu klauzule nie są same przez się „prawem powszechnie obowiązującym”, ale mogą tworzyć ryzyko kontraktowe lub wzmacniać argumentację właściciela serwisu w sporze. 

Kluczowe pytanie brzmi jednak: czy taki regulamin wiąże konkretnego scrapera? W relacji z użytkownikiem zalogowanym, zarejestrowanym albo takim, który kliknął „akceptuję”, odpowiedź zwykle jest prostsza. Wtedy mamy wyraźny argument, że po stronie użytkownika powstał obowiązek kontraktowy powstrzymania się od określonych działań. Znacznie trudniej bywa w odniesieniu do osoby, która jedynie odwiedza publicznie dostępną stronę bez zakładania konta i bez jednoznacznej akceptacji warunków. Wtedy pojawia się spór o to, czy i w jakim zakresie warunki serwisu skutecznie weszły do relacji prawnej. 

W orzecznictwie unijnym ważny jest wyrok Trybunału Sprawiedliwości UE w sprawie Ryanair przeciwko PR Aviation. W dużym uproszczeniu Trybunał wskazał, że gdy dana baza nie korzysta z ochrony przewidzianej w dyrektywie bazodanowej, sama dyrektywa nie stoi na przeszkodzie ustanowieniu przez właściciela takich danych ograniczeń umownych dotyczących sposobu korzystania. Innymi słowy: brak ochrony „bazodanowej” nie oznacza automatycznie wolnej amerykanki; w pewnych sytuacjach właściciel nadal może próbować oprzeć swoją ochronę na kontrakcie. 

Dla praktyka oznacza to tyle, że regulaminu nie wolno ignorować. Nawet jeżeli nie kończy on sprawy, to może znacząco zwiększyć ryzyko sporu. Jest też istotny dowodowo: pokazuje, że właściciel strony wyraźnie sprzeciwiał się określonemu wykorzystaniu swoich zasobów. To z kolei może mieć znaczenie przy ocenie dobrej lub złej wiary, zakresu dozwolonego korzystania, naruszenia obowiązków kontraktowych i oceny szkody. 

Prawo autorskie: nie wszystko na stronie jest utworem, ale wiele rzeczy jest

Polska ustawa o prawie autorskim stanowi, że przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. To oznacza, że ochroną nie są objęte same fakty, proste dane, numery telefonów, ceny jako takie czy czysto techniczne informacje. Ochroną mogą natomiast być objęte opisy produktów, artykuły, komentarze, fotografie, grafiki, układ treści, selekcja materiałów, autorskie zestawienia czy oryginalne elementy interfejsu. 

Z punktu widzenia scrapingu bardzo ważna jest więc różnica między „pobraniem informacji” a „zwielokrotnieniem utworu”. Jeśli bot pobiera z serwisu same surowe fakty i następnie wykorzystuje je jako dane wejściowe do analizy statystycznej, ryzyko naruszenia prawa autorskiego może być niższe niż w sytuacji, gdy pobierane są całe opisy, artykuły prasowe, treści opinii użytkowników albo zdjęcia. W tym drugim przypadku zwykle wchodzimy już w obszar czynności zastrzeżonych dla uprawnionego, chyba że zachodzi ustawowy wyjątek. 

W prawie autorskim trzeba pamiętać jeszcze o jednej rzeczy: nawet techniczne, automatyczne kopiowanie do pamięci lub na dysk bywa „zwielokrotnieniem” w znaczeniu prawnym. Ustawa przewiduje co prawda wyjątek dla tymczasowego zwielokrotnienia o charakterze przejściowym lub incydentalnym, niemającego samodzielnego znaczenia gospodarczego i stanowiącego integralną część procesu technologicznego, ale wyjątek ten nie obejmie każdego przypadku scrapingu, zwłaszcza gdy dane są zapisywane, porządkowane, archiwizowane i dalej wykorzystywane biznesowo. 

Bardzo często popełniany błąd polega na utożsamianiu „publicznego dostępu” z „domyślną zgodą na kopiowanie”. Taka teza nie wynika z ustawy. Co do zasady twórcy przysługuje wyłączne prawo korzystania z utworu i rozporządzania nim. Dlatego w praktyce ocena scrapingu z perspektywy prawa autorskiego zawsze zaczyna się od pytania: czy treść, którą pobieram, ma cechy utworu? Jeżeli tak, to trzeba szukać podstawy ustawowej albo umownej, która pozwala na takie korzystanie. 

Ochrona baz danych: dla scrapingu to często ważniejsze niż samo prawo autorskie

W wielu projektach scraping nie dotyczy pojedynczych utworów, tylko dużych zbiorów informacji: ofert, ogłoszeń, katalogów, wyników, cen, rekordów, ogłoszeń o pracę, list podmiotów czy porównywarek. Właśnie tutaj ogromne znaczenie ma ustawa o ochronie baz danych, wdrażająca dyrektywę 96/9/WE. Polska ustawa przyznaje producentowi bazy wyłączne i zbywalne prawo pobierania danych i wtórnego ich wykorzystania w całości lub w istotnej co do jakości albo ilości części bazy danych, jeżeli sporządzenie, weryfikacja lub prezentacja jej zawartości wymagała istotnego nakładu inwestycyjnego. 

To ochrona odmienna od prawa autorskiego. Nie chodzi tutaj o twórczość i oryginalność układu, lecz o inwestycję w stworzenie i utrzymywanie zasobu danych. W praktyce wiele serwisów internetowych będzie próbowało wykazać właśnie tę ochronę: nie dlatego, że poszczególne rekordy są twórcze, ale dlatego, że zbudowanie i utrzymanie całej bazy wymagało znaczących nakładów finansowych, organizacyjnych i technicznych. 

Trybunał Sprawiedliwości UE w sprawie British Horseracing Board przeciwko William Hill podkreślił zarazem, że ochrona sui generis dotyczy inwestycji w uzyskanie, weryfikację lub prezentację zawartości bazy, a nie inwestycji w samo wytworzenie danych. To istotne ograniczenie. Jeżeli właściciel serwisu chce powoływać się na ochronę bazodanową, musi wykazać kwalifikowaną inwestycję w rozumieniu dyrektywy, a nie tylko to, że dane „powstały w jego przedsiębiorstwie”. 

Z perspektywy developera najważniejsze są jednak skutki praktyczne. Nawet jeśli pojedyncze pobranie niewielkiego fragmentu bazy nie będzie naruszeniem, to ustawa i dyrektywa chronią także przed działaniami polegającymi na systematycznym, powtarzalnym pobieraniu małych części w taki sposób, że w rezultacie obchodzony jest sens ochrony. Polska ustawa wprost zakazuje powtarzającego się i systematycznego pobierania lub wtórnego wykorzystania nieistotnej części co do jakości lub ilości zawartości bazy, jeżeli takie działania są sprzeczne z normalnym korzystaniem z bazy i powodują nieusprawiedliwione naruszenie słusznych interesów producenta. 

To właśnie ten punkt najczęściej „łapie” projekty scrapingowe. Programista mówi: „ale ja pobierałem tylko po 50 rekordów na minutę, to przecież mało”. Prawnie nie liczy się wyłącznie wielkość pojedynczego requestu. Liczy się także powtarzalność, systematyczność, skala, efekt końcowy i wpływ na normalną eksploatację bazy. Jeżeli końcowym skutkiem jest zbudowanie konkurencyjnego zasobu, lustra serwisu, porównywarki czy metawyszukiwarki pasożytującej na cudzej inwestycji, ryzyko wzrasta bardzo istotnie. 

„Lawful user”, nieistotne części i granica, której często nie widać w kodzie

Dyrektywa bazodanowa oraz polska ustawa przyznają użytkownikowi legalnie korzystającemu z publicznie udostępnionej bazy pewien zakres swobody. W szczególności co do zasady nie można mu zabronić pobierania lub wtórnego wykorzystania nieistotnej co do jakości lub ilości części bazy danych. To jednak nie jest licencja na dowolny scraping. Ochrona „lawful user” nie znosi zakazu przejmowania istotnych części bazy ani zakazu systematycznego obchodzenia ochrony przez wielokrotne pobieranie fragmentów. 

W praktyce największy problem polega na tym, że granica między częścią istotną i nieistotną rzadko daje się policzyć prostym procentem. „Istotność” może mieć charakter ilościowy, ale także jakościowy. Czasami nawet relatywnie mały wycinek będzie istotny, jeface

żeli obejmuje najbardziej wartościową lub strategiczną część całej bazy. Z drugiej strony duży wolumen technicznych danych pomocniczych nie zawsze będzie najważniejszy gospodarczo. Ocena jest więc funkcjonalna i zależy od konkretnego przypadku. 

Dobrze pokazuje to sprawa CV-Online Latvia przeciwko Melons, dotycząca metawyszukiwarki ogłoszeń o pracę. Trybunał analizował tam, czy eksploatacja treści dostępnych w internecie przez wyspecjalizowaną wyszukiwarkę nie narusza prawa producenta bazy, zwłaszcza gdy może zagrażać zwrotowi z inwestycji w stworzenie, weryfikację lub prezentację treści. Dla praktyki to ważny sygnał: prawo patrzy nie tylko na sam moment pobrania danych, ale też na ekonomiczny model wtórnego wykorzystania tych danych. 

Nowe wyjątki dla eksploracji tekstów i danych: po 2024 r. sytuacja w Polsce się zmieniła

W 2024 r. polskie prawo autorskie zostało znowelizowane w związku z wdrożeniem dyrektywy DSM. Dla świata scrapingu i AI ma to fundamentalne znaczenie, bo do ustawy weszły przepisy o eksploracji tekstów i danych, czyli TDM. Ustawa definiuje eksplorację tekstów i danych jako ich analizę przy zastosowaniu zautomatyzowanej techniki służącej do analizowania tekstów i danych w postaci cyfrowej w celu wygenerowania informacji obejmujących w szczególności wzorce, tendencje i korelacje. 

Po pierwsze, art. 26² ustawy autorskiej przewiduje szczególny wyjątek dla instytucji dziedzictwa kulturowego i określonych podmiotów naukowych działających dla celów badań naukowych, pod warunkiem braku bezpośredniej lub pośredniej korzyści majątkowej. Po drugie, art. 26³ wprowadza szerszy wyjątek: wolno zwielokrotniać rozpowszechnione utwory w celu eksploracji tekstów i danych, chyba że uprawniony zastrzegł inaczej. To jest właśnie model „dozwolone, ale z możliwością opt-out”. 

To zmienia analizę wielu projektów. Dziś nie wystarczy już powiedzieć: „nie miałem licencji, więc pewnie nie wolno”. W pewnych sytuacjach ustawa sama daje podstawę do zwielokrotniania utworów na potrzeby TDM. Ale równie błędne byłoby stwierdzenie odwrotne: „skoro jest TDM exception, to wolno mi wszystko”. Nie. Ustawodawca wyraźnie pozwolił uprawnionemu zastrzec brak zgody. Co więcej, w przypadku utworów publicznie udostępnionych online zastrzeżenie ma być dokonane wyraźnie, w formacie przeznaczonym do odczytu maszynowego wraz z metadanymi. 

Z punktu widzenia praktyki technicznej to bardzo istotne. Jeżeli właściciel serwisu w sposób zgodny z ustawą oznaczy, że nie zezwala na TDM, wówczas ogólny wyjątek z art. 26³ nie powinien działać. Jeżeli natomiast takiego skutecznego zastrzeżenia nie ma, pojawia się ustawowa przestrzeń do legalnej eksploracji tekstów i danych. Nadal jednak trzeba pamiętać, że to tylko jedna warstwa problemu. TDM exception nie uchyla automatycznie regulaminu, nie znosi RODO i nie wyłącza odrębnej ochrony baz danych. 

Analogiczne rozwiązanie wprowadzono do ustawy o ochronie baz danych. Zgodnie z art. 8a wolno zwielokrotniać rozpowszechnione bazy danych w celu eksploracji tekstów i danych, chyba że uprawniony zastrzegł inaczej; przepisy przewidują również wymóg wyraźnego zastrzeżenia oraz odpowiedniej formy przy udostępnianiu online. To oznacza, że po nowelizacji ocena legalności scrapingu musi uwzględniać nie tylko stare kategorie „copyright vs database right”, ale także nową kategorię: czy działa wyjątek TDM i czy został skutecznie wyłączony przez opt-out. 

Co w praktyce oznacza „zastrzeżenie inaczej”?

Dla programisty najbardziej praktyczne pytanie brzmi: jak rozpoznać, że właściciel strony skutecznie zastrzegł brak zgody na TDM lub scraping? Ustawa nie ogranicza się do klasycznego tekstowego „zakazujemy scrapingu”. W odniesieniu do treści publicznie dostępnych online mówi o formacie przeznaczonym do odczytu maszynowego wraz z metadanymi. To wskazuje, że samo czytanie regulaminu może nie wystarczyć; trzeba też sprawdzać techniczne sygnały publikowane przez serwis. 

Nie oznacza to jednak, że każdy techniczny sygnał automatycznie będzie wystarczający albo że każdy brak metadanych daje pełną swobodę. Ten obszar będzie dopiero dojrzewał w praktyce i sporach. Z ostrożnego punktu widzenia warto przyjąć, że im bardziej jednoznaczny, publiczny i maszynowo odczytywalny komunikat właściciela strony, tym słabsza pozycja prawna scrapera powołującego się na ogólny wyjątek TDM. 

Dobrą praktyką compliance jest więc dokumentowanie tego, co zespół techniczny sprawdził przed rozpoczęciem scrapingu: regulamin, dostępne metadane, komunikaty dotyczące TDM, dokumentację API, politykę botów, zakres licencji oraz to, czy serwis przewiduje oficjalny kanał dostępu do danych. Taka dokumentacja nie daje immunitetu, ale może mieć znaczenie dowodowe i organizacyjne, zwłaszcza gdy projekt rozwija się komercyjnie. 

Dane osobowe: publicznie dostępne nie znaczy „wolne od RODO”

To jeden z najczęściej bagatelizowanych obszarów. Jeżeli scraping obejmuje dane osobowe, wchodzi RODO. Nie ma znaczenia, że dane były publicznie dostępne na stronie. Z perspektywy ochrony danych nadal dochodzi do przetwarzania danych osobowych, a więc potrzebna jest podstawa prawna z art. 6 RODO i respektowanie zasad z art. 5 RODO, w tym zgodności z prawem, rzetelności, przejrzystości, minimalizacji i prawidłowości danych. 

W praktyce biznesowej najczęściej rozważaną podstawą będzie uzasadniony interes administratora, ale nie działa on automatycznie. Europejskie organy ochrony danych od lat podkreślają, że publiczna dostępność danych nie znosi ochrony. EDPS wskazuje wprost, że przy web scrapingu osoby mogą tracić kontrolę nad swoimi danymi, gdy są one zbierane bez ich wiedzy, wbrew ich oczekiwaniom i dla celów innych niż pierwotne. EDPS zaznacza także, że przetwarzanie publicznie dostępnych danych osobowych nadal w pełni podlega europejskim regułom ochrony danych. 

To ma duże znaczenie dla projektów typu lead generation, enrichment, agregacja profili, modele rekrutacyjne, OSINT komercyjny czy trening modeli na forach, portalach i profilach zawodowych. Samo stwierdzenie „przecież te dane były publiczne” nie wystarczy. Trzeba odpowiedzieć na pytania o cel, niezbędność, proporcjonalność, zakres danych, okres retencji, obowiązek informacyjny i możliwość realizacji praw osób, których dane dotyczą. RODO wymaga, aby przetwarzanie było zgodne z prawem tylko wtedy i tylko w takim zakresie, w jakim istnieje ku temu jedna z podstaw przewidzianych w art. 6 ust. 1. 

Szczególnie niewygodny dla projektów scrapingowych jest art. 14 RODO. Jeżeli dane nie zostały pozyskane bezpośrednio od osoby, administrator co do zasady ma obowiązek przekazać jej określone informacje, w tym tożsamość administratora, cele i podstawę prawną przetwarzania, okres przechowywania oraz — gdy podstawą jest uzasadniony interes — także wskazanie tego interesu. Dla masowego scrapingu oznacza to realny problem operacyjny, a czasem wręcz modelowe ryzyko niezgodności z prawem. 

Warto też pamiętać o zasadzie minimalizacji i prawidłowości danych. Organy ochrony danych zwracają uwagę, że web scraping łatwo prowadzi do nieproporcjonalnego i „niedyskryminującego” zbierania wszystkiego, co da się znaleźć. Tymczasem RODO wymaga, by zakres danych był adekwatny i ograniczony do tego, co niezbędne. Przy projektach AI czy analitycznych pojawia się też problem jakości źródeł, błędów, nieaktualności, duplikatów i błędnych inferencji. 

Czy regulamin może zakazać tego, na co ustawa pozwala?

To pytanie jest szczególnie ciekawe po nowelizacji TDM. Odpowiedź zależy od tego, o jakim reżimie mówimy. W dyrektywie bazodanowej istnieje przepis stanowiący, że postanowienia umowne sprzeczne z określonymi uprawnieniami lawful usera są nieważne. W szczególności dyrektywa przewiduje nieważność postanowień sprzecznych z art. 8. To pokazuje, że ustawodawca unijny nie zawsze pozwala kontraktowi „wyłączyć” wszystkie ustawowe uprawnienia użytkownika. 

Jednocześnie sprawa Ryanair uczy ostrożności: jeśli dana baza nie podpada pod ochronę dyrektywy, sama dyrektywa nie blokuje kontraktowych ograniczeń. Z perspektywy praktycznej nie warto więc formułować prostych sloganów typu „regulamin nigdy nie może być ważniejszy od ustawy” albo odwrotnie „regulamin zawsze wszystko załatwia”. Prawidłowa odpowiedź jest bardziej zniuansowana i zależy od tego, czy mamy do czynienia z bazą chronioną, z utworem, z wyjątkiem ustawowym, z relacją kontraktową oraz z konkretnym zakresem zakazu. 

Dla projektów biznesowych najlepszą praktyką nie jest szukanie „sprytnej interpretacji”, tylko analiza warstwowa. Najpierw: czy istnieje wiążący regulamin. Następnie: czy materiał jest objęty prawem autorskim lub ochroną bazy danych. Dalej: czy działa wyjątek TDM i czy został wyłączony opt-outem. Na końcu: czy występują dane osobowe i czy model przetwarzania da się obronić na gruncie RODO. Dopiero taki test pozwala mówić o świadomym ryzyku. 

Kiedy ryzyko jest najwyższe?

Z perspektywy praktycznej najwyższe ryzyko prawne pojawia się zwykle wtedy, gdy spełnionych jest kilka przesłanek naraz. Po pierwsze, scraping jest masowy, systematyczny i trwały. Po drugie, pobierane są treści mające cechy utworu albo istotna część chronionej bazy danych. Po trzecie, właściciel strony wyraźnie zakazał takich działań w regulaminie lub w maszynowo odczytywalnym zastrzeżeniu TDM. Po czwarte, dane są dalej wykorzystywane komercyjnie — zwłaszcza do budowy konkurencyjnego produktu, agregatora lub modelu o realnej wartości rynkowej. Po piąte, w danych występują dane osobowe. 

Wysokie ryzyko mają więc typowo takie modele jak: budowa alternatywnej wyszukiwarki ofert na podstawie cudzego serwisu, systematyczne kopiowanie katalogów konkurenta, pobieranie artykułów i opisów do własnego portalu, masowe budowanie leadów z publicznych profili albo trenowanie modeli na treściach, przy których uprawniony skutecznie zastrzegł brak zgody na TDM. 

Niższe ryzyko może występować przy jednorazowym, ograniczonym pobraniu danych niechronionych, bez danych osobowych, bez wpływu na normalne korzystanie z serwisu, najlepiej przy braku zakazu i przy ewidentnie analitycznym celu wewnętrznym. Ale nawet wtedy nie ma automatycznej gwarancji bezpieczeństwa. W prawie nowych technologii „niskie ryzyko” nie jest synonimem „na pewno legalne”. 

Co powinien zrobić informatyk przed uruchomieniem scrapera?

Po pierwsze, zmapować źródła i rodzaj danych. Trzeba wiedzieć, czy pobierane są fakty, utwory, zdjęcia, opisy, recenzje, rekordy bazodanowe, dane osobowe, czy mieszanka tego wszystkiego. Bez tej klasyfikacji nie da się poprawnie ocenić projektu. 

Po drugie, sprawdzić dokumentację prawną i techniczną serwisu: regulamin, zasady korzystania z API, komunikaty o TDM, ewentualne zastrzeżenia maszynowo odczytywalne. Po nowelizacji z 2024 r. pominięcie tego etapu jest po prostu błędem compliance. 

Po trzecie, ocenić skalę i cel. Im bardziej projekt zbliża się do komercyjnego wtórnego wykorzystania cudzego zasobu, tym większe ryzyko. Szczególnie problematyczne są modele zastępujące właściciela źródła lub pasożytujące na jego inwestycji. 

Po czwarte, przeanalizować RODO. Jeżeli w grę wchodzą dane osobowe, trzeba od razu odpowiedzieć na pytanie o podstawę z art. 6, obowiązek informacyjny z art. 14, minimalizację, retencję i prawa osób. Jeśli zespół nie ma na to sensownej odpowiedzi, projekt prawnie jest niedojrzały. 

Po piąte, rozważyć alternatywy: oficjalne API, licencję, partnerstwo danych, zakup feedu, dostęp do open data albo zgodę właściciela serwisu. Z biznesowego punktu widzenia bywa to tańsze niż późniejszy spór, blokada IP, wezwanie do zaprzestania naruszeń czy konieczność przebudowy całego produktu. W wielu przypadkach najbezpieczniejsza architektura to nie „sprytniejszy scraper”, lecz legalny kanał dostępu do danych. 

Wnioski końcowe

Web scraping nie jest dziś obszarem „poza prawem”. Wręcz przeciwnie: jest przecięciem kilku dojrzałych reżimów prawnych, które nakładają się na siebie i wzajemnie modyfikują ocenę ryzyka. Z perspektywy polskiego i unijnego prawa nie wystarczy powiedzieć: „dane były publiczne”. Trzeba uwzględnić regulamin, prawa autorskie do treści, ochronę baz danych, nowe przepisy o eksploracji tekstów i danych oraz — jeśli w grę wchodzą osoby fizyczne — pełne wymagania RODO. 

Najważniejsza praktyczna zasada brzmi więc tak: legalność web scrapingu zależy nie od samego narzędzia, lecz od konfiguracji celu, skali, źródła, rodzaju danych i sposobu dalszego wykorzystania. Ten sam kod może w jednym projekcie służyć dopuszczalnej analizie publicznych danych, a w innym prowadzić do naruszenia cudzych praw wyłącznych, warunków korzystania z serwisu albo przepisów o ochronie danych osobowych. 

Jeżeli więc informatyk, founder albo data scientist pyta dziś, czy może użyć web scrapingu w swojej pracy, najbardziej uczciwa odpowiedź prawnika brzmi: czasem tak, ale nigdy „na skróty”. Zanim scraper trafi na produkcję, warto przejść pełny audyt źródeł i podstaw prawnych. W przeciwnym razie projekt, który z technicznego punktu widzenia wygląda jak automatyzacja, z prawnego punktu widzenia może okazać się nieuprawnionym przejęciem cudzej treści, cudzej bazy albo cudzych danych osobowych.