Zum Hauptinhalt springen

Methodik — wie KYC Drift Angaben zu gehosteter KI erfasst

1615 Wörter
Inhaltsverzeichnis

Status des Piloten
#

Dies ist ein beleggestützter Pilot, kein vollständiges Marktaudit. Er enthält 44 aktuelle Fakten zu acht gehosteten KI-Diensten. Sämtliche 44 sind Anbieterangaben; keine stammt aus einer kontrollierten Beobachtung der Produktoberfläche. 17 Dimensionen ergeben über die acht Dienste 136 mögliche Vergleichsfelder. In 45 Feldern liegt mindestens ein aktueller Datensatz mit ausgewiesenem Geltungsbereich vor; in 91 Feldern nicht. Das sind Bestandszahlen, weder ein Prozentwert für Vollständigkeit noch die Aussage, alle Varianten untersucht zu haben.

Was der Datensatz erfasst
#

Die Grundeinheit ist eine einzelne Faktenbeobachtung: genau ein Dienst, ein Attribut, eine Lebenszyklusphase und ein Geltungsbereich. Die Phasen sind Registrierung, laufende Nutzung, Zahlung, Wiederherstellung und Löschung. Eine Beobachtung kann die angegebene Anforderung, die Art der Erhebung oder Prüfung, Verknüpfungsziele und Empfänger, geltende Region, Tarife, Plattform oder Anmeldemethode, Datumsangaben und Belege enthalten.

Seit dem 26. Juli 2026 wird der Datensatz nur noch ergänzt. Eine Richtlinienänderung fügt eine neue Beobachtung hinzu, die ausdrücklich auf den abgelösten Eintrag verweist; eine Korrektur verweist auf den korrigierten Eintrag. Die ersten 44 Beobachtungen bilden einen Legacy-Ausgangsstand. Wir behaupten nicht, dass er die Änderungshistorie vor diesem Stichtag vollständig abbildet. Die aktuellen Vergleichsansichten werden aus dem Verlauf abgeleitet; sie ersetzen ihn nicht.

Was bewusst nicht gemessen wird
#

  • Netzwerk-Anonymität. IP-Adressen, Geräte-Fingerprinting, der Umgang mit Tor/VPN und Website-Analytics gehören zu einer anderen Schicht. Eine veröffentlichte Aussage zu Netzwerkdaten kann separat erfasst werden, aber kein Vergleichsfeld belegt Anonymität im Netzwerk.
  • Daten bei Zahlungsdienstleistern. Wir können festhalten, dass ein Anbieter eine Zahlungsmethode akzeptiert. Was ein Intermediär über den Zahler weiß, liegt außerhalb des Datensatzes.
  • Zugriff aufgrund rechtlicher Verfahren. Angegebene Gesellschaft und Jurisdiktion werden erfasst. Daraus leiten wir keine Aussage darüber ab, welche Daten ein Gerichtsbeschluss oder eine Maßnahme der nationalen Sicherheit erreichen kann.
  • Umsetzung im Backend. Eine Richtlinie zeigt, was ein Anbieter veröffentlicht hat, nicht dass Produkt oder Backend entsprechend handeln.

Woher die Werte stammen
#

Anbieterdokumente und kontrollierte Oberflächenläufe sind parallele Belegrollen, keine Stufen einer gemeinsamen Quellenhierarchie:

  • Anbieterdokumente beantworten, was ein Anbieter in Richtlinien, Nutzungsbedingungen oder Hilfematerial veröffentlicht hat. Eine Anbieterangabe reicht nur so weit wie Wortlaut und Geltungsbereich des Dokuments.
  • Kontrollierte Oberflächenläufe beantworten, wie sich ein bestimmter Produktweg unter dokumentierten Bedingungen verhielt, etwa Datum, Region, Tarif, Plattform und Anmeldemethode. Eine Oberflächenbeobachtung setzt ein aufbewahrtes, geprüftes Artefakt voraus, dessen Prüfsumme im Freigabemanifest gebunden ist. Das Ergebnis wird nicht über den Lauf hinaus verallgemeinert.
  • Antworten des Supports, archivierte Oberflächenkopien und Drittberichte können Fragen aufwerfen oder einen Datensatz ergänzen. Sie werden aber erst dann zum sichtbaren Wert, wenn sie in der passenden Rolle als qualifizierter Beleg registriert sind.

Keine Rolle überschreibt die andere stillschweigend. In der aktuellen P0-Phase wird die Freigabe aufgeschoben, wenn sich ein Anbieterdokument und ein kontrollierter Lauf bei vergleichbarem Geltungsbereich widersprechen. Beide Belegströme werden getrennt aufbewahrt; ein neuer Zustand „widersprüchlich“ wird jedoch noch nicht veröffentlicht. Sobald P1 eine strukturierte Konfliktbeziehung in den Verlauf einführt, der nur durch neue Einträge erweitert wird, können beide Einträge parallel veröffentlicht werden, ohne dass einer den anderen ersetzt. Der aktuelle Pilot enthält ausschließlich Anbieterdokumente und keine kontrollierten Oberflächenbeobachtungen.

Erhebung und Pflicht werden ebenfalls getrennt. Wenn eine Datenschutzerklärung besagt, dass eine Telefonnummer erhoben werden kann, belegt das keine Telefonpflicht bei der Registrierung. Eine Anbieterangabe gilt nur dann als „erforderlich“, wenn das Dokument verpflichtende Sprache verwendet. Eine Oberflächenbeobachtung erhält diesen Wert nur, wenn der definierte Ablauf ohne die Angabe nicht fortgesetzt werden konnte.

Kontrolliertes Vokabular und keine leeren Felder
#

Die Felder verwenden Zustände wie erforderlich · optional · bedingt · verfügbar · erfasst, wenn angegeben · kann erheben · nicht geprüft · widersprüchlich · regionsabhängig · tarifabhängig · nicht anwendbar.

  • nicht geprüft bedeutet, dass für den angezeigten Dienst und die Dimension kein aktueller Datensatz mit passendem Geltungsbereich vorliegt.
  • widersprüchlich ist ein reservierter Zustand und wird im aktuellen Piloten nicht verwendet. In P0 blockiert eine Abweichung zwischen Belegrollen mit vergleichbarem Geltungsbereich die Freigabe, statt als öffentliches Feld zu erscheinen. Der Zustand wird erst verwendet, wenn P1 die strukturierte Beziehung bereitstellt, mit der beide Einträge parallel veröffentlicht werden können.
  • nicht offengelegt ist reserviert und wird im aktuellen Piloten nicht verwendet. Dafür wäre eine registrierte Auswertung eines klar definierten Dokumentbestands nötig; eine Lücke in den bisher erfassten Fakten genügt nicht.

Kein Feld bleibt leer. Schweigen im Dokument und eine Lücke unserer Recherche sind verschiedene Zustände. Keiner von beiden belegt, dass eine Anforderung nicht existiert.

Belege, Datumsangaben und Integrität
#

Für Anbieterdokumente gelten folgende Regeln:

  • Archiv zuerst. Anbieter-Seiten werden über Webarchive erfasst. Zitiert wird die archivierte Kopie, nicht eine neue direkte Anfrage unserer Infrastruktur.
  • Inhaltsprüfung. Eine Erfassung stützt aktuelle Fakten nur, wenn alle von ihnen verwendeten Zitate weiterhin im dekodierten Archivinhalt vorhanden sind. Ausgangserfassung und jüngste weiterhin stützende Nachprüfung werden getrennt angezeigt.
  • Aufgabe des SHA-256. Der SHA-256-Wert ist ein Fingerabdruck des dekodierten Archivinhalts. Damit lässt sich eine aufbewahrte Kopie vergleichen und eine Änderung der Bytes erkennen. Er belegt nicht, wann diese Bytes existierten.
  • Quelle der Erfassungszeit. Das angezeigte Datum stammt aus dem Wayback-Eintrag. Ein kryptografischer Zeitstempel ist noch nicht umgesetzt; bestehende Erfassungen tragen daher keinen bei der Erfassung erzeugten kryptografischen Zeitnachweis.
  • Zitate und Aufbewahrung. Kurze bereinigte Auszüge bleiben in der Ausgangssprache. Die verwendeten Inhalte werden zusätzlich aufbewahrt, damit ein defekter Archivlink den Datensatz nicht löscht.

Bei kontrollierten Oberflächenläufen hält der Beleg Bedingungen und Ergebnis fest, bewahrt das vorgesehene Artefakt im vom Repository kontrollierten Pfad für Interface-Runs auf und bindet dessen Prüfsumme in das Freigabemanifest ein. Dokumentarchive und Oberflächenartefakte haben unterschiedliche Integritätsprüfungen und bleiben getrennte Belegströme.

Ein Datum heißt nur dann Geltungsdatum, wenn der Anbieter ausdrücklich erklärt, dass die Richtlinie oder Bedingung an diesem Tag wirksam wird. „Zuletzt aktualisiert“ ist ein Dokumentdatum, kein Geltungsdatum. Erfassungs- und Beobachtungsdaten werden nicht stillschweigend zu einem der beiden erklärt.

Quelle, Integrität, Umsetzung, Aktualität und Konflikt
#

Diese Kennzeichnungen bleiben getrennt, weil sie verschiedene Fragen beantworten:

  • Quelle der Aussage unterscheidet Anbieterangabe und Oberflächenbeobachtung.
  • Belegintegrität zeigt das Ergebnis der jeweils geltenden Prüfung für Dokumentarchiv oder Oberflächenartefakt.
  • Tatsächliche Umsetzung bleibt ohne separaten kontrollierten Test ungetestet. Ein archiviertes Dokument genügt nie.
  • „Geprüft bis“ eines Fakts folgt jedem zitierten Belegstrom bis zum aktuellen Nachfolger, der die Aussage weiterhin stützt, und nimmt dann das älteste der jüngsten Prüfdaten dieser Ströme.
  • „Geprüft bis“ des Datensatzes ist das älteste Datum unter den aktuellen Fakten. Eine Teilaktualisierung verschiebt daher nicht den Stand des gesamten Piloten.
  • Quellenkonflikt ist eine reservierte Kennzeichnung. In P0 beschreibt sie keinen öffentlichen Wert: Eine ungelöste Abweichung bei vergleichbarem Geltungsbereich blockiert die Freigabe. Sobald P1 die strukturierte Beziehung in den nur durch neue Einträge erweiterten Verlauf einführt, weist die Kennzeichnung die Verbindung zwischen den abweichenden Einträgen aus und ermöglicht ihre parallele Darstellung.

Aus diesen Angaben wird kein zusammengefasster Vertrauenswert berechnet.

Änderungen, Korrekturen und Einwände
#

Eine Änderung wird nur so genau datiert, wie die Belege es erlauben. Der Zeitpunkt einer Momentaufnahme wird nicht stillschweigend zum Geltungsdatum. In P0 blockiert eine Abweichung zwischen Belegrollen mit vergleichbarem Geltungsbereich die Freigabe; sie wird weder nach redaktioneller Vorliebe aufgelöst noch als neuer Zustand veröffentlicht. Sobald P1 die strukturierte Konfliktbeziehung in den Verlauf einführt, der nur durch neue Einträge erweitert wird, können beide Einträge parallel sichtbar bleiben.

Bestätigt unsere Prüfung einen Fehler im Datensatz, korrigieren wir ihn öffentlich. Anbieter und Leser können an editor@cypherpunkguide.com schreiben. Wir versuchen üblicherweise, den Eingang eines Einwands binnen 14 Tagen zu bestätigen, und markieren den betroffenen Wert während der Prüfung. Das ist ein vom überwachten Korrekturkanal abhängiges Betriebsziel, keine garantierte Antwortfrist.

Aktualisierungsziel und heutige Grenze
#

Ziel ist die monatliche Nachprüfung aller Quellen mit anschließender menschlicher Bewertung erkannter Änderungen. Diese Kadenz ist noch kein aktives Serviceversprechen. Verbindlich wird sie erst, wenn Erfassung, Validierung, Differenzanalyse, menschliche Entscheidung und Freigabe zwei aufeinanderfolgende Zyklen unter produktionsgleichen Bedingungen mit allen Prüfschritten auf GREEN und einem beobachtbaren Lebenszeichen abgeschlossen haben. Bis dahin erfolgen Aktualisierungen und Korrekturen manuell; die angezeigten „geprüft bis“-Daten bleiben die verlässlichen Aktualitätsgrenzen.

Warum es keine Scores gibt
#

Ein zusammengefasster Datenschutzwert würde allen Lesern dasselbe Bedrohungsmodell vorgeben. Telefonpflicht, Weiterleitung an nachgelagerte Anbieter, Kontoverknüpfung und Aufbewahrungsfrist sind keine austauschbaren Einheiten. KYC Drift veröffentlicht Fakten, Datumsangaben, Geltungsbereiche, Lücken und Quellen, ohne daraus eine Qualitätsrangfolge oder Empfehlung zu machen.

Auswahl und Lizenz
#

Die acht Dienste bilden eine Gelegenheitsstichprobe für den Piloten: Für jeden war mindestens eine inhaltlich geprüfte Primärquelle des Anbieters verfügbar, ohne ein Konto anzulegen. Die Auswahl ist weder vollständig noch repräsentativ für den gesamten Markt gehosteter KI. Metadaten und Anmerkungen stehen unter CC BY 4.0; zitierte Anbietertexte bleiben Eigentum der jeweiligen Rechteinhaber. Der maschinenlesbare Export ist unter /en/data/kyc-drift/index.json verfügbar.

Zitiervorschlag: Cora Aegis, „KYC Drift: Identität und Datenumgang bei gehosteter KI — Pilot“ (v2026.07), https://cypherpunkguide.com/de/data/kyc-drift/, CC BY 4.0

Verwandte Artikel