Legalność web scrapingu w 2026: precedensy sądowe, GDPR, 152-FZ i praktyki

Wprowadzenie: dlaczego biznes powinien rozumieć ramy prawne web scrapingu w 2026 roku

Web scraping z narzędzia inżynierów przekształcił się w strategiczną dyscyplinę zarządzania danymi. W 2026 roku jego legalność zależy nie tylko od technologii, ale również od niuansów prawa międzynarodowego: precedensy sądowe w USA, europejska praktyka stosowania GDPR, rosyjskie zasady 152-FZ oraz stanowisko Roskomnadzoru. W efekcie to samo działanie może być legalne w jednej jurysdykcji, warunkowo dozwolone w drugiej i ryzykowne w trzeciej. To przewodnik pomoże Ci pewnie poruszać się w polu prawnym, stworzyć zgodność „by design”, zminimalizować ryzyka i maksymalnie wykorzystać wartość danych otwartych — bez konfliktów z regulatorami i właścicielami praw.

Czego się nauczysz: systematyczne zrozumienie kategorii prawnych danych; aktualny przegląd precedensów (w tym przypadku hiQ vs LinkedIn w ostatnich latach), praktyki europejskich regulatorów i rosyjskich sądów; jasne ramy oceny legalności; szczegółowe instrukcje ustawienia procesów; checklisty; narzędzia; realne przypadki i typowe błędy. Mówimy prostym językiem, jednocześnie na profesjonalnym poziomie, abyś mógł wdrożyć właściwe praktyki już dziś.

Ważna uwaga: niniejszy materiał dostarcza ogólnych informacji prawnych oraz analitycznych wskazówek. Nie stanowi porady prawnej i nie tworzy relacji klient-adwokat. Przed podjęciem decyzji skonsultuj się z prawnikiem zaznajomionym z Twoją branżą i jurysdykcjami.

Podstawy: co to jest web scraping i jak prawo postrzega dane

Kluczowe terminy i ich prawne znaczenie

• Web scraping — zautomatyzowane pozyskiwanie danych z publicznie dostępnych stron HTML lub API. Istotne prawnie: sposób dostępu (publiczny/ograniczony), obecność barier technicznych, warunki użytkowania.
• Dane otwarte — dane dostępne bez barier dla czytania przez ludzi. Ważne: „otwartość” nie pomija praw autorskich, praw pokrewnych, praw do baz danych i wymagań dotyczących danych osobowych.
• Dane osobowe (DO) — w UE/Obszarze EFTA według GDPR to każda informacja dotycząca zidentyfikowanej lub możliwej do zidentyfikowania osoby. W Rosji według 152-FZ — każda informacja dotycząca bezpośrednio lub pośrednio zidentyfikowanego lub identyfikowalnego obywatela Rosji.
• Publicznie dostępne dane osobowe — w UE: dane osobowe opublikowane przez podmiot lub stronę trzecią; pozostają DO z pełnym zestawem wymagań prawnych. W Rosji: po zmianach w 2021 roku wymaga się odrębnej zgody na ich rozpowszechnianie; fakt publikacji nie oznacza swobodnego użytkowania.
• Warunki korzystania (ToS/Terms) — postanowienia umowne strony lub API. Naruszenie ich wiąże się z konsekwencjami cywilnymi i, w niektórych jurysdykcjach, może być związane z normami dotyczącymi nieuprawnionego dostępu, jeżeli omijane są techniczne środki.
• robots.txt — plik z rekomendacjami dla robotów internetowych. Zasady techniczne dotyczące indeksacji i omijania. W większości porządków prawnych nie ma sam w sobie mocy prawnej, ale ignorowanie go może zwiększyć ryzyko (udowadnia niedobroszczerność).
• API vs HTML — dostęp przez API zazwyczaj jest licencjonowany i sformalizowany, a web scraping HTML opiera się na publiczności interfejsu. Z prawnego punktu widzenia API jest preferowane, ale wiąże się z surowszymi ograniczeniami kontraktowymi.

Główne osie oceny prawnej

• Jurysdykcja: gdzie znajdują się Ty, serwery, użytkownicy i podmioty danych.
• Typ danych: osobowe/nieosobowe; tajemnice handlowe; prawa autorskie i prawa pokrewne; prawa do bazy danych (w UE).
• Metoda dostępu: publiczna strona bez rejestracji vs za logowaniem, omijanie CAPTCHY i paywall, użycie sesji.
• Cele przetwarzania: dziennikarstwo, badania, zgodność, konkurencja, analiza komercyjna, bezpieczeństwo.
• Zakres i częstotliwość: „rozsądne” pozyskiwanie poszczególnych elementów vs systematyczne kopiowanie istotnej części bazy.

Dogłębna analiza: globalne ramy prawne i trendy

USA: sprawa hiQ vs LinkedIn i podobne pozycje

Sprawa hiQ vs LinkedIn przez lata kształtowała ton dyskusji wokół scrapingu publicznych profili. Na koniec 2024 roku sądy potwierdziły: dostęp do stron ogólnodostępnych bez omijania uwierzytelnienia sam w sobie nie jest równoznaczny z „nieautoryzowanym dostępem” w rozumieniu amerykańskiego prawa o przestępstwach komputerowych (CFAA), zwłaszcza po orientacyjnym wpływie sprawy Van Buren. Jednakże istnieją inne prawne dźwignie: roszczenia umowne według ToS, ochrona baz danych i treści, nieuczciwa konkurencja, trespass to chattels oraz inne teorie. Szereg głośnych sporów zakończyło się ugodami i/lub wyjaśnieniami praktyk platform. W latach 2025–2026 firmy powinny monitorować wszelkie nowe zwroty w podobnych sprawach w sądach federalnych, ale obecna fundamentalna linia dla publicznych stron pozostaje: CFAA stosuje się ostrożnie, bez rozszerzenia na „po prostu czytanie” tego, co jest dostępne dla szerokiej publiczności.

Wniosek praktyczny: w USA scraping publicznych stron bez omijania uwierzytelnienia nie jest równoważny z kryminalnym atakiem komputerowym. Ale naruszenie ToS i ignorowanie oficjalnych protokołów (w tym robots.txt) może zwiększyć ryzyko cywilnych roszczeń i prowadzić do postępowania, szczególnie przy masowym kopiowaniu lub komercyjnych działaniach pasożytniczych.

UE/Obszar EFTA: GDPR, ePrivacy i prawa do baz danych

• GDPR: wszelkie dane osobowe z publicznych źródeł pozostają DO. Potrzebna jest podstawa prawna (najczęściej „legitymne interesy”), informowanie zgodnie z art. 14 (lub uzasadnienie wyjątku), minimalizacja, terminy przechowywania, bezpieczeństwo i mechanizmy dla praw podmiotów. Regulatorzy (np. CNIL, irlandzki DPC i inni) wielokrotnie podkreślali: „publiczność” nie jest równoznaczna z „bez kontroli”. Niezastosowanie się do zasad prowadzi do dużych grzywien, co pokazują dochodzenia w sprawie masowych wycieków i scrapingu, prowadzące do nieautoryzowanego agregowania profili.
• Decyzje regulatorów: europejskie organy nadzoru nakładały znaczne kary za niewystarczającą ochronę przed scrapingiem (jako przejaw niewystarczających działań w zakresie „privacy by design” u operatorów publikujących dane), jak również za nielegalne przetwarzanie przez scrapujących. Praktyka dotycząca usług formujących biometryczne i behawioralne profile na podstawie publicznych obrazów i stron demonstruje surowe podejście do nieprzejrzystego przetwarzania i braku podstaw prawnych.
• Prawo sui generis do baz danych (Dyrektywa 96/9/WE): zabrania pozyskiwania lub ponownego wykorzystania istotnej części bazy oraz systematycznego pozyskiwania nieistotnej części, jeśli powoduje to straty. Kluczowe sprawy Trybunału UE podkreślają, że metawyszukiwarki i klony baz, reprodukujące wartość ekonomiczną źródła, podlegają zakazowi. To krytyczne dla projektów, które budują produkt na „odzwierciedlaniu” cudzej bazy danych.

Rosja: 152-FZ i stanowisko Roskomnadzoru

W Rosji wszelkie informacje dotyczące osoby mogącej być zidentyfikowaną — to dane osobowe. Zmiany z 2021 roku zaostrzyły reżim „publicznie dostępnych DO”: do ich rozpowszechniania wymagana jest odrębna zgoda z możliwością dostosowania warunków dostępu. Agregator, który zbiera takie dane, staje się operatorem DO ze wszystkimi obowiązkami: cele, podstawy prawne, powiadomienie Roskomnadzoru (w stosownych przypadkach), lokalizacja (242-FZ), prawa podmiotów, bezpieczeństwo.

Praktyka sądowa i nadzór w RF konsekwentnie wychodzą z założenia, że fakt umieszczenia informacji w Internecie nie otwiera „swobodnej licencji”. Nielegalny parsing danych osobowych i ich publikacja w agregatorach prowadzą do roszczeń o ochronę prywatności, do zaleceń Roskomnadzoru oraz kar administracyjnych. Dla nieosobowych danych kluczowe pozostają pytania o prawa autorskie, tajemnicę handlową i nieuczciwą konkurencję. Naruszenia ograniczeń technicznych oraz włamania do ochrony podlegają przepisom karnym o nieuprawnionym dostępie do informacji komputerowej.

Robots.txt, ToS, API: jak prawo postrzega sygnały techniczne i umowne

• robots.txt: prawnie częściej traktowane jako polityka techniczna, a nie zakaz w sensie prawa. Ale dowodowo jest ważne: ignorowanie może pokazać zamiar obchodzenia wyraźnych zasad, a w połączeniu z ToS i CAPTCHAMI zwiększa szanse na przegraną w sporze.
• ToS: w UE naruszenie ToS — kwestia umowy; w USA — ryzyko roszczeń cywilnych (umowa, delikt). W Rosji — publiczna oferta/umowa przystąpienia. Klucz: czy zgodziłeś się na ToS (akceptacja), jak udokumentowana jest komunikacja, i czy istnieje uzasadnienie dla uczciwego użytkowania.
• API: umowy licencyjne i ograniczenia częstotliwości tworzą jasne ramy prawne. Plusy: przewidywalność i jakość danych. Minusy: ograniczenia dotyczące ilości i celów. Próby obchodzenia limitów API poprzez scraping HTML lub proxy zazwyczaj zwiększają ryzyko.

Trendy 2026

• Przesunięcie fokusu na „obowiązek staranności” platform: regulatorzy zwiększają oczekiwania wobec właścicieli stron w zakresie zapobiegania nielegalnemu scrapingowi danych osobowych i informowania użytkowników o ryzykach.
• Lokalizacja i suwerenność danych: więcej wymagań dotyczących przechowywania kopii DO lokalnie i ograniczania transgranicznego transferu.
• Przejrzystość łańcucha dostaw danych: od źródła do konsumenta — wymóg weryfikowalnych podstaw prawnych i umów.
• Etyka i zaufanie: firmy konkurują nie tylko pod względem ilości danych, ale także „etyczności” ich pochodzenia i przetwarzania.

Praktyka 1: Ramy oceny prawnej scrapingu od A do Z

Krok 1. Mapowanie danych i celów

1. Opisz cele scrapingu: analizy cen, badania rynku, cele naukowe, kontrola jakości, monitorowanie ryzyka.
2. Skategoryzuj typ danych: osobowe, metadane, zwykłe dane biznesowe (ceny, SKU, harmonogramy), chronione elementy (biometria, identyfikatory finansowe).
3. Oceń dostępność: publiczna strona, czy wymagana jest rejestracja, czy występują CAPTCHY, paywalle, tokeny.
4. Określ jurysdykcje: gdzie jesteś, gdzie serwer, gdzie podmioty danych, dokąd są przekazywane dane.

Krok 2. Wybór podstawy prawnej (GDPR) i reżimu prawnego (RF)

• UE/Obszar EFTA (GDPR): najczęściej — „legitymny interes” (art. 6(1)(f)). Należy przeprowadzić Ocenę legitymnego interesu (LIA): opisać interes, konieczność przetwarzania, ocenić równowagę z prawami podmiotów, wdrożyć środki ochrony (minimalizacja, pseudonimizacja, ograniczenie celów).
• RF (152-FZ): określ, czy przetwarzasz dane osobowe. Jeśli tak — potrzebna jest podstawa prawna: zgoda, prawo, umowa, inne przewidziane podstawy. Dla „publicznie dostępnych DO” sprawdź, czy istnieje odrębna zgoda na rozpowszechnianie i warunki dostępu. Uwzględnij lokalizację (242-FZ) i powiadomienie Roskomnadzoru, jeśli to konieczne.

Krok 3. Przejrzystość i informowanie

• GDPR art. 14: jeśli DO są pozyskiwane nie od podmiotu, potrzebne jest informowanie. Możliwe są wyjątki, jeśli udostępnienie informacji jest niemożliwe lub wymaga nieproporcjonalnych wysiłków; wtedy umieść ogólną publiczną informację o swoim przetwarzaniu, zapewnij łatwość realizacji praw podmiotów, udokumentuj ocenę proporcjonalności.
• RF: informuj podmioty w ramach swojego stanowiska dotyczącego DO; zapewnij mechanizmy odwołań i usunięcia. Dla danych rozpowszechnianych z ograniczeniami przestrzegaj reżimu ustalonego przez podmiot.

Krok 4. Czystość umowna

• Przeanalizuj ToS źródła: czy istnieje zakaz automatycznego zbierania, ograniczenia dotyczące użytkowania komercyjnego, warunki licencjonowania.
• Sprawdź możliwości API: jeśli API jest dostępne i pokrywa potrzeby, zazwyczaj jest preferowane.
• Oceń prawo do bazy danych (UE): czy istnieje ryzyko pozyskania istotnej części lub systematycznego odtwarzania treści.

Krok 5. DPIA i środki ochrony

• Jeśli ryzyko jest wysokie (masowe DO, profilowanie, grupy wrażliwe) — przeprowadź DPIA: zagrożenia, środki, pozostałe ryzyko, plan minimalizacji.
• Wdróż minimalizację: zbieraj tylko niezbędne pola, przechowuj jak najmniej, usuwaj według harmonogramu.
• Kontroluj międzynarodowe transfery: UE — standardowe klauzule umowne i ocena kraju docelowego.

Krok 6. Rejestry i procedury operacyjne

• RoPA (rejestr operacji): cele, kategorie danych, odbiorcy, okres przechowywania, środki bezpieczeństwa.
• Procedury DSR (wnioski podmiotów): dostęp, usunięcie, sprzeciw wobec przetwarzania.
• Zarządzanie incydentami: polityka powiadamiania o naruszeniach, wewnętrzna komunikacja, plan reakcji.

Podsumowanie: macierz podejmowania decyzji

Scal wszystko w „mapę ryzyk”: typ danych × sposób dostępu × jurysdykcje × cel. Zielona strefa — publiczne nie-DO, API, wyraźna licencja. Żółta — publiczne DO z LIA, powiadomieniem, minimalizacją. Czerwona — omijanie barier, systematyczne kopiowanie bazy, specjalna kategoria DO.

Praktyka 2: Techniczny projekt i etyka scrapingu

Zasady „privacy & compliance by design”

• Szacunek dla źródła: przestrzegaj robots.txt jako podstawowej polityki; jeśli coś jest zabronione — oceń podstawy prawne i środki pomocnicze lub szukaj alternatywnych źródeł.
• Ograniczenia częstotliwości i obciążenia: ustanów ograniczenia zapytań, używaj pamięci podręcznej i „usypiających” interwałów; sprawdzaj godziny szczytu, aby nie zakłócać działania zasobów.
• Identyfikuj się: jasny User-Agent, kontaktowy adres e-mail do skarg; to zmniejsza ryzyko eskalacji.
• Jakość danych: sprawdzaj ważność, przechowuj sumy kontrolne i datę scrapingu; dokumentuj źródło dla audytu.
• Minimalizacja: nie zbieraj wrażliwych pól bez wyraźnej potrzeby; stosuj pseudonimizację.
• Bezpieczeństwo: szyfrowanie w przechowywaniu i w transporcie, kontrola dostępu, logowanie, identyfikatory do śledzenia.

Etapowa realizacja

1. Skansowanie: audyt robots.txt i ToS, mapa adresów URL i wzorów danych, ocena CAPTCHY i dynamiki strony.
2. Plan zapytań: limit częstotliwości, okna czasowe, ponowne próby z opóźnieniem wykładniczym, pamięć podręczna na poziomie wyniku.
3. Ekstrakcja: parsing z wyraźnym schematem, pomijanie pól, które nie wpisują się w cel.
4. Oczyszczanie: filtrowanie, normalizacja, usuwanie wyraźnych pól osobowych bez podstawy prawnej.
5. Przechowywanie: segmentacja według źródeł, czas życia danych, polityki usuwania.
6. Kontrola: monitorowanie błędów, 4xx/5xx, informowanie źródła o awariach.

Normy etyczne

• Nie twórz obciążenia, które zakłóca normalne działanie strony.
• Nie omijaj technicznych barier dostępu i nie naśladuj zachowania prawdziwych użytkowników bez zgody.
• Szanuj prośby o wyłączenie i usunięcie danych.
• Uwzględniaj interesy podmiotów danych, nawet jeżeli formalnie istnieje podstawa prawna.

Praktyka 3: Strategia prawna i umowna: ToS, licencje, API

Model „negocjuj lub ograniczaj”

• Pierwszy wybór — API: jeśli spełnia cele biznesowe, zorganizuj dostęp. Plusy: przewidywalność, SLA, pewność prawna. Minusy: limity i opłaty.
• Licencja na treści: przy systematycznym użytkowaniu danych z zewnętrznej strony rozważ umowę licencyjną. Jest to tańsze niż postępowanie sądowe, jeśli dane są kluczowe.
• Scraping z uwzględnieniem ToS: jeśli ToS zabraniają robotów — sprawdź możliwości pisemnej zgody, programy małych wolumenów, partnerstwa.

Ocena praw do bazy danych i treści

• UE: oceń, czy nie pozyskujesz „istotnej części” bazy lub reprodukujesz jej wartość ekonomiczną. Regularne zapytania, które replikują bazę, są ryzykowne.
• Prawa autorskie: teksty, zdjęcia, struktury strony; cytowanie i uczciwe użytkowanie są ograniczone.

Ramy analizy przedumownej

1. Wartość biznesowa danych i alternatywy.
2. Zakres i częstotliwość dostępu.
3. Reżim danych (DO/nie DO), jurysdykcje, międzynarodowe transfery.
4. Modele licencyjne i koszty zgodności w porównaniu do ryzyka prawnego.

Praktyka 4: Infrastruktura i proxy: jak działać legalnie i przejrzyście

Wskazówki prawne dotyczące korzystania z proxy

• Celem: proxy są dozwolone do równoważenia ruchu, testowania geograficznego, zapewniania niezawodności i prywatności infrastruktury — ale nie do obchodzenia zakazów dostępu lub ukrywania naruszeń ToS.
• Legalność i zgoda: korzystaj tylko z dostawców, którzy legalnie uzyskują zasoby i zgodę właścicieli końcowych IP (szczególnie w przypadku mobilnych proxy). Wyklucz nieautoryzowane botnety i szare sieci.
• Przejrzystość: dokumentuj źródła IP, geografię, czy uzyskałeś zgodę na konkretne jurysdykcje i jak przetwarzane są skargi.

Model operacyjny bez obchodzenia zakazów

1. Polityka proxy: dokument zakazujący używania proxy do omijania CAPTCHY, paywall, uwierzytelnienia i ograniczenia częstotliwości ustalonego przez właściciela strony.
2. Segmentacja: rozdziel pule proxy do testów, produkcji i zwrotnej informacji, aby badać incydenty.
3. Etyczne limity: na poziomie kodu i proxy-gate, ustal maksymalną częstotliwość zapytań poniżej średniego użytkownika i przestrzegaj okien „ciszy”.
4. Dzienniki: prowadź logi (szyfrowane identyfikatory), aby odpowiadać na roszczenia i eliminować nadużycia.
5. Rejestr źródeł: dla każdego dostawcy — umowa, jurysdykcja, kontakt, SLA w zakresie powiadamiania o nadużyciach.

Mobilne proxy: kiedy są uzasadnione i jak działać bezpiecznie

• Use-cases: testowanie geograficzne mobilnych interfejsów, sprawdzanie dostępności, mierzenie prędkości i jakości.
• Kontrola zgodności: audyt dostawcy pod kątem legalności źródeł IP; pisemne zapewnienia o zgodzie końcowych użytkowników; procesy reagowania na skargi.
• Środki techniczne: białe listy domen (gdzie dozwolone są zapytania), ograniczenie prędkości, zakaz przesyłania osobistych identyfikatorów przez proxy bez szyfrowania.

W zasadzie: proxy to narzędzie inżynierii sieciowej, a nie środek do obchodzenia zakazów. Jakiekolwiek scenariusze „do obchodzenia blokad i detekcji” zwiększają ryzyko prawne i są sprzeczne z etyką.

Praktyka 5: Dokumentowanie procesów: uczynienie zgodności weryfikowalnym

Artefakty dla audytora i regulatora

• Mapa danych: źródła, kategorie danych, pola, jurysdykcje, cele.
• RoPA: rejestr przetwarzania dla każdego celu; aktualizowany przy zmianach.
• LIA: uzasadnienie legitymnego interesu (UE), równowaga z prawami podmiotów, środki łagodzące.
• DPIA: dla scenariuszy wysokiego ryzyka (masowe profilowanie, dane wrażliwe).
• Polityki: polityka scrapingu, polityka proxy, polityka przechowywania i usuwania, polityka reagowania na incydenty.
• Szablony powiadomień: strona przejrzystości (art. 14), odpowiedzi na DSR, procesy wycofywania zgód (RF: warunki rozpowszechnienia DO).

Etapowa operacjonalizacja

1. Wyznacz właściciela procesu (Data Steward) i powiązania Legal × Engineering × Security.
2. Opisz end-to-end pipeline: zbieranie, przetwarzanie, przechowywanie, dostęp, usunięcie.
3. Wyznacz KPI: czas reakcji na DSR, odsetek minimalizowanych pól, średni czas życia danych, skuteczność audytów.
4. Przeprowadź ćwiczenia typu tabletop: scenariusz skargi podmiotu danych, wniosek regulatora, roszczenie właściciela praw.
5. Wdroż regularne przeglądy ToS kluczowych źródeł.

Szablony, które warto mieć

• Szablon LIA (krótka forma: cel, konieczność, równowaga, środki, wnioski).
• Szablon DPIA (rejestr ryzyk, prawdopodobieństw, wpływów, przeciwdziałań).
• Szablon odpowiedzi na DSR (w tym identyfikacja wnioskodawcy, terminy, wyjątki).
• Szablon prośby o zgodę na scraping do właściciela strony (z opisem zakresu, celów, częstotliwości, kontaktów).

Praktyka 6: Treści i IS: jak nie przekroczyć granicy

Prawa autorskie

• Co jest chronione: teksty, zdjęcia, design, kod; fakty jako takie — nie, ale ich zestawienie i układ mogą być chronione.
• Uczciwe użytkowanie: ograniczone, zależne od jurysdykcji; nie polegaj na tym jako na głównej strategii.

Prawo do baz danych (UE)

• Unikaj istotnego pozyskania i systematycznego kopiowania nieistotnych części, które odtwarzają wartość ekonomiczną.
• Środki techniczne: selektywne próbki, agregowanie bez rekonstrukcji źródła, odsyłanie do pierwotnego źródła w celu weryfikacji.

Tajemnica handlowa i nieuczciwa konkurencja

• Nie pozyskuj zamkniętych sekcji; nie korzystaj z cudzych sekretów, które stały się dostępne przez obejście barier.
• Nie twórz iluzji partnerstwa ani afiliacji z źródłem, jeśli jej nie ma.

Praktyka 7: API vs HTML: jak wybierać i łączyć

Kiedy API jest lepsze

• Gdy istnieją stabilne potrzeby i procesy krytyczne dla SLA.
• Gdy potrzebne jest wsparcie prawne i techniczne.
• Gdy ważne jest przestrzeganie limitów i licencji, a także otrzymywanie aktualizacji schematów.

Kiedy HTML jest uzasadnione

• Dane są proste, nie osobowe, brak API, a dostęp publiczny jest oczywisty.
• Kiedy potrzebny jest szybki jednorazowy snapshot rynku.

Model hybrydowy

• Podstawowy przepływ — poprzez API; HTML — jako rezerwa do walidacji i zamykania luk, przy ścisłych limitach i zasadach etycznych.

Typowe błędy: czego NIE robić

• Ignorować ToS i robots.txt „bo technicznie można”.
• Zbierać wszystko bez wyjątku: naruszenie zasady minimalizacji.
• Przechowywać bez końca: brak terminów usuwania i aktualizacji.
• Przekraczać granice bez mechanizmów prawnych.
• Brak powiadomień i przejrzystości zgodnie z art. 14 (UE) lub wymaganiami 152-FZ.
• Używać podejrzanych proxy, powiązanych z botnetami i naruszających zgodę właścicieli.
• Omijać CAPTCHY i uwierzytelnianie: wysokie ryzyko prawne i reputacyjne.

Narzędzia i zasoby: co wykorzystywać

Narzędzia prawne i zgodności

• Generatory i szablony LIA/DPIA oraz rejestrów przetwarzania.
• Platformy do zarządzania DSR i audytów.
• Systemy data lineage i katalogów danych dla przejrzystości źródeł.

Narzędzia techniczne

• Frameworki scrape'ujące wspierające rate limiting, retraje i caching.
• Narzędzia do anonimizacji i pseudonimizacji.
• SIEM/logowanie, kontrola dostępu, szyfrowanie na poziomie bazy i kanału transportowego.

Praktyki operacyjne

• Okresowe przeglądy ToS i robots.txt kluczowych domen.
• Wewnętrzne checklisty przed uruchomieniem nowego źródła.
• Szkolenie zespołu z etyki scrapingu oraz zasad „minimalizacji”.

Przypadki i wyniki: z praktyki biznesu

Przypadek 1: Monitoring cen bez DO

Firma X zajmuje się handlem elektroniką. Cel — codzienny monitoring cen konkurencji. Dane: nazwy produktów, SKU, cena, dostępność. Działania: analiza ToS (brak zakazu indeksowania; są zakazy dotyczące masowego kopiowania treści). Technicznie: agresywna pamięć podręczna, dostęp bez logowania, ograniczenie częstotliwości 0.1 RPS na domenę, nocne okna. Prawo: nie-DO; analiza praw do bazy (UE) — wyłącznie wybrane pozycje; brak rekonstrukcji bazy. Wynik: stabilny feed bez skarg, obniżenie kosztów zakupu o 3.7%, brak incydentów przez 12 miesięcy.

Przypadek 2: Agregator ofert pracy (UE)

Firma Y zbiera oferty pracy z stron pracodawców. Dane: tytuły, opisy, lokalizacje, czasami kontaktowe e-maile rekruterów (DO). Prawo: LIA, art. 14 informowanie przez publiczną stronę oraz mechanizm opt-out dla adresów kontaktowych, usunięcie adresów przy pierwszym kontakcie, minimalizacja (przechowywanie e-maili w postaci haszowanej do momentu kontaktu z pracodawcą). Prace umowne: propozycje licencji dla dużych stron, gdzie ToS zabraniają robotów. Wynik: 10 umów partnerskich, utrzymanie zgodności, brak grzywien; wzrost pokrycia rynku o 18%.

Przypadek 3: Rosyjski analityk marketingowy

Firma Z analizuje otwarte profile wykonawców na platformach freelancerskich. Dane: nick, portfolio, stawki, opinie; mogą występować DO. Prawo RF: określenie jako operator DO, informowanie o działalności, lokalizacja kopii w RF, polityka przetwarzania; wyłączenie z indeksu na żądanie; zbieranie wyłącznie publicznych pól; wyłączenie telefonów i e-maili (jeśli nie ma wyraźnej zgody na rozpowszechnianie). Wynik: prawnie czysty produkt, brak zaleceń, lojalność platform (wymiana feedów).

FAQ: 10 kluczowych pytań

1. Czy można legalnie scrapować strony bez logowania?

Jeśli strona jest publiczna i nie ma obchodzenia technicznych barier, w wielu jurysdykcjach nie jest to traktowane jako nielegalny dostęp. Ale pozostają ryzyka: naruszenie ToS, bazy danych (UE), DO (GDPR/152-FZ). Sprawdź podstawę prawną, minimalizację, powiadomienie i respektuj robots.txt.

2. Jak prawo odnosi się do robots.txt?

To techniczna rekomendacja, a nie prawo. Jednak ignorowanie go może wzmocnić dowody na niedobroszczerność i naruszenia ToS. W praktyce zgodności robots.txt powinno się przestrzegać z zasady.

3. Czy potrzebna jest podstawa prawna zgodnie z GDPR, jeśli dane są publiczne?

Tak. Publiczność nie znosi wymogów GDPR. Najczęściej odpowiedni będzie legitymny interes z LIA. Obowiązkowe są minimalizacja, przejrzystość (art. 14), terminy przechowywania i mechanizmy praw podmiotów.

4. Co się zmieniło w sprawie hiQ vs LinkedIn do 2026 roku?

Na koniec 2024 roku podstawowa linia wygląda następująco: scraping publicznych stron bez omijania uwierzytelnienia nie jest przestępstwem CFAA sam w sobie. W okresie 2025–2026 śledź nowe decyzje w podobnych sporach. Nie polegaj na CFAA jako na „indulgencji”: ToS, prawa autorskie, bazy danych i inne normy pozostają.

5. Czy można scrapować kontaktowe e-maile?

Ryzyko jest podwyższone, ponieważ to DO. Dla UE — LIA i art. 14 informowanie lub wyjątek, ścisła minimalizacja i cel. Dla RF — podstawy według 152-FZ i poszanowanie warunków rozpowszechnienia. W niektórych przypadkach lepiej usunąć e-mail z początkowego zbierania.

6. Co z mobilnymi proxy?

Używaj tylko legalnych źródeł, nie do obchodzenia zakazów. Określ politykę, ogranicz prędkość, prowadź dzienniki i reaguj na skargi. Omijanie CAPTCHY/uwierzytelnienia za pomocą proxy zwiększa ryzyko naruszeń.

7. Jakie konsekwencje niesie za sobą naruszenie ToS?

Roszczenia cywilne, blokady, możliwe roszczenia dotyczące nieuczciwej konkurencji i IS. W niektórych scenariuszach suma działań może być interpretowana jako nieautoryzowany dostęp.

8. Czy trzeba informować Roskomnadzór?

Zależy od charakteru przetwarzania DO i podstaw. Jeśli jesteś operatorem DO, sprawdź wymogi dotyczące powiadamiania, lokalizacji i polityki. W razie wątpliwości — audyt u specjalisty.

9. Jak spełnić art. 14, jeśli podmiotów jest wiele?

Oceń „nieproporcjonalne wysiłki”: jeśli właściwe, stosuj publiczne powiadomienia, jasne kanały opt-out i zmniejszaj ilość DO. Udokumentuj ocenę.

10. Jak unikać roszczeń dotyczących baz danych w UE?

Nie pozyskuj istotnej części i nie odbudowuj wartości ekonomicznej. Pracuj z próbkowaniem, agregowaniem, odsyłaniem do pierwotnego źródła i, gdy to możliwe, uzyskuj licencję.

Odpowiedzialność: grzywny, roszczenia, reputacja

UE/Obszar EFTA

• GDPR: do 20 milionów euro lub 4% globalnego obrotu; niektóre sprawy związane z masowym scrapingiem prowadziły do dużych kar dla operatorów, którzy niechronili DO przed nielegalnym pozyskaniem, oraz dla scrapujących przy nielegalnym dalszym przetwarzaniu.
• Bazy danych: zakazy sądowe, odszkodowania, zajęcie korzyści.

USA

• Roszczenia cywilne za naruszenie ToS, praw autorskich, nieuczciwą konkurencję, trespass to chattels; zakazy sądowe i odszkodowania.

Rosja

• 152-FZ i Kodeks wykroczeń administracyjnych: kary administracyjne za naruszenia przetwarzania DO, zalecenia do usunięcia, ograniczenia działalności stron/aggregatorów.
• KK RF: za nieuprawniony dostęp do informacji komputerowej przy obchodzeniu ochrony.
• Roszczenia cywilne: ochrona czci, godności, prywatności, IS; odszkodowania.

Reputacja

Nawet prawidłowy scraping może wywołać negatywne odczucia, jeśli brakuje przejrzystości. Proaktywna komunikacja, etyka i jasne mechanizmy wyłączenia zmniejszają ryzyko.

Kontrolne listy i gotowe ramy

Checklist do pre-scrapingu

• Określony cel i minimalny zestaw pól.
• Sprawdzone ToS, robots.txt, dostępność API.
• Skategoryzowane DO/niedane DO, jurysdykcje.
• Przygotowane LIA/DPIA w razie potrzeby.
• Określone terminy przechowywania i usuwania.
• Skonfigurowane ograniczenia częstotliwości oraz caching.
• Opisane mechanizmy DSR i opt-out.

Ramy „4 kwadrantów”

• Dane: DO vs nie DO.
• Dostęp: publiczny vs ograniczony.
• Prawo: UE/USA/RF/inne.
• Cel: legitymny interes/badania/dziennikarstwo/marketing.

Checklist po scrapingu

• Kontrola jakości, usunięcie zbędnych pól.
• Dokumentowanie źródeł i dat.
• Aktualizacja rejestrów (RoPA), LIA/DPIA.
• Kontrola międzynarodowych transferów.
• Aktualizacja strony przejrzystości i FAQ.

Co obserwować w latach 2025–2026

• Nowe decyzje w sprawach takich jak hiQ vs LinkedIn oraz podejście sądów do połączonych roszczeń (ToS + IS + nieuczciwa konkurencja).
• Decyzje europejskich regulatorów (CNIL, DPC i in.) dotyczące masowego scrapingu DO, w tym wymagania „privacy by design” dla platform.
• Praktyka rosyjska dotycząca „publicznie dostępnych DO”, lokalizacji i zaleceń Roskomnadzoru; rozwój administracyjnych grzywien.
• Aktualizacje w ePrivacy i możliwe wyjaśnienia EDPB dotyczące monitorowania publicznych źródeł.

Podsumowanie: strategia zrównoważonego scrapingu

Legalny web scraping to nie zestaw sztuczek, ale systemowa dyscyplina na styku prawa, inżynierii i etyki. Właściwe pytania brzmią: po co potrzebujemy tych danych, czy możemy się obejść mniejszą ilością, co powiemy podmiotom danych i właścicielom stron, jak udowodnimy swoją dobrą wolę za rok. W 2026 roku wygrywa ten, kto buduje procesy „zgodnie z prawem z definicji”: szanuje robots.txt i ToS, wybiera API, gdy to możliwe, dokumentuje podstawy prawne, minimalizuje zbieranie, chroni dane i otwarcie komunikuje się ze źródłami i podmiotami. Takie podejście minimalizuje ryzyka, przyspiesza zatwierdzenia i buduje zaufanie — zasób, który trudno skopiować i niemożliwe jest go zdobyć poprzez scraping.

Następne kroki: przeprowadź audyt aktualnych źródeł według checklist; zaktualizuj LIA/DPIA; wdroż politykę proxy i etyki scrapingu; stwórz stronę przejrzystości oraz procesy DSR; przeszkol zespół i wyznacz właścicieli; regularnie przeglądaj ToS kluczowych źródeł i monitoruj praktykę regulatorów. Zrównoważona zgodność to przewaga konkurencyjna. Wykorzystaj ją.