Zastrzeżenie TDM, robots.txt i crawlery AI — co może zrobić właściciel strony?

1. Najpierw ustal, czym jest zastrzeżenie TDM

Art. 4 dyrektywy DSM przewiduje wyjątek pozwalający, pod określonymi warunkami, na zwielokrotnianie i pobieranie legalnie dostępnych utworów lub innych przedmiotów ochrony do celów text and data mining. Ustęp 3 uzależnia zastosowanie tego wyjątku od tego, czy właściciel praw nie zastrzegł wykorzystania w odpowiedni sposób.

Zastrzeżenie nie jest uniwersalnym zakazem każdego automatycznego wejścia na stronę. Nie każde żądanie dotyczy chronionego utworu, nie każdy crawler wykonuje TDM i nie każdy przypadek korzystania opiera się na tym samym wyjątku. Dlatego politykę techniczną trzeba powiązać z prawami do konkretnych zasobów i zakładanym celem dostępu.

2. Dla treści online przygotuj maszynowo odczytywalny sygnał

W przypadku treści udostępnionych publicznie online dyrektywa wskazuje maszynowo odczytywalne środki jako właściwy sposób zastrzeżenia. Nie ustanawia jednak jednego, zamkniętego formatu dla wszystkich rodzajów treści i sposobów publikacji.

Komisja Europejska prowadzi proces dotyczący odpowiednich, powszechnie uzgodnionych protokołów TDM. Oprócz robots.txt analizowane są również inne rozwiązania, dlatego polityka organizacji powinna być wersjonowana i możliwa do rozszerzenia, zamiast zakładać, że jeden plik rozwiąże każdy przypadek.

• wskaż, które domeny, subdomeny i typy zasobów obejmuje polityka
• oddziel treści własne od materiałów, do których prawa mają inne podmioty
• zapisuj datę publikacji i każdej zmiany sygnału
• sprawdzaj aktualny stan prac Komisji i dokumentację wykorzystywanych protokołów

3. Traktuj robots.txt jako komunikat, nie zaporę

robots.txt pozwala kierować reguły do określonych nazw crawlerów i ścieżek. Część dostawców publikuje własne identyfikatory oraz deklaruje sposób respektowania tych reguł. Konfigurację trzeba jednak przygotować osobno dla każdej domeny i zweryfikować po wdrożeniu.

Serwer nie wymusza przestrzegania robots.txt. Klient może zignorować plik, posługiwać się innym User-Agentem albo pobierać treść przez mechanizm, którego polityka nie rozróżnia. Jeśli decyzja ma być egzekwowana, potrzebna jest dodatkowa kontrola na CDN, reverse proxy, WAF-ie lub w aplikacji.

4. Rozdziel crawlera od celu jego działania

Dwa podobne żądania HTTP mogą służyć indeksowaniu wyszukiwarki, odpowiedzi w AI Search, treningowi modelu, realizacji polecenia użytkownika albo zwykłemu scrapingowi. Nazwa dostawcy nie zawsze wystarcza, aby rozstrzygnąć cel konkretnego pobrania.

W polityce warto utrzymywać kontrolowany słownik celów: Search, AI Search, Training/TDM, Agent, Scraping i Unknown. Dla każdego wyniku zapisuj, czy cel został zadeklarowany przez dostawcę, wynika z technicznie rozróżnialnego crawlera, został oszacowany z zachowania czy pozostaje nieustalony.

• tożsamość deklarowana nie oznacza jeszcze tożsamości zweryfikowanej
• brak wiarygodnego sygnału celu powinien prowadzić do statusu Unknown
• reguła allow search / block training wymaga rozróżnialnego sygnału technicznego
• zmiana dokumentacji dostawcy powinna uruchamiać przegląd klasyfikacji

5. Zbuduj macierz dostawca × cel × zasób

Jedna globalna lista allow/block zwykle jest zbyt prosta. Publiczny artykuł, dokumentacja produktu, płatne archiwum, zdjęcie i dane produktowe mogą mieć inną wartość biznesową, inny zakres praw oraz inny oczekiwany poziom dostępności.

Dla każdego połączenia określ decyzję: Allow, Monitor, Rate limit albo Block. Dodaj właściciela biznesowego, podstawę decyzji, wersję polityki i datę przeglądu. Przed blokowaniem sprawdź również wpływ na SEO, partnerów, monitoring dostępności i funkcje uruchamiane na żądanie użytkownika.

• zinwentaryzuj wartościowe typy treści i właścicieli praw
• określ pożądane oraz niepożądane przypadki użycia
• dopasuj maszynowy sygnał i techniczną akcję
• przetestuj regułę na obserwacji przed szerokim blokowaniem

6. Zachowuj wersjonowany ślad dowodowy

Pojedynczy wpis w access logu pokazuje za mało. Użyteczny rekord powinien łączyć czas, URL, User-Agent, dostępne sygnały sieciowe, podstawę identyfikacji, oceniony cel, wersję polityki, wykonaną akcję i rezultat żądania.

Warto rozdzielić dane zaobserwowane od pól wywnioskowanych. Dzięki temu późniejszy przegląd pokaże, co rzeczywiście wysłał klient, co potwierdził system, a co było klasyfikacją z określonym poziomem pewności. Okres przechowywania adresów IP i dostęp do logów powinny wynikać z przyjętych zasad bezpieczeństwa i ochrony danych.

7. Opisuj konflikt z polityką, nie automatyczne naruszenie prawa

Jeżeli crawler pobiera ścieżkę objętą regułą Disallow albo ponawia żądania po technicznej odmowie, można udokumentować konflikt z opublikowaną polityką lub dalszą aktywność po blokadzie. To nadal nie pokazuje automatycznie, czy dane zostały użyte do treningu, jaki podmiot odpowiadał za pobranie i czy konkretny materiał był objęty prawem wyłącznym.

Praktyczne statusy to: policy respected, observed policy conflict, identity unverified, purpose unknown, not applicable oraz manual review. Taki słownik daje zespołom wspólny obraz sytuacji bez zastępowania technicznym skrótem pełnej oceny prawnej.

8. Zacznij od obserwacji i ograniczonego zakresu

Pierwszy etap nie musi obejmować całego serwisu. Wybierz jeden typ wartościowej treści, zbierz dostępne logi, sprawdź obecną konfigurację robots.txt i opisz oczekiwane zachowanie kilku klas crawlerów. Na tej podstawie powstaje pierwsza wersja macierzy polityki.

Dopiero po sprawdzeniu jakości identyfikacji i skutków biznesowych włączaj automatyczne ograniczenia. Celem jest kontrolowany dostęp i odtwarzalna decyzja, a nie maksymalna liczba zablokowanych żądań.