Was Europa aus Sicherheitsfallstudien lernen kann

Ein Safety Case ist ein lebendiges Argument von Gefahren und Annahmen über Evidenz, Restrisiko bis hin zu einer Entscheidung. Es bietet KI-Teams eine...

Was Europa aus Sicherheitsfallstudien lernen kann

Eine Datei, die antworten muss, bevor der Zug fährt

Die europäischen Eisenbahnvorschriften beginnen mit einer unspektakulären Frage: Was hat sich geändert. Eine Änderung kann technischer, betrieblicher oder organisatorischer Art sein. Sie kann Ausrüstung, ein Verfahren, eine Personalregelung oder eine Schnittstelle zwischen Organisationen betreffen. Die Gemeinsame Sicherheitsmethode für Risikobewertung und Risikobeurteilung verlangt vom Antragsteller, die Bedeutung dieser Änderung zu bewerten, bei Bedarf einen Risikomanagementprozess anzuwenden und eine unabhängige Bewertungsstelle einzuschalten, die prüft, ob der Prozess und seine Ergebnisse korrekt angewendet wurden. Die Regel interessiert nicht, ob die Änderung mit Zuversicht angekündigt wurde. Sie interessiert, ob die Begründung für den Weiterbetrieb überprüfbar ist.

Diese Gewohnheit lohnt es, in die KI zu übernehmen. Ein System wird nicht sicher, weil sein Modell klug ist, seine Oberfläche ruhig wirkt oder sein Anbieter einen ansehnlichen Testbericht vorgelegt hat. Es wird für eine definierte Nutzung vertretbar, wenn eine Organisation erklären kann, was sie behauptet, welche Gefahren hinter der Behauptung stehen, welche Annahmen die Behauptung möglich machen, welche Belege jedes Glied stützen, wer das verbleibende Risiko übernommen hat und was die Entscheidung wieder öffnen würde. Das Ergebnis wird gemeinhin als Sicherheitsnachweis bezeichnet: ein strukturiertes Argument, das durch Belege gestützt, durch Bedingungen begrenzt und durch Änderungen aufrechterhalten wird.

Ein Sicherheitsnachweis ist keine Geschichte über einen imaginären Unfall. Er ist eine Möglichkeit, sich zu weigern, den Unfall die gesamte Beweisführung tragen zu lassen. Er stellt die schwierigen Fragen, solange Konstruktion, Beschaffung und Betriebspraxis noch geändert werden können. Das macht ihn für Eisenbahnen, Luftfahrt, Medizinprodukte, industrielle Steuerung und kritische Infrastruktur nützlich. Es macht ihn auch für KI nützlich, wo eine Komponente gleichzeitig statistisch beeindruckend und betrieblich unvorbereitet sein kann. Ein Modell kann einen Test bestehen, während das System darum herum keine sichere Antwort auf Unsicherheit, keinen rechenschaftspflichtigen Betreiber und keinen Weg hat, eine schlechte Entscheidung zu korrigieren.

Diese Unterscheidung ist in Europa wichtig, weil der Rechtsakt über künstliche Intelligenz von Hochrisikosystemen bereits verlangt, mit einem kontinuierlichen, dokumentierten Risikomanagementprozess zu leben. Artikel 9 beschreibt die iterative Identifizierung, Schätzung, Bewertung und Behandlung von Risiken während des gesamten Systemlebenszyklus, einschließlich vernünftigerweise vorhersehbarem Missbrauch und Informationen aus der Überwachung nach dem Inverkehrbringen. Artikel 11 verlangt technische Dokumentation, bevor ein System auf den Markt gebracht wird, und sagt, dass diese auf dem neuesten Stand gehalten werden muss. Diese Bestimmungen verwenden Sicherheitsnachweis nicht als universelles Etikett. Sie beschreiben jedoch die Gewohnheiten, die einen Sicherheitsnachweis glaubwürdig machen.

Ein Sicherheitsnachweis macht den Weg von einem Sicherheitsanspruch zu einer Freigabeentscheidung sichtbar genug, um ihn anzufechten.

Sicherheitsnachweis ist kein Testbericht

Ein Testbericht beantwortet eine Frage zu einem Test. Er hält fest, was getestet wurde, unter welchen Bedingungen, mit welchem Ergebnis und, wenn die Arbeit gut ist, mit welchen Einschränkungen. Das ist wertvoll. Ein Sicherheitsnachweis stellt eine andere Frage: Gibt es ein ausreichend gestütztes Argument, dass dieses System für diesen Zweck akzeptabel ist, in diesem Kontext, mit diesen Personen, Kontrollen und verbleibenden Risiken. Ein Testergebnis kann ein Teil dieses Arguments sein. Es kann nicht stillschweigend zum gesamten Argument werden, nur weil die Tabelle grüne Zellen enthält.

Angenommen, ein Klassifikator wurde gegen einen beschrifteten Datensatz getestet. Der Bericht kann uns sagen, wie er auf diesem Datensatz abgeschnitten hat, vielleicht nach Klasse, Schwellenwert oder Arbeitspunkt. Er sagt uns nicht von selbst, ob die Eingaben im Produktivbetrieb dieselbe Bedeutung haben, ob die betroffene Bevölkerungsgruppe repräsentiert ist, ob eine prüfende Person eine schwache Ausgabe erkennen kann, ob ein Einspruch möglich ist, ob ein Anbieter das Modell ohne Vorankündigung ändern kann oder ob die Organisation eine nachgelagerte Aktion stoppen und rückgängig machen kann. Diese Fragen gehören zum System und seiner Nutzung, nicht nur zur Komponente.

Der gegenteilige Fehler ist ebenfalls häufig. Eine umfangreiche Nachweismappe kann Hunderte von Seiten enthalten und dennoch kein Argument liefern. Ein Katalog aus Tests, Richtlinien und Besprechungsnotizen ist kein Sicherheitsnachweis, wenn keine Behauptung sie verbindet. Belege brauchen eine Aufgabe. Ein Test kann eine Behauptung über Robustheit stützen. Eine Rollenbeschreibung kann eine Behauptung über Befugnisse stützen. Eine Rückfallübung kann eine Behauptung über Wiederherstellung stützen. Ein Prüfpfad kann eine Behauptung über Rückverfolgbarkeit stützen. Ohne die Beziehung zwischen Behauptung und Beleg ist die Datei ein Archiv von Aktivitäten, keine Erklärung von Sicherheit.

Deshalb kann ein Sicherheitsnachweis an einer Stelle kürzer sein als ein Testbericht und an anderer Stelle umfangreicher. Er wächst um die Gefahren und die Entscheidungen herum. Ein Entwurfswerkzeug mit geringen Folgen kann ein bescheidenes Argument benötigen, das Umfang, Datenverarbeitung, Prüfung und Korrektur abdeckt. Ein System, das mit klinischen, Verkehrs-, Finanz- oder öffentlichen Dienstleistungsentscheidungen verbunden ist, benötigt mehr Belege, weil mehr Menschen vom Ergebnis abhängen und weil der Weg zur Abhilfe schwierig sein kann. Der Umfang folgt der Konsequenz und der Unsicherheit, nicht der modischen Länge der Modellkarte.

Das Argument sollte auch Komponentenbelege von Betriebsbelegen unterscheiden. Komponentenbelege betreffen das Modell, den Algorithmus oder den Sensor isoliert oder in einer kontrollierten Integration. Betriebsbelege betreffen den tatsächlichen Arbeitsablauf: Zugriff, Aktualität der Daten, menschliche Prüfung, Warteschlangen, Werkzeugberechtigungen, Störungsbearbeitung und Änderungskontrolle. Ein Modell kann stabil sein, während eine Warteschlange zusammenbricht. Ein Arbeitsablauf kann gut gestaltet sein, während ein Anbieter das Eingabeschema ändert. Sicherheitsnachweise zwingen beide Sichtweisen auf dieselbe Seite, was leicht unbequem und daher gesund ist.

Beginnen Sie mit einer Behauptung, die Grenzen hat

Jeder Sicherheitsnachweis beginnt mit einer Behauptung auf oberster Ebene. Die Behauptung sollte eng genug sein, um getestet zu werden, und nützlich genug, um eine Entscheidung zu leiten. Der Satz dieses KI-System ist sicher ist keine Behauptung mit Grenzen. Sicher für wen, bei welcher Tätigkeit, unter welchen Bedingungen und mit welchen Kontrollen. Eine bessere Behauptung könnte besagen, dass eine bestimmte Entscheidungsunterstützungsfunktion für eine benannte Gruppe geschulter Bediener akzeptabel ist, vorausgesetzt, das System wird nur für Empfehlungen verwendet, Belege und Unsicherheit werden angezeigt, eine Person mit Befugnis prüft das Ergebnis und definierte Stopp- und Korrekturwege sind verfügbar.

Dieser Satz ist weniger vermarktbar und viel wertvoller. Er benennt den Zweck, die handelnde Person, die Grenze und die Bedingungen. Er zeigt auch auf, was die Behauptung falsch machen würde. Wenn dieselbe Funktion direkt mit einer automatischen Entscheidung verbunden ist, deckt die Behauptung das nicht mehr ab. Wenn die vorgesehenen Nutzer nicht geschult sind oder eine Ausgabe nicht anfechten können, schwächt sich die Behauptung ab. Wenn sich eine Datenquelle ändert und nicht zurückverfolgt werden kann, kann der Beleg für die Behauptung verfallen. Eine gute Behauptung auf oberster Ebene trägt ihre eigene Liste von Wegen, wieder eröffnet zu werden.

Ansprüche lassen sich zerlegen. Das System bleibt innerhalb seines vorgesehenen Zwecks. Die Eingaben erfüllen die genannten Qualitäts- und Berechtigungsbedingungen. Die Modellausgabe wird so interpretiert, dass kein unsicheres Automatisierungs-Bias entsteht. Maßnahmen mit hohen Konsequenzen erhalten eine Überprüfung, die ihrem Risiko angemessen ist. Bediener können eine Ausgabe verwerfen oder umkehren. Die Organisation kann eine bedeutsame Abweichung erkennen. Eine Änderung wird nicht freigegeben, ohne die betroffenen Annahmen zu prüfen. Jeder Teilanspruch benötigt Kontrollen und Nachweise. Der Baum ist keine Illustration für eine Folie; er ist der Weg, über den ein Prüfer ein schwaches Glied lokalisieren kann.

Ein Anspruch sollte auch sagen, was er nicht zu beweisen versucht. Der Fall kann die sichere Nutzung für eine Aufgabe stützen, ohne allgemeine Intelligenz, universelle Fairness oder Eignung für jede Bevölkerungsgruppe zu beweisen. Er kann eine Freigabe unter einem definierten Einsatzprofil stützen, ohne zu beweisen, dass eine nicht dokumentierte Konfiguration sich genauso verhält. Nicht-Ansprüche sind keine Bescheidenheitsverzierungen. Sie verhindern, dass ein enges Ergebnis sich durch eine Organisation als viel größeres Versprechen verbreitet.

Hinter dieser Präzision steht ein nützlicher europäischer Instinkt. Die Verordnung 402/2013 verlangt von einem Eisenbahn-Antragsteller zu entscheiden, ob eine Änderung bedeutsam ist, ein Risikoakzeptanzprinzip zu wählen und gegebenenfalls eine unabhängige Bewertung heranzuziehen. Der Antragsteller muss nicht beweisen, dass jeder erdenkliche zukünftige Eisenbahnzustand sicher ist. Er muss die aktuelle Änderung und ihre Schnittstellen so verständlich machen, dass eine verhältnismäßige Entscheidung möglich ist. KI-Teams können dieselbe Disziplin übernehmen. Benennen Sie die Änderung, benennen Sie den Betriebskontext und machen Sie die Grenze sichtbar.

Gefahren sind Bedingungen, keine Schlagzeilen

Eine Gefahr ist ein Zustand, der zu Schaden führen kann. Diese Unterscheidung ist nützlicher, als sie zunächst erscheint. Eine falsche Leistungsentscheidung ist ein Ergebnis. Eine Gefahr könnte ein unvollständiger Datensatz sein, kombiniert mit einem System, das eine nicht belegte Empfehlung als genehmigungsreif darstellt. Eine verzögerte Wartungswarnung ist ein Ergebnis. Eine Gefahr könnte ein veralteter Sensor-Datenstrom sein, den der Arbeitsablauf als aktuell behandelt. Ein Datenschutzverstoß ist ein Ergebnis. Eine Gefahr könnte eine zu weit gefasste Abrufberechtigung sein, gekoppelt mit einem Werkzeug, das Quellmaterial in einen dauerhaften Datensatz kopiert.

Gefahren so zu beschreiben, verlagert die Aufmerksamkeit nach vorn. Es ermöglicht Gestaltungs- und Betriebskontrollen. Wenn die Gefahr eine nicht belegte Empfehlung mit unangemessener Autorität ist, könnte eine Kontrolle Quellennachweise verlangen, Unsicherheit sichtbar machen, die Aktion einschränken und einen Überprüfungsweg bieten. Wenn die Gefahr veraltete Eingaben sind, könnte eine Kontrolle die Aktualität prüfen, den Datenzustand kennzeichnen, die Aktion blockieren oder an eine Person weiterleiten. Wenn die Gefahr übermäßiger Zugriff ist, könnte eine Kontrolle den Abruf einschränken, Identitäten trennen, Ausgaben schwärzen und die Zugriffsentscheidung protokollieren. Die Kontrolle sollte die Bedingung angehen, nicht nur versprechen, im Umgang mit dem Ergebnis vorsichtig zu sein.

Die Gefahrenanalyse sollte vorhersehbare Fehlanwendung einschließen, nicht nur den Zweck, der in einem Beschaffungsdokument steht. Der KI-Verordnung macht dies für Hochrisikosysteme ausdrücklich. Artikel 9 verlangt eine Bewertung der Risiken, wenn ein System bestimmungsgemäß und unter vernünftigerweise vorhersehbarer Fehlanwendung verwendet wird. Fehlanwendung bedeutet nicht jede absurde Anfrage. Sie bedeutet Verwendungen, die ein kompetentes Team anhand der Schnittstelle, der Anreize, der Anweisungen und des umgebenden Arbeitsablaufs vorhersehen könnte. Wenn der schnellste Weg im System darin besteht, eine Empfehlung anzunehmen, ohne ihre Nachweise zu lesen, gehört dieser Weg in die Analyse, auch wenn die Richtlinie eine Überprüfung vorschreibt.

Gefahren leben auch an Schnittstellen. Ein Modell kann eine begrenzte Empfehlung liefern, aber eine Integration kann daraus eine unbegrenzte Anweisung machen. Ein Anbieter kann einen versionierten Endpunkt bereitstellen, aber eine Bereitstellung kann Antworten über den Gültigkeitszeitraum hinaus zwischenspeichern. Eine öffentliche Behörde kann die Entscheidungsverantwortung behalten, aber ein Vertrag kann den Anbieter zur einzigen Partei machen, die den Nachverfolgungsverlauf einsehen kann. Die Systemgrenze für einen Sicherheitsnachweis muss dem kausalen Pfad bis zur Konsequenz folgen. Die Grenze nur um das Modell zu ziehen, ist ein effizienter Weg, die Arbeit zu übersehen, die das Modell relevant macht.

Nicht jede Gefahr verdient dieselbe Behandlung. Einige können durch Design reduziert werden. Einige benötigen prozessuale Kontrollen oder menschliche Überprüfung. Einige können überwacht und unter Bedingungen akzeptiert werden. Einige zeigen an, dass die vorgeschlagene Nutzung nicht angemessen ist. Ein Sicherheitsnachweis sollte die Begründung zeigen, nicht hinter einer universellen Risikobewertung verstecken. Die europäische Eisenbahnmethode erlaubt verschiedene Prinzipien der Risikoakzeptanz, einschließlich bewährter Verfahren, Vergleich mit ähnlichen Teilen eines Systems und expliziter Risikoschätzung. Die Lehre ist nicht, dass eine Methode überall gewinnt. Die Lehre ist, dass die Methode und ihre Eignung für die Änderung dokumentiert werden müssen.

Annahmen sind tragend

Jedes Sicherheitsargument ruht auf Annahmen. Die Bedienperson ist geschult. Die Quelle ist aktuell. Der Schwellenwert hat die Bedeutung, die das Team ihm zuschreibt. Die Person, die die Warnung erhält, kann rechtzeitig handeln. Der externe Dienst wird verfügbar sein oder es gibt eine Ausweichlösung. Die Ausgabe wird eine Empfehlung bleiben und nicht zu einer faktischen Entscheidung werden. Die Organisation wird bemerken, wenn eine Modellaktualisierung das Verhalten ändert. Viele Sicherheitsfehler entstehen nicht, weil eine Annahme unvernünftig ist. Sie entstehen, weil eine Annahme unsichtbar ist.

Eine Annahme gehört in den Nachweis, mit einer verantwortlichen Stelle und einer Möglichkeit, sie zu prüfen. Wenn das Argument auf geschulten Prüfpersonen beruht, sollte der Nachweis die erforderliche Kompetenz, deren Feststellung und die Folgen bei Personalwechsel angeben. Wenn das Argument darauf beruht, dass eine Quelle innerhalb eines Aktualitätsfensters bleibt, sollte das System die Aktualität aufzeichnen und die Aktion dort davon abhängig machen, wo es nötig ist. Wenn das Argument darauf beruht, dass eine Integration ein Feld erhält, sollten der Schnittstellenvertrag und ein Test die Abhängigkeit sichtbar machen. Eine Annahme, die nicht geprüft werden kann, ist ein Risiko mit einem freundlicheren Namen.

Annahmen können auch die Außenwelt betreffen, nicht nur die Software. Ein Krankenhaus kann von einem klinischen Behandlungspfad abhängen. Ein Bahnbetreiber kann von einer Signaltechnik-Schnittstelle abhängen. Eine öffentliche Stelle kann von einem gesetzlichen Verfahren und einer menschlichen Entscheidungsperson abhängen, die die Autorität behält. Ein Hersteller kann davon abhängen, dass Wartung in einem festgelegten Intervall durchgeführt wird. Der Sicherheitsnachweis kontrolliert nicht jede äußere Bedingung. Er muss jedoch angeben, welche Bedingungen er voraussetzt, welche Partei sie verantwortet und wie eine Änderung erkannt wird.

Wenn sich Annahmen ändern, sollte sich der Nachweis nicht stillschweigend dehnen. Ein Team kann mit einer reinen Empfehlungsnutzung beginnen und dann eine automatische Übergabe hinzufügen, weil die Empfehlung häufig angenommen wurde. Das Modell hat sich nicht geändert, aber die Autorität und die Gefahr schon. Ein Datenanbieter kann eine neue Kategorie hinzufügen, die harmlos erscheint, bis sie die Bedeutung einer nachgelagerten Regel verändert. Eine Bereitstellung kann von geschulten Fachleuten zu einem allgemeinen Supportteam wechseln. Das sind Änderungen am Nachweis, auch wenn die Versionsnummer des Modells dieselbe bleibt.

Annahmen sind besonders wichtig für probabilistische Systeme, weil ein stabiler Durchschnitt eine instabile Randlage verbergen kann. Der Nachweis sollte angeben, wo das System voraussichtlich unsicher ist, welche Hinweise auf diese Unsicherheit deuten und welche menschliche oder technische Kontrolle übernimmt. Das Ziel ist nicht, so zu tun, als ließe sich Unsicherheit beseitigen. Es geht darum, eine unausgesprochene Erwartung von Gewissheit nicht zur Betriebspolitik werden zu lassen.

Belege sind kein Pass für jeden Kontext. Ihre Annahmen bestimmen, wohin sie reisen können.

Belege brauchen eine lückenlose Herkunftskette

Ein Beleg in einem Sicherheitsnachweis ist mehr als ein Ergebnis, das in eine Tabelle kopiert wurde. Er hat eine Identität, einen Geltungsbereich, ein Datum, eine Methode, eine verantwortliche Person oder ein verantwortliches Team und eine Beziehung zu der Behauptung, die er stützt. Ein Test braucht eine definierte Eingabe und Konfiguration. Eine Überprüfung braucht eine Fragestellung und eine Entscheidung. Eine Übung braucht eine erwartete Reaktion und eine Beobachtung. Ein Protokoll braucht genügend Kontext, um ohne Rückgriff auf Erinnerung interpretiert werden zu können. Ein Quelldatensatz braucht eine Herkunftsspur. Die Details unterscheiden sich je nach Fachgebiet, aber das Prinzip bleibt stabil: Belege sollten auch nach dem Meeting, in dem sie überzeugend klangen, prüfbar sein.

Der AI Act verleiht diesem Prinzip für Hochrisikosysteme rechtliches Gewicht. Artikel 11 verlangt, dass die technische Dokumentation vor dem Inverkehrbringen des Systems verfügbar und auf dem neuesten Stand gehalten wird. Artikel 12 verlangt die automatische Aufzeichnung relevanter Ereignisse über die gesamte Lebensdauer des Systems, wobei die Protokollierungsfunktionen dem vorgesehenen Zweck angemessen sein und sich zur Identifizierung von Risiken, zur Unterstützung der Überwachung nach dem Inverkehrbringen und zur Überwachung des Betriebs eignen müssen. Artikel 13 verlangt Informationen, die es Bereitstellern ermöglichen, Fähigkeiten, Einschränkungen, vorhersehbare Risiken, menschliche Aufsicht und Eingabeanforderungen zu verstehen. Ein Sicherheitsnachweis verbindet diese Aufzeichnungen, statt sie in getrennten Compliance-Schubladen zu belassen.

Belege müssen ihre Bedingungen bewahren. Ein Leistungsergebnis ohne seine Testpopulation kann falsch gelesen werden. Ein Robustheitsergebnis ohne die verwendeten Störungen kann überbewertet werden. Eine Faktorenprüfung ohne den Arbeitsablauf und den Zeitdruck, unter denen sie durchgeführt wurde, kann zu einem allgemeinen Kompliment werden. Ein Vorfallprotokoll ohne die geltende Version, den Datenzustand und die Berechtigungen kann eine attraktive, aber falsche Ursachenanalyse ergeben. Je folgenreicher die Entscheidung, desto weniger akzeptabel ist es, ein Ergebnis von den Umständen zu lösen, die es wahr gemacht haben.

Belege können qualitativ oder quantitativ sein. Ein dokumentiertes Expertenurteil kann ein gültiger Beleg sein, wenn die Fragestellung angemessen ist, die Expertise benannt und die Begründung festgehalten ist. Ein numerischer Wert kann ein schwacher Beleg sein, wenn Nenner, Schwellenwert oder Testbedingungen unklar sind. Es gibt keine moralische Hierarchie, in der eine Zahl automatisch eine sorgfältige Beobachtung übertrumpft. Der Nachweis sollte die Zweckmäßigkeit und die Unsicherheit erklären, nicht Ehrfurcht vor Dezimalstellen zelebrieren.

Rückverfolgbarkeit macht Uneinigkeit auch produktiv. Eine prüfende Person sollte sagen können, welche Behauptung nicht belegt ist, welche Annahme zu optimistisch ist oder welche Kontrolle nicht durchgeführt wurde. Der Fall wird dann zu einem gemeinsamen Gegenstand der Auseinandersetzung und nicht zu einem zeremoniellen Genehmigungspaket. Das ist ein Grund, warum sicherheitskritische Branchen in unabhängige Bewertung und strukturierte Sicherheitsnachweise investieren. Ziel ist nicht, Widerspruch bequem zu machen. Ziel ist, Widerspruch lokalisierbar zu machen.

Restrisiko ist eine Entscheidung, kein Rest

Risiko verschwindet nicht, weil Kontrollen hinzugefügt wurden. Das nach Kontrollen verbleibende Risiko ist das Restrisiko. Es muss beschrieben und von einer Stelle akzeptiert werden, die in der Lage ist, die Belege zu verstehen, Bedingungen aufzuerlegen und die Nutzung zu stoppen, wenn die Bedingungen nicht erfüllt sind. Ein Risiko als akzeptabel zu bezeichnen, ist nicht dasselbe wie zu sagen, es sei gering. Es bedeutet, dass die Organisation eine begründete Entscheidung über die verbleibende Gefährdung in einem definierten Kontext getroffen und die Grundlage für diese Entscheidung nicht verborgen hat.

Artikel 9 der KI-Verordnung verwendet diese Sprache direkt für Hochrisikosysteme. Das für jede Gefährdung relevante Restrisiko und das Gesamtrestrisiko müssen als akzeptabel beurteilt werden. Die Verordnung verlangt außerdem die Beseitigung oder Verringerung, soweit technisch machbar, sowie Minderungs- und Kontrollmaßnahmen, wenn Risiken nicht beseitigt werden können. Das ist eine sinnvolle Reihenfolge. Zuerst das Design ändern, wenn möglich. Dann Kontrollen hinzufügen. Dann festhalten, was übrig bleibt. Ein Warnhinweis ist keine Ausrede, um ein vermeidbares Risiko in der Architektur zu belassen.

Das Restrisiko sollte die Umkehrbarkeit einschließen. Die Risikokriterien der KI-Verordnung berücksichtigen, ob ein Ergebnis korrigiert oder umgekehrt werden kann, und stellen fest, dass nachteilige Auswirkungen auf Gesundheit, Sicherheit oder Grundrechte nicht allein deshalb als leicht korrigierbar gelten sollten, weil es einen technischen Rückgängig-Button gibt. Das ist eine leise, aber wichtige Unterscheidung. Ein Entwurf kann korrigiert werden. Ein verlorener Vorteil, ein verweigerter Dienst oder eine öffentliche Anschuldigung können viel schwerer zu beheben sein. Der Fall sollte stärkere Kontrollen dort vorsehen, wo die betroffene Person das Ergebnis realistisch nicht ablehnen oder rückgängig machen kann.

Die Akzeptanz muss Bedingungen haben. Ein System kann für einen begrenzten Pilotversuch, ein geschultes Team, eine benannte Datenquelle und einen Überprüfungsweg akzeptiert werden. Es darf nicht für eine andere Personengruppe, einen unbeaufsichtigten Arbeitsablauf oder eine Integration akzeptiert werden, die Belege entfernt. Bedingungen sollten so formuliert sein, dass eine betreibende Person erkennen kann, ob sie noch gelten. Wenn eine Bedingung nur darin besteht, dass Nutzende Urteilsvermögen anwenden, sagt der Fall nicht, wie das System das Urteilsvermögen unterstützt oder was passiert, wenn die Arbeitsbelastung das Urteilsvermögen erschwert.

Eine Restrisikoentscheidung braucht auch ein Ablaufdatum oder einen Überprüfungsauslöser. Ein festes Kalenderdatum kann helfen, aber Ereignisse sind meist aussagekräftiger: eine Modelländerung, eine neue Datenquelle, ein wesentlicher Vorfall, ein Driftsignal, eine Änderung bei den Nutzenden, eine neue rechtliche Pflicht oder ein Scheitern einer Kontrollübung. Die Entscheidung ist kein Talisman, der auf die Veröffentlichung gelegt wird. Sie ist eine Genehmigung mit einem Wartungsplan.

Menschliche Aufsicht muss Autorität haben

Menschliche Aufsicht wird oft so erwähnt, als ob eine Person, die irgendwo in der Nähe des Ergebnisses steht, das System sicher macht. Die KI-Verordnung ist anspruchsvoller. Artikel 14 verlangt, dass Hochrisikosysteme so gestaltet werden, dass natürliche Personen sie während der Nutzung wirksam überwachen können. Die Aufsicht muss im Verhältnis zu Risiko, Autonomie und Kontext stehen. Die dafür eingesetzten Personen sollten Fähigkeiten und Grenzen verstehen, Anomalien erkennen, Automatisierungsbias erkennen, Ergebnisse interpretieren, entscheiden, das System nicht zu nutzen oder zu übersteuern, und durch ein sicheres Verfahren eingreifen oder das System stoppen können.

Das sind Anforderungen an die Gestaltung ebenso wie an die personelle Ausstattung. Eine prüfende Person kann eine Ausgabe nicht interpretieren, wenn die Belege verborgen sind. Eine prüfende Person kann eine Empfehlung nicht in Frage stellen, wenn die Oberfläche die Annahme als einzig bequemen Weg darstellt. Eine prüfende Person kann ein System nicht anhalten, wenn die Stopp-Aktion eine Berechtigung voraussetzt, die niemand erteilt hat. Eine prüfende Person kann keine sinnvolle Aufsicht ausüben, wenn sie nur an der Durchsatzmenge gemessen wird. Ein Safety Case sollte die menschliche Rolle daher als ein Kontrollelement mit Eingaben, Befugnissen, Arbeitsbelastung, Schulung und beobachtbarem Verhalten behandeln.

Die Befugnis ist das Detail, das höfliche Beschreibungen auslassen. Wer darf den Arbeitsablauf pausieren. Wer darf eine Aktion rückgängig machen. Wer darf erklären, dass eine Annahme nicht mehr gilt. Wer darf den Lieferanten kontaktieren. Wer ist für den Datensatz verantwortlich. Wer entscheidet, ob das Restrisiko weiterhin akzeptabel ist. Wenn niemand die Befugnis hat, ist die Beschreibung des Menschen im Regelkreis Theater. Die Person mag die Ausgabe sehen, aber Sehen ist nicht Regieren.

Gute Aufsicht ist auch selektiv. Das Ziel ist nicht, jeden trivialen Entwurf einem Gremium vorzulegen. Es geht darum, menschliches Urteilsvermögen dort einzusetzen, wo die Konsequenzen, die Unsicherheit oder die Anfechtbarkeit es erfordern. Manche Fälle können durch strukturierte Prüfungen bearbeitet werden. Manche erfordern eine geschulte Fachkraft. Manche erfordern zwei unabhängige Bestätigungen nach geltendem Recht. Manche sollten abgelehnt werden. Der Safety Case sollte die Auswahl erläutern und nachweisen, dass der gewählte Weg im tatsächlichen Betrieb verfügbar ist, nicht nur in einem Verfahrenshandbuch.

Es liegt eine bescheidene Art von Respekt in dieser Gestaltungsweise. Sie akzeptiert, dass Menschen ermüden, dass Warteschlangen wachsen, dass Oberflächen die Aufmerksamkeit lenken und dass eine Warnung, die hundertmal erscheint, aufhören kann, eine Warnung zu sein. Die Sicherheitstechnik hat dies durch Erfahrung in Verkehr und Industrie gelernt. KI-Teams müssen nicht jede Lektion wiederholen, indem sie ein vermeidbares Experiment an der Öffentlichkeit durchführen.

Veränderung läuft dem Safety Case immer wieder über den Weg

Ein Safety Case ist lebendig, weil das System lebendig ist. Die Modellversion kann sich ändern, aber auch der Prompt, der Abrufindex, die Taxonomie, die Richtlinie, die Hardware, die personelle Ausstattung, die Oberfläche, die Datenquelle oder der Lieferant. Eine kleine Änderung kann eine Annahme ungültig machen oder ein Kontrollelement verschieben. Das daraus resultierende Risiko kann höher, niedriger oder einfach anders sein. Die richtige Antwort ist nicht, das System für immer einzufrieren. Es geht darum, Veränderung sichtbar zu machen, ihre Bedeutung einzuordnen und zu entscheiden, welche Teile der Argumentation erneut überprüft werden müssen.

Die Praxis der Eisenbahn bietet ein klares Muster. Die Verordnung 402/2013 wendet ihre gemeinsame Methode an, wenn technische, betriebliche oder organisatorische Änderungen das Eisenbahnsystem betreffen. Der Antragsteller bewertet die Bedeutung der Änderung und nutzt bei Bedarf Risikoakzeptanzprinzipien und eine unabhängige Bewertung. Die Verordnung weist auch darauf hin, dass die Gesamtheit der Änderungen seit dem letzten Risikoprozess von Bedeutung sein kann. Mehrere kleine Änderungen können sich zu einer bedeutenden summieren. Die KI-Governance braucht dasselbe Misstrauen gegenüber harmlos wirkenden Inkrementen.

Für KI sollte ein Änderungsprotokoll festhalten, was sich bewegt hat und was nicht. Haben sich die Modellgewichte geändert. Hat sich die Belegerhebung geändert. Haben sich die Werkzeugberechtigungen geändert. Hat sich die Nutzergruppe geändert. Hat sich der Schwellenwert verschoben. Ist der Arbeitsablauf an einem Punkt automatisch geworden, der zuvor nur beratend war. Ist der Fallback-Pfad verfügbar geblieben. Hat die Evaluierung den neuen Zustand erfasst. Das Protokoll sollte jede Antwort mit der betroffenen Behauptung, Gefahr, dem Kontrollelement oder der Annahme verknüpfen und die Tests oder Überprüfungen festlegen, die vor der Freigabe erforderlich sind.

Die Änderungskontrolle sollte einen sicheren Freigabemodus umfassen. Ein Schattenlauf, ein gestufter Weg, eine begrenzte Nutzergruppe, eine explizite Rollback-Bedingung oder eine menschliche Bestätigung können verhindern, dass das neue Verhalten zur institutionsweiten Tatsache wird, bevor es jemand geprüft hat. Diese Mechanismen sind kein Beleg dafür, dass das System schwach ist. Sie sind ein Beleg dafür, dass die Organisation versteht, dass neues Verhalten einen Ort zum Lernen braucht.

Die Überwachung nach dem Inverkehrbringen erweitert den Fall über die Freigabe hinaus. Artikel 9 verweist auf Daten, die gemäß Artikel 72 erhoben werden, und Artikel 72 verlangt ein dokumentiertes Überwachungssystem für Hochrisikosysteme während ihrer gesamten Lebensdauer. Die Überwachung sollte auf die Signale achten, die für die Behauptung von Bedeutung sind: veränderte Fehlermuster, ungewöhnliche Ablehnungen, unerwartete Nutzung, Ergebnisse von Einsprüchen, fehlende Nachweise, Sicherheitsvorfälle und Versagen menschlicher Kontrollen. Ein Dashboard, das nur die Betriebszeit meldet, ist eine fröhliche Art, ein Sicherheitsproblem zu übersehen.

Unabhängige Bewertung ist ein nützliches Übel

Menschen, die ein System gebaut haben, kennen seine Eleganz, seine Abkürzungen und den Druck, unter dem es entwickelt wurde. Dieses Wissen ist notwendig. Es reicht nicht aus, um das Risiko zu akzeptieren. Eine unabhängige Bewertung schafft Raum für jemanden, der das Argument infrage stellt, ohne dieselben Startanreize zu tragen. Unabhängigkeit erfordert keine Feindseligkeit oder ein externes Logo auf jeder Seite. Sie erfordert Kompetenz, Umfang, Zugang zu Nachweisen und die Befugnis, eine Meinungsverschiedenheit festzuhalten, die der Eigentümer nicht einfach löschen kann.

Die europäische Eisenbahnmethode macht diese Trennung konkret. Die ERA beschreibt eine Bewertungsstelle, die für die Prüfung der ordnungsgemäßen Anwendung des Risikobewertungsverfahrens und seiner Ergebnisse zuständig ist, mit Anforderungen an Kompetenz, Akkreditierung oder Anerkennung. Die Verordnung erlaubt eine unabhängige und kompetente externe oder interne Stelle, sofern sie die Kriterien erfüllt. Das Konzept ist verhältnismäßig und nicht theatralisch. Es erkennt an, dass Sicherheitsnachweise intern erbracht werden können, wenn die Unabhängigkeit real ist, und dass ein Gütesiegel keinen Prüfer retten kann, der die relevanten Nachweise nicht sehen kann.

Für KI kann Unabhängigkeit in Schichten erfolgen. Ein Domänenverantwortlicher prüft, ob die Nutzung legitim ist und ob die Gefahrenanalyse die Arbeit widerspiegelt. Ein technischer Prüfer prüft die Integration und die Fehlermodi. Ein Sicherheitsprüfer testet Zugriffs- und Manipulationspfade. Ein Betriebsprüfer prüft Arbeitslast, Eskalation und Wiederherstellung. Eine Governance- oder Compliance-Funktion prüft Aufzeichnungen und Pflichten. Für Anwendungen mit hohen Konsequenzen kann im Rahmen des einschlägigen Rechtsrahmens eine externe Bewertung oder ein benannter Stellen-Weg gelten. Der Sicherheitsnachweis sollte die Rolle jedes Prüfers und die Fragen, die er stellen darf, benennen.

Unabhängigkeit ist auch ein Schutz vor Intransparenz der Anbieter. Ein Anbieterbericht kann eine Behauptung stützen, aber der Betreiber muss wissen, was getestet wurde, unter welcher Konfiguration und welche Einschränkungen bestehen bleiben. Wenn ein kritisches Ergebnis bei Vertragsende nicht wiederholt, eingesehen oder übertragen werden kann, gehört die Abhängigkeit in den Fall. Die Beschaffung sollte Zugang zu Nachweisen, Versionsidentität, Vorfallmeldung, Änderungsmitteilung, Export, Rollback und einen praktikablen Ausstieg verlangen. Das Wort praktikabel trägt hier eine schwere Last. Ein Recht, das unter Zeitdruck nicht ausgeübt werden kann, ist keine große Kontrolle.

Eine gute Bewertung bringt mehr hervor als einen Genehmigungsstempel. Sie hält Bedingungen, offene Feststellungen, Nachweislücken, Restrisiko und erforderliche Folgemaßnahmen fest. Manchmal ist die richtige Entscheidung, mit Einschränkungen freizugeben. Manchmal ist es, zu verzögern. Manchmal ist es, die vorgeschlagene Nutzung abzulehnen. Eine Sicherheitskultur ist nicht eine, in der jeder Fall besteht. Es ist eine, in der die Entscheidung dem Argument folgt.

Was der KI-Verordnung zur Argumentation hinzufügt

Die KI-Verordnung macht nicht aus jeder KI-Bereitstellung eine Eisenbahn. Sie schafft jedoch einen europäischen Wortschatz für Risikomanagement, technische Dokumentation, Protokollierung, Transparenz, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit für Hochrisikosysteme. Ein Sicherheitsnachweis kann einer Organisation helfen, diese Pflichten zu einer operativen Erklärung zu verbinden, anstatt jeden Artikel als separate Compliance-Aufgabe zu behandeln.

Artikel 8 knüpft die Konformität an den vorgesehenen Zweck und den allgemein anerkannten Stand der Technik und ermöglicht es, erforderliche Prüfungen, Berichte, Informationen und Unterlagen in bestehende Harmonisierungsrechtsvorschriften der Union zu integrieren, soweit ein Produkt bereits davon erfasst ist. Das ist für die Sicherheitstechnik von Bedeutung. Er erkennt an, dass ein System möglicherweise bereits über einen ausgereiften Assurance-Prozess verfügt und dass die Verknüpfung von Dateien sinnvoller ist als deren Duplizierung. Der Fall sollte zeigen, wo die KI-Nachweise im umfassenderen Produkt- oder Dienstleistungsargument einzuordnen sind.

Artikel 11 und Anhang IV geben der technischen Dokumentation eine breite Struktur. Sie umfasst den vorgesehenen Zweck, Versionen, Schnittstellen, Hardware, Entwicklungsmethoden, Architektur, Datenherkunft und -merkmale, menschliche Aufsicht, vorab festgelegte Änderungen, Validierungs- und Prüfverfahren, Metriken, Prüfprotokolle und Maßnahmen zur Cybersicherheit. Das ist nicht dasselbe wie ein Safety Case, liefert aber viele der Objekte, die ein Safety Case benötigt. Ein Team kann jedes Objekt einer Anforderung zuordnen und aufdecken, was noch keinen Verantwortlichen oder keine Nachweise hat.

Die Protokollierungsanforderung in Artikel 12 ist besonders praxisnah. Wenn ein Hochrisikosystem technisch in der Lage sein muss, Ereignisse während seiner gesamten Lebensdauer automatisch aufzuzeichnen, sollte die Freigabeentscheidung die Frage stellen, was das System tatsächlich rekonstruieren kann. Welche Eingabe, welches Modell, welche Konfiguration, welcher Nachweis, welcher Tool-Aufruf, welcher menschliche Eingriff und welche nachgelagerte Aktion lassen sich miteinander verknüpfen. Welche Protokolle unterliegen der Kontrolle des Anbieters und welche der Kontrolle des Betreibers. Wie werden sie geschützt und aufbewahrt. Kann eine betroffene Person oder Behörde den relevanten Pfad nachvollziehen, ohne einen Datensatz mit unzusammenhängenden personenbezogenen Daten zu erhalten.

Artikel 15 ergänzt eine Lebenszyklusbetrachtung von Genauigkeit, Robustheit und Cybersicherheit, einschließlich der Widerstandsfähigkeit gegenüber Fehlern, Störungen und Inkonsistenzen sowie, soweit relevant, Backup- oder Ausfallsicherheitsplänen. Ein Safety Case gibt diesen Begriffen einen Ort, an dem sie zur Geltung kommen. Die Aussage ist nicht, dass ein Wert hoch ist. Die Aussage ist, dass das System für seinen vorgesehenen Zweck konsistent funktioniert, dass bekannte Fehlerbedingungen begrenzt sind und dass der Arbeitsablauf eine sichere Reaktion vorsieht, wenn sie auftreten. Die Nachweise müssen die Bedingungen angeben, unter denen die Schlussfolgerung gilt.

Die Pflichten der Verordnung gelten je nach System, Anbieter, Betreiber und Verwendung. Ein Safety Case sollte nicht so tun, als ob eine allgemeine Vorlage die Einstufung oder Rechtsberatung festlegt. Er sollte die Entscheidung über die Anwendbarkeit, ihre Begründung und die Punkte, die sie ändern würden, dokumentieren. Das ist ein weiterer Vorteil expliziter Annahmen. Wenn sich eine Tatsache ändert, weiß die Organisation, welcher Teil des Arguments Aufmerksamkeit benötigt, anstatt die gesamte Rechtslage in Panik neu zu entdecken.

Die Luftfahrt behandelt Lernen als Teil der Assurance

Das Konzeptpapier zur künstlichen Intelligenz der Europäischen Agentur für Flugsicherheit, Ausgabe 2, ist hilfreich, weil es KI-Sicherheit nicht als eine einzelne Modelleigenschaft beschreibt. Das Papier verfeinert die Leitlinien für Anwendungen der Stufe 1, die menschliche Fähigkeiten erweitern, und vertieft die Arbeit an Learning Assurance, KI-Erklärbarkeit und ethikbasierter Bewertung. Es befasst sich auch mit Systemen der Stufe 2, bei denen KI unter menschlicher Aufsicht automatisch Entscheidungen treffen kann, und hebt die Zusammenarbeit zwischen Mensch und KI sowie die Gestaltung sicherer Interaktion hervor.

Die wichtige Idee ist nicht, dass jede Organisation die Terminologie der Luftfahrt übernehmen sollte. Es geht darum, dass die Assurance der Beziehung zwischen dem System und der menschlichen Arbeit folgen muss. Ein Modell, das eine geschulte Bedienperson unterstützt, ist nicht dasselbe Sicherheitsproblem wie ein Modell, das entscheidet, während eine Person lediglich überwacht. Die Fähigkeit der Bedienperson, zu verstehen, einzugreifen und sich zu erholen, ist Teil des Systems. Gleiches gilt für die Grenzen rund um Lernen, Aktualisierungen und Nachweise. Das EASA-Papier bietet KI-Teams ein europäisches Beispiel einer Branche, die versucht, diese Beziehungen vor der Einführung explizit zu machen.

Lernassurance ist ein nützlicher Begriff, weil maschinelles Lernen die übliche Evidenzlogik verändern kann. Eine konventionelle Softwarefreigabe kann gegen eine definierte Implementierung getestet werden. Ein adaptives System kann sein Verhalten ändern, wenn sich Daten, Zustand oder Umgebung ändern. Der Sicherheitsnachweis muss daher festlegen, was lernen darf, was eingefroren ist, wie die Änderung erkannt wird, welche Evidenz aktualisiert wird und wann das System erneut in einen Akzeptanzprozess eintritt. Wenn Lernen außerhalb des Nachweises liegt, betrifft der Nachweis das System von gestern.

Mensch-KI-Teaming verändert auch die Bedeutung von Aufsicht. Der Mensch ist keine Notbremse, die an einer Maschine angebracht ist, die ohne Fahrer entworfen wurde. Das Team ist eine soziotechnische Anordnung mit Rollen, Erwartungen, Signalen, Autorität und Schulung. Eine sichere Interaktion kann erfordern, dass die Maschine eine Einschränkung erklärt, eine Bestätigung anfordert, eine Aktion ablehnt oder Unsicherheit sichtbar macht. Sie kann erfordern, dass der Mensch die Maschine hinterfragt und die Organisation dieses Hinterfragen belohnt. Die Evidenz sollte die Interaktion untersuchen und sie nicht aus einem politischen Satz ableiten.

Auch hier ist kein erfundenes Flugzeug oder kein erfundener Unfall nötig, um den Punkt zu machen. Ein Konzeptpapier einer öffentlichen Behörde genügt, um zu zeigen, dass sich das europäische Sicherheitsdenken auf Lernen, menschliche Interaktion und Assurance als ein einziges Designproblem zubewegt. KI-Teams können das Material als Anstoß lesen, um zu fragen, was ihr eigenes System lernt, was die Bediener sehen können und welche Evidenz eine Änderung übersteht.

Ein zusammengesetztes Freigabetor, als solches gekennzeichnet

Illustratives zusammengesetztes Beispiel, kein berichtetes Ereignis: Stellen Sie sich einen öffentlichen Dienst vor, der ein KI-Tool in Betracht zieht, das Mitarbeitern hilft, eingehendes Fallmaterial zu organisieren, bevor eine Person die Entscheidung trifft. Das Tool ist nicht befugt, über Anspruchsberechtigung zu entscheiden, eine Mitteilung zu versenden oder einen Fall abzuschließen. Der vorgeschlagene Sicherheitsanspruch ist eng gefasst: geschulte Mitarbeiter können das Tool nutzen, um eine Prüfwarteschlange vorzubereiten, wenn der Quelldatensatz vollständig ist, das Evidenzpanel sichtbar ist, die Empfehlung klar als Empfehlung gekennzeichnet ist und der Mitarbeiter sie übersteuern, pausieren oder entfernen kann.

Der erste Zweig des Nachweises benennt Gefahren. Ein unvollständiger Datensatz könnte eine scheinbar kohärente Priorität erhalten. Ein veraltetes Politikdokument könnte die Empfehlung prägen. Eine Warteschlange könnte Druck auf einen Prüfer ausüben, die Reihenfolge ohne Prüfung zu akzeptieren. Ein Berechtigungsfehler könnte Material einer Person in einem anderen Fall offenlegen. Ein Lieferantenupdate könnte die Bedeutung einer Kategorie verändern. Dies sind keine Behauptungen, dass ein solches Ereignis eingetreten ist. Es sind Bedingungen, die das Team aus dem vorgeschlagenen Design vernünftigerweise vorhersehen kann.

Der nächste Zweig benennt Kontrollen. Vollständigkeit und Aktualität der Eingaben werden geprüft, bevor eine Empfehlung angezeigt wird. Die für den Vorschlag verwendete Evidenz ist neben dem Fall sichtbar. Die Aktion bleibt ein Entwurf, bis eine geschulte Person sie annimmt oder ändert. Eine fehlende Quelle leitet das Element auf einen anderen Pfad um. Berechtigungen werden an der Abrufgrenze getestet, nicht nur an der Benutzeroberfläche. Der Arbeitsablauf hat eine Pausensteuerung und einen manuellen Pfad. Eine Versionsänderung läuft in einem eingeschränkten Modus und kann zurückgerollt werden. Der Fall dokumentiert, warum jede Kontrolle existiert und welche Gefahr sie adressiert.

Evidenz muss dann die Kontrollen ausüben. Ein Datentest liefert unvollständige und veraltete Datensätze und dokumentiert das Ergebnis. Eine Usability-Überprüfung fragt, ob Mitarbeiter die Evidenz finden und die Empfehlung unter realistischer Arbeitslast verstehen können. Ein Zugriffstest prüft, ob ein Fall kein Material außerhalb seines Geltungsbereichs abrufen kann. Eine Freigabeprobe verifiziert, dass die Pausen- und Rollback-Pfade funktionieren. Eine Änderungsüberprüfung bestätigt, dass die neue Kategorie und Politik die Warteschlangenlogik nicht ungültig machen. Dies sind hypothetische Tests in diesem zusammengesetzten Beispiel, keine Berichte über Tests, die von einem benannten Dienst durchgeführt wurden.

Die Entscheidung ist an Bedingungen geknüpft. Das Werkzeug kann innerhalb des genannten Rahmens zur Vorbereitung der Warteschlange verwendet werden. Es darf nicht verwendet werden, um die inhaltliche Entscheidung zu treffen oder zu übermitteln. Die Bedingung, dass Mitarbeitende befugt sein müssen, eine Entscheidung zu überstimmen, ist einer Rolle zugewiesen. Die Bedingung, dass die Aktualität der Quelle erfasst wird, wird überwacht. Eine Änderung am Modell, an der Richtlinie, am Datenvertrag, an der Nutzergruppe oder an der nachgelagerten Aktion führt zur Wiedereröffnung des Falls. Wenn die Organisation diese Bedingungen nicht nachweisen kann, bleibt das Freigabetor geschlossen. Die Geschichte ist gerade deshalb nützlich, weil niemand so tun muss, als hätte es eine bestimmte Stadt, ein bestimmtes Team oder einen bestimmten Dienstag gegeben.

Ein kleines Beispiel aus unserem Trust Centre

Bei Dweve trifft unser öffentliches Trust Centre in seinem Bewertungsprotokoll eine ähnliche Unterscheidung. Die Seite „Evaluations" stellt eine Methode vor, die das Modell, die genaue Testreihe, die Konfiguration, den erfassten Zustand, die Belege und die Entscheidung der prüfenden Person identifiziert. Sie trennt die Identität der Bewertung vom sich ändernden Modellzustand, unterscheidet die vorbereitete Abdeckung von einem tatsächlichen Ergebnis und beschreibt die Wiedergabe als einen Vertrag, der vom erfassten Artefakt, vom Ausführungsgraphen, vom Routing, von der Reihenfolge, vom Zustand, von den Einschränkungen, von den Werkzeugen und von den Belegen abhängt. Die Seite stellt außerdem fest, dass zum 1. August 2026 noch kein erstes Ergebnis einer externen Veröffentlichung vorlag, weil diese Veröffentlichung noch nicht stattgefunden hatte.

Das ist ein kleines Beispiel, kein Beweis dafür, dass für jede Nutzung unserer Systeme ein Sicherheitsnachweis erbracht wurde. Sein Wert liegt in der Abgrenzung. Eine Methode ist kein Ergebnis. Eine Kategorie ist keine Bewertung. Eine geplante Veröffentlichung ist kein historischer Durchlauf. Ein reproduzierbarer erfasster Zustand ist nicht dasselbe wie eine reale Welt, deren Belege und adaptiver Zustand sich geändert haben. Genau diese Unterscheidungen braucht ein Sicherheitsnachweis, wenn er angibt, wo Belege gelten und wo sie enden.

Für ein europäisches Technologieunternehmen kann es sich so anfühlen, als würde man durch die Veröffentlichung solcher Grenzen wertvollen Marketingraum ungenutzt lassen. Es ist nützlicher, als diesen Raum mit einer Zahl zu füllen, die niemand verteidigen kann. Dieselbe Disziplin gilt für eine öffentliche Behörde, einen Lieferanten, eine Forschungsgruppe oder ein internes Plattformteam. Geben Sie an, welche Belege vorhanden sind, welche vorbereitet, welche geschützt, welche nicht erhoben wurden und welches zukünftige Ereignis ein neues Ergebnis schaffen würde. Die Leserin oder der Leser kann dann entscheiden, was die Belege stützen.

Unser Beispiel zeigt auch, warum ein Trust Centre eher als ein Verzeichnis von Belegen denn als ein Versprechen gelesen werden sollte. Die öffentliche Seite verweist auf Identität, Methode, Erfassung, Prüfung und Freigabegrenzen. Sie ersetzt nicht die Notwendigkeit, einen bestimmten Einsatz, einen bestimmten Zweck oder eine betroffene Personengruppe zu prüfen. Ein Sicherheitsnachweis würde diesen lokalen Kontext, die Gefahren des tatsächlichen Arbeitsablaufs und die Befugnis der entscheidenden Person hinzufügen. Öffentliche Transparenz ist eine Ausgangsfläche, kein universelles Zertifikat.

Was ein Sicherheitsnachweis belegen kann

Ein guter Sicherheitsnachweis kann eine begrenzte Schlussfolgerung stützen. Er kann zeigen, dass ein System für einen benannten Zweck entwickelt wurde, dass vorhersehbare Gefahren identifiziert wurden, dass Kontrollen diese Gefahren adressieren, dass Belege unter den angegebenen Bedingungen erhoben wurden, dass Restrisiken bewertet wurden, dass eine zuständige Stelle die Nutzung angenommen oder abgelehnt hat und dass die Organisation über eine Möglichkeit verfügt, Änderungen zu erkennen und die Entscheidung zu überprüfen. Er kann ein Argument so nachvollziehbar machen, dass es angefochten und gewartet werden kann.

Er kann auch zeigen, was unsicher ist. Ein Fall kann starke Belege für eine Personengruppe und begrenzte Belege für eine andere aufweisen. Er kann zeigen, dass das System gegenüber einer definierten Klasse fehlerhafter Eingaben robust ist, nicht jedoch gegenüber einer unbekannten Klasse. Er kann zeigen, dass ein Mensch eingreifen kann, wenn Personalausstattung und Berechtigungen wie angegeben sind. Er kann zeigen, dass eine Ausweichlösung existiert, aber noch nicht in vollem Betriebsumfang erprobt wurde. Ein wahrheitsgemäßer Fall verbirgt diese Asymmetrien nicht. Er macht sie zu Nutzungsbedingungen.

Ein Safety Case kann auch Beschaffungs- und Governance-Entscheidungen unterstützen. Ein Käufer kann die Nachweise, die ein Anbieter vorlegt, mit den Nachweisen vergleichen, die der Workflow benötigt. Eine Regulierungsbehörde kann erkennen, welche Behauptungen belegt und welche Aufzeichnungen fehlen. Ein Vorstand kann verstehen, wo das Restrisiko liegt und wer es trägt. Eine betreibende Person kann wissen, welches Signal eine Pause auslösen sollte. Betroffene Menschen können einen klareren Weg haben, ein Ergebnis anzufechten. Der Case wird zu einer Karte der Verantwortung, nicht nur zu einem technischen Artefakt.

Er kann Veränderung unterstützen, ohne so zu tun, als sei Veränderung kostenlos. Indem die Organisation Behauptungen, Gefahren, Annahmen, Kontrollen und Nachweise miteinander verbindet, kann sie die kleinste sinnvolle Neubewertung ermitteln, wenn sich eine Komponente ändert. Das ist effizienter, als jeden Test blind zu wiederholen, und sicherer, als anzunehmen, dass keine Neubewertung nötig ist. Verhältnismäßigkeit funktioniert nur, wenn die Struktur sichtbar ist. Andernfalls führt ein Team entweder Rituale aus oder nimmt Abkürzungen.

Was ein Safety Case nicht beweisen kann

Ein Safety Case kann nicht beweisen, dass niemals Schaden eintreten wird. Reale Systeme treffen auf Bedingungen, die nicht vorhergesehen wurden, und Menschen reagieren auf Anreize und Druck auf eine Weise, die kein Diagramm vollständig vorhersagen kann. Der Zweck ist nicht Gewissheit. Es ist eine disziplinierte Grundlage für Betrieb, Lernen und Anhalten, wenn die Grundlage nicht mehr trägt.

Er kann nicht beweisen, dass ein Modell allgemein intelligent, allgemein fair oder in jedem Bereich sicher ist. Nachweise haben einen Geltungsbereich. Ein Test auf einem Datensatz entscheidet nicht über die Leistung für einen anderen. Eine erfolgreiche Überprüfung in einem Workflow begründet nicht dieselbe Autorität in einem anderen. Ein gut gestalteter Stoppweg beweist nicht, dass jede betreibende Person ihn ohne Schulung, Zeit oder organisatorische Unterstützung nutzt. Der Case muss dem Drang widerstehen, lokale Nachweise in ein globales Adjektiv zu verwandeln.

Er kann Verantwortung nicht auf einen Anbieter, eine Prüfstelle oder ein Zertifizierungszeichen übertragen. Nachweise können von jemand anderem erstellt werden, aber die einsetzende Organisation hat weiterhin eine Nutzung, einen Workflow und Menschen, die vom Ergebnis abhängen. Verträge können Pflichten zuweisen und Zugang ermöglichen. Sie können eine Organisation nicht unwissend über das System machen, das sie betreibt. Auch kann ein Zertifikat eine Änderung nicht entschuldigen, die das System aus dem bewerteten Geltungsbereich herausführt.

Er kann eine verbotene oder ungeeignete Nutzung nicht durch zusätzliche Dokumentation akzeptabel machen. Wenn die Gefahr nicht auf ein akzeptables Maß kontrolliert werden kann, kann die Antwort sein, den Zweck zu ändern oder nicht einzusetzen. Safety Cases werden oft als Assurance beschrieben, aber das wertvollste Ergebnis kann ein gut begründetes Nein sein. Eine vollständige Akte kann eine schlechte Entscheidung dennoch unterstützen, wenn die Argumentation schwach ist. Der Sinn der Akte ist es, die Entscheidung besser zu machen, nicht nur besser nachvollziehbar, nachdem sie getroffen wurde.

Schließlich kann er Gesetz, professionelles Urteilsvermögen oder demokratische Rechenschaftspflicht nicht ersetzen. Er ist ein technisches und Governance-Instrument. Er sollte Menschen helfen, die Entscheidung und ihre Bedingungen zu verstehen, nicht so tun, als würde er Fragen klären, die in die Zuständigkeit von Gerichten, Regulierungsbehörden, Klinikern, öffentlichen Amtsträgern oder den betroffenen Menschen gehören.

Fragen für ein europäisches Release-Meeting

Ein Team muss nicht auf einen perfekten Standard oder einen 400-seitigen Ordner warten, um zu beginnen. Es kann eine Reihe einfacher Fragen stellen. Was genau behaupten wir, dass dieses System tun darf. Wer ist betroffen, wenn es falsch liegt. Welche Gefahren sind Bedingungen im System und Workflow und keine vagen schlechten Ergebnisse. Welche Annahmen müssen wahr bleiben. Welche Nachweise stützen jede Behauptung, und unter welcher Konfiguration und Population. Was bleibt ungewiss. Wer akzeptiert dieses Restrisiko. Wer kann das System stoppen. Welches Ereignis würde die Argumentation wieder eröffnen.

The meeting should make room for a less comfortable question: what would make us refuse the release. If the only answer is a lower score, the team has probably not described its hazards. A refusal may be triggered by missing evidence, an unowned assumption, a failed recovery exercise, an inaccessible reviewer, an unbounded integration or a change that cannot be replayed. Naming the refusal conditions turns safety into an operational control rather than a mood.

Ask how the case travels with the system. Can an operator find the intended purpose, limitations and stop route. Can an incident investigator identify the model, evidence, permissions and human decisions that mattered. Can a buyer export the records if the supplier changes. Can a regulator obtain the information needed to assess conformity. Can a new team understand why a control exists without interviewing the person who left. A safety case that lives only in a private folder is a fragile memory, not a living argument.

Ask how the case changes. What is the review trigger for a model update, source change, policy change, new user group, new tool, new jurisdiction or new downstream action. Which evaluations are repeated, and which assumptions are checked. What happens when monitoring finds a weak signal but not yet a serious incident. Is there a safe, owned route to pause and investigate. A well-run organisation should be able to answer without inventing a crisis to make the process feel real.

And ask whether the evidence can be read by the people whose decision it is supposed to support. A technical file that nobody can interpret is not transparent. A policy that nobody can apply is not a control. A dashboard full of green cells that hides the denominator is not reassurance. European safety practice is at its best when it makes the reasoning available to the person with responsibility, not only to the person who assembled the document.

The quiet advantage of an honest argument

Safety cases look bureaucratic from a distance because they contain records, roles, conditions and review points. Up close, they are a way to keep engineering honest when systems become persuasive. They prevent a test from masquerading as a decision, an assumption from masquerading as a fact, a planned evaluation from masquerading as a result and a human presence from masquerading as authority.

Europe already has pieces of this discipline in its institutions. Railways treat technical, operational and organisational change as a risk question and use common methods and independent assessment. Aviation guidance discusses learning assurance, explainability and human-AI teaming. The AI Act joins lifecycle risk management with documentation, logs, transparency, human oversight and lifecycle performance. These are not identical frameworks, and they should not be flattened into one checklist. They do share a respect for conditions, evidence and responsibility.

The practical lesson is simple enough to carry into a Monday meeting. Begin with a claim that has edges. Name the hazards that could make it false. Record the assumptions that let it stand. Put controls where the work actually happens. Attach evidence with identity and scope. Judge residual risk rather than hiding it. Give a person real authority to intervene. Reopen the argument when the system or context changes. Let an independent reviewer be inconvenient. Publish limits with the same care as successes.

That approach will not make every AI system safe, and it will not turn uncertainty into certainty. It will make unsafe confidence harder to maintain. It will give operators a route to pause, give reviewers something concrete to challenge and give affected people a better explanation of where responsibility sits. It will also make good systems easier to improve because the organisation can see which part of the argument changed.

Ein Safety Case ist daher kein abschließender Absatz nach der Technik. Er ist der rote Faden, der Zweck, Design, Menschen, Nachweise und Veränderung miteinander verbindet. Europa kann von Safety Cases lernen, denn sie bieten eine zivile Form ingenieurtechnischer Disziplin: Kein Slogan wird ohne Weg akzeptiert, kein Weg ohne Nachweise, und kein Nachweis darf weiter reisen, als seine Annahmen tragen.

Quellen