Kann ein Regulierer ein bewegliches Ziel prüfen?

Ja, aber nicht, indem man ein adaptives System als statisches Objekt behandelt. Ein Audit braucht einen erfassten Zustand, eine begrenzte Aussage, Belege...

Kann ein Regulierer ein bewegliches Ziel prüfen?

Eine Prüfung darf ein Foto machen

Ein bewegliches Ziel ist nicht der Prüfung entzogen. Es entzieht sich nur der Art von Prüfung, die eine zeitlose Frage stellt und eine zeitlose Antwort erwartet. Dieser Unterschied ist wichtig. KI-Systeme ändern sich auf mehrere Arten gleichzeitig. Ein Anbieter veröffentlicht eine neue Modellversion. Ein Betreiber ändert den Prompt oder den Entscheidungsschwellenwert. Ein Abrufkorpus erhält ein neues Richtliniendokument. Eine Identitätsregel ändert, wer ein Tool aufrufen darf. Ein Tool erhält ein Feld, verliert ein Feld oder beginnt, unter demselben Feldnamen eine andere Bedeutung zurückzugeben. Ein menschliches Team ändert sein Verfahren. Die Welt, die die Eingaben liefert, ändert sich, ohne den Release-Manager von irgendjemandem zu fragen.

Nichts davon macht eine Prüfung zwecklos. Es macht den Prüfungsgegenstand präziser. Die Frage ist nicht, ob eine Organisation beweisen kann, dass ein System für immer unverändert bleibt. Das wäre selbst für einen Taschenrechner, der mit einer Datenbank verbunden ist, ein seltsames Versprechen. Die Frage ist, ob die Organisation zeigen kann, welches System zu einem relevanten Zeitpunkt in Betrieb war, was es bewirken sollte, welche Belege diese Nutzung stützten, welche Bedingungen die Belege begrenzten, wem die Entscheidung gehörte und welche spätere Änderung dazu führen sollte, die Entscheidung neu zu bewerten.

Eine Prüfung darf ein Foto machen. Sie darf das Foto nur nicht als Landschaft bezeichnen. Ein ordnungsgemäßer Datensatz identifiziert den Zustand, der geprüft wurde, und bewahrt den Weg von diesem Zustand zum nächsten. Er kann dann etwas Nützliches sagen: Diese Bewertung betraf dieses Modell, diese Einstellungen, diese Datengrenze, diese Tools, diese Richtlinie, diesen Arbeitsablauf und diese Release-Entscheidung. Er kann auch etwas weniger Bequemes und Wertvolleres sagen: Das Ergebnis ließ sich nicht automatisch auf den nächsten Zustand übertragen.

Das ist ein besserer Ausgangspunkt als das vertraute Theater unveränderlicher Abzeichen. Ein Abzeichen suggeriert, dass jemand die Sache geklärt hat. Ein Prüfungsdatensatz sollte es ermöglichen zu sehen, was geklärt wurde, auf welcher Grundlage, für welche Verwendung und wie lange diese Grundlage gültig blieb. Eine Regulierungsbehörde braucht keine eingefrorene Organisation. Eine Regulierungsbehörde braucht eine Organisation, die einen eingefrorenen Datensatz von einem laufenden Dienst unterscheiden kann, ohne beides als mystisches Objekt zu behandeln.

Europas KI-Regeln weisen bereits in diese Richtung. Für Hochrisiko-KI-Systeme verlangt der Artificial Intelligence Act technische Dokumentation, bevor ein System auf dem Markt bereitgestellt oder in Betrieb genommen wird, und verlangt, dass sie auf dem neuesten Stand gehalten wird. Er verlangt außerdem die automatische Aufzeichnung relevanter Ereignisse über die gesamte Lebensdauer des Systems und ein dokumentiertes System zur Überwachung nach dem Inverkehrbringen, das der Technologie und dem Risiko angemessen ist. Das sind keine Anweisungen, einen einzigen zeremoniellen Screenshot zu erstellen. Es sind Anweisungen, eine Belegkette durch den Wandel hindurch zu führen.

Das bewegliche Ziel ist meist ein System

Es ist verlockend, ein KI-System als Modell zu beschreiben und dann über Versionierung zu sprechen, als ob eine neue Modelldatei die ganze Geschichte wäre. Das ist praktisch für Präsentationen und ungenau für die meisten operativen Fragen. Ein Modell ist eine wichtige Komponente. Es ist selten das vollständige Objekt, dessen Verhalten einen Menschen, einen Arbeitsablauf oder eine rechtliche Verpflichtung betrifft.

Betrachten wir einen gewöhnlichen Entscheidungsunterstützungsweg, der hier als hypothetisches Beispiel beschrieben wird und nicht als Darstellung einer realen Bereitstellung. Ein Benutzer übermittelt eine Anfrage. Der Dienst ruft Dokumente ab, die er verwenden darf. Ein Modell entwirft eine Empfehlung. Eine Regel prüft, ob die erforderlichen Belege vorhanden sind. Ein geschulter Prüfer kann die Empfehlung annehmen, ändern oder ablehnen. Ein Arbeitsablauf zeichnet dann eine Aktion auf. Das beobachtete Ergebnis hängt von mehr ab als vom Modell. Es hängt von Quellversionen, Abrufeinstellungen, Berechtigungen, Formulierung der Oberfläche, Schwellenwerten, Warteschlangenregeln, menschlicher Autorität und der Handlungsgrenze ab.

Wenn sich der Quellkorpus ändert, kann das Modell eine andere faktische Grundlage erhalten, ohne dass sich ein einziger Parameter ändert. Wenn sich ein Prompt ändert, kann ein Modell zu einer anderen Art von Urteil aufgefordert werden. Wenn ein Review-Bildschirm keine Unsicherheit mehr anzeigt, ist die in einer Risikodatei beschriebene menschliche Aufsicht möglicherweise nicht mehr die Aufsicht, die Menschen tatsächlich ausüben. Wenn eine Integration Empfehlungen automatisch anwendet, hat das System eine neue Autorität erlangt, selbst wenn die Modellantwort byteweise identisch ist.

Deshalb beginnt ein sinnvoller Prüfungsnachweis mit dem beabsichtigten Zweck und der Systemgrenze. Die Anforderungen an die technische Dokumentation in Anhang IV der KI-Verordnung umfassen Beschreibungen des beabsichtigten Zwecks, der Versionen, der Überwachungs- und Kontrollfunktionen, der Validierung und Prüfung, des Risikomanagements, der während des Lebenszyklus vorgenommenen Änderungen sowie der relevanten Leistungskennzahlen. Es geht nicht darum, dass jedes System eine Kathedrale aus Papierkram braucht. Es geht darum, dass eine prüfende Person eine Behauptung nicht bewerten kann, wenn das Objekt, auf das sich die Behauptung bezieht, stillschweigend seine Form ändert.

Das weitere Objekt als System zu bezeichnen, ist kein Mittel, um die Arbeit bedeutender klingen zu lassen. Es ist ein Mittel, um einen Kategorienfehler zu vermeiden. Eine Modellbewertung kann eine Modellfrage beantworten. Ein Systemaudit muss eine Systemfrage beantworten. Ersteres kann feststellen, wie sich eine Komponente unter definierten Bedingungen verhalten hat. Letzteres muss zeigen, wie diese Komponente mit Menschen, Daten, Regeln, Werkzeugen und Konsequenzen verbunden war. Weder ersetzt das andere. Eine Modellbewertung ist keine Workflow-Beschreibung, so wie ein guter Reifentest kein Routenplan ist.

Was eine Prüfperson tatsächlich feststellen will

Die Prüfung eines sich ändernden Systems bedeutet nicht, jeden Moment seines Lebens in einem Besprechungsraum nachzuspielen. Es bedeutet, bestimmte Aussagen überprüfbar zu machen. Wurde das System innerhalb des angegebenen Zwecks verwendet? Wurde die Freigabeentscheidung durch Belege gestützt, die diesem Zweck angemessen waren? Hat die Organisation die Informationen bewahrt, die zur Untersuchung eines strittigen Ergebnisses erforderlich sind? Haben wesentliche Änderungen eine Neubewertung ausgelöst? Hat die Überwachung den Unterschied zwischen einer harmlosen Aktualisierung und einer wesentlichen Änderung sichtbar gemacht? Konnten die verantwortlichen Personen die Route pausieren, einschränken oder korrigieren, als die Belege nicht mehr hielten?

Das sind praktische Fragen, weil jede ein beobachtbares Gegenstück hat. Der beabsichtigte Zweck gehört in einen Nachweis. Eine Bewertung hat eine Testreihe, eine Konfiguration, eine Testpopulation oder eine Eingabegrenze, eine Methode, ein Ergebnis und eine Einschränkung. Eine Freigabeentscheidung hat eine verantwortliche Person und Bedingungen. Eine Änderung hat eine Identität, ein Datum, einen Grund und eine bewertete Auswirkung. Die Überwachung hat benannte Signale, Schwellenwerte oder Auslöser für Überprüfungen. Ein Pausenweg hat eine Befugnis und einen Ablauf. Die Einzelheiten variieren, aber die Prüfbarkeit entsteht dadurch, dass abstrakte Zusicherungen in Dinge verwandelt werden, die andere inspizieren können.

Hier gibt es eine wichtige Grenze. Ein Audit beweist nicht, dass jede zukünftige Ausgabe korrekt, fair oder harmlos sein wird. Es kann eine ungewisse Welt nicht in eine deterministische verwandeln. Es kann feststellen, ob eine Organisation Behauptungen aufgestellt hat, die eng genug gefasst waren, um geprüft zu werden, ob sie Belege gesammelt hat, die diese Behauptungen stützen können, und ob sie die Fähigkeit bewahrt hat, diese zu überdenken. Das mag bescheiden klingen. Es ist auch der Punkt, an dem Rechenschaftspflicht beginnt.

Der Unterschied zwischen Belegen und Zusicherungssprache ist wichtig. Zu sagen, dass ein Modell bewertet wurde, ist noch kein Beleg für eine nützliche Bewertung. Das Wort braucht ein Objekt. Gegenüber welcher Aufgabe, welchen Kriterien und welchen Daten wurde bewertet? Mit welchem Modell- und Systemzustand? Unter welchen Betriebsbedingungen? Wer hat die Methode geprüft? Was war außerhalb des Rahmens? Was würde das Ergebnis veralten lassen? Ohne diese Fragen ist Bewertung nur eine beruhigende Vergangenheitsform.

Die früheren Ethik-Leitlinien der Europäischen Kommission für vertrauenswürdige KI beschreiben Reproduzierbarkeit in einfachen Worten: Ein KI-Experiment sollte bei Wiederholung unter denselben Bedingungen dasselbe Verhalten zeigen. Das ist eine nützliche Definition, weil sie ihre eigene Grenze enthält. Gleiche Bedingungen sind keine leere Formulierung. Ein wiederholtes Experiment kann zeigen, ob die dokumentierte Behauptung reproduzierbar ist. Es kann nicht zeigen, dass sich unverändertes Verhalten einstellt, wenn sich Datenquelle, Richtlinie oder Einsatzweg ändern. Reproduzierbarkeit ist daher kein Versprechen, dass die Welt stillsteht. Sie ist eine Disziplin, die präzise festhält, was tatsächlich geschehen ist.

Eine erfasste Evaluierung ist ein Zeitpunkt. Der Audit wird dauerhaft, wenn der nächste Zustand damit verglichen werden kann.

Eine Versionsnummer ist notwendig, aber nicht hinreichend

Versionsnummern sind nützlich, weil sie verhindern, dass ein Datensatz so tut, als wären Namen genug. Doch ein Versionslabel kann auch falsche Sicherheit erzeugen. Ein Label wie Version 4.2 mag eine Softwareversion identifizieren, aber es identifiziert nicht unbedingt den tatsächlichen Zustand einer KI-Route. Ein Konfigurationswert kann außerhalb des Modell-Repositorys liegen. Ein Abrufindex kann aus sich ändernden Dokumenten neu aufgebaut werden. Ein Feature-Flag kann einen anderen Tool-Pfad wählen. Eine Policy-Engine kann eine erlaubte Aktion ändern. Ein Dienst kann daher eine einwandfrei formatierte Versionsnummer haben und dennoch schwer zu rekonstruieren sein.

Entscheidend ist die Identität, die zur Behauptung passt. Betrifft die Behauptung einen Offline-Modell-Benchmark, können das Modell-Artefakt, der Inferenzcode, die Parametereinstellungen, die Dataset-Version, die Metrikdefinition und die Ausführungsumgebung wesentlich sein. Betrifft die Behauptung einen Live-Entscheidungsunterstützungsdienst, kann der Datensatz zusätzlich die Eingabeaufforderung oder Vorlage, die Abrufkonfiguration, Quellkennungen und Aktualität, den Berechtigungsstatus, Tool-Schemas, die Policy-Version, die Prüfoberfläche und die Workflow-Regel benötigen. Ein Audit-Paket muss nicht jedes Byte jedes Systems enthalten. Es muss die Elemente enthalten oder zuverlässig darauf verweisen, die die Bedeutung der Behauptung verändern könnten.

Deshalb ist ein Manifest oft hilfreicher als ein Archiv, das auf einer Festplatte abgelegt wird. Ein Manifest sagt, welche Artefakte zusammengehören, ihre Kennungen, ihre Integritätsverweise, ihre Beziehungen und ihre Zugriffsbedingungen. Es ermöglicht einem Prüfer, das relevante Paket zu finden, ohne anzunehmen, dass jede Quelle in einen uneingeschränkten Ordner kopiert werden kann. Einige Belege enthalten personenbezogene Daten, sicherheitsrelevante Details, lizenzierte Materialien oder Geschäftsgeheimnisse. Prüfbarkeit erfordert kontrollierten Zugriff und aussagekräftige Rückverfolgbarkeit, nicht die verpflichtende öffentliche Offenlegung von allem, was ein System funktionieren lässt.

Anhang IV verfolgt einen ähnlich pragmatischen Ansatz. Er behandelt die technische Dokumentation nicht als kurze Produktbeschreibung. Er verlangt Informationen über das System und seinen Lebenszyklus, einschließlich Änderungen während der Entwicklung und nach dem Inverkehrbringen, Überwachungs- und Kontrollfunktionen, Validierungs- und Testverfahren sowie deren Ergebnisse, Maßnahmen des Risikomanagements und eine Beschreibung der Leistungskennzahlen. Das Dokument muss klar genug sein, damit die zuständigen nationalen Behörden und benannten Stellen die Konformität bewerten können. Mit anderen Worten: Die Informationen müssen für die Prüfung strukturiert sein, nicht nur gesammelt, weil ein Speichersystem verfügbar war.

Dahinter steht eine kleine, aber entscheidende Designfrage: Was müsste sich ändern, bevor die bisherigen Nachweise die gegenwärtige Behauptung nicht mehr stützen könnten? Die Antwort schafft die Versionsgrenze. Wenn eine neue Abrufquelle die sachliche Grundlage von Empfehlungen verändert, gehört sie zur Identität. Wenn eine neue Prüfoberfläche eine Warnung verdeckt, gehört sie zur Identität. Wenn eine rein kosmetische Textänderung das bewertete Verhalten nicht beeinflussen kann, gehört sie wahrscheinlich in den Änderungsverlauf, aber nicht in den Bewertungs-Fingerabdruck. Gute Versionierung ist keine maximale Sammlung. Sie ist begründete Relevanz.

Den Vertrag erfassen, nicht nur die Ausgabe

Eine Ausgabe ist ein Nachweis für etwas, aber nicht immer ein ausreichender Nachweis. Ein Screenshot kann zeigen, was auf einem Bildschirm erschien. Er kann oft nicht zeigen, welches Modell ihn erzeugt hat, welche Quelle abgerufen wurde, was ein Tool zurückgab, welche Regel angewendet wurde, welche Eingaben ausgelassen wurden oder ob die Ansicht eine Warnung verdeckte. Dies ist einer der Gründe, warum Screenshots sich in Konformitätsordnern mit der Feierlichkeit archäologischer Funde ansammeln und mit deutlich weniger Erklärungskraft.

Ein erfasster Vertrag ist reichhaltiger. Er verbindet das Ergebnis mit den Bedingungen, unter denen das System erwartungsgemäß handeln sollte. Für eine Bewertung kann das die genaue Testsuite, die Eingaben oder einen geschützten Verweis darauf, die erwarteten Assertions, die Modell- und Dienstkonfiguration, die relevanten Richtlinien- und Toolversionen, die Ausführungsumgebung, sofern sie das Ergebnis beeinflusst, und die Akzeptanzregel umfassen. Für einen Live-Lauf kann es die Anforderungsidentität, den autorisierten Umfang, die Quellen- und Abrufprotokolle, die Modellroute, Toolaufrufe, Kontrollen, menschliche Eingriffe und die daraus resultierende Zustandsänderung umfassen. Ziel ist es nicht, ein endloses Tagebuch zu führen. Es geht darum, genügend kausal relevante Informationen zu bewahren, um später eine ernsthafte Frage stellen zu können.

Es gibt eine sinnvolle Unterscheidung zu treffen. Eine Bewertungserfassung belegt eine Behauptung über einen definierten Test oder eine definierte Übung. Ein Betriebsprotokoll hilft, ein bestimmtes Ereignis oder eine bestimmte Entscheidung zu rekonstruieren. Ein Freigabeprotokoll erklärt, warum eine Organisation ein System in eine definierte Route zugelassen hat. Ein Änderungsprotokoll erklärt, was später verändert wurde. Diese Protokolle überschneiden sich, sollten aber nicht verwechselt werden. Ein Produktionsprotokoll als Benchmark zu behandeln oder eine Benchmark als Nachweis für einen Produktionsworkflow ist ein effizienter Weg, um jedes Protokoll mit mehr zu belasten, als es tragen kann.

Die Protokollierungsregel der KI-Verordnung für Hochrisikosysteme ist ähnlich zweckgebunden. Artikel 12 verlangt die automatische Aufzeichnung relevanter Ereignisse über die gesamte Lebensdauer des Systems, mit Protokollierungsfunktionen, die dem vorgesehenen Zweck angemessen sind. Die Verordnung bezieht sich auf die Rückverfolgbarkeit der Funktionsweise des Systems, die Überwachung des Betriebs und die Überwachung nach dem Inverkehrbringen. Sie verlangt keine wahllose Aufzeichnungsgewohnheit. Sie verlangt Protokolle mit einer Aufgabe.

Der Ausdruck „Datensätze mit einem Auftrag“ ist ein besserer Leitfaden als eine allgemeine Forderung nach Beobachtbarkeit. Die Modellkennung kann helfen, ein Update zu unterscheiden. Die Herkunft der Eingabedaten kann eine überraschende Empfehlung erklären. Eine Regelversion kann erklären, warum ein Ergebnis blockiert wurde. Eine Übersteuerung durch die prüfende Person kann erklären, warum sich die operative Maßnahme vom Modellvorschlag unterscheidet. Ein Zeitstempel kann die Reihenfolge festlegen. Ein datenschutzbewusstes Design fragt dennoch, ob jedes Feld notwendig und verhältnismäßig ist, ob es für einen definierten Zeitraum aufbewahrt wird und ob es vor genau dem System geschützt ist, das es untersuchen soll.

Reproduzierbarkeit hat zwei ehrliche Formen

Menschen verwenden „reproduzierbar“ oft für verschiedene Dinge. Die Verwirrung ist verständlich. Ein Team kann meinen, dass es eine festgelegte Auswertung erneut ausführen und dasselbe Ergebnis erzielen kann. Eine Forscherin kann meinen, dass ein anderes Team die beschriebene Methode ausführen und das Ergebnis prüfen kann. Eine Betreiberin kann meinen, dass eine Untersuchung den Zustand rekonstruieren kann, der für eine bestimmte Entscheidung verwendet wurde. Eine Kundin kann meinen, dass ein Arbeitsablauf eine konsistente Behandlung gewährleistet und sich nicht willkürlich von Dienstag auf Donnerstag ändert. Diese Ziele hängen zusammen. Sie sind nicht eine einzige Eigenschaft mit mehreren Namen.

Erstens gibt es die Reproduzierbarkeit des erfassten Laufs. Wenn Artefakt, Konfiguration, Eingaben, relevanter Zustand und Ausführungsbedingungen festgehalten werden, sollte eine Wiederholung das dokumentierte Ergebnis innerhalb der vom System zugesicherten Bedingungen liefern. Manche Systeme können für einen definierten Ausführungspfad eine stärkere deterministische Aussage treffen. Andere verlassen sich auf kontrollierte Zufälligkeit, verteilte Infrastruktur oder Dienste Dritter und können nur eine engere Aussage treffen. Die verantwortungsvolle Sprache ist präzise. Sie sagt, was festgelegt ist, was gemessen wird, welche Abweichung möglich bleibt und wie der Vergleich durchgeführt wird.

Zweitens gibt es die Reproduzierbarkeit des Auswertungsarguments. Eine prüfende Person muss erkennen können, warum die Testreihe die Behauptung abbildet, ob die Metrik die angegebene Bedeutung hat, ob die Annahmeschwelle gerechtfertigt ist und ob die Belege auf den operativen Kontext übertragbar sind. Das löst keine Prüfsumme. Eine Prüfsumme kann belegen, dass sich eine Datei nicht geändert hat. Sie kann nicht belegen, dass die Datei die richtige Frage geprüft hat, dass die Grundgesamtheit angemessen war oder dass ein Ergebnis die damit verbundene Entscheidung stützt.

Die beiden Formen sollten zusammenkommen. Ein perfekt wiederholbarer Test, der das Falsche misst, ist immer noch der falsche Test. Ein ausgefeiltes Argument, das an einen nicht wiederholbaren Lauf geknüpft ist, lässt prüfende Personen nicht unterscheiden, ob ein Befund oder ein glücklicher Zufall vorliegt. Der brauchbare Maßstab ist keine abstrakte Forderung nach perfekter Reproduzierbarkeit. Es ist eine sichtbare Entsprechung zwischen der Behauptung, der Methode, den erfassten Bedingungen, dem beobachteten Ergebnis und der Nutzung, die die Organisation zulassen möchte.

Die Leitlinien der Kommission zu den Pflichten von Anbietern allgemeiner KI-Modelle halten die Auswertung ebenfalls mit Dokumentation und Risiko verbunden. Sie beschreiben technische Dokumentation für Behörden und gesonderte Informationen für nachgelagerte Anbieter, einschließlich Fähigkeiten, Einschränkungen und Integrationsinformationen. Für allgemeine KI-Modelle mit systemischem Risiko verlangt Artikel 55 eine Bewertung mit standardisierten Protokollen und modernsten Werkzeugen, einschließlich dokumentierter adversarischer Tests zur Ermittlung und Minderung systemischer Risiken. Eine Auswertung, die nicht sagen kann, was unter welchen Bedingungen und mit welchen Einschränkungen getestet wurde, wird nicht dadurch nützlicher, dass man sie standardisiert nennt.

Belege haben ein Ablaufdatum

Belege verfallen nicht, weil sich jemand entschieden hat, schwierig zu sein. Sie verfallen, wenn sich die Bedingungen, unter denen sie eine Aussage stützen konnten, so weit geändert haben, dass der Zusammenhang nicht mehr vorausgesetzt werden kann. Das ist gewöhnliches Denken. Ein Test eines Brückendesigns deckt nicht automatisch ein anderes Material ab. Eine Lebensmittelsicherheitsprüfung deckt einen neuen Lieferanten nicht durch bloßen Optimismus ab. Eine Bewertung einer KI-Route sollte nicht automatisch ein geändertes Modell, eine geänderte Datengrenze, eine geänderte Werkzeugautorität oder eine geänderte Entscheidungsfolge abdecken.

Die schwierige Arbeit besteht darin zu entscheiden, welche Änderungen von Bedeutung sind. Das ist eine Frage des technischen Urteils, der Risikoanalyse und der Governance, nicht eine einzelne Prozentzahl, die in eine Richtlinie geschrieben wird. Ein Patch, der die Farbe eines Buttons ändert, kann für eine Bewertung ohne Belang sein. Eine Änderung, die eine Warnung weniger sichtbar macht, kann wesentlich sein, wenn das Sicherheitsargument davon abhängt, dass eine prüfende Person sie sieht. Das Neuindizieren eines Quellkorpus kann für eine Aufgabe harmlos sein und für eine andere kritisch. Ein neuer Modell-Endpunkt kann eine breite Fähigkeit bewahren, während sich Latenz, Verweigerungsverhalten, Sprachabdeckung oder Werkzeugnutzungsmuster ändern, die für die Route von Bedeutung sind.

Eine nützliche Änderungskontrolle beginnt daher mit einer Auswirkungsfrage, nicht mit einem Release-Ritual. Welche Aussage könnte diese Änderung betreffen? Welche Annahme stört sie? Welcher Beleg war an den alten Zustand gebunden? Beantwortet eine begrenzte Prüfung die Frage, oder benötigt die Route eine neue Bewertung und Release-Entscheidung? Wer darf diese Entscheidung treffen, und wer kann sie anfechten? Die Antworten sollten festgehalten werden, weil die nächste prüfende Person sie sonst aus Ticket-Titeln, Überlieferungen und einer leichten Änderung der Schriftart des Release-Dashboards ableiten muss.

Hier wird Monitoring auch Teil der Belege, statt ein separates Observability-Hobby zu sein. Artikel 72 verlangt, dass Anbieter von Hochrisiko-KI-Systemen während der gesamten Systemlebensdauer aktiv und systematisch relevante Daten zur Leistung erfassen, dokumentieren und analysieren, um die fortlaufende Konformität bewerten zu können. Der Plan zur Überwachung nach dem Inverkehrbringen ist Teil der technischen Dokumentation. Monitoring ist also nicht nur eine Möglichkeit zu wissen, ob der Dienst ausgelastet ist. Es ist eine Möglichkeit zu erfahren, ob die Bedingungen hinter der ursprünglichen Aussage weiterhin gelten.

Monitoring macht nicht jedes Ergebnis selbsterklärend. Ein Anstieg der Abweichungen zwischen prüfenden Personen und einem System kann viele Ursachen haben. Eine Änderung der Quellfrische könnte auf ein Datenpipeline-Problem hinweisen statt auf Modelldrift. Eine höhere Verweigerungsrate könnte eine sicherere Richtlinie, eine defekte Integration oder eine neue Anfragepopulation darstellen. Der Datensatz sollte genügend Kontext für eine menschliche Untersuchung bewahren. Metriken sind Signale. Sie sind keine Zeugen.

Belege gelten in einem definierten Kontext. Eine wesentliche Änderung schafft eine Frage für die Überprüfung, keine Hintertür um die Überprüfung herum.

Wesentliche Änderung braucht einen Entscheidungsweg

Der Begriff wesentliche Änderung wird oft so behandelt, als benenne er eine selbsterklärende Eigenschaft. Das tut er nicht. Wesentlich für welche Behauptung, welches Risiko und welche Nutzer? Die Antwort muss konkret genug sein, damit Menschen sie auch dann anwenden können, wenn sie müde sind, spät dran sind und eine Änderung gern als geringfügig einstufen würden. Eine gute Richtlinie verspricht nicht, jede mögliche Aktualisierung im Voraus zu klassifizieren. Sie benennt die Faktoren, die bestimmen, ob eine Neubewertung erforderlich ist.

Zu diesen Faktoren gehören in der Regel der vorgesehene Zweck, die betroffenen Personen, die der Route eingeräumte Befugnis, die Datenquellen und deren Qualitätskontrollen, die Modell- oder Systemarchitektur, der Bewertungsumfang, die Entscheidungsschwellen, die Überwachungssignale, die menschliche Aufsicht, die Sicherheitskontrollen und die Wiederherstellungspfade. Eine Änderung, die einen dieser Punkte berührt, kann wesentlich sein, muss es aber nicht. Entscheidend ist, ob sie die Nachweise verändern kann, die für die bestehende Behauptung erforderlich sind, oder das Risiko, das nach den Kontrollen verbleibt.

Die KI-Verordnung enthält eine ausdrückliche Verantwortung im Zusammenhang mit wesentlichen Änderungen. Ihre genaue rechtliche Anwendung hängt von dem jeweiligen System und den beteiligten Akteuren ab und sollte daher nicht auf eine Formel verkürzt werden. Die operative Lehre ist einfacher und weiter gefasst: Eine Organisation sollte wissen, wann eine Änderung Verantwortung überträgt oder begründet, wann die vorhandene Dokumentation nicht mehr ausreicht und wann das System erneut bewertet werden muss, bevor eine neue Nutzung fortgesetzt wird. Das ist weniger aufregend als der Start einer neuen Funktion. Es führt aber auch seltener zu einer schwierigen Lage, in der alle sich einig sind, dass sich das System geändert hat, aber niemand die Entscheidung verantwortet.

Ein Entscheidungspfad gibt einer Änderung einen Ort, an den sie gehen kann. Ein Pfad kann eine dokumentierte Feststellung ohne Auswirkungen erlauben. Ein anderer kann eine gezielte Regressionsbewertung erfordern. Wieder ein anderer kann eine breitere Risikoprüfung, eine Änderung der Gebrauchsanweisung, einen überarbeiteten Überwachungsplan oder eine neue Freigabe erfordern. Der schwerwiegendste Pfad kann verlangen, dass die Route eingeschränkt oder pausiert bleibt, bis Nachweise vorliegen. Es geht nicht darum, jede Änderung teuer zu machen. Es geht darum, die wichtige Änderung so zu gestalten, dass sie sich nicht als routinemäßige Hausarbeit tarnen lässt.

Es hat etwas durchaus Erfrischendes, dass hier jede Romantik fehlt. Ein Änderungsdatensatz kann den vorherigen Zustand, den vorgeschlagenen Zustand, die betroffenen Behauptungen, die geprüften Nachweise, die Entscheidung, die Befugnis und die Bedingungen nach der Freigabe zeigen. Das ist Governance im Arbeitsalltag. Das wird nie so spannend wirken wie eine Modelldemonstration. Es hat aber die nützlichere Eigenschaft, einer Organisation zu helfen, sich zu erklären, wenn aus einer Demonstration ein echter Dienst geworden ist.

Die Bewertung sollte öffentlich scheitern dürfen, oder zumindest in der Datei

Bewertung wird zur Show, wenn jedes Ergebnis als Freigabeergebnis gilt. Ein ausgereiftes Bewertungsprogramm muss zu dem Schluss kommen können, dass die Nachweise unvollständig sind, dass ein Schwellenwert verfehlt wurde, dass eine bekannte Einschränkung eine vorgeschlagene Nutzung verhindert oder dass eine Behauptung enger gefasst werden muss. Das sind keine peinlichen Ausnahmen vom Prozess. Das sind Ergebnisse des Prozesses.

Das ist besonders wichtig für adaptive oder extern verbundene Systeme. Ein Team kann feststellen, dass eine Testreihe eine lebende Eingabepopulation nicht mehr abbildet. Ein Tool-Vertrag kann zu instabil werden, um eine Replay-Behauptung zu stützen. Ein Modellupdate kann eine Aufgabe verbessern, aber eine geschützte Route schwerer überwachbar machen. Ein operatives Signal kann zeigen, dass die Übergabe vom System an die prüfende Person unter normaler Arbeitslast versagt. Die richtige Antwort ist nicht unbedingt eine dramatische Abschaltung. Es kann eine Einschränkung sein, ein überarbeiteter Arbeitsablauf, ein weiterer Test, eine neue Annahmebedingung oder die Entscheidung, die ursprüngliche Behauptung nicht aufrechtzuerhalten.

Der Datensatz muss es einem Prüfer ermöglichen, dieses negative Ergebnis zu erkennen. Andernfalls baut eine Organisation eine sehr effektive Maschine, die nur die Beweise sammelt, die ihr gefallen. Die Anforderungen an das Qualitätsmanagement in Artikel 17 sind hier relevant. Sie umfassen unter anderem Techniken und Verfahren für Design, Entwicklung und Qualitätskontrolle; Untersuchung, Test und Validierung; Datenmanagement; Risikomanagement; Überwachung nach dem Inverkehrbringen; Meldung von Vorfällen; und Kommunikation mit Behörden. Ein Qualitätssystem ist kein Ordner, der Fehler verschwinden lässt. Es ist eine Möglichkeit, sie zu erkennen, zu dokumentieren und zu beheben.

Derselbe Grundsatz gilt für den Zugang. Eine externe Regulierungsbehörde, eine benannte Stelle oder ein autorisierter Prüfer benötigt möglicherweise technische Nachweise, die nicht offen veröffentlicht werden können. Eine öffentliche Zusammenfassung kann für andere Teile des Datensatzes angemessen sein. Dies sind unterschiedliche Zugangswege, nicht unterschiedliche Fakten. Der Öffentlichkeit sollte kein heiterer Bericht angeboten werden, während der kontrollierte Datensatz eine engere und bedingtere Realität beschreibt. Vertraulichkeit kann legitim sein. Widerspruch ist ein Governance-Versagen.

Bei Dweve macht unser öffentliches Trust Centre ein kleines, bewusst begrenztes Beispiel für diese Unterscheidung. Seine Evaluationsseite besagt, dass eine Evaluation das Modell, die genaue Suite, die Konfiguration, den erfassten Zustand, die Nachweise und die Entscheidung des Prüfers identifiziert. Sie besagt auch, dass ein wiederholter erfasster Vertrag auf unterstützten Architekturen byteidentische Ergebnisse liefern sollte, während eine Live-Wiederholung abweichen kann, wenn sich externe Nachweise oder adaptive Zustände ändern. Die Seite trennt die öffentliche Methode von einem ausgefüllten Marketing-Ergebnis. Das ist kein Beweis für die Qualität eines Modells. Es ist einfach die richtige Form einer Aussage über Evaluationsdatensätze.

Live-Überwachung ist kein Ersatz für eine Entscheidung vor der Veröffentlichung

Überwachung wird manchmal als Antwort auf Unsicherheit beschrieben: System freigeben, Dashboard beobachten, kontinuierlich verbessern. In diesem Satz steckt ein nützlicher Instinkt. Systeme brauchen nach der Veröffentlichung Beobachtung, weil der Einsatz Informationen hervorbringt, die ein Labor nicht liefern kann. Aber Überwachung kann eine Entscheidung nicht rückwirkend stützen, für die die Nachweise nie ausreichend waren. Sie kann einer Person, die von einer fehlerhaften Handlung mit hohen Konsequenzen betroffen ist, nicht sagen, dass die Organisation nächsten Monat aus der Grafik lernen wird.

Evaluation vor der Veröffentlichung und Überwachung nach der Veröffentlichung beantworten unterschiedliche Fragen. Evaluation fragt, ob die Organisation genügend Nachweise hat, um eine definierte Nutzung jetzt zu erlauben. Überwachung fragt, ob die Bedingungen hinter dieser Erlaubnis weiterhin gelten und ob neue Risiken oder Fehler auftauchen. Ersteres legt eine Ausgangsgrenze fest. Letzteres beobachtet die Grenze im Betrieb. Ein glaubwürdiges System braucht beides, sowie einen Weg, damit Daten und betriebliches Lernen zur Risikobewertung, Dokumentation und Änderungskontrolle zurückkehren.

Diese Schleife verwandelt ein statisches Zusicherungspaket in einen lebendigen Datensatz. Eine Evaluation liefert eine Basislinie. Ein Einsatzdatensatz sagt, welche Basislinie übernommen wurde. Protokollierung und Überwachung zeigen relevantes Verhalten. Eine Änderung kann die Basislinie verändern oder ihre Grenzen aufdecken. Eine Überprüfung aktualisiert dann die Aussage, ihre Nachweise, ihre Einschränkungen oder ihren Status. Das System bewegt sich. Der Datensatz bewegt sich mit, schreibt aber seine eigene Vergangenheit nicht um. Ein Prüfer kann sowohl die aktuelle Position als auch den Weg sehen, auf dem sie erreicht wurde.

Für Hochrisikosysteme ist die KI-Verordnung eindeutig, dass die Überwachung nach dem Inverkehrbringen relevante Leistungsdaten während der gesamten Lebensdauer sammeln und analysieren und die Bewertung der kontinuierlichen Konformität ermöglichen sollte. Sie verlangt auch, dass Betreiber den Betrieb auf der Grundlage der Gebrauchsanweisung überwachen und den Anbieter und die zuständige Behörde unverzüglich informieren, wenn sie Grund zu der Annahme haben, dass die Nutzung ein Risiko darstellen könnte. Diese Anforderungen beseitigen nicht die Notwendigkeit professionellen Urteilsvermögens. Sie geben dem professionellen Urteilsvermögen Datensätze, Auslöser und Wege.

Es besteht organisatorisch die Versuchung, Monitoring als Aufgabe des Betriebsteams und Evaluation als Aufgabe des Modellteams zu betrachten. Diese Aufteilung scheitert bereits bei der ersten bedeutsamen Frage zu einer Live-Route. Die Modellverantwortlichen wissen vielleicht, warum ein Test gewählt wurde. Die Betriebsverantwortlichen wissen vielleicht, dass die Quellen veraltet waren. Die Policy-Verantwortlichen wissen vielleicht, dass sich eine Entscheidungsregel geändert hat. Die Prüfenden wissen vielleicht, dass die Schnittstelle Automatisierungs-Bias erzeugt. Ein Audit-Trail sollte ihre Nachweise verbinden, ohne vorzutäuschen, dass eine einzelne Person das gesamte System überblickt.

Kann eine Aufsichtsbehörde eine Entscheidung nachvollziehen?

Manchmal sollte die Antwort innerhalb eines definierten Rahmens ja lauten. Wenn eine Organisation behauptet, dass eine Entscheidung oder Evaluation wiederholbar ist, muss sie benennen, was Wiederholung bedeutet. Heißt das, einen Modellaufruf mit demselben Prompt zu wiederholen? Heißt das, die vollständige Retrieval- und Tool-Sequenz neu aufzubauen? Heißt das, den Datensatz zu rekonstruieren, den eine prüfende Person gesehen hat? Heißt das, eine deterministische Berechnung aus gespeicherten Eingaben zu validieren? Jede dieser Möglichkeiten ist nützlich. Jede hat unterschiedliche technische und rechtliche Voraussetzungen.

Eine aussagekräftige Wiederholung beginnt mit gespeicherter Identität. Die prüfende Person muss wissen, welche Systemversion und Konfiguration in Kraft waren, welche Eingaben und Quellversionen zulässig waren, welche Policies und Berechtigungen galten, welche externen Abhängigkeiten reagiert haben und welche menschlichen Handlungen den Pfad verändert haben. Einige Elemente müssen möglicherweise direkt gespeichert werden. Andere können über stabile Kennungen referenziert und über kontrollierte Systeme rekonstruiert werden. Nicht akzeptabel ist es, eine Übung als wiederholbar zu bezeichnen, wenn sie von einer Live-Websuche, einer überschriebenen Datenbankzeile und einer aus dem Gedächtnis abgerufenen Einstellung vom Laptop einer Entwicklerin oder eines Entwicklers abhängt.

Auch dann kann eine Wiederholung einen Datensatz reproduzieren, statt die Welt zu wiederholen. Eine Live-Quelle kann aktualisiert oder zurückgezogen werden. Ein Drittanbieterdienst kann sich ändern. Ein adaptiver Dienst kann neuen regulierten Zustand ansammeln. Ein Mensch kann bei denselben Informationen eine andere Entscheidung treffen. Das sind keine Mängel der Idee der Wiederholbarkeit. Es sind Unterscheidungen, die der Datensatz bewahren muss. Die Wiederholung kann zeigen, was das System unter dem erfassten Vertrag getan hat. Sie behauptet nicht, dass die gegenwärtige Welt mit diesem Vertrag identisch ist.

Deshalb gehören menschliche Entscheidungsdatensätze neben technische Datensätze, wenn menschliche Aufsicht Teil des Sicherheits- oder Rechtsarguments ist. Ein Audit muss möglicherweise wissen, dass eine Person eine Empfehlung geprüft hat, welche Informationen ihr zur Verfügung standen, was sie gewählt hat und welche Befugnis sie hatte. Es muss nicht jede prüfende Person zu einem Überwachungsobjekt machen oder unbegrenztes persönliches Material aufbewahren. Es muss aber genügend Informationen enthalten, um festzustellen, ob die zugesagte Aufsicht im betreffenden Ereignis tatsächlich bestand.

Reproduktion ist daher eine Leiter, kein Prahlversprechen. Auf einer Sprosse kann die prüfende Person die Version identifizieren. Auf der nächsten kann sie die Nachweise einsehen. Weiter oben kann sie einen Test nachstellen oder einen Live-Entscheidungspfad analysieren. Die Organisation sollte angeben, welche Sprosse sie unterstützt, wo die Grenzen liegen und welche Teile autorisierten Zugriff erfordern. Ein bescheidener, testbarer Wiederholbarkeitsanspruch ist viel stärker als eine vage Zusicherung, dass alles nachvollziehbar sei.

Audits brauchen Datensätze, die voneinander abweichen

Der öffentliche Statusdatensatz einer Organisation, der interne Release-Datensatz, der Evaluationsbericht, die Betriebsprotokolle und das Störungsregister sollten über denselben grundlegenden Zustand nicht Unterschiedliches aussagen. Sie sollten aber auch nicht identische Dokumente sein. Jedes hat ein anderes Publikum und einen anderen Zweck. Der öffentliche Datensatz kann den beabsichtigten Zweck, den Status, bekannte Einschränkungen und einen Weg zu weiteren Informationen angeben. Die technische Datei kann detaillierte Architektur, Daten, Tests und Kontrollen enthalten. Der Betriebsdatensatz kann Ereignis-Traceability auf Ereignisebene enthalten. Die Änderungsdatei kann erklären, warum eine frühere Schlussfolgerung überarbeitet wurde.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Vor allem aber verändert die Frage die Rolle des Wandels. Wandel ist kein Peinlichkeitsfall mehr, den die Dokumentation zu verbergen sucht. Er wird zu einem Ereignis erster Klasse im Evidenzmodell des Systems. Manche Änderungen erfordern kaum mehr als einen Eintrag. Manche lösen einen Test aus. Manche eröffnen die Freigabeentscheidung neu. Das disziplinierte Unternehmen verwechselt diese Kategorien nicht und braucht keinen künftigen Vorfall, um zu entdecken, dass es sie gibt.

Also ja: Eine Aufsichtsbehörde kann ein sich bewegendes Ziel prüfen. Die Prüfung beginnt damit, den falschen Gegensatz zwischen einem eingefrorenen Modellblatt und einem völlig unerkennbaren Live-Dienst abzulehnen. Erfassen Sie den Zustand. Formulieren Sie die Behauptung. Bewahren Sie die Bedingungen. Verknüpfen Sie die Evidenz mit der Entscheidung. Dokumentieren Sie, was sich ändert. Bewerten Sie neu, wenn die Verknüpfung nicht mehr trägt. Das Ziel darf sich bewegen. Die Spur muss lesbar bleiben.

Quellen