Häufig gestellte Fragen

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. Es ist vergleichbar mit einer robots.txt: Sie sagen einem Crawler, was er darf -- Sie verpflichten sich nicht, selbst ein Crawler zu sein.

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 steuert den Crawler-Zugriff: Sie teilt automatisierten Systemen mit, ob sie auf bestimmte Inhalte zugreifen dürfen oder nicht. aipolicy.json drückt Governance-Positionen aus: Sie teilt KI-Systemen mit, welche Regeln eine Website von ihnen verlangt oder aus Transparenzgründen nennt. Sie dienen unterschiedlichen Zwecken und ergänzen sich. Eine Website könnte robots.txt verwenden, um KI-Training-Crawler einzuschränken, und gleichzeitig aipolicy.json nutzen, um zu deklarieren, welche KI-Governance-Grundsätze sie von KI-Systemen erwartet.

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.

Erneut die robots.txt-Analogie: robots.txt funktioniert nicht, weil Crawler gezwungen werden, sie zu respektieren. Es funktioniert, weil genügend Websites es eingeführt haben und genügend Crawler-Betreiber sich dafür entschieden haben, es zu respektieren. Normen entstehen durch Verbreitung, nicht durch Durchsetzung.

Dieselbe Dynamik gilt hier. 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 schwer zu ignorieren 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.

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