Zusammenfassung

  • ICANN veröffentlichte am 3. September einen auf den 28. August datierten Brief der Ko-Vorsitzenden der Universal Acceptance Expert Working Group. Nach ihrer Darstellung wurde ein im Gremium konsentiertes Abschlussdokument zur Prüfung an ICANNs CEO übergeben.
  • Als Beispiel einer Änderung nennt der Brief die Nutzung künstlicher Intelligenz zur Förderung von UA. Das Paket enthalte außerdem Prioritäten und einen Rahmen für die Messung von Bewusstsein, politischer Unterstützung, Umsetzung und Kompetenzaufbau.
  • Im Kommentarbericht ist KI sowohl Hilfsmittel für Erkennung, Tests und Korrekturen als auch eine eigene Klasse zu prüfender Systeme: Code-Assistenten, Mail-Sicherheit, Parser, Spamfilter und Sprachdienste.
  • Eine zweiseitige Rollen- und Nachweismatrix muss Ausgabe, menschliche Prüfung, Freigabe, Bereitstellung, Komponentenverhalten und durchgängigen Nutzererfolg auseinanderhalten.

Die Richtung des Nachweises entscheidet

Im Korrespondenzverzeichnis von ICANN erschien am 3. September ein neuer Übergabepunkt. Edmon Chung und Sarmad Hussain berichten in ihrem Brief vom 28. August, die Expertengruppe habe die öffentlichen Stellungnahmen ausgewertet, die Leitlinien überarbeitet und ein von ihren Mitgliedern im Konsens getragenes Schlussdokument an Präsident und CEO Kurt Erik Lindqvist gesandt.

Der Brief nennt nur ein Änderungsbeispiel: KI-Technologien sollen für die Verbreitung von Universal Acceptance genutzt werden. Hinzu kommen demnach eine Priorisierung für die Umsetzung und ein Rahmen, der Fortschritt auf vier Ebenen verfolgt.

KI kann dabei vor dem System stehen. Sie erzeugt Testfälle, durchsucht Quelltext, markiert eine fehlerhafte Validierung oder entwirft einen Patch. Dann ist ihre Ausgabe ein Vorschlag. Ein Mensch oder eine verantwortliche Organisation entscheidet, ob sie richtig ist und in einen produktiven Dienst gelangt.

KI kann ebenso im System stehen. Ein Code-Assistent erzeugt die Validierung, ein Sicherheitsmodell bewertet EAI-Nachrichten, ein Sprachdienst verarbeitet einen internationalisierten Domainnamen oder eine Identitätsanwendung normalisiert die Eingabe. Nun muss das Verhalten der KI selbst geprüft werden.

Die Zahl der analysierten Repositorien beschreibt deshalb keinen Nutzungserfolg. Und ein erfolgreicher Nutzerweg beweist nicht, dass KI ihn verursacht hat. Ohne Rollenfeld hat eine Kennzahl weder stabile Bedeutung noch einen belastbaren Verantwortlichen.

Übergabe, Prüfung und Betrieb bleiben getrennte Zustände

Die Ko-Vorsitzenden reichen ihr Dokument ausdrücklich zur Prüfung ein. Der Konsens der Expertengruppe schließt deren redaktionelle Arbeit ab; er genehmigt nicht automatisch Budget, Projekt, Vertragsanforderung oder Umsetzung durch Dritte. ICANN muss Machbarkeit und Priorität beurteilen. Betreiber behalten die Verfügung über ihre Anwendungen, Maildienste und Infrastruktur.

Auch die öffentliche Dokumentenkette ist noch begrenzt. Die geprüfte Korrespondenz verlinkt den Begleitbrief, nicht die endgültigen Leitlinien. Die geschlossene Kommentarseite bietet weiterhin den Februarentwurf an und kündigt seine Fertigstellung und Veröffentlichung im Futur an. Im UA-Nachrichtenverzeichnis war die Endfassung zum Stichtag nicht aufgeführt.

Daraus folgt weder, dass sie nicht existiert, noch, dass intern nichts geschieht. Es folgt nur eine Beweisgrenze: Der Brief trägt die Aussage, KI sei als Revisionsbeispiel aufgenommen worden. Er trägt nicht den genauen Wortlaut, die Nummer oder die Priorität einer endgültigen Regel. Einzelheiten zu beiden KI-Rollen müssen als Kommentare, nicht als beschlossene ICANN-Politik gekennzeichnet bleiben.

Sechs Funktionen statt eines UA-Siegels

Der Entwurf vom Februar beschreibt UA-Bereitschaft als die Fähigkeit, alle gültigen Domainnamen und E-Mail-Adressen einschließlich IDN und EAI nach den anwendbaren Standards anzunehmen, zu validieren, zu speichern, zu verarbeiten, anzuzeigen und interoperabel zu verwenden.

Ein Eingabefeld kann bestehen, während die API scheitert. Eine Datenbank kann speichern, während die Kontowiederherstellung die Adresse nicht verarbeitet. Der Mailserver kann annehmen, während ein Filter falsch klassifiziert. Richtige Darstellung in einer Schreibrichtung deckt bidirektionale Fälle nicht ab. Jede Prüfung bleibt an Funktion, Version und Korpus gebunden.

Dasselbe gilt für die vier Messbereiche des Entwurfs. Veranstaltungen messen Aufwand für Bewusstsein. Beschaffungsregeln belegen politische Unterstützung. Schulungen schaffen Fähigkeiten. Ein vollständig durchlaufener Registrierungs-, Anmelde-, Wiederherstellungs- und Kommunikationsweg ist ein Betriebsergebnis. Die Werte hängen zusammen, sind aber nicht addierbar.

Der Kommentarbericht zeigt das Spiegelbild

Der Bericht über 37 Eingaben dokumentiert Vorschläge für KI-gestützte Softwareentwicklung, automatische Erkennung, Tests in großem Maßstab und Prüfungen innerhalb von Entwicklungsabläufen. Hier senkt KI die Kosten des Suchens und Reparierens.

Zugleich hält der Bericht den Vorschlag fest, KI-Systeme als eigene Interessengruppe zu behandeln. Genannt werden Sprachmodelle, KI-basierte E-Mail-Sicherheit, Codegeneratoren, Parser für Domains und Adressen, Spamfilter, Sprachassistenten, Trainingsdatenketten und Diagnosewerkzeuge. Hier wird KI zur beweglichen Abhängigkeit, die das Ergebnis des Nutzers verändern kann.

Die ISPCP-Stellungnahme fordert KI-spezifische Indikatoren, Phasen, Ziele und Governance. Das ist ein Beitrag, keine verabschiedete Verpflichtung. Er legt aber offen, warum die Richtung des Tests nicht im Oberbegriff verschwinden darf.

Zwei Rollen, eine überprüfbare Kette

Daniel Kade schlägt für jeden Pilotversuch eine knappe Matrix vor. Zuerst wird KI als Diagnoseinstrument, Vorschlagsgenerator, Entscheidungshilfe, geprüfte Komponente oder automatisierter Betreiber klassifiziert. Doppelrollen erhalten getrennte, verknüpfte Zeilen.

Danach folgt die Autorität: Wer wählte Werkzeug und Korpus, wer prüfte das Ergebnis, wer durfte Code übernehmen, bereitstellen, abschalten und zurückrollen? Weder ein Modellanbieter noch ein erzeugter Patch besitzt Betriebsbefugnis.

Der technische Zustand bindet Modell- oder Dienstversion, Testspezifikation, Ausgabe, Repository-Revision, Build, Abhängigkeiten und Zeitpunkt. Ändert sich eine relevante Komponente, braucht der alte Befund eine erneute Prüfung oder eine begründete Aussage zur Vergleichbarkeit.

Der UA-Umfang nennt Eingabe, Validierung, Speicherung, Verarbeitung, Anzeige, Authentifizierung, Wiederherstellung, Zustellung oder Interoperabilität. Der Korpus nennt Schriften, Sprachen, gültige und ungültige Beispiele, Länge, bidirektionalen Text, Providerwege, Auswahl und Ausschlüsse.

Schließlich erhält jeder Befund eine Klasse: Hinweis, vorgeschlagene Reparatur, menschlich geprüfter Code, freigegebener Einsatz, Komponentenbeobachtung oder durchgängiges Nutzerergebnis. Zähler, Nenner, Fehler, Fehlalarme, übersehene Fälle, Korrekturweg und Wiederholungstermin gehören dazu.

Sensible Regeln und personenbezogene Daten müssen nicht veröffentlicht werden. Unverzichtbar ist nur die Grenze: Erzeugung ist keine Freigabe, Bereitstellung keine universelle Konformität und Komponentenprüfung kein Nutzerergebnis.

Quellen

  1. ICANN-Korrespondenz
  2. Brief der UA-EWG-Ko-Vorsitzenden vom 28. August 2026
  3. Öffentliche Kommentierung des Entwurfs
  4. Entwurf der Leitlinien zur Förderung von UA
  5. Zusammenfassung der öffentlichen Kommentare
  6. ISPCP-Stellungnahme
  7. Mandat der UA Expert Working Group
  8. ICANN-Verzeichnis zu Universal Acceptance