Wytyczne EROD dotyczące web scrapingu: celowane scrapery wygrywają

EROD właśnie napisała specyfikację dla scraperów

Europejskie organy ochrony danych powiedziały już wiele o modelach AI. Do tego lata żadne z tych stanowisk nie mówiło inżynierowi, co scraper powinien zrobić, zanim pobierze pierwszą stronę.

Wytyczne 03/2026 dotyczące web scrapingu w kontekście generatywnej AI to zmieniły. Europejska Rada Ochrony Danych przyjęła projekt 7 lipca 2026 r., a jego konsultacje publiczne kończą się 30 października 2026 r. Na papierze zakres jest wąski: prywatne firmy scrapujące dane osobowe w celu trenowania lub dostrajania generatywnej AI. W praktyce jest to najbardziej szczegółowy opublikowany przez regulatora opis tego, jak zbudować proces scrapingu możliwy do obrony prawnej, od kryteriów zdefiniowanych przed pierwszym zapytaniem po znacznik czasu przy ostatnim rekordzie.

Nasz wniosek po przeczytaniu wszystkich 23 stron: projekt nie wnika w to, jakich narzędzi używasz. Liczy się to, czy potrafisz określić, co zebrano, skąd i kiedy. Scrapery, które mogą odpowiedzieć na to jednym zapytaniem, nie będą miały problemu. Crawle bez określonego celu będą miały trudności z niemal każdym akapitem.

(Zastrzeżenie: to nie jest porada prawna. Po pierwsze, odnosimy się do projektu, a po drugie, jesteśmy inżynierami analizującymi jego znaczenie z perspektywy kodu).

Kluczowa granica: działanie celowane czy niecelowane

Akapit 8 dzieli scraping na dwa rodzaje w zależności od tego, jak precyzyjne i restrykcyjne jest zbieranie danych, "a nie od zastosowanych narzędzi technicznych". Scraping celowany opiera się na kryteriach zbierania: domenie, języku, temacie. Scraping niecelowany to crawler, który podąża za każdym znalezionym linkiem. Obawa Rady jest konkretna: w miarę rozrostu kolejki administrator "ma ograniczoną wiedzę o tym, jakie dane osobowe są zbierane i przetwarzane".

Ten podział przewija się przez resztę tekstu. Minimalizacja danych wymaga "zdefiniowania precyzyjnych kryteriów zbierania" oraz przeprowadzenia "procesu mapowania i inwentaryzacji danych" przed rozpoczęciem zbierania (akapit 37). Test niezbędności w ramach prawnie uzasadnionego interesu wskazuje, że zaweżenie kryteriów, "zamiast scrapowania znacznej części internetu", może być właśnie tym, co w ogóle czyni przetwarzanie niezbędnym (akapit 52). Przejrzystość wymaga opublikowania listy źródeł, najlepiej z nazwami domen, adresami URL i datami pobrania (akapity 30 i 31).

Narzędzie do monitorowania cen ze stałą listą stron produktowych w kilkunastu domenach sklepowych może wygenerować każdy z tych artefaktów ze swojego pliku konfiguracyjnego. Crawl typu breadth-first tego nie potrafi. Krytyka projektu opublikowana przez Privacy World trafnie punktuje ten rozdźwięk: obowiązki zostały napisane dla administratora, który wie, co zbiera, zaraz po tym, jak Rada przyznaje, że crawl niecelowany może zawierać dane osobowe, których nie da się zinwentaryzować.

Co to oznacza w praktyce: jeśli pobierasz jakiekolwiek dane dotyczące osób (opinie z nazwami użytkowników, ogłoszenia z nazwiskiem i numerem telefonu agenta, wątki na forach), Twoje kryteria scrapowania stają się elementem dokumentacji zgodności. Przechowuj je w systemie kontroli wersji obok kodu scrapera, a nie w czyjejś pamięci.

Sprzeciw witryny działa teraz na Twoją niekorzyść

To jest część, która wpłynie na najwięcej pipeline'ów. Projekt wymienia środki techniczne świadczące o jednoznacznym sprzeciwie witryny wobec scrapowania: robots.txt, ai.txt, "uwierzytelnianie botów w celu przeglądania treści" oraz weryfikacje, które "wymagają działania możliwego do wykonania wyłącznie przez człowieka" (paragraf 37). W przypadku danych treningowych zaleca się całkowite pominięcie takich serwisów.

Te same sygnały powracają w teście równowagi. Kiedy użytkownicy wiedzą, że witryna stosuje te zabezpieczenia, a mimo to dane są pobierane, projekt wskazuje, że trudniej uznać takie przetwarzanie za zgodne z ich oczekiwaniami (paragraf 64). Przykład 5 wyjaśnia to wprost: platforma z blokadą w robots.txt, weryfikacją obecności człowieka i jawnym zakazem trenowania modeli AI oznacza, że jej użytkownicy "nie mogą racjonalnie oczekiwać", iż podmioty trzecie będą scrapować ich dane w tym celu. Działa to tylko w jedną stronę. Brak pliku robots.txt nie oznacza zgody (paragraf 45).

Francuski CNIL doszedł do tego wcześniej. W dokumencie arkusz informacyjny o prawnie uzasadnionym interesie i scrapowaniu stron, opublikowanym po raz pierwszy w czerwcu 2025 roku, stwierdzono, że przetwarzanie "nie mieści się w granicach racjonalnych oczekiwań osób, których dane dotyczą", jeśli administrator nie wyklucza witryn wyrażających sprzeciw przez robots.txt lub mechanizmy weryfikacji człowieka.

Dwa mniej oczywiste punkty znalazły się wśród środków łagodzących (paragraf 66c). Pierwszy wyklucza dane osobowe widoczne dopiero po zalogowaniu. Drugi dotyczy witryn zwracających inną treść dla User-Agent scrapera niż dla zwykłej przeglądarki, "zwłaszcza gdy usługa scrapująca otrzymuje więcej danych" niż zobaczyłby człowiek. Jeśli Twój scraper odpytuje bogatsze wewnętrzne API zamiast parsować widoczną stronę, to właśnie o taki przypadek chodzi.

Przeanalizowaliśmy maszynowo czytelną stronę tego zjawiska (rozszerzenia robots.txt, podpisane boty, sygnały w treści) w artykule Search, Agent, Training: The Web's New Bot Rules, a podejście wydawców wolących pobierać opłaty zamiast blokować opisaliśmy w Pay-Per-Crawl Is Splitting the Web in Two. Projekt EROD to pierwszy przypadek, gdy organ regulacyjny potraktował te sygnały jako dowód na to, czego faktycznie oczekują użytkownicy.

Co to oznacza w praktyce: zapisuj stan robots.txt (oraz ai.txt, jeśli witryna go posiada) dla każdej domeny w momencie pobierania danych, bezpośrednio obok nich. Jeśli za rok ktoś zapyta, dlaczego dane źródło znalazło się w zbiorze treningowym, odpowiedź "było dozwolone w dniu pobrania" zadziała tylko wtedy, gdy masz na to twardy zapis.

Scraper może być podmiotem przetwarzającym

Sekcja 3.2.1 jest krotka i latwo ja pominac. Nie nalezy tego robic, zwlaszcza jesli tworzysz scrapery dla klientow. Jesli tworzysz zbior danych treningowych w imieniu dewelopera "zgodnie z jego udokumentowanymi instrukcjami", mozesz byc podmiotem przetwarzajacym (procesorem), a deweloper administratorem danych (paragraf 18). Jesli wspolnie z klientem ustalacie kryteria zbierania danych, mozecie byc wspoladministratorami (paragraf 20, Przyklad 1). Jesli pobrales dane na wlasna reke, a ktos inny wykorzystuje ten zbior ponownie, kazdy z was odpowiada za swoje wlasne przetwarzanie (paragraf 19).

Brian Hengesbaugh w swoim artykule dla IAPP na temat projektu trafnie podsumowuje kwestie biznesowa. Kiedy umowa definiuje dostawce jako podmiot przetwarzajacy, obowiazek spelnienia wymogow opisanych w wytycznych spoczywa na kliencie, a bezposrednie obowiazki samego dostawcy "moga byc wezsze i mniej uspokajajace, niz dotychczas sadzono". Dziala to w obie strony. Klient nie moze zepchnac zgodnosci z przepisami na freelancera, ktory napisal scraper, a freelancer, ktory samodzielnie dobiera liste zrodel, moze przypadkowo stac sie administratorem danych.

Co zespoly danych powinny zmienic juz teraz

Wiekszosc komercyjnego scrapingu pozostaje bez zmian. Ceny, stany magazynowe, specyfikacje produktow czy rozklady jazdy to na ogol nie dane osobowe, wiec RODO ich nie dotyczy. Projekt wyraznie zaznacza, ze w przypadku "mieszanych" zbiorow danych przepisy stosuja sie do czesci zawierajacej dane osobowe (paragraf 13). Zatem ogloszenie zawierajace nazwisko sprzedawcy lub opinia z nazwa uzytkownika sprawiaja, ze ten fragment podlega regulacjom.

W przypadku zadan, ktore zbieraja dane osobowe, oto jak wymogi projektu przekladaja sie na pipeline danych:

Dwa z tych wierszy wymagaja szerszego omowienia.

Filtruj na etapie parsowania, a nie w zadaniu czyszczacym tygodnie pozniej. Paragraf 38 wymienia wyrazenia regularne dla formatow takich jak numery ubezpieczen spolecznych i numery telefonow, stosowane bezposrednio podczas zbierania danych. Dane, ktorych nigdy nie zapisales, to dane, z ktorych nigdy nie musisz sie tlumaczyc. Paragraf 60 mowi wprost, dlaczego ma to znaczenie dla AI: gdy model zostanie juz wytrenowany, dane osobowe "nie moga byc z niego latwo usuniete".

Zapisuj zrodlowy URL i czas pobrania przy kazdym rekordzie. Paragraf 42 wymaga znacznikow czasu w celu zapewnienia prawidlowosci danych, ale te same dwa pola odpowiadaja pozniej na kazde pytanie o pochodzenie faktu. Zasady dotyczace danych treningowych zaostrzaly sie juz w ramach AI Act (pisalismy o tym w kwietniu) i to pytanie powraca bez przerwy.

Jesli tworzysz rozwiazania dla klientow, musisz miec instrukcje na pismie: zrodla, pola, wykluczenia. Projekt traktuje udokumentowane instrukcje jako warunek bycia podmiotem przetwarzajacym, a nie wspoladministratorem. Jednostronicowa specyfikacja pozwala uniknac sporow o role prawne w przyszlosci.

Co wydarzy sie po 30 pazdziernika

Ostateczny tekst ulegnie zmianie, a większy zwrot może nadejść z Brukseli, a nie z Rady. 21 października 2026 r. Rada uzgodniła stanowisko negocjacyjne w sprawie Digital Omnibus, czyli pakietu nowelizującego RODO. Według raportu IAPP na temat mandatu państwa członkowskie dodały „wyjaśnienia dotyczące podstawy prawnej przetwarzania danych osobowych oraz konieczności stosowania odpowiednich zabezpieczeń” w odniesieniu do danych treningowych dla modeli AI. Kolejnym etapem są negocjacje z Parlamentem Europejskim. Niezależnie od finalnego sformułowania, państwa członkowskie chcą zachowania zabezpieczeń, co wskazuje na test równowagi bardzo podobny do tego z obecnego projektu.

Uważamy, że podział na scraping ukierunkowany i nieukierunkowany przetrwa oba procesy, ponieważ to jedyna część projektu dotycząca inżynierii, a nie prawa. Regulator nie będzie czytać kodu Twojego crawlera. Może poprosić o kryteria zbierania danych, listę źródeł i znaczniki czasu, a zespół, który jest w stanie przekazać te informacje tego samego popołudnia, nie pozostawia zbyt wielu kwestii do sporów.

Kolejne pytanie, jakie organ ochrony danych zada twórcy scrapera, nie będzie więc brzmieć „jak to działa”, lecz raczej: „co dokładnie miało zostać pobrane”.