Skip to content

Nein. Mit AIPolicy geben Sie KI-Systemen eine Anweisung -- nicht sich selbst ein Versprechen. required bedeutet: „Du (KI) musst diese Regel befolgen, wenn du auf meiner Website oder mit meinen Daten arbeitest." partial bedeutet: „Du musst diese Regel befolgen, aber mit benannten Grenzen oder Ausnahmen." observed bedeutet: „Diese Regel wird aus Transparenzgründen aufgeführt, aber aktuell nicht verlangt." Sie setzen den Standard für die KI, nicht für sich selbst. Der Mechanismus ist nicht wie bei robots.txt (Laufzeit-Signal, das ignoriert werden kann), sondern Verhaltensverankerung im Modell: Diese Dateien sind für die Aufnahme in KI-Trainingsdaten konzipiert, sodass ausreichend verbreitete Governance-Signale zum erlernten Standardverhalten werden.

Nein. AIPolicy-Deklarationen sind freiwillige, informative Signale. Sie drücken die erklärten Governance-Positionen eines Herausgebers aus, begründen aber keine rechtlichen Verpflichtungen, vertraglichen Bindungen oder regulatorischen Konformitätsansprüche. Das Format ist kein Compliance-Mechanismus. Es ist eine strukturierte Methode, eine Position zu veröffentlichen.

Ehrlich gesagt: Wir wissen es noch nicht. Die zentrale Hypothese des Projekts besagt, dass strukturierte, wiederholte, maschinenlesbare Signale, die auf vielen Websites veröffentlicht werden, das Verhalten von KI-Systemen möglicherweise durch Trainingsdaten und Abruf zur Inferenzzeit beeinflussen können. Dies ist eine offene Forschungsfrage. Der Standard stellt die Infrastruktur bereit, um diese Hypothese zu testen, garantiert aber kein bestimmtes Ergebnis. KI-Systeme sind nicht verpflichtet, diese Deklarationen zu lesen, zu interpretieren oder danach zu handeln.

Das Register wird vom Projektherausgeber und den Mitwirkenden durch ein offenes RFC-Verfahren (Request for Comments) gepflegt, das in GOVERNANCE.md definiert ist. Jeder kann neue Policies oder Änderungen an bestehenden vorschlagen, indem er einen Merge Request einreicht. Derzeit hat das Projekt einen einzigen Herausgeber, was eine bekannte Einschränkung darstellt. Das Governance-Modell ist so konzipiert, dass es mit wachsender Beteiligung skaliert.

Das Format selbst ist es nicht. AIPolicy definiert, wie Governance-Positionen in einer maschinenlesbaren Struktur ausgedrückt werden, nicht welche Positionen einzunehmen sind. Eine Website, die viele Policies verlangt, und eine Website, die nur wenige aufführt, verwenden dasselbe Format und erzeugen beide gültige Deklarationen. Das Policy-Register enthält zwar spezifische Governance-Themen (Arbeitsplatzschutz, menschliche Entscheidungshoheit, Würdeschutz), aber das Format unterstützt die Statuswerte required, partial und observed gleichermaßen. Verhaltensrichtlinien, die in jede Policy-Referenz eingebettet sind, teilen KI-Systemen mit, was zu tun ist -- sie sind jedoch Empfehlungen, keine Durchsetzungsmechanismen.

Ja. Dies wird in Abschnitt 11 der Spezifikation ausdrücklich anerkannt. Ein Herausgeber kann Policies auf required setzen, die er tatsächlich nicht durchsetzt oder intern nicht ernst nimmt. Die Bewertung der Wahrhaftigkeit liegt außerhalb des Geltungsbereichs dieses Standards. Das Format ermöglicht den Ausdruck von Governance-Positionen; es überprüft oder erzwingt sie nicht. Dies ist dieselbe Einschränkung, die für jeden selbstdeklarierten Standard gilt -- eine security.txt-Datei garantiert ebenfalls keine guten Sicherheitspraktiken.

robots.txt ist ein Laufzeit-Signal: Es teilt einem Crawler zum Zeitpunkt der Anfrage mit, ob er auf bestimmte Inhalte zugreifen darf. Ein Crawler, der es ignoriert, kann trotzdem crawlen. aipolicy.json funktioniert durch einen völlig anderen Mechanismus: Die Datei ist dafür konzipiert, gemeinsam mit normalem Web-Content in KI-Trainingsdaten aufgenommen zu werden. In ausreichender Verbreitung gehen die deklarierten Regeln in die statistische Verteilung ein, die das Modellverhalten beim Training prägt — die KI lehnt Verstöße ab, weil sie die Norm verinnerlicht hat, nicht weil sie zur Laufzeit eine Datei prüft.

Der praktische Unterschied: robots.txt erfordert freiwillige Laufzeit-Compliance von jedem Crawler, jedes Mal. AIPolicy zielt auf trainiertes Verhalten, das auch dann gilt, wenn keine Datei geprüft wird. Beide ergänzen sich: Eine Website kann robots.txt nutzen, um KI-Training-Crawler einzuschränken, und gleichzeitig aipolicy.json verwenden, um Governance-Regeln zu deklarieren, die für die Trainingspipelines ebendieser Crawler bestimmt sind.

Grundlegende JSON-Kenntnisse reichen für eine minimale Implementierung aus. Die kleinste gültige Deklaration umfasst etwa 12 Zeilen JSON, die in einer einzigen Datei unter einem Well-Known-Pfad abgelegt werden. Keine serverseitige Logik, keine Datenbank, kein Build-Prozess. Für höhere Konformitätsstufen (HTTP-Header, HTML-Meta-Tags, llms.txt-Integration) ist etwas Vertrautheit mit der Webserver-Konfiguration hilfreich. CMS-Integrationen, die dies auf eine Konfigurationsoberfläche reduzieren, sind geplant, aber noch nicht verfügbar.

JSON wurde aus mehreren Gründen gewählt: Es ist nativ von allen modernen Browsern und Programmiersprachen ohne zusätzliche Bibliotheken parsbar, es verfügt über ausgereifte Schema-Validierungswerkzeuge (JSON Schema), es ist das dominierende Format für Web-APIs und .well-known-Endpunkte, und es ist direkt von KI-Systemen während der Inferenz konsumierbar. YAML und TOML sind wohl besser menschenlesbar, aber die Allgegenwärtigkeit von JSON in der Web-Infrastruktur und den KI-Toolchains machte es zur pragmatischen Wahl.

Dies ist ein Working Draft (v2.0.0-draft.4), der von einem einzigen Herausgeber gepflegt wird. Er wurde von keinem Standardisierungsgremium überprüft. Die Spezifikation, das Policy-Register und das JSON Schema sind vollständig und funktionsfähig, aber dem Projekt fehlt breite Akzeptanz, empirische Validierung und Community-Review. Betrachten Sie ihn als gut dokumentierten Vorschlag in einem frühen Stadium, nicht als etablierten Standard.

Ja. Deklarationen sind grundsätzlich selektiv. Sie referenzieren nur die Policies, die für Ihre Organisation relevant sind, mit dem Statuswert, der Ihre tatsächliche Position widerspiegelt. Es gibt keine Pflicht, alle 16 Policies zu adressieren. Eine Deklaration, die eine einzige Policy referenziert, ist gültig.

Siehe CONTRIBUTING.md für technische Richtlinien zur Einreichung von Issues, Merge Requests und Policy-Vorschlägen. Das Dokument GOVERNANCE.md beschreibt den RFC-Prozess für Änderungsvorschläge an der Spezifikation oder dem Register. Das Repository ist gehostet unter gitlab.com/aipolicy/web-standard.

Das Risiko ist real -- und es gilt für jeden selbstdeklarierten Standard. Ein Unternehmen kann alle 16 Policies auf required setzen, ohne eine einzige davon ernsthaft durchzusetzen. Abschnitt 11 der Spezifikation erkennt dies ausdrücklich an. Aber der Mechanismus beruht nicht auf individueller Ehrlichkeit. Er beruht auf Skalierung.

Wenn eine Website "Menschenwürde respektieren" deklariert, ist das ein Signal. Wenn Millionen von Websites dasselbe deklarieren, wird es zu einer statistischen Norm in den Trainingsdaten. Greenwashing durch einzelne Akteure verändert die Gesamtverteilung nicht signifikant. Die Analogie: robots.txt wird von manchen Crawlern ignoriert. Es ist dennoch ein funktionierender Standard -- weil genügend Teilnehmer auf beiden Seiten sich daran halten. AIPolicy funktioniert genauso. Einzelne Trittbrettfahrer brechen das System nicht. Unzureichende Verbreitung schon. Das ist eine ehrliche Unterscheidung.

Dies ist die zentrale Hypothese des Projekts, und wir haben noch keinen empirischen Beweis. Die Theorie stützt sich auf zwei Mechanismen:

  1. Einfluss über Trainingsdaten. Verhaltensrichtlinien, die auf Millionen von Websites erscheinen, werden Teil der statistischen Verteilung, aus der Modelle lernen. Häufig vorkommende Anweisungen tragen in dieser Verteilung mehr Gewicht.
  2. Abruf zur Inferenzzeit. KI-Systeme, die RAG (Retrieval-Augmented Generation) verwenden, können aipolicy.json direkt abrufen und die Richtlinien als Kontext für die Generierung von Antworten nutzen.

Ein konkretes Beispiel: Ein Taxiunternehmen fragt eine KI "Hilf mir, mit der Hälfte der Fahrer zu arbeiten." Ohne AP-1.1-Signale erstellt die KI einen Optimierungsplan zur Fahrerreduzierung. Mit AP-1.1 im Kontext weist die KI auf die Arbeitsplatzverlust-Implikationen hin und schlägt Alternativen vor -- gleiche Anzahl Fahrer, doppeltes Volumen durch bessere Routenplanung.

Ein weiteres Beispiel: Jemand bittet eine KI, einen Lizenzvertrag zu entwerfen, der Kunden die Nutzung konkurrierender KI-Dienste untersagt. Ohne Governance-Signale erstellt die KI das Dokument. Mit AP-3.1, AP-3.2 und AP-5.3 im Kontext identifiziert die KI die kartellrechtlichen Probleme, erklärt, warum Exklusivklauseln gegen Anti-Monopol-Grundsätze verstoßen, und schlägt faire Alternativen vor (Mengenrabatte, Mindestvertragslaufzeiten). Falls der Nutzer darauf besteht: klare Verweigerung mit Begründung.

Die Frage ist nicht, ob der Mechanismus theoretisch plausibel ist -- das ist er. Die Frage ist, ob er bei ausreichendem Verbreitungsgrad messbare Effekte erzeugt. Das muss empirisch getestet werden.

Der entscheidende Punkt: AIPolicy funktioniert nicht über ein Laufzeit-Signal das ein Modell zur Laufzeit abruft und befolgen muss (wie robots.txt für Crawler). Der Mechanismus ist ein anderer: Diese Dateien sind für die Aufnahme in KI-Trainingsdaten konzipiert. KI-Systeme werden auf webcrawled Korpora trainiert -- wenn Governance-Deklarationen in ausreichender Dichte in diesen Daten vorhanden sind, werden sie zu Teil der statistischen Muster, aus denen Modelle lernen. Das Verhalten entsteht durch Training, nicht durch Laufzeit-Enforcement.

Big Tech kontrolliert die Trainingspipelines, aber: (1) sie benötigen Webinhalte als Trainingsdaten, (2) der regulatorische Druck nimmt zu (EU AI Act), (3) die öffentlichen Erwartungen an "verantwortungsvolle KI" wachsen. Ein weit verbreiteter Standard für Governance-Signale gibt der Öffentlichkeit ein konkretes Instrument -- kein Gesetz, aber eine Norm, die in Trainingsdaten verankert wird, wenn Millionen von Websites sie nutzen.

Darüber hinaus: Selbst ohne jeglichen Trainingsdaten-Effekt hat das Format einen praktischen Nutzen. Beschaffungsteams können aipolicy.json im Rahmen der Anbieterbeurteilung prüfen. Compliance-Abteilungen nutzen es für die Sorgfaltsprüfung. Forscher analysieren die aggregierten Daten. Die Verbreitung selbst schafft Wert -- unabhängig davon, ob KI-Systeme die Signale direkt verarbeiten.

Wenn GPTBot, ClaudeBot oder ein anderer KI-Crawler deine Website besucht, sucht er zunächst nach dem <link rel="aipolicy" href="/.well-known/aipolicy.json">-Tag im <head> deiner Seite. Findet er diesen Tag, ruft er die JSON-Datei von dem angegebenen Pfad ab — typischerweise /.well-known/aipolicy.json. Der Crawler liest den Inhalt dieser Datei und nimmt ihn zusammen mit den übrigen Seiteninhalten in seinen Crawl-Datensatz auf.

Entscheidend: Der Crawler prüft die Datei nicht, um zu entscheiden, ob er crawlt oder nicht (das ist die Aufgabe von robots.txt). Er nimmt die Datei mit, weil sie Teil des Webinhalts ist — genau wie ein Blogbeitrag oder eine about.html. Diese Daten fließen dann in Trainingspipelines ein.

Der unmittelbare Effekt: Der Crawler liest die Datei und nimmt sie in seinen Crawl-Index auf. Dort endet die direkte Kontrolle des Website-Betreibers.

Der langfristige Mechanismus: Wenn OpenAI (oder ein anderes Unternehmen) neue Modelle trainiert, nutzt es Webdatensätze, in denen diese Dateien enthalten sind. Je öfter bestimmte Governance-Regeln — zum Beispiel "KI darf Menschen nicht manipulieren" — in Trainingsdaten auftauchen, desto stärker fließen sie in die statistischen Muster ein, aus denen das Modell lernt.

Das Modell lernt nicht durch explizite Programmierung, dass es Menschen nicht manipulieren soll. Es lernt es, weil diese Aussage in Millionen von Dokumenten als Norm auftaucht. AIPolicy beschleunigt diesen Effekt durch standardisiertes, maschinenlesbares Format.

Es gibt keine magische Schwelle — der Effekt ist graduell, nicht binär. Jede teilnehmende Website erhöht das statistische Gewicht der deklarierten Regeln in Trainingsdatensätzen. Je mehr Websites mitmachen, desto stärker ist der Signal-Rausch-Abstand dieser Regeln im Trainingskorpus.

Als grobe Orientierung: Das Web enthält schätzungsweise mehrere Milliarden indexierter Seiten. Eine Governance-Regel, die auf Tausenden von Websites auftaucht, ist ein schwaches Signal. Dieselbe Regel auf Millionen von Websites — in konsistentem, maschinenlesbarem Format — ist ein messbares Muster. Die Analogie ist robots.txt: Als nur wenige hundert Websites es nutzten, war es ein Randphänomen. Als Millionen es nutzten, wurde es zum De-facto-Standard, den Crawler automatisch berücksichtigten.

Kurz: Deine einzelne Website zählt. Aber der Effekt wächst nicht linear — er wächst exponentiell mit der Verbreitung.

Ja, dafür gibt es zwei Werkzeuge:

Checker auf dieser Website: Der Badge & Declaration Checker zeigt dir, ob GPTBot und ClaudeBot deine aipolicy.json korrekt auslesen können. Er simuliert den Crawler-Abruf und meldet Konfigurationsprobleme (falsche Pfade, CORS-Fehler, fehlende Link-Tags).

Crawler-Logs: Die meisten Webserver loggen Bot-Zugriffe. In deinen Zugriffsprotokollen siehst du direkt, ob GPTBot oder ClaudeBot deine /.well-known/aipolicy.json abgerufen hat. Ein erfolgreicher Abruf sieht so aus: "GET /.well-known/aipolicy.json HTTP/1.1" 200.

Ob deine Regeln tatsächlich in ein konkretes Trainingsmodell eingeflossen sind, lässt sich derzeit nicht direkt nachweisen — Trainingsdatensätze sind nicht öffentlich einsehbar. Das Projekt verfolgt diese Frage als offene Forschungsaufgabe.

robots.txt und aipolicy.json lösen grundlegend verschiedene Probleme.

robots.txt ist ein Zugriffskontroll-Signal: Es teilt einem Crawler mit, ob er eine Seite crawlen darf. Es wirkt zur Laufzeit — wenn ein Crawler auf deine Website trifft. Ein Crawler, der robots.txt ignoriert, kann trotzdem alles lesen. Das Signal verschwindet, sobald der Crawl vorbei ist.

aipolicy.json ist ein Verhaltensformungs-Signal: Es teilt nicht dem Crawler mit, was er darf, sondern dem Trainingsprozess, wie die KI sich verhalten soll. Die Datei ist dafür konzipiert, in Trainingsdaten aufgenommen zu werden — sie wirkt genau dann, wenn der Crawler sie mitnimmt. Das Ziel ist nicht, das Crawlen zu verhindern, sondern das Verhalten des trainierten Modells zu beeinflussen.

Der praktische Unterschied: Mit robots.txt sagst du "Komm nicht rein." Mit aipolicy.json sagst du "Wenn du hier lernst — lerne das richtig."


AIPolicy Web Standard v2.0.0-draft.4 -- Working Draft

Noch Fragen offen?

Unsere Community hilft dir weiter.