AX/G/004

GDPR a scraping: co możesz, czego nie

Praktyczny przewodnik dla małej firmy bez prawnika in-house. Bez "konsultuj się z radcą" — konkretne reguły, które obowiązują.

Disclaimer: nie jesteśmy prawnikami, nie jest to porada prawna. Ten przewodnik to summary praktyk które stosujemy w produkcji od 4 lat dla klientów w PL/UE. Dla projektów wysokiego ryzyka (medycyna, finanse, dane wrażliwe) konsultuj się z radcą.

GDPR nie zakazuje scrapingu. Zakazuje określonych operacji na danych osobowych. Większość scrapingu nie dotyka danych osobowych w ogóle.

Reguła 1: Dane publiczne ≠ wolne do każdego użytku

"Wszystko co publiczne mogę scrape'ować" — błąd. Publiczna dostępność nie oznacza zgody na każde wykorzystanie. Cena produktu na sklepie online jest publiczna — ale to nie znaczy że możesz ją publicznie republic'ować z atrybucją sklepu. ToS strony może zabraniać scrapingu. Prawo autorskie chroni układ bazy danych.

Praktyczna zasada: publiczne dane do użytku wewnętrznego (analytics, benchmarking, monitoring) = bezpieczne. Publikacja w niezmienionej formie = ryzykowne. Komercyjna redystrybucja = zwykle wymaga umowy ze źródłem.

Reguła 2: Dane osobowe wymagają podstawy prawnej

GDPR Art. 6 lista 6 podstaw przetwarzania danych osobowych. W kontekście scrapingu trzy są najczęściej relevantne:

  • Art. 6(1)(a) — zgoda: osoba wyraziła zgodę. Niemożliwe przy scrape'ach na skalę.
  • Art. 6(1)(b) — wykonanie umowy: jeśli osoba jest twoim klientem / kontrahentem.
  • Art. 6(1)(f) — uzasadniony interes: cel biznesowy uzasadnia przetwarzanie, ale wymaga LIA (Legitimate Interest Assessment) — udokumentowanej oceny.

Praktycznie: scraping danych zawodowych (LinkedIn business pages, company directories) opiera się zwykle na 6(1)(f). Scraping danych prywatnych (osobiste profile, prywatne adresy, dane wrażliwe) — nie ma legalnej podstawy w 99% przypadków.

Reguła 3: Kontekst publikacji się liczy

Imię i email opublikowane na "Skontaktuj się" stronie firmy jako business contact = przeznaczone do business use. Te same dane na profilu osobistym Facebook = przeznaczone do social use.

Pierwszy test: w jakim kontekście dane są publikowane? Jeśli to public business contact, scraping pod B2B sales jest zwykle OK pod 6(1)(f). Jeśli to dane z kontekstu osobistego, NIE używaj pod B2B sales — to naruszenie uzasadnionego interesu.

Reguła 4: Wyłączenia sektorowe

Niektóre kategorie danych są szczególnie chronione (Art. 9 GDPR):

  • Dane o zdrowiu
  • Pochodzenie rasowe lub etniczne
  • Poglądy polityczne, religijne, światopoglądowe
  • Orientacja seksualna
  • Dane biometryczne (np. rozpoznawanie twarzy)
  • Przynależność do związków zawodowych

Te wymagają zgody jednostki ALBO ścisle określonych podstaw prawnych (badania medyczne, postępowanie sądowe etc). Scraping ich pod marketing/sales = wysokie ryzyko niezależnie od źródła.

Reguła 5: Obowiązki informacyjne (Art. 13 i 14)

Jeśli zbierasz dane osobowe (z dowolnego źródła, w tym scraping), musisz spełnić obowiązek informacyjny:

  • Kto jest administratorem i kontakt
  • Cel przetwarzania i podstawa prawna
  • Okres przechowywania
  • Prawa osoby (dostęp, sprostowanie, usunięcie)

Art. 14 (dane zebrane nie od osoby) wymaga informowania osoby w ciągu miesiąca od zebrania, chyba że: dostarczenie informacji jest niemożliwe lub wymagałoby niewspółmiernego wysiłku.

Praktycznie: scrapując dane B2B (np. listę 5000 firm), publikuj politykę prywatności gdzie tłumaczysz jak zbierasz i przetwarzasz dane. To pokrywa Art. 14 dla skali na której manual notification jest nieracjonalna.

Reguła 6: Right to be forgotten

Osoba ma prawo żądać usunięcia swoich danych (Art. 17). W praktyce: jeśli email 'john@company.com' jest w twojej bazie z scrape'u i John napisze że chce być usunięty — musisz usunąć w ciągu miesiąca.

Operacyjna implementacja: dedykowany endpoint / formularz do żądania usunięcia (np. privacy@axsolutions.pl), system tracking żądań, hard-delete vs soft-delete strategia. Bez tego dostajesz fine.

Reguła 7: ToS targetu może być dodatkową warstwą

Niezależnie od GDPR, target strony może mieć ToS zakazujące scrapingu. To kwestia umowy cywilnej nie kryminalnej, ale ToS violation może kończyć się: ban IP, cease & desist, w extreme przypadkach pozew (hiQ Labs vs LinkedIn jest kluczowym precedensem — wygrali, ale po 5 latach sporu).

Praktyczna zasada:

  • Sklep e-commerce monitoring: ToS często zabraniają ale enforcement minimalny. Risk acceptable dla większości scenariuszy.
  • LinkedIn / Facebook: ToS agresywnie egzekwowane. Skala enterprise = realne ryzyko prawne.
  • Gov portale (BIP, eZamówienia): dane publiczne z definicji. Brak ToS issue.

Reguła 8: Rate limiting jako etyka inżynierska

GDPR tego nie wymaga ale dobry scraping zawsze stosuje:

  • Comfortable rate (1 request per 5-30 sekund per target, nie hammer)
  • Respektowanie robots.txt (informacja, nie obowiązek prawny, ale signal dobrej praktyki)
  • Identyfikowalny User-Agent (nie udawanie regular browser)
  • Backing off przy 429/503
  • Off-hours scraping gdy możliwe

To zwiększa odporność (mniej ban'ów, więcej uptime'u) i zmniejsza ryzyko prawne (jasny brak intencji destabilizacji).

Czek-lista dla projektu scrape'u

Zanim odpalisz pipeline w produkcji:

  1. Identyfikacja danych: czy zbieram dane osobowe? Jeśli tak, jakie kategorie?
  2. Podstawa prawna: dla danych osobowych zdefiniuj Art. 6 GDPR.
  3. LIA jeśli 6(1)(f): udokumentowane uzasadnienie biznesowe vs prawa osób.
  4. Polityka prywatności opublikowana, zawiera informacje wymagane Art. 13/14.
  5. Mechanizm usunięcia: endpoint privacy@, max 30 dni response time.
  6. Retencja: zdefiniowane terminy usuwania (np. 24 mies od ostatniego kontaktu).
  7. Rate limiting: comfortable, respektujący target.
  8. Logging: timestamp + source + cel każdej operacji (audit trail).

Sedno

Scraping publicznych danych biznesowych pod B2B sales/marketing/research jest legalny w 95% przypadków, jeśli:

  • masz politykę prywatności tłumaczącą Art. 14
  • masz mechanizm usunięcia danych
  • nie scrapujesz danych szczególnie chronionych (Art. 9)
  • stosujesz comfortable rate i transparent User-Agent
  • masz udokumentowane LIA jeśli opierasz się na 6(1)(f)

Reszta to edge case'y — sektory regulowane, scale enterprise, niejasne ToS. Wtedy konsultacja z radcą jest nieuniknienna. Dla typowego małego biznesu pod price monitoring, lead intel, market research — powyższa checklista wystarcza.

Masz podobny problem?

Większość tych technik wdrażamy na produkcję.

Jeśli ten artykuł rezonuje z czymś, co próbujesz rozwiązać — napisz. Wstępna ocena projektu jest bezpłatna.