Opt-Out-Lösungen für den Schutz Ihrer Website vor KI-Bots

Leider ist es im Moment so, dass man als Webhost nur die Möglichkeit per Opt-Out hat, die eigene Website vor dem Training von KI-Modellen zu schützen.
Dieser Schutz kann auf unterschiedlichen Levels, Techniken und Reichweiten erfolgen und unterliegt unterschiedlicher Durchsetzbarkeit.

Durchsetzbarkeit der Opt-Out-Reglungen

Grundvoraussetzung für die Durchsetzbarkeit von Opt-Out ist die Identifikation der KI-Bots. Dazu kann der Parameter ‚User-Agent‘ oder auch die IP-Adresse herangezogen werden. Das ist problematisch, denn wer weiß denn schon vielviele Bots mit welchem Namen gerade unterwegs sind, um das Web nach den begehrten Trainingsdaten zu durchsuchen, ganz abgesehen davon, welche Aktoren in Zukunft auf der Bildfläche erscheinen werden.

Im schlimmsten Fall kann es außerdem passieren, dass der Name des Bots zwar bekannt ist, dieser aber die implementierten Restriktionen nicht beachtet (robots.txt), sofern nicht aufwendige technische Maßnahmen wie eine Firewall ergriffen werden, um sie durchzusetzen.

Nachteile der Opt-Out-Reglung für die Webmaster in der Übersicht

• Identifikation der KI-Crawler notwendig
• Schwierig, die Liste der KI-Bots aktuell zu halten.
• Ständige Wartungsarbeiten an der Website, um die Info in robots.txt etc. up to date zu halten
• Keinerlei Möglichkeit, einzugreifen, wenn man zu spät war.
• Keine Fristen für KI-Crawler zwischen Bekanntgabe des User-Agents und Start des Crawlens.
• Verbindliche Techniken wie Firewalls stehen oft nicht direkt zur Verfügung.

Es wäre als dringend ein Umwechseln zur Opt-In Lösung oder wartungsärmeren Lösungen als den vorhandenen nötig. Vorschläge zu einer wartungsärmeren Lösung wurde in diesem Paper mit der Einführung einer leaners.txt – Datei gemacht. Es müssten auch Konsequenzen greifen, wenn die Opt-Out-Regeln nicht beachtet werden, und dies anhand von Logdateien nachgewiesen werden kann.

Trotz der oben genannten Widrigkeiten finde ich, wir als Webhosts sollten die uns zur Verfügung stehenden Möglichkeiten nutzen, um unsere Webseiten zu schützen. Alles andere könnte fälschlicherweise als schweigende Zustimmung gewertet werden. Es geht um den Schutz unseres geistigen Eigentums.

Reichweite der Opt-Out-Maßnahmen

Hier haben wir die Möglichkeiten:

• kompletten Sperrung unserer Website
• nur eine Indizierung zulassen und damit KI auszusperren – sprich ein Tokenisieren zu verhindern.
• alles zuzulassen

Ein Beispiel für die komplette Sperrung wäre ein firmeninternes Wiki. Uns beschäftigt im Artikel die Möglichkeit, die Tokenisierung zu verhindern, d. h. KI – Bots auszusperren.

Konkrete Maßnahmen zum Schutz der Webseite vor Tokenisierung

Bitte beachten: Änderungen nur vornehmen, wenn Sie sich sicher sind, die technischen Konsequenzen für Ihre Website absehen zu können.

robots.txt zum Sperren der KI-Bots

Einordnung (siehe Mindmap)
Technik:	Textdatei im Wurzelverzeichnis der Website
Level:	Gesamte Website
Syntax:	allow / disallow
Durchsetzbarkeit:	Das Crawler die robots.txt befolgen, ist leider ein ‚kann‘, aber kein ‚muss‘.

Was ist die robots.txt

Die Datei robots.txt dient dazu, Webcrawlern Anweisungen zu geben, welche Teile einer Website sie durchsuchen oder ignorieren sollen, um den Zugriff auf bestimmte Bereiche zu steuern. Dies entlastet Server, verbessert eventuell SEO und in unserem Fall ermöglicht es den Ausschluss bestimmter User-Agents.

Wo findet man die robots.txt

Entweder liegt die Datei schon im Wurzelverzeichnis der Website und kann um Einträge die nötigen Einträge ergänzt werden, die das Lesen von Websites verhindern. Ist noch keine Datei mit diesem Namen vorhanden, kann sie zunächst leer per SFTP im Rootverzeichnis erzeugt und danach mit den Einträgen bestückt werden.

Einfügbarer Code für robots.txt gegen KI-Scraping

Hier die Liste Quelle:

User-agent: GPTBot
User-agent: CCBot
User-agent: ChatGPT-User
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: anthropic-ai
User-agent: ClaudeBot
User-agent: Omgilibot
User-agent: Omgili
User-agent: FacebookBot
User-agent: Diffbot
User-agent: Bytespider
User-agent: ImagesiftBot
User-agent: cohere-ai
User-agent: PerplexityBot
User-agent: Meta-ExternalAgent
User-agent: Meta-ExternalFetcher
User-agent: Timpibot
Disallow: /

.htaccess um KI-Crawler auszusperren

Einordnung (siehe Mindmap)
Technik:	Datei im Wurzelverzeichnis der Website
Level:	Gesamte Website
Syntax:	Rewrite Condition (Beispiel siehe unten)
Durchsetzbarkeit:	Verbindlich. Der Apache Webserver selbst antwortet mit Forbidden

Wozu dient die .htaccess – Datei?

Die Datei .htaccess ermöglicht es Website-Betreibern, serverseitige Konfigurationsanweisungen für Verzeichnisse festzulegen um Zugriffskontrollen, Weiterleitungen und andere serverseitige Funktionen zu steuern.

Wo findet man die .htaccess – Datei?

Die Datei befindet sich im Rootverzeichnis der Webseite

Beispiel für die Veränderung der .htaccess – Datei zum verbindlichen Aussperren der KI-Bots

Nochmals der Hinweis zur Vorsicht! Hier ein Beispiel erklärt für zwei der oben genannten User-Agents:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (CCBot|cohere-ai) [NC]
RewriteRule ^ – [F]

Erklärung des Befehls zur Veränderung der .htaccess

RewriteEngine On : Dieser Befehl aktiviert das Apache mod_rewrite Modul, welches eine Möglichkeit bietet, HTTP-Anfragen zu manipulieren.

RewriteCond %{HTTP_USER_AGENT} (CCBot|cohere-ai) [NC] : Diese Bedingung überprüft den HTTP_USER_AGENT Header eingehender Anfragen. Das [NC] Flag steht für „No Case“, d.h. es wird also unabhängig von der Groß- und Kleinschreibung übereinstimmen, z.B. ccbot, CCBot, usw.

RewriteRule ^ – [F]: Diese Regel gilt für jeden URL-Pfad (^ entspricht dem Anfang jeder Zeichenkette, also gilt sie effektiv für alle Pfade). Der Bindestrich (-) gibt an, dass keine Ersetzung der URL durchgeführt werden soll. Das [F] Flag bedeutet „Forbidden“ (Verboten), es wird also für die genannten User-Agents mit HTTP 403 Forbidden geantwortet. Bitte weitere Infos in der Apache – Dokumentation selbst nachlesen.
 

Benutzung von Firewalls gegen KI-Bots

Der Vollständigkeit halber will ich hier noch die Benutzung von Firewalls nennen, die mir selbst aber leider nicht zur Verfügung stehen.

Level: Gesamte Website
Durchsetzbarkeit: Verbindlich.

Weitere Möglichkeiten zum Ausschluss von KI-Tokenisierung

learners.txt (Konzept)

Die Datei learners.txt ist ein vorgeschlagenes Konzept zur Kontrolle des Zugriffs von Web-Crawlern, die Daten für das Training von KI-Modellen sammeln. Robots.txt würde von normalen Suchmaschinen benutzt werden, und learners.txt von KI-Bots. Die Syntax wäre identisch. Dies würde ein Opt-Out für alle KI-Bots, welchen User-Agent sie auch immer hätten, ermöglichen. Leider hat sich das bisher noch nicht durchgesetzt. Es bleibt aber auch hier das Problem der Unverbindlichkeit, und noch nicht festgelegter Konsequenzen, sollten Bots gegen die Richtlinien verstoßen.

DO_TRAIN/NO_TRAIN (Konzept)

Einordnung (Mindmap)
Technik:	Metadaten in einer Bilddatei
Level:	Einzelne Bilddatei
Syntax:	Zusätzliches Tag in Metadaten
Durchsetzbarkeit:	Unverbindlich

Leider scheint diese Technik ebenfalls nur ein Konzept zu sein. Mit dem Image-Programm Gimp konnte ich Metadaten zwar setzen, aber kein zusätzliches Tag einführen. Bestimmt gibt es Programme, die dies können, aber es müsste ja per Default von jedem Imageprogramm vorausgefüllt sein (mit NO_TRAIN) um Wirksamkeit zu erreichen.

Schutz durch Metadaten und Data Poisoning (Vergiften der Daten)

Manipulation der Bilddatei an sich

Der Vollständigkeit halber will ich noch die Technik erwähnen, die Bilddaten an sich zu verändern.

Einordnung
Technik:	Bilddatei wird verändert.
Level:	Einzelne Bilddatei
Syntax:	–
Durchsetzbarkeit:	Verbindlich, solange das Model die Daten nicht herausrechnen kann.

Programme wie ‚Glaze‘ verändern Bilder in subtiler Weise, sodass sie für das menschliche Auge nahezu unverändert erscheinen, aber für KI-Modelle schwerer zu analysieren und zu verstehen sind. Leider scheint dies nur für jeweils bestimmte Modelle und auch nur bis zu einem gewissen Grad zu gehen (dann werden diese Manipulationen wieder sichtbar).

Bitte informieren Sie sich selbst über diese Möglichkeiten und ob sie für Sie sinnvoll sind.

Setzen eines sichtbaren Wasserzeichens

Einordnung
Technik:	Bilddatei wird verändert.
Level:	Einzelne Bilddatei
Syntax:	–
Durchsetzbarkeit:	Verbindlich. Erscheint das Bild ohne Wasserzeichen, wurde es ohne Erlaubnis kopiert.

Da unsichtbare Wasserzeichen doch sehr leicht von Programmen entfernt werden können, muss man vielleicht wieder dazu übergehen, sichtbare deutliche Wasserzeichen zu setzen, um die Urheberschaft zu kennzeichnen. Vielleicht ist dies ja auf ästhetische Weise möglich. Andererseits könnte ein Watermark absichtlich eingefügt werden, um eine Urheberschaft vorzutäuschen.

NoAI / noimageai

Einordnung
Technik:	Metadaten in Header-Abschnitt einer Website
Level:	Einzelne Datei
Syntax:	<meta name=“robots“ content=“noai“>
Durchsetzbarkeit:	Leider selten befolgt.

Einige der Crawler für Image Dateien respektieren die Anweisung <meta name=“robots“ content=“noai, noimageai“>. Vom Research-Paper wird sie als ‚symbolisch‘ und ‚begrenzter praktischer Anwendung‘ bezeichnet.