4 dni temu
Publicznie dostępna strona internetowa nie jest automatycznie otwartym magazynem danych dla wszystkich bota. Pytanie, czy scraping jest legalny, wymaga analizy nie jednego przepisu, ale całego układu praw i obowiązków: regulaminu serwisu, prawa autorskiego, ochrony baz danych, RODO, tajemnicy przedsiębiorstwa oraz sposobu technicznego pobierania informacji.
Dla przedsiębiorcy różnica jest istotna. Ten sam proces – automatyczne pobranie ofert konkurencji, danych z portalu ogłoszeniowego albo profili zawodowych – może być neutralnym działaniem analitycznym, naruszeniem warunków umownych lub podstawą roszczeń cywilnych. O wyniku nie przesądza sama nazwa narzędzia ani fakt, iż dane wyświetlały się w przeglądarce.
Czym jest scraping w sensie prawnym
Scraping to automatyczne pozyskiwanie danych z witryny, aplikacji lub interfejsu internetowego, zwykle przy użyciu skryptu, bota albo narzędzia no-code. Z prawnej perspektywy trzeba oddzielić co najmniej trzy czynności: uzyskanie dostępu do serwisu, skopiowanie określonych treści oraz dalsze wykorzystanie pozyskanych danych.
Automatyzacja sama w sobie nie jest zakazana. Prawo nie ustanawia ogólnej zasady, według której człowiek może przepisać informację z ekranu, ale program wykonujący tę samą czynność już nie. Masowość, powtarzalność i cel gospodarczy sprawiają jednak, iż scraping częściej ingeruje w interesy operatora serwisu oraz w prawa osób, których dane dotyczą.
Znaczenie ma również źródło. Inaczej należy oceniać pobieranie danych udostępnionych w oficjalnym API, inaczej indeksowanie ogólnodostępnych stron, a jeszcze inaczej korzystanie z konta użytkownika, obejście limitów zapytań, CAPTCHA, blokad adresów IP czy mechanizmu logowania. Każdy z tych modeli rodzi inny profil ryzyka.
Czy scraping jest legalny w świetle regulaminu serwisu?
Regulamin nie jest ustawą, ale może wiązać użytkownika jako element stosunku umownego. o ile przedsiębiorca zakłada konto, akceptuje regulamin, a następnie używa automatycznego narzędzia mimo wyraźnego zakazu, operator może twierdzić, iż doszło do naruszenia umowy. Konsekwencją bywa blokada konta lub adresu IP, ale w określonych sytuacjach także żądanie naprawienia szkody.
Sama obecność zakazu w regulaminie nie przesądza jeszcze o odpowiedzialności każdego podmiotu pobierającego dane. Trzeba ustalić, czy i kiedy regulamin został skutecznie zaakceptowany, do kogo jest skierowany oraz czy dane były dostępne bez rejestracji. W praktyce biznesowej nie warto jednak zakładać, iż brak logowania usuwa problem. Zwłaszcza gdy regulamin precyzyjnie zakazuje automatycznego wydobywania danych, a operator oferuje odpłatne API lub licencję na dostęp do nich.
Wyrok Trybunału Sprawiedliwości UE w sprawie Ryanair potwierdził, iż twórca bazy, która nie korzysta z ochrony prawa autorskiego ani z prawa sui generis do bazy danych, może co do zasady ograniczać jej wykorzystanie na podstawie warunków umownych. Nie oznacza to, iż każda klauzula będzie skuteczna w każdej relacji, ale pokazuje, iż ocena nie kończy się na pytaniu o własność pojedynczej informacji.
Dane, utwory i baza danych to nie to samo
Fakt, oferta, cena, kod pocztowy czy termin wydarzenia zwykle nie są utworem. Prawo autorskie chroni sposób twórczego wyrażenia, nie samą informację. o ile jednak bot pobiera opisy produktów, artykuły, fotografie, grafiki, katalogi lub kreatywnie przygotowane profile, może dochodzić do zwielokrotniania utworów, a przy dalszej publikacji także do ich rozpowszechniania.
Osobną ochronę zapewnia ustawa o ochronie baz danych. Chroni ona istotny nakład inwestycyjny poniesiony na uzyskanie, weryfikację lub prezentację zawartości bazy. Zakazane może być pobranie lub wtórne wykorzystanie całości albo istotnej części zawartości bazy. Ryzyko może powstać również przy systematycznym pobieraniu nieistotnych części, o ile takie działania zastępują normalne korzystanie z bazy lub godzą w uzasadnione interesy producenta.
W sprawie Innoweb Trybunał Sprawiedliwości UE szeroko spojrzał na pojęcie wtórnego wykorzystania bazy danych. Dla projektów tworzących porównywarki, agregatory czy narzędzia analityczne jest to sygnał ostrzegawczy: warto badać nie tylko liczbę rekordów pobieranych jednorazowo, ale także funkcję produktu. o ile użytkownik końcowy może dzięki niemu korzystać z cudzej bazy bez odwiedzania źródłowego serwisu, ryzyko wyraźnie rośnie.
Eksploracja tekstów i danych nie daje blankietowej zgody
W prawie unijnym funkcjonują wyjątki dotyczące eksploracji tekstów i danych, uregulowane w dyrektywie DSM. W uproszczeniu: jeden model jest przeznaczony dla instytucji badawczych i instytucji dziedzictwa kulturowego, a drugi może obejmować szersze zastosowania, o ile dostęp do materiałów jest zgodny z prawem, a uprawniony nie zastrzegł wykorzystania w odpowiedni sposób.
Nie jest to uniwersalna podstawa dla komercyjnego scrapingu. Po pierwsze, wyjątki odnoszą się do określonych czynności eksploatacji chronionych materiałów, a nie do wszystkich możliwych roszczeń związanych z pobieraniem danych. Po drugie, uprawniony może skutecznie zastrzec wykorzystanie, w szczególności w formie możliwej do odczytu maszynowego dla treści udostępnianych online. Po trzecie, przez cały czas trzeba uwzględnić regulamin, ochronę bazy danych i przepisy o danych osobowych.
RODO: scraping publicznych profili przez cały czas jest przetwarzaniem
Publiczna dostępność danych osobowych nie zwalnia z obowiązków wynikających z RODO. Imię i nazwisko, służbowy e-mail, historia zatrudnienia, zdjęcie, lokalizacja czy treść wpisów mogą być danymi osobowymi. Podmiot, który je zbiera, łączy, ocenia i wykorzystuje do własnych celów, często działa jako administrator danych.
W projekcie scrapingowym trzeba ustalić podstawę prawną przetwarzania, najczęściej rozważa się prawnie uzasadniony interes. Wymaga to jednak realnego testu równowagi: jaki jest cel biznesowy, czy jest niezbędny, jakiego zakresu danych wymaga i czy interes lub prawa osoby fizycznej nie przeważają. Zbieranie całych profili „na przyszłość” trudno pogodzić z zasadą minimalizacji danych.
Istotny jest również obowiązek informacyjny wobec osób, których dane pozyskano nie bezpośrednio od nich. RODO przewiduje szczególne reguły dla takich przypadków, w tym ograniczony wyjątek, gdy przekazanie informacji wymagałoby niewspółmiernie dużego wysiłku. Nie jest to jednak automatyczne zwolnienie dla każdej dużej bazy. Administrator powinien potrafić wykazać, dlaczego wyjątek ma zastosowanie, i wdrożyć odpowiednie działania zastępcze.
Dodatkowe ryzyko powstaje przy profilowaniu kandydatów, klientów lub inwestorów, przy pobieraniu danych szczególnej kategorii oraz przy transferze danych poza Europejski Obszar Gospodarczy. Narzędzie techniczne, dostawca chmury i miejsce przetwarzania danych powinny zostać zweryfikowane przed rozpoczęciem operacji, nie po otrzymaniu skargi.
Granica techniczna może stać się granicą prawną
Pobieranie treści dostępnej bez logowania jest czym innym niż przełamywanie zabezpieczeń. Używanie cudzych danych dostępowych, obchodzenie ograniczeń technicznych, manipulowanie żądaniami do prywatnego API lub omijanie blokad może prowadzić do odpowiedzialności wykraczającej poza spór o regulamin. W zależności od okoliczności pojawiają się zagadnienia nieuprawnionego dostępu do informacji, ingerencji w system teleinformatyczny albo odpowiedzialności za zakłócenie jego działania.
Nawet bez obchodzenia zabezpieczeń nadmierna liczba zapytań może wyrządzić operatorowi mierzalną szkodę. Bot generujący obciążenie porównywalne z atakiem na dostępność serwisu nie staje się legalny tylko dlatego, iż każde pojedyncze żądanie dotyczy strony publicznej. W relacjach B2B znaczenie mogą mieć też przepisy o zwalczaniu nieuczciwej konkurencji, zwłaszcza gdy dane są wykorzystywane do pasożytniczego przejęcia efektów cudzej inwestycji.
Jak ocenić projekt przed uruchomieniem bota
Przed wdrożeniem warto przygotować krótką ocenę prawną i techniczną. Powinna ona odpowiedzieć na pięć konkretnych pytań:
- Czy źródło dopuszcza automatyczne pobieranie danych, a jeżeli nie, czy istnieje licencja albo oficjalne API?
- Czy pobierane elementy są utworami, częścią chronionej bazy danych lub informacją stanowiącą tajemnicę przedsiębiorstwa?
- Czy projekt obejmuje dane osobowe i jaka podstawa prawna, obowiązek informacyjny oraz okres retencji będą adekwatne?
- Czy sposób działania bota respektuje limity, plik robots.txt, zabezpieczenia oraz bezpieczeństwo infrastruktury źródłowej?
- Czy planowane użycie danych konkuruje z funkcją źródłowego serwisu lub odbiera mu możliwość normalnej eksploatacji bazy?
Plik robots.txt nie jest sam w sobie przepisem prawa ani umową. Jest jednak czytelnym technicznym komunikatem woli operatora i ważnym dowodem przy ocenie staranności przedsiębiorcy. Podobnie limity zapytań, komunikaty o zakazie automatyzacji oraz odpłatny model dostępu nie powinny być traktowane wyłącznie jako przeszkoda dla zespołu developerskiego.
Najbezpieczniejszy model opiera się na minimalizacji: pobierać tylko dane potrzebne do jasno określonego celu, ograniczać częstotliwość żądań, dokumentować podstawę prawną i nie budować produktu, który faktycznie replikuje cudzy serwis. Gdy dane mają zasilać model AI, system scoringowy albo narzędzie sprzedażowe, analiza powinna objąć także dalszy cykl życia danych, a nie wyłącznie moment ich pobrania.
Warto potraktować scraping jak każde inne źródło danych w organizacji: zanim kod zacznie wykonywać tysiące żądań, trzeba ustalić, skąd dane pochodzą, kto ponosi ryzyko ich użycia i czy cel biznesowy uzasadnia wybrany sposób pozyskania.
