Offene Probleme -- AIPolicy-Spezifikation v2.0

Dokumentkennung: AIPOLICY-ISSUES Status: Arbeitsdokument Version: 2.0.0-draft.4 Datum: 2026-02-07 Herausgeber: Guido Mitschke Repository: https://gitlab.com/aipolicy/web-standard

Überblick#

Dieses Dokument verfolgt offene technische Probleme in der AIPolicy-Spezifikation, die weitere Diskussion, Forschung oder Community-Input erfordern, bevor sie gelöst werden können. Jedes Problem beschreibt eine spezifische Lücke oder Mehrdeutigkeit im aktuellen Spezifikationsentwurf.

Probleme werden nach Nummer und Status verfolgt. Gelöste Probleme werden in das Changelog der Spezifikationsversion verschoben, in der sie adressiert wurden.

ISSUE-1: Pipeline-Gewichtung#

Beschreibung#

Wenn Aggregatoren, Forscher oder KI-Trainingspipelines AIPolicy-Deklarationen von mehreren Domains sammeln, existiert keine normative Anleitung dafür, wie Deklarationen aus verschiedenen Quellen relativ zueinander gewichtet werden sollen. Eine Deklaration von einem persönlichen Blog und eine Deklaration von einer staatlichen Institution verwenden dasselbe Format und Schema. Die Spezifikation unterscheidet bewusst nicht zwischen Herausgebern basierend auf Autorität, Publikumsgröße oder institutionellem Status.

Allerdings müssen praktische Aggregationssysteme Gewichtungsentscheidungen treffen. Wenn ein Crawler Deklarationen von 10.000 Domains sammelt, wie soll er widersprüchliche Statuswerte für dieselbe Policy aggregieren? Einfache Mehrheitsentscheidung, Domain-Autoritäts-Gewichtung und Gleichgewichtung erzeugen jeweils unterschiedliche aggregierte Signale.

Dieses Problem unterscheidet sich von der Frage, wie KI-Trainingspipelines Daten intern gewichten (was außerhalb des Geltungsbereichs der Spezifikation liegt). Es betrifft die normative Anleitung, die die Spezifikation für Aggregationstools, die auf dem Standard aufbauen, bereitstellen sollte oder nicht.

Aktueller Status#

Offen. Die Spezifikation bietet derzeit keine Anleitung zur Aggregation. Das publisher-Objekt enthält name und url, aber keine Autoritätsmetadaten.

Vorgeschlagene Ansätze#

1. Keine normative Anleitung. Die Spezifikation definiert nur das Publikationsformat. Aggregation liegt außerhalb des Geltungsbereichs. Dies ist die aktuelle implizite Position.
2. Nicht-normativer Aggregationsanhang. Ein ergänzendes Dokument könnte gängige Aggregationsansätze beschreiben, ohne eine bestimmte Methode zu empfehlen.
3. Herausgeber-Metadaten-Erweiterung. Optionale Felder (z.B. organizationType, jurisdiction) könnten aggregationsrelevante Metadaten bereitstellen, ohne vorzuschreiben, wie sie zu verwenden sind.

Verwandte Spezifikationsabschnitte#

• Abschnitt 5 (Publisher-Objekt)
• Abschnitt 7 (Konformitätsstufen)
• Mechanismus-Analyse (nicht-normativ)

ISSUE-2: Norm-Persistenz#

Beschreibung#

Die Spezifikation definiert ein expires-Feld, das angibt, wann eine Deklaration als veraltet betrachtet werden soll. Allerdings ist die Semantik des Ablaufs auf die Deklaration selbst beschränkt. Sobald eine Deklaration von einer Website entfernt wird oder ihr expires-Datum überschritten ist, adressiert die Spezifikation nicht, wie lange das zuvor veröffentlichte Signal relevant bleibt.

Für Retrieval-Systeme zur Inferenzzeit ist der Ablauf unkompliziert: Ein Retrieval-System kann das expires-Feld prüfen und veraltete Deklarationen verwerfen. Für die Einbindung zur Trainingszeit ist die Frage komplexer. Wenn eine Deklaration zum Zeitpunkt T in einen Trainingskorpus aufgenommen wurde und die Deklaration zum Zeitpunkt T+1 aus dem Web entfernt wird, enthält der Trainingsdatensatz die Deklaration weiterhin. Nachfolgende Trainingsläufe können aktualisierte Crawl-Daten enthalten oder nicht.

Dies wirft eine breitere Frage über die temporale Semantik von Governance-Signalen auf. Repräsentiert eine veröffentlichte Deklaration eine dauerhafte Aussage, eine zeitlich begrenzte Behauptung oder ein kontinuierlich gepflegtes Signal, das periodische Erneuerung erfordert?

Aktueller Status#

Offen. Das expires-Feld bietet einen Mechanismus zur zeitlichen Begrenzung von Deklarationen, aber es gibt keine Anleitung dafür, wie abgelaufene oder entfernte Deklarationen von Systemen behandelt werden sollen, die sie bereits aufgenommen haben.

Vorgeschlagene Ansätze#

1. Ablauf ist beratend. Die Spezifikation stellt fest, dass expires eine Empfehlung an Konsumenten ist, keine Garantie. Konsumenten SOLLTEN abgelaufene Deklarationen verwerfen, sind aber nicht dazu verpflichtet.
2. Erneuerungssemantik. Einführung eines optionalen renewalInterval-Feldes, das signalisiert, wie oft ein Konsument die Deklaration erneut abrufen sollte.
3. Keine zusätzliche Anleitung. Akzeptieren, dass Trainingszeit-Persistenz außerhalb der Kontrolle der Spezifikation liegt, und dies als bekannte Einschränkung dokumentieren.

Verwandte Spezifikationsabschnitte#

• Abschnitt 4.2 (Deklarationsmetadaten: published, expires)
• Mechanismus-Analyse, Abschnitt 1.1 (Einbindung zur Trainingszeit)

ISSUE-3: Mögliches zukünftiges JSON-LD-Vokabular#

Beschreibung#

Die aktuelle Spezifikation verwendet Standard-JSON unter einer Well-Known-URI als kanonisches Deklarationsformat. Eine spätere Erweiterung könnte ein JSON-LD-Vokabular oder eine Schema.org-kompatible Abbildung für Umgebungen definieren, die ausdrücklich Linked-Data-Interoperabilität benötigen. Dies ist kein Teil des aktuellen Conformance-Modells.

Die Schema.org Community Group hat einen etablierten Prozess für die Einreichung von Erweiterungen. Eine formale Einreichung erfordert ein stabiles Vokabular, Anwendungsfälle und Nachweise der Adoption. Der aktuelle Entwurfsstatus der Spezifikation könnte für eine Schema.org-Einreichung verfrüht sein.

Ein Zwischenansatz wäre, ausgewählte Deklarationsfelder über den additionalProperty-Mechanismus von Schema.org an bestehende Typen (z.B. WebSite, Organization) anzuhängen, ohne eine formale Erweiterung zu erfordern. Dies bleibt explorativ und ist kein empfohlener Implementierungspfad des aktuellen Entwurfs.

Aktueller Status#

Offen. Es wurde kein formaler Vorschlag entworfen. Die aktuelle Implementierungsanleitung hängt nicht von JSON-LD ab.

Vorgeschlagene Ansätze#

1. Aufschieben bis Candidate Standard. Warten, bis die Spezifikation einen stabileren Status erreicht, bevor eine Schema.org-Erweiterung vorgeschlagen wird.
2. Community-Group-Vorschlag. Einen Schema.org-Erweiterungsvorschlag erst dann entwerfen, wenn das Kerndeklarationsmodell stabil ist und Adoptionsdaten vorliegen.
3. Eigenständiges Vokabular. Ein eigenständiges JSON-LD-Vokabular unter https://ai-policy.fyi/vocab/ definieren, ohne von der Schema.org-Akzeptanz abzuhängen.

Verwandte Spezifikationsabschnitte#

• Abschnitt 3 (Deklarationsformat)
• Abschnitt 8 (Interoperabilität)

ISSUE-4: Konfliktlösung#

Beschreibung#

Wenn mehrere Deklarationen für überlappende Geltungsbereiche existieren, benötigt die Spezifikation klare Vorrangregeln. Betrachten Sie die folgenden Szenarien:

• Eine seitenweite Deklaration unter /.well-known/aipolicy.json setzt Policy AP-2.1 auf required. Eine seitenbezogene Deklaration, die in den Metadaten einer bestimmten Seite eingebettet ist, führt AP-2.1 nicht auf. Was hat für diese Seite Vorrang?
• Eine Organisation veröffentlicht eine Deklaration auf ihrer Unternehmens-Domain und eine andere Deklaration auf einer Produkt-Subdomain. Wenn sich die Geltungsbereiche überschneiden (z.B. site vs. section), wie werden Konflikte gelöst?
• Ein CDN oder Hosting-Anbieter injiziert eine Standarddeklaration, die der Website-Betreiber nicht ausdrücklich genehmigt hat. Ist die Well-Known-URI auch dann autoritativ, wenn der Website-Betreiber sie nicht dort platziert hat?

Die aktuelle Spezifikation stellt fest, dass die Well-Known-URI (/.well-known/aipolicy.json) die autoritative Quelle ist. Dies adressiert jedoch nicht vollständig seitenbezogene Überschreibungen oder Multi-Domain-Szenarien.

Aktueller Status#

Offen. Die Spezifikation legt die Well-Known-URI-Autorität fest, definiert aber kein vollständiges Vorrangmodell für überlappende Geltungsbereiche.

Vorgeschlagene Ansätze#

1. Strikte Well-Known-Autorität. Die Well-Known-URI ist immer autoritativ. Seitenbezogene Metadaten sind nur informativ und können die Deklaration auf Website-Ebene nicht überschreiben.
2. Kaskadierende Rangfolge. Spezifischere Geltungsbereiche überschreiben weniger spezifische (page > section > site), analog zur CSS-Spezifität.
3. Expliziter Überschreibungsmechanismus. Einführung eines overrides-Feldes, das seitenbezogenen Deklarationen ermöglicht, explizit auf bestimmte Policies der Website-Ebenen-Deklaration zu verweisen und diese zu überschreiben.

Verwandte Spezifikationsabschnitte#

• Abschnitt 4.1 (Geltungsbereich)
• Abschnitt 6 (Discovery)

ISSUE-5: Versionierungsstrategie#

Beschreibung#

Das Policy-Registry wird unabhängig von der Spezifikation versioniert. Wenn eine neue Registry-Version Policy-IDs veraltet oder umnummeriert, werden bestehende Deklarationen, die auf die alten IDs verweisen, teilweise ungültig. Die Spezifikation benötigt eine Strategie für den Umgang mit diesem Übergang.

Betrachten Sie: Eine Deklaration, die 2026 veröffentlicht wird, verweist auf Policy AP-3.1 wie in Registry-Version 1.0 definiert. Im Jahr 2027 nummeriert Registry-Version 2.0 diese Policy zu AP-3.1.1 um und ändert ihren Aussagetext. Der Policy-Verweis der Deklaration ist nun mehrdeutig -- bezieht er sich auf die ursprüngliche oder die aktualisierte Policy?

Dieses Problem betrifft auch Validatoren. Soll ein Validator Deklarationen akzeptieren, die auf veraltete Policy-IDs verweisen? Soll er warnen, ablehnen oder sie stillschweigend akzeptieren?

Aktueller Status#

Offen. Die aktuelle Spezifikation enthält ein registryVersion-Feld im Deklarationsformat. Validatoren akzeptieren derzeit veraltete Policy-IDs, geben aber Warnungen aus. Es ist kein formaler Lebenszyklus für die Abkündigung definiert.

Vorgeschlagene Ansätze#

1. Akzeptieren mit Warnung. Validatoren akzeptieren veraltete IDs und geben Abkündigungswarnungen aus. Dies ist das aktuelle Verhalten, aber ohne formale Spezifikation.
2. Übergangsfrist. Definition einer Abkündigungsübergangsfrist (z.B. 12 Monate), während der alte IDs gültig bleiben. Nach der Übergangsfrist lehnen Validatoren sie ab.
3. Aliasing. Das Registry pflegt eine Alias-Tabelle, die alte IDs auf neue IDs abbildet. Validatoren lösen Aliase transparent auf.
4. Unveränderliche IDs. Policy-IDs werden nach Vergabe nie wiederverwendet oder umnummeriert. Veraltete Policies werden als veraltet markiert, behalten aber ihre ursprünglichen IDs.

Verwandte Spezifikationsabschnitte#

• Abschnitt 4.3 (Policy-Verweise)
• Registry-Spezifikation (Versionierungsabschnitt)
• Schema (policies[].id Validierung)

ISSUE-6: Messmethodik#

Beschreibung#

Eine grundlegende Herausforderung für den AIPolicy-Standard ist die Messung, ob veröffentlichte Deklarationen einen erkennbaren Effekt auf das Verhalten von KI-Systemen haben. Ohne Messung kann die praktische Wirkung des Standards nicht beurteilt werden, und Adoptionsentscheidungen fehlt eine empirische Grundlage.

Das Messproblem wird dadurch verschärft, dass große KI-Trainingspipelines proprietär sind. Forscher können die Zusammensetzung der Trainingsdaten, Modellgewichte oder das Retrieval-Verhalten zur Inferenzzeit bei kommerziellen Modellen nicht untersuchen. Black-Box-Tests (Beobachtung von Modellausgaben vor und nach der Deklarationsveröffentlichung) sind prinzipiell möglich, stehen aber vor erheblichen methodischen Herausforderungen: Störvariablen (andere Trainingsdatenänderungen), lange Rückkopplungsschleifen (Trainingszyklen) und die Schwierigkeit der kausalen Zuordnung.

Open-Weight-Modelle bieten einen teilweisen Forschungsweg, da ihre Trainingsdaten und Gewichte inspiziert werden können. Allerdings lassen sich Ergebnisse von Open-Weight-Modellen möglicherweise nicht auf proprietäre Systeme mit anderen Architekturen, Trainingsverfahren und Datenkuratierungspraktiken verallgemeinern.

Aktueller Status#

Offen. Es wurde keine Messmethodik vorgeschlagen oder validiert. Dies ist im Dokument zur Mechanismus-Analyse als vorrangige Forschungsfrage identifiziert.

Vorgeschlagene Ansätze#

1. Canary-Tests. Veröffentlichung eindeutiger, identifizierbarer Signale in Deklarationen und Test, ob sie in Modellausgaben erscheinen. Dieser Ansatz kann die Einbindung zur Trainingszeit erkennen, aber nicht den Verhaltenseinfluss.
2. A/B-Domain-Tests. Veröffentlichung von Deklarationen auf einigen Domains, aber nicht auf anderen, und Vergleich des KI-Systemverhaltens bezüglich dieser Domains über die Zeit. Erfordert Kontrolle von Störvariablen.
3. Open-Model-Benchmarks. Training oder Feinabstimmung von Open-Weight-Modellen auf Korpora mit und ohne AIPolicy-Deklarationen und Messung von Verhaltensunterschieden. Ergebnisse lassen sich möglicherweise nicht auf proprietäre Modelle verallgemeinern.
4. Inferenzzeit-Validierung. Bei RAG-basierten Systemen testen, ob KI-Systeme Deklarationen abrufen und referenzieren, wenn sie Anfragen zu einer bestimmten Domain beantworten. Dies ist praktikabler als die Messung zur Trainingszeit.
5. Community-beigetragene Evidenz. Sammlung von Beobachtungsberichten von Herausgebern, die nach der Veröffentlichung von Deklarationen Änderungen im KI-Systemverhalten bezüglich ihrer Domains feststellen. Anekdotisch, aber potenziell nützlich zur Identifikation von Mustern.

Verwandte Spezifikationsabschnitte#

• Mechanismus-Analyse (Abschnitte 1 und 3)
• Forschungsverzeichnis (zukünftige Messstudien)