Zgoda na treści dla AI — kto może czytać, trenować i działać

Jeden internet, różne cele wykorzystania

Kiedyś wystarczało w przybliżeniu rozstrzygnąć, czy strona może być indeksowana przez wyszukiwarkę. W przypadku AI to zbyt duże uproszczenie. Ten sam tekst może trafić do wyniku wyszukiwania, zbioru treningowego, odpowiedzi RAG, agenta przeglądającego internet w imieniu użytkownika albo produktu, który tworzy zamiennik oryginalnej treści.

Zgoda na treści nie jest więc jednym przełącznikiem. Wydawca może chcieć widoczności w wyszukiwarce, ale odrzucać trening modelu. Twórca może pozwolić na podgląd i cytat, ale nie na masowe pobieranie archiwum. Firma może dopuścić asystenta do dokumentacji, ale nie do danych klientów.

„Zgoda” oznacza tu wyrażone preferencje i uprawnienia do wykorzystania treści, a nie twierdzenie, że każde użycie wymaga indywidualnego pozwolenia. Przykładowo art. 4 dyrektywy UE 2019/790 przewiduje warunkowy wyjątek dotyczący eksploracji tekstów i danych oraz możliwość zastrzeżenia praw. Sam sygnał techniczny nie rozstrzyga kwestii prawnej. Dyrektywa, art. 4.

Robots.txt nie wystarcza do ekonomii AI

Robots.txt informuje współpracujące roboty, które ścieżki mogą odwiedzać. Nie egzekwuje dostępu ani nie udziela licencji na treść; według RFC 9309 nie zastępuje uwierzytelniania. Rozróżnienie celów zależy również od tożsamości robotów i zasad konkretnego operatora. Robots Exclusion Protocol.

Konkretny przykład daje Anthropic: rozróżnia ClaudeBot dla potencjalnych danych treningowych, Claude-SearchBot dla wyszukiwania i Claude-User dla żądań użytkownika. Reguły można ustawić osobno; nie należy zakładać tych samych nazw ani zachowania u innego dostawcy. Dokumentacja robotów.

Sygnał techniczny, umowa i rzeczywisty dostęp

Praktyczne rozwiązanie rozróżnia preferencje techniczne, warunki licencji i rzeczywistą kontrolę dostępu. Zespół produktowy musi wiedzieć, jakiej treści może użyć, w jakim celu i na jakiej podstawie. Zapis źródła oraz warunków wykorzystania pomaga wyjaśnić decyzję; sam nie tworzy żadnego uprawnienia.

Słabym punktem jest egzekwowanie. Jeśli crawler kłamie o celu, miesza wyszukiwanie z treningiem albo ukrywa czytanie za zwykłą sesją użytkownika, reguła zmienia się w prośbę. Dlatego ważna jest także infrastruktura: CDN, logi dostępu, tożsamości botów i możliwość blokowania według zachowania, nie tylko według nazwy.

Dlaczego to ma znaczenie dla produktów z agentami

Przeglądarki agentowe i asystenci wyostrzają problem. Nie chodzi tylko o to, że model czyta treść. Agent może przeglądać strony w imieniu użytkownika, streszczać płatne materiały, kopiować pracę twórców albo automatyzować kroki, które pierwotna strona przewidywała dla człowieka.

Dla zespołów produktowych dyscyplina jest prosta: oddzielić czytanie, cytowanie, trening i działanie. Każda warstwa powinna mieć własne uprawnienia, logi i wyłącznik. Bez tego zgoda rozmywa się we mgle, a spór zaczyna się dopiero wtedy, gdy treść została już użyta.

Przykład: publiczna pomoc i portal klienta

Firma chce, aby wyszukiwarki znajdowały publiczne strony pomocy, ale dokumenty umowne udostępnia tylko zalogowanym klientom. Dla pomocy ustawia preferencje robotów, a portal chroni uwierzytelnianiem i uprawnieniami do konkretnego konta. Gdy asystent klienta streszcza dokument, aplikacja sprawdza dostęp do tego dokumentu; logowanie nie daje automatycznie prawa do eksportu całego archiwum ani zmiany umów.

Rozdzielenie celów może też wpłynąć na widoczność w wyszukiwaniu. Zablokowanie przyszłego zbierania danych nie usuwa automatycznie wcześniej użytych treści z istniejących modeli. Najpierw ustal oczekiwane zachowanie, a następnie sprawdź, co obsługuje konkretna usługa.

Źródła

• RFC 9309 — reguły robots.txt i ograniczenia bezpieczeństwa.
• Dokumentacja robotów Anthropic — odrębne cele poszczególnych robotów.
• Dyrektywa UE 2019/790, art. 4 — eksploracja tekstów i danych oraz zastrzeżenie praw.