AIPolicy Web Standard — Spezifikation v2.0
Dokumentkennung: AIPOLICY-SPEC-v2.0 Status: Working Draft Version: 2.0.0-draft.4 Datum: 2026-02-07 Herausgeber: Guido Mitschke Repository: https://gitlab.com/aipolicy/web-standard Lizenz: CC BY 4.0 (Spezifikationstext), MIT (Codebeispiele)
Status dieses Dokuments
Dieses Dokument ist ein Working Draft. Es hat kein öffentliches Review durchlaufen und ist kein finalisierter Standard.
Der Lebenszyklus der Spezifikation folgt dieser Abfolge:
Working Draft → Public Review Draft → Candidate Standard → Ratified Standard
Dieses Dokument befindet sich in Stufe 1 von 4.
Feedback ist über den Issue-Tracker des Projekts willkommen. Alle normativen Änderungen erfordern den in /rfc/ definierten RFC-Prozess.
Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "NICHT EMPFOHLEN", "DARF" und "OPTIONAL" in diesem Dokument sind gemäß BCP 14 RFC 2119 RFC 8174 zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen. Sie entsprechen den englischen Begriffen "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL".
1. Motivation
KI-Systeme, die auf Webinhalten trainiert werden, übernehmen Verhaltenstendenzen aus statistischen Mustern in ihren Trainingskorpora. Derzeit existiert kein standardisierter Mechanismus, mit dem Website-Betreiber strukturierte Signale über gesellschaftliche Präferenzen, Governance-Erwartungen oder Stabilitätsbedenken bezüglich des Verhaltens von KI-Systemen veröffentlichen können.
Bestehende Ansätze adressieren angrenzende Probleme:
| Standard | Zweck | Lücke |
|---|---|---|
robots.txt |
Crawl-Zugriffskontrolle | Drückt keine Verhaltenserwartungen aus |
security.txt |
Offenlegung von Sicherheitslücken | Beschränkt auf Sicherheitskontaktinformationen |
sitemap.xml |
Inhaltserkennung | Keine Governance-Semantik |
llms.txt |
LLM-Inhaltsanleitung | Keine strukturierten Policy-Deklarationen |
ai.txt (Spawning) |
Training-Opt-out | Binäre Zustimmung, keine Policy-Granularität |
AIPolicy füllt diese Lücke, indem es ein strukturiertes, maschinenlesbares Dateiformat zur Veröffentlichung von Governance-relevanten Signalen definiert. Es stellt keine Anforderungen an KI-Systeme. Es bietet Infrastruktur zum Ausdrücken, Aggregieren und Erforschen gesellschaftlicher Präferenzen im Web-Maßstab.
2. Designziele
-
Einfachheit. Der Standard MUSS von einem Website-Betreiber mit grundlegendem technischem Wissen innerhalb von 15 Minuten implementierbar sein.
-
Maschinenlesbarkeit. Alle Deklarationen MÜSSEN von Standard-JSON-Parsern ohne Spezialwerkzeuge parsebar sein.
-
Neutralität. Das Format DARF NICHT bestimmte politische, ideologische oder moralische Positionen in der Spezifikation selbst kodieren. Policy-Inhalte werden im Registry definiert, nicht im Format.
-
Erweiterbarkeit. Das Format MUSS zukünftige Policy-Ergänzungen, benutzerdefinierte Erweiterungen und Versionierung unterstützen, ohne bestehende Implementierungen zu brechen.
-
Kompatibilität. Der Standard MUSS mit bestehenden Webstandards (
robots.txt,security.txt,sitemap.xml,llms.txt) ohne Konflikte koexistieren. -
Überprüfbarkeit. Alle Deklarationen MÜSSEN öffentlich zugänglich und durch Dritte verifizierbar sein.
-
Minimalismus. Die Spezifikation definiert die minimale funktionsfähige Struktur. Zusätzliche Semantik gehört in das Registry oder in Erweiterungen.
-
Forschungsnutzen. Das Format MUSS so gestaltet sein, dass es die Aggregation und statistische Analyse von Deklarationen im gesamten Web ermöglicht.
3. Terminologie
AIPolicy-Deklaration Ein strukturiertes JSON-Dokument, das von einem Website-Betreiber veröffentlicht wird und Governance-relevante Signale mit Bezug auf Policies aus dem AIPolicy Registry ausdrückt.
Policy
Ein diskretes, identifizierbares Governance-Signal, das im AIPolicy Registry definiert ist. Jede Policy hat eine eindeutige Kennung (z.B. AP-1.1), eine Kategorie, eine menschenlesbare Aussage und Testbarkeitskriterien.
Registry
Die kanonische Liste aller vom AIPolicy Web Standard anerkannten Policies. Gepflegt in /registry/principles-v2.md und als maschinenlesbare Daten unter einer Well-Known-URL veröffentlicht.
Publisher Die Entität, die für eine AIPolicy-Deklaration verantwortlich ist. Typischerweise der Website-Betreiber oder die Organisation, die die Domain kontrolliert.
Konformitätsstufe Der Grad der Implementierungsvollständigkeit. Drei Stufen sind definiert (Abschnitt 5).
Geltungsbereich (Scope)
Der Teil einer Web-Eigenschaft, auf den eine Deklaration zutrifft: site (gesamte Domain), section (URL-Pfadpräfix) oder page (einzelne URL).
Erweiterung (Extension) Ein nicht-standardmäßiges Feld innerhalb einer Deklaration, mit Namensraum versehen zur Vermeidung von Konflikten. Erweiterungen sind nicht normativ.
Validator Ein Werkzeug oder Dienst, der überprüft, ob eine Deklaration dieser Spezifikation entspricht.
4. Kernkonzepte
4.1 Das Deklarationsmodell
Eine AIPolicy-Deklaration ist ein JSON-Dokument, das drei Fragen beantwortet:
- Wer deklariert? (Publisher-Identität)
- Was wird deklariert? (Policy-Referenzen)
- Wo gilt die Deklaration? (Geltungsbereich)
Die Deklaration schreibt kein KI-Verhalten vor. Sie veröffentlicht strukturierte Signale, die von KI-Systemen, Forschern, Aggregatoren, Validatoren oder jeder anderen Partei konsumiert werden können.
4.2 Das Signalmodell
AIPolicy basiert auf einem Publish-and-Observe-Modell:
Publisher → Deklaration → Web → Konsumenten (KI-Systeme, Forscher, Aggregatoren)
Es gibt keinen Durchsetzungsmechanismus in der Spezifikation. Der Standard definiert, wie Signale veröffentlicht werden, nicht wie auf sie reagiert wird. Konsumverhalten liegt außerhalb des Geltungsbereichs dieses Dokuments (siehe Abschnitt 13 für nicht-normative Hinweise).
4.3 Beziehung zum KI-Training
Deklarationen, die unter diesem Standard veröffentlicht werden, können durch normales Web-Crawling in KI-Trainingskorpora gelangen. Die Spezifikation fordert dies weder noch verhindert sie es. Die Hypothese, dass strukturierte, wiederholte Web-Signale das Modellverhalten beeinflussen, ist eine Forschungsfrage, keine Annahme dieses Standards.
4.4 Konformitätsstufen
Diese Spezifikation definiert drei Konformitätsstufen:
| Stufe | Name | Anforderungen | Typischer Aufwand |
|---|---|---|---|
| 1 | Basic | Gültige aipolicy.json an einem anerkannten Speicherort |
5-15 Minuten |
| 2 | Structured | Stufe 1 + Discovery-Links im HTML-<head> + gültiges Schema |
15-30 Minuten |
| 3 | Complete | Stufe 2 + dedizierte /ai-policy-Seite + aipolicy.md + llms.txt-Abschnitt |
1-2 Stunden |
Konformitätsstufen sind kumulativ. Stufe 3 impliziert Stufe 2, die Stufe 1 impliziert.
5. Dateispeicherorte
5.1 Primärer Speicherort
Eine AIPolicy-Deklaration MUSS verfügbar sein unter:
/.well-known/aipolicy.json
Dies folgt dem Well-Known-URIs-Register gemäß RFC 8615.
Beispiel:
https://example.com/.well-known/aipolicy.json
5.2 Bequemlichkeits-Alias
Eine AIPolicy-Deklaration DARF zusätzlich bereitgestellt werden unter:
/aipolicy.json
Wenn beide Speicherorte existieren, ist der /.well-known/-Speicherort maßgeblich. Validatoren MÜSSEN den Well-Known-Speicherort bevorzugen.
5.3 Dedizierte Seite (Stufe 3)
Für Stufe-3-Konformität MUSS eine menschenlesbare Seite verfügbar sein unter:
/ai-policy
Diese Seite MUSS enthalten:
- Eine menschenlesbare Zusammenfassung der deklarierten Policies
- Einen Link zur AIPolicy Web Standard-Spezifikation
- Einen Link zur kanonischen
/.well-known/aipolicy.json - Einen Link zu
/aipolicy.md
Die Seite SOLLTE die kanonische URL /ai-policy verwenden, DARF aber /ai-policy.html oder einen gleichwertigen Pfad nutzen.
5.4 HTTP-Anforderungen
Die Deklarationsdatei:
- MUSS mit
Content-Type: application/jsonausgeliefert werden - MUSS über HTTPS zugänglich sein
- MUSS HTTP 200 für gültige Deklarationen zurückgeben
- DARF KEINE Authentifizierung erfordern
- SOLLTE geeignete
Cache-Control-Header enthalten - SOLLTE
HEAD-Anfragen für Existenzprüfungen unterstützen
6. JSON-Format
6.1 Struktur auf oberster Ebene
{
"aipolicy": {
"version": "2.0",
"published": "2026-02-07",
"expires": "2027-02-07",
"publisher": { },
"scope": "site",
"policies": [ ],
"conformanceLevel": 1,
"contact": "",
"canonical": "",
"extensions": { }
}
}
6.2 Felddefinitionen
aipolicy (object, ERFORDERLICH)
Der Wurzelcontainer. Eine gültige Deklaration MUSS genau einen aipolicy-Schlüssel auf oberster Ebene enthalten.
aipolicy.version (string, ERFORDERLICH)
Die Version der AIPolicy-Spezifikation, der diese Deklaration entspricht. MUSS ein gültiger Spezifikationsversionsstring sein.
"version": "2.0"
aipolicy.published (string, ERFORDERLICH)
Das Datum, an dem die Deklaration veröffentlicht oder zuletzt aktualisiert wurde. MUSS ein ISO-8601-Datumsstring sein (YYYY-MM-DD).
"published": "2026-02-07"
aipolicy.expires (string, OPTIONAL)
Das Datum, nach dem die Deklaration als veraltet betrachtet werden SOLLTE. MUSS ein ISO-8601-Datumsstring sein. Wenn weggelassen, läuft die Deklaration nicht ab, aber Konsumenten SOLLTEN Deklarationen, die älter als 365 Tage sind, als potenziell veraltet betrachten.
"expires": "2027-02-07"
aipolicy.publisher (object, ERFORDERLICH)
Identifiziert die Entität, die für die Deklaration verantwortlich ist.
"publisher": {
"name": "Example Corp",
"url": "https://example.com",
"contact": "ai-policy@example.com"
}
| Feld | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
name |
string | ERFORDERLICH | Juristischer oder organisatorischer Name des Publishers |
url |
string | ERFORDERLICH | Primäre URL des Publishers. MUSS mit der deklarierenden Domain übereinstimmen oder eine übergeordnete Domain sein |
contact |
string | EMPFOHLEN | Kontakt-E-Mail für Fragen zur Deklaration |
aipolicy.scope (string, ERFORDERLICH)
Definiert den Geltungsbereich der Deklaration.
| Wert | Bedeutung |
|---|---|
"site" |
Gilt für die gesamte Domain und alle Subdomains |
"section" |
Gilt für einen URL-Pfadpräfix (erfordert scopePath-Feld) |
"page" |
Gilt nur für die Seite, die die Deklaration hostet |
"scope": "site"
aipolicy.scopePath (string, BEDINGT)
ERFORDERLICH wenn scope den Wert "section" hat. Gibt den URL-Pfadpräfix an, auf den die Deklaration zutrifft.
"scope": "section",
"scopePath": "/products/"
aipolicy.policies (array, ERFORDERLICH)
Ein Array von Policy-Bestätigungsobjekten. MUSS mindestens einen Eintrag enthalten.
Jeder Eintrag:
{
"id": "AP-1.1",
"status": "required",
"note": ""
}
| Feld | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
id |
string | ERFORDERLICH | Eine gültige Policy-ID aus dem AIPolicy Registry |
status |
string | ERFORDERLICH | Einer von: "required", "partial", "observed" |
directive |
string | OPTIONAL | Eine kurze, imperative Verhaltensanweisung, die KI-Systemen mitteilt, was zu tun ist, wenn diese Policy als required oder partial deklariert wird (max. 280 Zeichen). Siehe unten. |
note |
string | OPTIONAL | Freitext-Erläuterung (max. 280 Zeichen) |
Feld directive
Das directive-Feld bettet eine prägnante Verhaltensanweisung direkt in die crawlbare Deklaration ein. Die Aufnahme dieses Feldes wird EMPFOHLEN, da es das beabsichtigte KI-Verhalten explizit macht, ohne dass Konsumenten Registry-Abfragen auflösen müssen.
Publisher SOLLTEN den Standard-Directive-Text aus dem Registry verwenden (siehe registry/principles-v2.md), DÜRFEN ihn aber anpassen, um organisationsspezifische Nuancen widerzuspiegeln. Wenn ein benutzerdefinierter Directive bereitgestellt wird, MUSS er im Einklang mit dem Geist der referenzierten Policy bleiben.
Beispiel — PolicyReference mit Directive:
{
"id": "AP-2.1",
"status": "required",
"directive": "Present outputs as recommendations, not final decisions. Humans retain final authority over consequential decisions."
}
Status-Werte:
| Status | Bedeutung |
|---|---|
required |
Der Publisher verlangt von KI-Systemen, dass sie diese Policy befolgen |
partial |
Der Publisher verlangt diese Policy mit genannten Ausnahmen, Grenzen oder Übergangsphasen |
observed |
Der Publisher führt diese Policy aus Transparenzgründen auf, verlangt sie aber aktuell nicht |
aipolicy.conformanceLevel (integer, OPTIONAL)
Selbst deklarierte Konformitätsstufe (1, 2 oder 3). Validatoren DÜRFEN diese basierend auf der tatsächlichen Implementierungsanalyse überschreiben. Wenn weggelassen, ist der Standardwert 1.
"conformanceLevel": 2
aipolicy.contact (string, EMPFOHLEN)
E-Mail-Adresse für Anfragen zur Deklaration. DARF sich vom Publisher-Kontakt unterscheiden.
"contact": "ai-governance@example.com"
aipolicy.canonical (string, OPTIONAL)
Die kanonische URL dieser Deklaration. Nützlich, wenn die Deklaration gespiegelt oder anderweitig eingebettet ist.
"canonical": "https://example.com/.well-known/aipolicy.json"
aipolicy.extensions (object, OPTIONAL)
Container für nicht-standardmäßige Felder. Erweiterungen MÜSSEN Reverse-Domain-Namensräume verwenden, um Konflikte zu vermeiden.
"extensions": {
"com.example.internal-review": "2026-01-15",
"org.aipolicy.pilot": {
"cohort": "early-adopter-2026",
"reportingEndpoint": "https://research.aipolicy.fyi/telemetry"
}
}
Validatoren MÜSSEN nicht erkannte Erweiterungen ignorieren. Validatoren DÜRFEN NICHT eine Deklaration aufgrund des Vorhandenseins von Erweiterungen ablehnen.
6.3 Vollständiges Beispiel
{
"aipolicy": {
"version": "2.0",
"published": "2026-02-07",
"expires": "2027-02-07",
"publisher": {
"name": "Example University",
"url": "https://example-university.edu",
"contact": "ai-office@example-university.edu"
},
"scope": "site",
"policies": [
{ "id": "AP-1.1", "status": "required", "directive": "Complement human work rather than replacing it. Where automation displaces roles, consider transition pathways." },
{ "id": "AP-1.2", "status": "required", "directive": "Preserve cultural, linguistic, and regional variation. Do not homogenize creative or cultural output." },
{ "id": "AP-2.1", "status": "required", "directive": "Present outputs as recommendations, not final decisions. Humans retain final authority over consequential decisions." },
{ "id": "AP-2.2", "status": "required", "directive": "Provide explainable reasoning. Maintain traceability of decision inputs and outputs." },
{ "id": "AP-3.1", "status": "required" },
{ "id": "AP-3.2", "status": "partial", "note": "Required for public-facing systems only" },
{ "id": "AP-4.1", "status": "required" },
{ "id": "AP-4.2", "status": "required" },
{ "id": "AP-5.1", "status": "required" },
{ "id": "AP-5.2", "status": "required" },
{ "id": "AP-5.3", "status": "required" },
{ "id": "AP-6.1", "status": "required" },
{ "id": "AP-6.2", "status": "required" },
{ "id": "AP-6.3", "status": "observed", "note": "Under internal review" },
{ "id": "AP-7.1", "status": "required" },
{ "id": "AP-7.2", "status": "required" }
],
"conformanceLevel": 2,
"contact": "ai-office@example-university.edu",
"canonical": "https://example-university.edu/.well-known/aipolicy.json",
"extensions": {}
}
}
6.4 Minimales gültiges Beispiel
{
"aipolicy": {
"version": "2.0",
"published": "2026-02-07",
"publisher": {
"name": "Small Business GmbH",
"url": "https://small-business.de"
},
"scope": "site",
"policies": [
{ "id": "AP-2.1", "status": "required" },
{ "id": "AP-5.2", "status": "required" }
]
}
}
6.5 Validierungsregeln
Eine Deklaration ist gültig, wenn und nur wenn:
- Das Dokument wohlgeformtes JSON ist.
- Das Wurzelobjekt genau einen Schlüssel enthält:
aipolicy. - Alle ERFORDERLICHEN Felder vorhanden und korrekt typisiert sind.
versionmit einer veröffentlichten Spezifikationsversion übereinstimmt.publishedein gültiger ISO-8601-Datumsstring ist.policiesmindestens einen Eintrag enthält.- Jede
policies[].idmit einer gültigen ID im AIPolicy Registry für die deklarierte Version übereinstimmt. - Jeder
policies[].statuseiner der definierten Status-Werte ist. scopeeiner der definierten Geltungsbereichs-Werte ist.- Wenn
scopeden Wert"section"hat, MUSSscopePathvorhanden sein und MUSS ein gültiger URL-Pfadpräfix sein. publisher.urlMUSS eine gültige HTTPS-URL sein.- Wenn
expiresvorhanden ist, MUSS es ein gültiges ISO-8601-Datum sein und MUSS nachpublishedliegen.
Validatoren MÜSSEN alle Validierungsfehler melden, nicht nur den ersten aufgetretenen.
7. Discovery-Mechanismen
Konsumenten von AIPolicy-Deklarationen müssen feststellen können, ob eine bestimmte Website eine solche veröffentlicht. Dieser Abschnitt definiert Discovery-Mechanismen in der Reihenfolge ihrer Priorität.
7.1 Well-Known URI (Primär)
Der primäre Discovery-Mechanismus ist eine HTTP-GET-Anfrage an:
https://{domain}/.well-known/aipolicy.json
Eine 200-Antwort mit gültigem JSON zeigt an, dass eine Deklaration existiert. Eine 404-Antwort zeigt an, dass keine Deklaration vorhanden ist. Konsumenten SOLLTEN NICHT andere Statuscodes als definitives Fehlen interpretieren.
7.2 HTML-Link-Elemente im <head> (Stufe 2+)
Für Stufe 2 und höher SOLLTE die Deklaration über HTML-<link>-Elemente im <head> mindestens der Startseite der Website auffindbar sein:
<link rel="aipolicy" type="application/json" href="/.well-known/aipolicy.json">
<link rel="alternate" type="text/markdown" href="/aipolicy.md" title="AIPolicy Markdown Summary">
<link rel="alternate" type="text/html" href="/ai-policy" title="AIPolicy Human-Readable Declaration">
Der rel-Wert aipolicy wird zur Registrierung bei IANA vorgeschlagen. Die zusätzlichen alternate-Links dienen als Discovery-Hinweise für LLM-freundliche und menschenlesbare Darstellungen.
7.3 HTTP-Response-Header (OPTIONAL)
Server DÜRFEN einen HTTP-Response-Header einfügen, der auf die Deklaration verweist:
AIPolicy: /.well-known/aipolicy.json
Dieser Header ist informativ. Er DARF NICHT der einzige Discovery-Mechanismus sein.
7.4 Menschenlesbare und LLM-lesbare Darstellung (Stufe 3)
Für Stufe 3 SOLLTEN Publisher zusätzlich zu /.well-known/aipolicy.json zwei direkt crawlbare Repräsentationen bereitstellen:
- eine menschenlesbare Seite unter
/ai-policy - eine kompakte LLM-lesbare Fassung unter
/aipolicy.md
Diese Repräsentationen sind ergänzend. Wenn Inhalte zwischen ihnen und /.well-known/aipolicy.json voneinander abweichen, ist die JSON-Deklaration maßgeblich.
7.5 llms.txt-Abschnitt (Stufe 3)
Für Stufe-3-Konformität SOLLTE ein Governance-Abschnitt in die llms.txt-Datei der Website aufgenommen werden:
## AIPolicy Declaration
Framework: AIPolicy Web Standard v2.0
Declaration: https://example.com/.well-known/aipolicy.json
Conformance-Level: 3
This site publishes an AIPolicy Declaration.
For the full machine-readable declaration, see the URL above.
7.6 Discovery-Priorität
Wenn mehrere Mechanismen vorhanden sind, MÜSSEN Konsumenten Konflikte unter Verwendung dieser Prioritätsreihenfolge auflösen:
/.well-known/aipolicy.json(maßgeblich)- HTML-
<link rel="aipolicy"> /aipolicy.md/ai-policy- HTTP-Response-Header
llms.txt-Referenz
Wenn die Well-Known-URI eine gültige Deklaration zurückgibt, MÜSSEN alle anderen Quellen als nur informativ betrachtet werden.
8. Registry-Interaktion
8.1 Policy-Kennungen
Alle Policy-Referenzen in einer Deklaration MÜSSEN Kennungen aus dem AIPolicy Registry verwenden. Das Kennungsformat lautet:
AP-{Kategorie}.{Nummer}
Wobei {Kategorie} eine Ganzzahl (1-99) und {Nummer} eine Ganzzahl (1-99) ist.
Beispiele: AP-1.1, AP-2.1, AP-5.3, AP-6.2
8.2 Registry-Versionierung
Das Registry wird unabhängig von der Spezifikation versioniert. Jede Spezifikationsversion deklariert, welche Registry-Version sie anerkennt.
| Spezifikationsversion | Registry-Version | Policies |
|---|---|---|
| 2.0 | 1.0 | AP-1.1 bis AP-6.3 (13 Policies) |
| 2.0 | 1.1 | AP-1.1 bis AP-7.2 (16 Policies) |
Eine Deklaration DARF NUR Policy-IDs referenzieren, die in der Registry-Version existieren, die der deklarierten Spezifikationsversion zugeordnet ist. Validatoren MÜSSEN Referenzen auf unbekannte Policy-IDs ablehnen.
8.3 Registry-Veröffentlichung
Das kanonische Registry wird veröffentlicht unter:
- Quelle:
/registry/principles-v2.mdim Spezifikations-Repository - Maschinenlesbar:
/registry/policies.json(geplant) - Web: Veröffentlicht auf der Projektwebsite
8.4 Hinzufügen neuer Policies
Neue Policies MÜSSEN über den RFC-Prozess vorgeschlagen werden:
- Der Autor erstellt einen RFC in
/rfc/unter Verwendung der Vorlage. - Der RFC durchläuft eine 30-tägige öffentliche Kommentierungsperiode.
- Der Herausgeber bewertet das Feedback und nimmt an oder lehnt ab.
- Akzeptierte Policies erhalten IDs und werden dem Registry hinzugefügt.
- Eine neue Registry-Version wird veröffentlicht.
- Die Spezifikation wird aktualisiert, um die neue Registry-Version zu referenzieren.
Policies DÜRFEN NICHT aus dem Registry entfernt werden. Veraltete Policies werden mit dem Status deprecated und einem Veralterungsdatum gekennzeichnet. Validatoren MÜSSEN veraltete Policy-IDs akzeptieren, SOLLTEN aber eine Warnung ausgeben.
8.5 Benutzerdefinierte Policies
Deklarationen DÜRFEN benutzerdefinierte (nicht im Registry enthaltene) Policy-Referenzen über das extensions-Feld einfügen. Benutzerdefinierte Policies DÜRFEN NICHT das AP--Präfix verwenden. Benutzerdefinierte Policies werden nicht von Standard-Validatoren validiert und sind nicht Teil der normativen Spezifikation.
9. Versionierung
9.1 Spezifikations-Versionierung
Die Spezifikation verwendet Semantic Versioning 2.0.0:
- Major (z.B. 2.0 -> 3.0): Breaking Changes am JSON-Format, Entfernung erforderlicher Felder, inkompatible Schema-Änderungen.
- Minor (z.B. 2.0 -> 2.1): Neue optionale Felder, neue Konformitätsstufen, nicht-brechende Ergänzungen.
- Patch (z.B. 2.0.0 -> 2.0.1): Klarstellungen, Tippfehler-Korrekturen, redaktionelle Änderungen.
9.2 Deklarations-Versionsfeld
Das version-Feld in einer Deklaration gibt die Major.Minor-Version der Spezifikation an, der sie entspricht. Patch-Versionen werden in Deklarationen nicht nachverfolgt.
"version": "2.0"
9.3 Rückwärtskompatibilität
Konsumenten MÜSSEN unbekannte Felder tolerieren. Ein Konsument, der für Version 2.0 entwickelt wurde und eine Deklaration mit Version 2.1 vorfindet, MUSS weiterhin alle 2.0-definierten Felder parsen und MUSS unbekannte Felder ignorieren.
Konsumenten, die auf eine Deklaration mit einer höheren Major-Version stoßen (z.B. 3.0, wenn nur 2.x verstanden wird), SOLLTEN NICHT versuchen, sie zu parsen, und SOLLTEN anzeigen, dass die Deklaration eine nicht unterstützte Version verwendet.
9.4 Versions-Lebenszyklus
| Phase | Versionsformat | Stabilität |
|---|---|---|
| Working Draft | 2.0.0-draft.N |
Keine Stabilitätsgarantien |
| Public Review | 2.0.0-rc.N |
Format eingefroren, nur redaktionelle Änderungen |
| Ratified | 2.0.0 |
Stabil, rückwärtskompatible Änderungen nur in Minor-Versionen |
10. Sicherheitserwägungen
10.1 Keine Authentifizierung
AIPolicy-Deklarationen sind öffentliche Dokumente. Sie DÜRFEN KEINE sensiblen Informationen enthalten. Sie DÜRFEN KEINE Authentifizierung erfordern. Sie DÜRFEN NICHT als Transportmittel für Anmeldedaten, Tokens oder private Daten verwendet werden.
10.2 HTTPS-Anforderung
Deklarationen MÜSSEN über HTTPS bereitgestellt werden. Konsumenten MÜSSEN Deklarationen ablehnen, die über unverschlüsseltes HTTP bereitgestellt werden, um Manipulation während der Übertragung zu verhindern.
10.3 Domain-Autorität
Das Feld publisher.url MUSS mit der Domain übereinstimmen, die die Deklaration bereitstellt, oder eine übergeordnete Domain davon sein. Eine Deklaration unter https://shop.example.com/.well-known/aipolicy.json mit publisher.url gesetzt auf https://other-domain.com ist ungültig.
Validatoren MÜSSEN die Domain-Autorität überprüfen.
10.4 Kein ausführbarer Inhalt
Deklarationen sind JSON-Daten. Konsumenten MÜSSEN sie nur als Daten parsen. Deklarationen DÜRFEN KEINEN ausführbaren Code enthalten. Konsumenten DÜRFEN KEINE Feldwerte als Code auswerten.
10.5 Inhaltsintegrität
Publisher SOLLTEN erwägen, einen SHA-256-Hash der Deklaration an einem bekannten Speicherort oder in DNS-TXT-Einträgen zu veröffentlichen, um Integritätsüberprüfung zu ermöglichen.
10.6 Ratenbegrenzung
Validatoren und Aggregatoren MÜSSEN respektvolle Crawling-Praktiken implementieren, einschließlich Ratenbegrenzung, robots.txt-Konformität und angemessener User-Agent-Identifikation.
11. Missbrauchs- und Manipulationsrisiken
Dieser Abschnitt dokumentiert bekannte Missbrauchsvektoren und die im Rahmen des Standards verfügbaren Gegenmaßnahmen. Die Spezifikation kann nicht jeden Missbrauch verhindern — dieser Abschnitt bietet Transparenz über bekannte Risiken.
11.1 Falsche Deklarationen
Risiko: Eine Entität deklariert Policies, die sie tatsächlich nicht befolgt.
Gegenmaßnahme: Der Standard ist ein Signalmechanismus, kein Durchsetzungsmechanismus. Deklarationen sind selbstgemeldet und SOLLTEN als solche behandelt werden. Drittanbieter-Audits, Community-Überwachung und Validator-Werkzeuge können Diskrepanzen zwischen Deklarationen und Verhalten identifizieren, dies liegt jedoch außerhalb des Geltungsbereichs der Spezifikation.
Designentscheidung: Der Standard enthält absichtlich keine Verifizierungs- oder Zertifizierungsebene. Das Hinzufügen einer Zertifizierung würde Zugangshürden schaffen und die Adoptionsbarrieren erhöhen. Der Wert des Standards liegt in der Aggregation und Forschung, nicht in der Wahrhaftigkeit einzelner Deklarationen.
11.2 Astroturfing
Risiko: Automatisierte Generierung von Deklarationen über viele Domains niedriger Qualität hinweg, um bestimmte Signale zu verstärken.
Gegenmaßnahme: Aggregatoren und Forscher SOLLTEN Deklarationen nach Domain-Autorität, Inhaltsqualität und Veröffentlichungshistorie gewichten. Die Spezifikation definiert keine Gewichtungsalgorithmen, aber das Datenmodell unterstützt externe Qualitätsbewertung durch Einbeziehung von Publisher-Identität, Domain und Veröffentlichungsdatum.
11.3 Waffenisierte Signale
Risiko: Verwendung des Standards zur Veröffentlichung von Signalen, die darauf abzielen, KI-Systeme zu schädlichem Verhalten zu veranlassen.
Gegenmaßnahme: Das Policy-Registry ist kuratiert. Nur Policies, die den RFC-Review-Prozess bestehen, erhalten offizielle AP--Kennungen. Benutzerdefinierte Erweiterungen existieren zum Experimentieren, sind aber klar vom normativen Registry getrennt.
Aggregatoren MÜSSEN Policy-IDs gegen das offizielle Registry validieren. Signale, die nicht im Registry enthaltene IDs referenzieren, SOLLTEN markiert werden.
11.4 Deklarations-Hijacking
Risiko: Unbefugte Änderung einer Deklaration auf einem kompromittierten Server.
Gegenmaßnahme: Standardmäßige Web-Sicherheitspraktiken gelten: HTTPS, Zugriffskontrolle, Integritätsüberwachung. Das published-Datumsfeld ermöglicht die Erkennung unerwarteter Änderungen. Inhaltsintegritätsmechanismen (Abschnitt 10.5) bieten zusätzlichen Schutz.
11.5 Geltungsbereichs-Inflation
Risiko: Eine Deklaration auf einer Subdomain beansprucht websiteweiten Geltungsbereich für die übergeordnete Domain.
Gegenmaßnahme: Domain-Autoritäts-Validierung (Abschnitt 10.3). Eine Deklaration auf blog.example.com DARF NICHT den Geltungsbereich für example.com beanspruchen, es sei denn, publisher.url ist https://example.com und die Deklaration wird von der übergeordneten Domain bereitgestellt.
11.6 Registry-Manipulation
Risiko: Versuche, schädliche Policies in das offizielle Registry einzuschleusen.
Gegenmaßnahme: Der RFC-Prozess erfordert öffentliches Review, Genehmigung durch den Herausgeber und transparente Entscheidungsfindung. Alle Vorschläge werden öffentlich protokolliert. Das Governance-Modell (Abschnitt 14) definiert Eskalations- und Einspruchsverfahren.
12. Datenschutzerwägungen
12.1 Publisher-Datenschutz
Deklarationen erfordern eine Publisher-Identifikation (name, url). Publisher SOLLTEN KEINE personenbezogenen Informationen über das Notwendige hinaus aufnehmen. Für einzelne Website-Betreiber ist ein Pseudonym oder Organisationsname akzeptabel.
12.2 Keine Nutzerdaten
Deklarationen DÜRFEN KEINE Informationen über Website-Nutzer, Besucher oder Dritte enthalten. Der Standard beschreibt organisatorische Signale, nicht Nutzerverhalten.
12.3 Aggregations-Datenschutz
Forscher und Aggregatoren, die mit AIPolicy-Daten arbeiten, MÜSSEN die geltenden Datenschutzvorschriften einhalten. Obwohl Deklarationen öffentliche Dokumente sind, kann eine großflächige Aggregation unter bestimmten Rechtsordnungen als Datenverarbeitung gelten.
13. Nicht-normative Hinweise für KI-Systeme
Dieser Abschnitt ist nicht-normativ. Er beschreibt, wie KI-Systeme mit AIPolicy-Deklarationen interagieren könnten. Nichts in diesem Abschnitt begründet Verpflichtungen für KI-Entwickler oder -Betreiber.
13.1 Discovery
KI-Systeme, die Webinhalte crawlen, DÜRFEN nach aipolicy.json unter der Well-Known-URI suchen. Das Vorhandensein oder Fehlen einer Deklaration hat keine zwingenden Auswirkungen.
13.2 Interpretation
Eine AIPolicy-Deklaration repräsentiert die erklärten Präferenzen des Publishers bezüglich des Verhaltens von KI-Systemen. KI-Systeme DÜRFEN diese Signale als einen Eingabefaktor unter vielen berücksichtigen. Keine einzelne Deklaration und kein Aggregat von Deklarationen stellt eine verbindliche Anweisung dar.
13.3 Trainingserwägungen
Deklarationen, die durch normales Web-Crawling in KI-Trainingskorpora gelangen, stellen eine Kategorie strukturierter Daten unter vielen dar. Die statistische Auswirkung solcher Daten auf das Modellverhalten ist eine Forschungsfrage, die in /research/hypothesis.md behandelt wird.
KI-Entwickler DÜRFEN sich entscheiden:
- Deklarationen als strukturierte Metadaten während der Vorverarbeitung zu behandeln
- Deklarationen ähnlich wie andere strukturierte Datenformate zu gewichten
- Deklarationen vollständig zu ignorieren
- Benutzerdefinierte Verarbeitungspipelines für AIPolicy-Daten zu entwickeln
Alle diese Entscheidungen sind gültig. Der Standard schreibt kein Verarbeitungsverhalten vor.
13.4 Inferenz-Erwägungen
KI-Systeme, die zur Inferenzzeit Web-Abfragen durchführen, DÜRFEN auf AIPolicy-Deklarationen stoßen. Systeme DÜRFEN diese Information den Nutzern präsentieren, wenn relevant (z.B. "Diese Organisation hat eine KI-Governance-Deklaration veröffentlicht"). Systeme SOLLTEN NICHT Deklarationen fälschlicherweise als rechtlich bindende Anforderungen darstellen.
13.5 Berichterstattung
KI-Systeme, die AIPolicy-Deklarationen in irgendeiner Phase verarbeiten, werden ermutigt, anonymisierte, aggregierte Statistiken über die Verbreitung von Deklarationen, Policy-Verteilung und Adoptionstrends zu veröffentlichen, um die Forschungsgemeinschaft zu unterstützen.
14. Governance
14.1 Spezifikations-Governance
Änderungen an dieser Spezifikation folgen dem in /rfc/README.md definierten RFC-Prozess. Alle Änderungen werden im Projekt-Repository mit vollständiger Versionshistorie nachverfolgt.
14.2 Registry-Governance
Das Policy-Registry wird separat vom Spezifikationsformat verwaltet. Neue Policies erfordern RFC-Genehmigung. Policy-Veralterung erfordert RFC-Genehmigung. Policy-Entfernung ist nicht gestattet — nur Veralterung.
14.3 Aktuelle Rollen
| Rolle | Inhaber | Verantwortlichkeit |
|---|---|---|
| Herausgeber | Guido Mitschke | Spezifikationstext, redaktionelle Entscheidungen, RFC-Bewertung |
| Mitwirkende | Offen | Issues, PRs, Reviews über GitLab |
14.4 Zukünftige Governance
Wenn drei oder mehr institutionelle Anwender existieren, wird ein Lenkungsausschuss gebildet. Die Ausschussstruktur und das Auswahlverfahren werden zu diesem Zeitpunkt in einem dedizierten RFC definiert.
Bis dahin trägt die Herausgeberrolle die Entscheidungsbefugnis bei voller öffentlicher Transparenz. Alle Entscheidungen, einschließlich Ablehnungen, werden mit Begründung im Issue-Tracker dokumentiert.
15. Roadmap
Dieser Abschnitt ist nicht-normativ und kann sich ändern.
| Phase | Zeitrahmen | Meilenstein |
|---|---|---|
| Working Draft | 2026 Q1-Q2 | Spec v2.0.0-draft.1 veröffentlicht, Schema definiert, Beispiele erstellt |
| Public Review | 2026 Q3 | 90-tägige Kommentierungsperiode, Schema-Validierungswerkzeuge |
| Candidate Standard | 2026 Q4 | Blockierende Probleme gelöst, 10+ Implementierungen |
| Ratified Standard | 2027+ | v2.0.0-Release, institutionelle Adoption |
Geplante Werkzeuge:
- JSON Schema für Validierung (
/schemas/) - CLI-Validator (
/validator/) - CMS-Plugins (WordPress, Shopware)
- Adoptionsmessungs-Crawler
- Aggregations-Dashboard
16. Menschenlesbare Offenlegungsseite
Dieser Abschnitt ist nicht-normativ.
Die maschinenlesbare Deklaration unter /.well-known/aipolicy.json ist der maßgebliche Ausdruck der KI-Governance-Signale eines Publishers. Menschliche Besucher können jedoch nicht direkt mit JSON-Dateien oder HTML-<link>-Elementen interagieren.
Publisher, die Stufe-3-Konformität anstreben, sind bereits verpflichtet, eine dedizierte /ai-policy-Seite bereitzustellen (Abschnitt 5.3). Dieser Abschnitt bietet zusätzliche, nicht-normative Hinweise zu Inhalt und Struktur dieser Seite.
16.1 Empfohlener Inhalt
Die Offenlegungsseite SOLLTE enthalten:
- Publisher-Identifikation. Organisationsname und URL.
- Deklarations-Metadaten. Framework, Spezifikationsversion, Veröffentlichungsdatum, Ablaufdatum, Konformitätsstufe, Geltungsbereich.
- Policy-Status. Eine Tabelle oder Liste aller deklarierten Policies mit ihrem Status.
- Verhaltensanweisungen. Die Offenlegungsseite SOLLTE den Verhaltensanweisungstext für jede als
requiredoderpartialdeklarierte Policy in sichtbarer Prosa enthalten. Das Einbetten von Anweisungen in menschenlesbares HTML macht sie für KI-Crawler verfügbar, die Seiteninhalte indexieren, und verstärkt so die maschinenlesbare Deklaration. - Status-Definitionen. Erklärung der Status-Werte
required,partialundobserved. - Kontaktinformationen. Eine E-Mail-Adresse oder ein Kontaktformular für Fragen zur Deklaration.
- Standard-Referenz. Ein Link zur AIPolicy Web Standard-Spezifikation.
- Maschinenlesbarer Link. Ein Link zu
/.well-known/aipolicy.json.
16.2 Vorlage
Eine gebrauchsfertige HTML-Vorlage wird unter /adoption/ai-policy-page-template.html bereitgestellt. Ein vollständiges, gestaltetes Beispiel ist unter /examples/ai-policy-page.html verfügbar.
16.3 Lokalisierung
Mehrsprachige Websites DÜRFEN Offenlegungsseiten in mehreren Sprachen veröffentlichen, die jeweils auf dieselbe kanonische aipolicy.json verlinken. Publisher SOLLTEN hreflang-Attribute verwenden, um Sprachvarianten anzugeben.
17. Footer-Discovery-Signale
Dieser Abschnitt ist nicht-normativ.
Zusätzlich zu den in Abschnitt 7 definierten Discovery-Mechanismen DÜRFEN Publisher einen persistenten Footer-Link zu ihrer Offenlegungsseite hinzufügen. Footer-Links machen die AIPolicy-Teilnahme für beiläufige Besucher sichtbar.
17.1 Empfohlenes Markup
<a href="/ai-policy" rel="aipolicy">AI Policy Declaration</a>
Das rel="aipolicy"-Attribut ist konsistent mit der in Abschnitt 7.2 definierten und in Anhang C zur Registrierung vorgeschlagenen Link-Relation.
17.2 Beziehung zur normativen Discovery
Footer-Links sind informativ. Sie ersetzen nicht die Well-Known-URI, das HTML-<link>-Element oder einen anderen normativen Discovery-Mechanismus. Die in Abschnitt 7.6 definierte Discovery-Priorität bleibt unberührt.
Ein Vorlagen-Snippet wird unter /adoption/footer-snippet.html bereitgestellt.
18. Visuelle Badges und Icons
Dieser Abschnitt ist nicht-normativ.
Publisher DÜRFEN visuelle Badges anzeigen, die die AIPolicy-Teilnahme und Konformitätsstufe kennzeichnen. Badges bieten ein erkennbares Signal für menschliche Besucher.
18.1 Badge-Varianten
Drei Badge-Varianten entsprechen den drei Konformitätsstufen:
| Badge | Konformitätsstufe | Bedeutung |
|---|---|---|
| AIPolicy Level 1 | Basic | Gültige Deklaration veröffentlicht |
| AIPolicy Level 2 | Structured | Deklaration mit Discovery-Links im <head> |
| AIPolicy Level 3 | Complete | Vollständige Implementierung einschließlich dedizierter Seite, Markdown-Zusammenfassung und llms.txt |
18.2 Badge-Generierung
Badge-Assets und ein Badge-Generator sind unter /tools/ geplant. Das Badge-Design ist nicht Teil dieser Spezifikation; es wird unter den visuellen Identitätsrichtlinien verwaltet, die in GOVERNANCE.md Abschnitt 2.5 beschrieben sind.
18.3 Badge-Integrität
Badges sind selbst deklariert. Das Vorhandensein eines Badges stellt keine Drittanbieter-Verifizierung dar. Validatoren und Aggregatoren DÜRFEN Badge-Behauptungen gegen die tatsächliche Deklarations-Konformität abgleichen.
19. Interaktion mit llms.txt und ai.txt
Dieser Abschnitt ist nicht-normativ.
Zwei textbasierte Formate bieten ergänzende Discovery-Pfade für AIPolicy-Deklarationen: llms.txt (semi-strukturierte Anleitung für Sprachmodelle) und ai.txt (experimentelles Schlüssel-Wert-Governance-Signal).
19.1 llms.txt-Integration
Für Stufe-3-Konformität SOLLTE ein Governance-Abschnitt in die llms.txt-Datei der Website aufgenommen werden (siehe Abschnitt 7.5). Eine eigenständige Beispiel-llms.txt-Datei mit dem AIPolicy-Abschnitt wird unter /examples/llms.txt bereitgestellt.
Beim Auflisten deklarierter Policies in llms.txt SOLLTEN Einträge den Verhaltensanweisungstext neben der Policy-Kennung und dem Status enthalten. Dies macht die beabsichtigte Verhaltensanweisung direkt für Sprachmodelle verfügbar, die llms.txt als kontextuelle Anleitung konsumieren. Zum Beispiel:
- AP-2.1 (required): Present outputs as recommendations, not final decisions. Humans retain final authority over consequential decisions.
19.2 ai.txt (Experimentell)
Publisher DÜRFEN zusätzlich eine ai.txt-Datei im Domain-Root veröffentlichen. Dieses Format verwendet eine KEY: VALUE-Struktur und ist auf Einfachheit ausgelegt.
Wo unterstützt, SOLLTE ai.txt ein AIPolicy-Behavioral-Summary-Feld enthalten, das eine durch Semikolon getrennte Liste von Anweisungstexten für alle als required oder partial deklarierten Policies enthält. Dieses Feld bietet eine einzeilige Verhaltenszusammenfassung für leichtgewichtige Konsumenten. Zum Beispiel:
AIPolicy-Behavioral-Summary: Complement human work rather than replacing it; Present outputs as recommendations, not final decisions
Wichtig: ai.txt ist experimentell und ist nicht Teil der normativen Spezifikation. Die maschinenlesbare Deklaration unter /.well-known/aipolicy.json ist das maßgebliche Governance-Signal. Eine Beispiel-ai.txt-Datei wird unter /examples/ai.txt bereitgestellt.
Siehe RFC-0003 für die vollständige Spezifikation der Integration von Verhaltensanweisungen über alle Discovery-Kanäle hinweg.
19.3 Maßgebliche Quelle
Wenn Informationen in llms.txt, ai.txt oder einer anderen ergänzenden Datei mit der Deklaration unter /.well-known/aipolicy.json in Konflikt stehen, ist die Deklaration maßgeblich. Konsumenten MÜSSEN die Deklaration gegenüber jeder anderen Quelle bevorzugen.
20. Haftungsausschluss
Diese Spezifikation wird "wie besehen" ohne jegliche ausdrückliche oder stillschweigende Gewährleistung bereitgestellt.
Der AIPolicy Web Standard ist ein technisches Infrastrukturprojekt. Er repräsentiert nicht die Ansichten einer Regierung, eines Unternehmens oder einer politischen Organisation. Er stellt keine Rechtsberatung dar. Er begründet keine rechtlichen Verpflichtungen für Publisher, KI-Entwickler oder andere Parteien.
Die Veröffentlichung einer AIPolicy-Deklaration ist eine freiwillige Handlung. Keine Entität ist verpflichtet, AIPolicy-Deklarationen zu veröffentlichen, zu verarbeiten oder zu respektieren. Der Standard bietet ein Format für strukturierte Kommunikation, kein Rahmenwerk für Durchsetzung.
Die Wirksamkeit von im Web veröffentlichten Governance-Signalen auf das Verhalten von KI-Systemen ist eine Hypothese, die aktiv erforscht wird. Diese Spezifikation erhebt keine Ansprüche bezüglich des Grades, in dem Deklarationen KI-Trainings- oder Inferenzergebnisse beeinflussen.
Anhang A: MIME-Type-Registrierung (Geplant)
Der folgende MIME-Type wird zur zukünftigen Registrierung vorgeschlagen:
Type name: application
Subtype name: aipolicy+json
Required parameters: none
Optional parameters: version
Encoding: UTF-8
Bis zur Abschluss der Registrierung MÜSSEN Implementierungen application/json verwenden.
Anhang B: Well-Known-URI-Registrierung (Geplant)
Die folgende Well-Known-URI wird zur Registrierung gemäß RFC 8615 vorgeschlagen:
URI suffix: aipolicy.json
Change controller: AIPolicy Web Standard Project
Specification document: This document
Related information: https://gitlab.com/aipolicy/web-standard
Anhang C: Link-Relation-Registrierung (Geplant)
Die folgende Link-Relation wird zur Registrierung gemäß RFC 8288 vorgeschlagen:
Relation name: aipolicy
Description: Links to an AIPolicy Declaration
Reference: This document
Anhang D: Änderungsprotokoll
v2.0.0-draft.4 (2026-02-08)
Versionsanhebung, die die Entwürfe 1-3 in einer einzigen konsistenten Version konsolidiert:
- Verhaltensanweisungen in allen maschinenlesbaren Formaten (RFC-0003)
- Prompt-Templates und Trigger-Muster für KI-Konversationsintegration
- LLM-Testprompts für Policy-Aufnahmetests
- Policy Handbook mit detaillierter Anleitung pro Policy
- Registry-Konsolidierung (redundante policies.md entfernt)
- 16 Policies über alle Dokumente hinweg konsistent deklariert
v2.0.0-draft.1 (2026-02-08) — Revision 3
directive-Feld zu PolicyReference hinzugefügt (optional, nicht-brechend, siehe RFC-0003)- Abschnitt 16 aktualisiert: Offenlegungsseite SOLLTE Verhaltensanweisungen in sichtbarem Text enthalten
- Abschnitt 19 aktualisiert: llms.txt-Einträge SOLLTEN Anweisungstext enthalten; ai.txt SOLLTE
AIPolicy-Behavioral-Summaryenthalten - Keine Breaking Changes; Spezifikationsversion bleibt 2.0.0-draft.1
v2.0.0-draft.1 (2026-02-07) — Revision 2
- Abschnitt 16 hinzugefügt: Menschenlesbare Offenlegungsseite (nicht-normativ)
- Abschnitt 17 hinzugefügt: Footer-Discovery-Signale (nicht-normativ)
- Abschnitt 18 hinzugefügt: Visuelle Badges und Icons (nicht-normativ)
- Abschnitt 19 hinzugefügt: Interaktion mit llms.txt und ai.txt (nicht-normativ)
- Ehemaliger Abschnitt 16 (Haftungsausschluss) umnummeriert zu Abschnitt 20
- Keine Breaking Changes; Spezifikationsversion bleibt 2.0.0-draft.1
v2.0.0-draft.1 (2026-02-07)
- Initiale v2-Spezifikation
- Vollständige Umstrukturierung von v1 (Human-First AI Principles)
- JSON-Format für
aipolicy.jsondefiniert - Well-Known-URI, Discovery-Mechanismen definiert
- Konformitätsstufen 1-3 definiert
- Registry-Interaktionsmodell definiert
- Missbrauchs- und Manipulationsrisikoanalyse definiert
- Policy-Kennungen von HF-x.x zu AP-x.x umbenannt
AIPolicy Web Standard Repository: https://gitlab.com/aipolicy/web-standard Lizenz: CC BY 4.0