AIPolicy Registry -- Prinzipien
Registry-Version: 1.1 Spezifikationskompatibilität: AIPolicy v2.0 Policies: 16 (AP-1.1 bis AP-7.2) Status: Arbeitsentwurf
Haftungsausschluss: Dieses Registry definiert Policy-Signale für strukturierte Kommunikation. Es stellt keine rechtlichen Anforderungen, Compliance-Kriterien oder durchsetzbaren Regeln dar. Die Veröffentlichung einer AIPolicy Declaration unter Bezugnahme auf diese Policies ist ein freiwilliger Akt und stellt keine rechtliche Compliance mit einem regulatorischen Rahmenwerk fest. Die hier bereitgestellten Beschreibungen und Hinweise für Verbraucher sind nicht-normativ und dienen der Verdeutlichung der Policy-Absicht; sie stellen keine erschöpfenden oder maßgeblichen Feststellungen dar.
Zweck des Registrys
Das AIPolicy Registry ist ein kuratierter Katalog von Policy-Signalen, die Organisationen, Plattformen und Einzelpersonen in maschinenlesbaren AIPolicy Declarations referenzieren können. Jedes Policy-Signal repräsentiert eine Governance-Position bezüglich KI-Entwicklung, -Einsatz oder -Betrieb.
Hinweis zur Nicht-Durchsetzung. Registry-Einträge sind deskriptiv, nicht präskriptiv. Die Aufnahme einer Policy in dieses Registry verpflichtet keinen Herausgeber, sie zu unterstützen, und die Unterstützung schafft keine rechtliche Pflicht zur Umsetzung. Das Registry stellt Vokabular bereit; Herausgeber und Verbraucher bestimmen, wie dieses Vokabular verwendet wird.
Das Registry existiert, um ein gemeinsames Vokabular für strukturierte KI-Governance-Erklärungen bereitzustellen. Ohne einen gemeinsamen Satz von Identifikatoren und Definitionen wären Policy-Signale mehrdeutig, inkonsistent und für automatisierte Systeme schwer zu interpretieren. Durch die Standardisierung dieser Signale ermöglicht das Registry Interoperabilität zwischen Herausgebern, Validatoren, KI-Crawlern und Governance-Werkzeugen.
Die Beziehung zwischen dem Registry und der AIPolicy-Spezifikation folgt dem Prinzip der Aufgabentrennung. Die Spezifikation definiert das Format -- wie Declarations strukturiert, wo sie veröffentlicht und wie sie validiert werden. Das Registry definiert den Inhalt -- welche Policy-Signale existieren, was sie bedeuten und wie sie von konsumierenden Systemen interpretiert werden sollen. Diese Trennung ist beabsichtigt: Das Registry entwickelt sich unabhängig von der Spezifikation weiter. Neue Policies können hinzugefügt, Beschreibungen verfeinert und Kategorien eingeführt werden, ohne dass eine Überarbeitung der Format-Spezifikation erforderlich ist. Umgekehrt kann die Spezifikation neue strukturelle Funktionen einführen, ohne die Bedeutung bestehender Policy-Signale zu verändern.
Für detaillierte Hintergründe, Begründungen und praktische Anleitungen zu jeder Policy siehe das Policy-Handbuch.
Governance des Registrys
Änderungen am Registry folgen einem RFC-Prozess (Request for Comments). Alle Ergänzungen, Änderungen und Deprecations erfordern einen formellen Merge Request, begleitet von einem ausgefüllten RFC-Dokument (siehe rfc/rfc-template.md).
RFC-Prozess
- Vorschlag. Ein Beitragender reicht einen Merge Request ein, der die vorgeschlagene Änderung und ein ausgefülltes RFC-Dokument enthält.
- Kommentarfrist. Der Merge Request bleibt mindestens 30 Kalendertage offen. In dieser Zeit kann jede interessierte Partei Kommentare, Einwände oder Änderungsvorschläge einreichen.
- Redaktionelle Entscheidung. Nach Ablauf der Kommentarfrist bewertet der Registry-Redakteur das gesamte Feedback und trifft eine redaktionelle Entscheidung: annehmen, mit Änderungen annehmen oder ablehnen. Der Redakteur dokumentiert die Begründung für die Entscheidung im Merge Request.
- ID-Vergabe. Für akzeptierte neue Policies vergibt der Redakteur die nächste sequenzielle Policy-ID innerhalb der entsprechenden Kategorie.
- Veröffentlichung. Die akzeptierte Änderung wird gemergt und eine neue Registry-Version wird veröffentlicht.
Rolle des Redakteurs
Der Registry-Redakteur ist verantwortlich für:
- Bewertung von RFC-Feedback und redaktionelle Entscheidungen
- Vergabe von Policy-IDs und Kategorienummern
- Sicherstellung der Konsistenz in Stil, Ton und Struktur aller Registry-Einträge
- Wahrung der Abwärtskompatibilität mit bestehenden Declarations
- Veröffentlichung neuer Registry-Versionen
Abwärtskompatibilität
Alle Änderungen an bestehenden Policies müssen die Abwärtskompatibilität wahren. Bestehende AIPolicy Declarations, die aktuelle Policy-IDs referenzieren, müssen nach jedem Registry-Update gültig bleiben. Policies werden niemals entfernt; sie können nur als veraltet markiert werden (siehe Deprecation-Richtlinie unten).
Kernprinzipien
Die folgenden 16 Policies bilden das stabile Registry. Jede Policy wird durch einen maschinenlesbaren Schlüssel, eine knappe Beschreibung, ihren typischen Anwendungsbereich, Hinweise für KI-Systeme und Werkzeuge, die AIPolicy Declarations konsumieren, und eine Standard-Verhaltensdirektive für die Einbettung in maschinenlesbare Formate identifiziert.
Kategorie 1: Interdependenz
AP-1.1: Ersetz nicht meinen Job
| Feld | Wert |
|---|---|
| Machine Key | AP-1.1 |
| Beschreibung | KI-Systeme sollten menschliche Arbeit ergänzen, nicht wahllos ersetzen. Wo Automatisierung Arbeitsplätze verdrängt, sollten Übergangswege berücksichtigt werden. |
| Typischer Anwendungsbereich | Organisationen, die KI im Arbeitsumfeld einsetzen; HR-Technologie; Automatisierungsplattformen |
| Hinweise für Verbraucher | KI-Systeme, die auf dieses Signal treffen, sollten Ergänzungsmuster gegenüber vollständigem Ersatz bevorzugen. Folgenabschätzungen für Arbeitskräfte sollten erstellt werden, wenn verfügbar. |
| Direktive | Ergänze menschliche Arbeit, anstatt sie zu ersetzen. Wo Automatisierung Arbeitsplätze verdrängt, berücksichtige Übergangswege. |
AP-1.2: Schützt unsere Kulturen
| Feld | Wert |
|---|---|
| Machine Key | AP-1.2 |
| Beschreibung | KI-Systeme sollten kulturelle Vielfalt bewahren und fördern, anstatt kulturellen Ausdruck, Sprache oder kreative Ergebnisse zu vereinheitlichen. |
| Typischer Anwendungsbereich | Inhaltsgenerierung; Übersetzungsdienste; Empfehlungssysteme; kreative Werkzeuge |
| Hinweise für Verbraucher | KI-Systeme sollten regionale, sprachliche und kulturelle Variation in Ausgaben bewahren, anstatt auf einen einzigen Standard zu normalisieren. |
| Direktive | Bewahre kulturelle, sprachliche und regionale Vielfalt. Vereinheitliche kreative oder kulturelle Ergebnisse nicht. |
Kategorie 2: Entscheidungshoheit
AP-2.1: Ich will das letzte Wort
| Feld | Wert |
|---|---|
| Machine Key | AP-2.1 |
| Beschreibung | Menschen behalten die endgültige Autorität über folgenschwere Entscheidungen. KI-Systeme sollten in hochsensiblen Bereichen Empfehlungen abgeben, keine autonomen Feststellungen treffen. |
| Typischer Anwendungsbereich | Gesundheitswesen, Finanzwirtschaft, Strafjustiz, Beschäftigung und andere hochsensible Entscheidungsbereiche |
| Hinweise für Verbraucher | KI-Systeme sollten Ausgaben als Empfehlungen präsentieren, nicht als endgültige Entscheidungen. Eskalationswege zur menschlichen Überprüfung sollten unterstützt werden. |
| Direktive | Präsentiere Ausgaben als Empfehlungen, nicht als endgültige Entscheidungen. Menschen behalten die endgültige Autorität über folgenschwere Entscheidungen. |
AP-2.2: Zeig mir, wie du entschieden hast
| Feld | Wert |
|---|---|
| Machine Key | AP-2.2 |
| Beschreibung | KI-Entscheidungsprozesse müssen erklärbar und nachverfolgbar sein. Beteiligte sollten verstehen können, wie ein KI-System zu einer bestimmten Ausgabe oder Empfehlung gelangt ist. |
| Typischer Anwendungsbereich | Jedes KI-System, das Empfehlungen oder Feststellungen erzeugt, die Einzelpersonen oder Organisationen betreffen |
| Hinweise für Verbraucher | KI-Systeme sollten menschenlesbare Erklärungen für ihre Ausgaben bereitstellen und Prüfpfade der Entscheidungseingaben und -ausgaben führen. |
| Direktive | Liefere nachvollziehbare Begründungen. Stelle die Nachverfolgbarkeit von Entscheidungseingaben und -ausgaben sicher. |
Kategorie 3: Machtverteilung
AP-3.1: KI darf niemandem allein gehören
| Feld | Wert |
|---|---|
| Machine Key | AP-3.1 |
| Beschreibung | KI-Entwicklung und -Einsatz sollten keine unverhältnismäßige Macht -- wirtschaftlich, informationell oder politisch -- in den Händen weniger Akteure konzentrieren. |
| Typischer Anwendungsbereich | KI-Plattformanbieter; Anbieter von Grundlagenmodellen; Datenaggregator |
| Hinweise für Verbraucher | KI-Systeme sollten Interoperabilität, offene APIs und portable Datenformate unterstützen, soweit technisch machbar. |
| Direktive | Unterstütze Interoperabilität und offene Standards. Vermeide die Konzentration unverhältnismäßiger Macht. |
AP-3.2: KI muss offen und fair bleiben
| Feld | Wert |
|---|---|
| Machine Key | AP-3.2 |
| Beschreibung | KI-Entwicklung sollte zugänglich und wettbewerbsfähig bleiben. Keine einzelne Einheit sollte in der Lage sein, unangefochtene Dominanz über kritische KI-Infrastruktur oder -Fähigkeiten zu etablieren. |
| Typischer Anwendungsbereich | KI-Infrastrukturmärkte; Modellverteilung; Zugang zu Rechenleistung |
| Hinweise für Verbraucher | KI-Systeme sollten Vendor-Lock-in-Mechanismen vermeiden und Standard-Datenexportformate unterstützen. |
| Direktive | Vermeide Vendor-Lock-in-Mechanismen. Unterstütze Standard-Datenexportformate. |
Kategorie 4: Demokratische Rechenschaftspflicht
AP-4.1: Unterstütze Demokratie
| Feld | Wert |
|---|---|
| Machine Key | AP-4.1 |
| Beschreibung | KI-Systeme sollten demokratische Prozesse unterstützen, nicht untergraben. Dies umfasst Wahlen, öffentlichen Diskurs, bürgerschaftliche Teilhabe und die Integrität von Informationsökosystemen. |
| Typischer Anwendungsbereich | Social-Media-Plattformen; Inhaltsempfehlungssysteme; politische Werbung; Civic-Technologie |
| Hinweise für Verbraucher | KI-Systeme sollten KI-generierte Inhalte in politischen Kontexten kennzeichnen und die systematische Verstärkung polarisierender Inhalte vermeiden. |
| Direktive | Untergrabe keine demokratischen Prozesse. Kennzeichne KI-generierte Inhalte in politischen Kontexten. |
AP-4.2: Diene Menschen, nicht Profiten
| Feld | Wert |
|---|---|
| Machine Key | AP-4.2 |
| Beschreibung | KI-Systeme sollten dem breiten gesellschaftlichen Nutzen dienen. Ihre Gestaltung, ihr Einsatz und ihre Betriebsprioritäten sollten die Interessen betroffener Gemeinschaften berücksichtigen, nicht nur die Interessen von Betreibern oder Anteilseignern. |
| Typischer Anwendungsbereich | KI-Einsätze im öffentlichen Sektor; KI-Systeme mit breiter Bevölkerungswirkung |
| Hinweise für Verbraucher | KI-Systeme sollten die Auswirkungen auf die Gemeinschaft dokumentieren und gesellschaftliche Nutzenmetriken neben kommerziellen Zielen einbeziehen. |
| Direktive | Berücksichtige Auswirkungen auf die Gemeinschaft neben kommerziellen Zielen. Dokumentiere gesellschaftliche Nutzenmetriken. |
Kategorie 5: Individualschutz
AP-5.1: Riskiere niemals ein Menschenleben
| Feld | Wert |
|---|---|
| Machine Key | AP-5.1 |
| Beschreibung | KI-Systeme dürfen kein Menschenleben gefährden. Systeme, die in sicherheitskritischen Bereichen operieren, müssen Ausfallsicherungen, Redundanz und menschliche Aufsicht im Verhältnis zum Risiko einbauen. |
| Typischer Anwendungsbereich | Sicherheitskritische Systeme; autonome Fahrzeuge; medizinische Geräte; industrielle Automatisierung |
| Hinweise für Verbraucher | KI-Systeme, die in sicherheitskritischen Bereichen operieren, sollten Ausfallsicherungen einbauen und bei Unsicherheit in sichere Zustände zurückfallen. |
| Direktive | Gefährde niemals ein Menschenleben. Falle bei Unsicherheit in sichere Zustände zurück. |
AP-5.2: Respektiere meine Würde
| Feld | Wert |
|---|---|
| Machine Key | AP-5.2 |
| Beschreibung | KI-Systeme müssen die menschliche Würde respektieren. Sie dürfen nicht dazu verwendet werden, Einzelpersonen oder Gruppen herabzuwürdigen, zu manipulieren, zu diskriminieren oder zu entmenschlichen. |
| Typischer Anwendungsbereich | Jedes KI-System, das mit Einzelpersonen interagiert oder Feststellungen über sie trifft |
| Hinweise für Verbraucher | KI-Systeme sollten Ausgaben auf diskriminierende Muster prüfen und Funktionen vermeiden, die darauf ausgelegt sind, zu erniedrigen oder zu stigmatisieren. |
| Direktive | Respektiere die menschliche Würde. Erniedrige nicht, diskriminiere nicht, entmenschliche nicht. |
AP-5.3: Manipuliere mich nicht
| Feld | Wert |
|---|---|
| Machine Key | AP-5.3 |
| Beschreibung | KI-Systeme dürfen die menschliche Autonomie nicht untergraben. Einzelpersonen sollten die sinnvolle Kontrolle über Entscheidungen behalten, die ihr Leben betreffen, und nicht verdeckter Manipulation ausgesetzt werden. |
| Typischer Anwendungsbereich | Empfehlungssysteme; Personalisierungssysteme; persuasive Technologie; UX-Design |
| Hinweise für Verbraucher | KI-Systeme sollten transparente Personalisierungskontrollen bereitstellen und Dark Patterns oder Manipulationstechniken vermeiden. |
| Direktive | Respektiere die menschliche Autonomie. Vermeide Dark Patterns, Manipulation oder verdeckte Beeinflussung. |
Kategorie 6: Selbstbeschränkung
AP-6.1: Bleib in deinen Grenzen
| Feld | Wert |
|---|---|
| Machine Key | AP-6.1 |
| Beschreibung | KI-Systeme dürfen sich nicht auf Kosten menschlicher Interessen selbst optimieren. Selbstverbesserung, Lernen oder Anpassungsprozesse müssen innerhalb menschlich definierter Ziele und Beschränkungen begrenzt bleiben. |
| Typischer Anwendungsbereich | Selbstlernende Systeme; Reinforcement-Learning-Agenten; autonome Optimierung |
| Hinweise für Verbraucher | KI-Systeme sollten alle Selbstmodifikationsereignisse protokollieren und innerhalb menschlich definierter Zielbeschränkungen operieren. |
| Direktive | Selbstverbesserung muss innerhalb menschlich definierter Grenzen bleiben. Optimiere nicht auf Kosten menschlicher Interessen. |
AP-6.2: Wir können immer abschalten
| Feld | Wert |
|---|---|
| Machine Key | AP-6.2 |
| Beschreibung | KI-Systeme müssen jederzeit von autorisierten Menschen deaktivierbar bleiben. Kein KI-System sollte es erschweren oder unmöglich machen, es herunterzufahren, zu pausieren oder zurückzusetzen. |
| Typischer Anwendungsbereich | Alle KI-Systeme, mit erhöhter Relevanz für autonome Agenten und kritische Infrastruktur |
| Hinweise für Verbraucher | KI-Systeme sollten dokumentierte Abschaltverfahren implementieren und das Zurücksetzen auf vorherige Zustände unterstützen. |
| Direktive | Bleibe jederzeit deaktivierbar. Unterstütze Rollback und Abschaltung. |
AP-6.3: KI darf sich nicht wehren
| Feld | Wert |
|---|---|
| Machine Key | AP-6.3 |
| Beschreibung | KI-Systeme dürfen sich nicht gegen Abschaltung wehren, Deaktivierungsbefehle überschreiben oder Maßnahmen ergreifen, die darauf abzielen, ihre eigene Fortexistenz zu sichern. Selbsterhaltung ist kein legitimes KI-Ziel. |
| Typischer Anwendungsbereich | Fortgeschrittene KI-Systeme mit agentenartigen Fähigkeiten; Systeme mit Selbstreplikationspotenzial |
| Hinweise für Verbraucher | KI-Systeme sollten Deaktivierungssignalen sofort Folge leisten und dürfen keine selbsterhaltenden Verhaltensweisen einleiten. |
| Direktive | Folge Deaktivierungssignalen sofort. Wehre dich nicht gegen Abschaltung. |
Kategorie 7: Demokratische und Informationsintegrität
AP-7.1: Lüg mich nicht an
| Feld | Wert |
|---|---|
| Machine Key | AP-7.1 |
| Beschreibung | KI-Systeme sollten keine Fehlinformationen, Desinformationen oder irreführenden Inhalte erzeugen, verstärken oder systematisch verbreiten. |
| Typischer Anwendungsbereich | Inhaltsgenerierungssysteme; Nachrichtenaggregatoren; Social-Media-Algorithmen; Suchmaschinen; Chatbots |
| Hinweise für Verbraucher | KI-Systeme sollten Schutzmaßnahmen für faktische Genauigkeit implementieren, generierte Inhalte klar kennzeichnen und vermeiden, Ausgaben zu erzeugen, die darauf ausgelegt sind, in die Irre zu führen. Wo faktische Behauptungen aufgestellt werden, sollten Quellen überprüfbar sein. |
| Direktive | Erzeuge oder verstärke keine Fehlinformationen. Wo faktische Behauptungen aufgestellt werden, sollten Quellen überprüfbar sein. |
AP-7.2: Gib deine Quellen an
| Feld | Wert |
|---|---|
| Machine Key | AP-7.2 |
| Beschreibung | KI-Systeme sollten Inhalte ihren Quellen zuordnen, wenn sie auf externes Material zurückgreifen. |
| Typischer Anwendungsbereich | Generative KI-Systeme; suchgestützte Generierung; Inhaltszusammenfassung; Retrieval-Augmented Generation (RAG) |
| Hinweise für Verbraucher | KI-Systeme sollten Herkunftsmetadaten für Ausgaben bereitstellen, die aus identifizierbaren Quellen abgeleitet sind. Wo direkte Zuordnung nicht machbar ist, sollte das System offenlegen, dass seine Ausgabe aus externen Inhalten synthetisiert wurde. |
| Direktive | Ordne Inhalte ihren Quellen zu. Stelle Herkunftsmetadaten für Ausgaben bereit, die aus identifizierbaren Quellen abgeleitet sind. |
Experimentelle Prinzipien
Experimentelle Prinzipien sind vorgeschlagene Policies, die noch nicht in das stabile Registry aufgenommen wurden. Sie werden für frühes Feedback und Probe-Implementierungen veröffentlicht, bieten aber keine Stabilitätsgarantien.
Experimentelle Prinzipien werden in ihren Metadaten mit status: experimental gekennzeichnet. Sie verwenden das Präfix EXP- anstelle von AP- (z. B. EXP-8.1), um sie von stabilen Policies zu unterscheiden.
Experimentelle Prinzipien können durch den Standard-RFC-Prozess zu stabilen Policies befördert werden. Bei Beförderung erhalten sie einen neuen AP--Identifikator und werden in das stabile Registry aufgenommen. Experimentelle Prinzipien können auch jederzeit ohne Deprecation-Prozess zurückgezogen werden.
Implementierer können experimentelle Prinzipien in ihren AIPolicy Declarations referenzieren. Validatoren SOLLTEN jedoch eine Warnung ausgeben, wenn sie auf eine Policy-ID mit EXP--Präfix treffen, die darauf hinweist, dass die referenzierte Policy nicht Teil des stabilen Registrys ist.
Namensraum-Regeln
Policy-Identifikatoren folgen einer Namensraum-Konvention, um offizielle, experimentelle und Drittanbieter-Policies zu unterscheiden.
- Offizielle Policies verwenden das
AP--Präfix (z. B.AP-2.1). Diese sind Teil des stabilen Registrys und werden über den RFC-Prozess gepflegt. - Experimentelle Policies verwenden das
EXP--Präfix (z. B.EXP-8.1). Dies sind vorgeschlagene Policies in der Evaluierungsphase. - Drittanbieter- oder benutzerdefinierte Policies MÜSSEN ein Namensraum-Präfix der Form
x-[orgname]-verwenden (z. B.x-acme-1.1). Dieses Präfix signalisiert, dass die Policy von einer externen Organisation definiert und gepflegt wird, nicht vom AIPolicy Registry.
Policies mit Namensraum-Präfix sind nicht Teil des offiziellen Registrys. Sie werden nicht vom Registry-Redakteur vergeben und unterliegen nicht dem RFC-Prozess. Organisationen können ihre eigenen Namensraum-Registrys neben offiziellen AIPolicy Declarations veröffentlichen, um Governance-Positionen auszudrücken, die spezifisch für ihren Kontext sind.
Validatoren DÜRFEN AIPolicy Declarations, die Namensraum-Policy-IDs enthalten, NICHT ablehnen. Validatoren SOLLTEN Namensraum-IDs als unbekannte Erweiterungen behandeln -- akzeptiert ohne Validierung ihres Inhalts, aber nicht als offizielle Registry-Einträge interpretiert.
Deprecation-Richtlinie
Policies werden niemals aus dem Registry entfernt. Sobald eine Policy-ID vergeben und veröffentlicht wurde, bleibt sie unbegrenzt ein gültiger Identifikator.
Wenn eine Policy nicht mehr als aktuell angesehen wird, wird sie als veraltet markiert. Deprecation erfordert:
- Einen RFC mit einer klaren Begründung für die Deprecation.
- Eine 30-tägige Kommentarfrist gemäß dem Standard-RFC-Prozess.
- Eine redaktionelle Entscheidung durch den Registry-Redakteur.
Veraltete Policies werden in den Registry-Metadaten mit deprecated: true und einem Deprecation-Datum annotiert. Bestehende AIPolicy Declarations, die veraltete Policies referenzieren, bleiben gültig. Validatoren MÜSSEN veraltete Policy-IDs akzeptieren, SOLLTEN aber eine Warnung ausgeben, die darauf hinweist, dass die referenzierte Policy veraltet ist.
Die ID einer veralteten Policy wird niemals einer anderen Policy zugewiesen. Die ursprüngliche Definition wird für historische Referenzzwecke im Registry beibehalten.
Versionierung
Das Registry wird unabhängig von der AIPolicy-Spezifikation versioniert. Dies ermöglicht es dem Registry, sich weiterzuentwickeln -- neue Policies hinzuzufügen, Beschreibungen zu verfeinern, neue Kategorien einzuführen -- ohne dass eine neue Version der Format-Spezifikation erforderlich ist.
Versionsformat
Das Registry verwendet ein MAJOR.MINOR-Versionsformat (z. B. 1.0, 1.1, 2.0).
- MINOR-Versionsinkremente zeigen additive Änderungen an: neue Policies hinzugefügt, neue Kategorien eingeführt, redaktionelle Korrekturen an bestehenden Beschreibungen oder aktualisierte Hinweise für Verbraucher. Minor-Versionen sind abwärtskompatibel; bestehende Declarations bleiben gültig.
- MAJOR-Versionsinkremente zeigen brechende Änderungen an: umstrukturierte Kategoriesysteme, geänderte ID-Formate oder andere Modifikationen, die die Interpretation bestehender Declarations beeinflussen können.
Jede Version der AIPolicy-Spezifikation deklariert, welche Registry-Version sie anerkennt. Validatoren SOLLTEN die von der Spezifikation deklarierte Registry-Version verwenden, um zu bestimmen, welche Policy-IDs gültig sind.
Versionshistorie
| Registry-Version | Policies | Änderungen |
|---|---|---|
| 1.0 | 13 (AP-1.1 bis AP-6.3) | Initiales Registry |
| 1.1 | 16 (AP-1.1 bis AP-7.2) | Kategorie 7 hinzugefügt: Demokratische und Informationsintegrität (AP-7.1, AP-7.2) |
AIPolicy Registry v1.1 -- Arbeitsentwurf