Schwerwiegende KI-Vorfälle: Beweise sichern, Schäden eindämmen und entscheiden, ob ein Fehler nach Artikel 73 des AI Act gemeldet werden muss

Ein Fehler ist nicht automatisch ein schwerwiegender Vorfall

Die Reaktion auf ein gefährliches Ergebnis eines KI-Systems beginnt damit, Begriffe zu trennen, die häufig vermischt werden. Ein Modellfehler kann eine ungenaue, widersprüchliche oder unerwünschte Ausgabe sein. Ein Betriebsstörfall kann einen Dienstausfall, eine fehlerhafte Konfiguration, eine fehlgeschlagene Integration oder einen Einsatz von Werkzeugen außerhalb des vorgesehenen Verhaltens umfassen. Ein Schaden ist eine konkrete nachteilige Folge für eine Person, eine Organisation, Sachen, die Umwelt oder einen Prozess. Ein schwerwiegender Vorfall im regulatorischen Sinn dieses Leitfadens ist eine engere Kategorie, die an bestimmte im AI Act definierte Folgen anknüpft.

Nicht jede Halluzination, Qualitätsminderung, Nutzerbeschwerde oder beleidigende Antwort löst für sich genommen das Regime von Artikel 73 aus. Ebenso wäre es unklug, einen Fall abzutun, weil eine isolierte Ausgabe geringfügig erscheint: Eine scheinbar gewöhnliche Antwort kann eine klinische Entscheidung, eine Einstellungsentscheidung, den Zugang zu einer Dienstleistung, die physische Sicherheit oder den Betrieb kritischer Infrastruktur beeinflusst haben. Die Analyse muss von beobachtbaren Tatsachen ausgehen, nicht von internen Etiketten wie „kleiner Bug“ oder „unkritische Beschwerde“.

Der konsolidierte Text des AI Act definiert einen schwerwiegenden Vorfall anhand von Ergebniskategorien. Dazu zählen Tod oder schwere Gesundheitsschäden, eine schwerwiegende und nachhaltige Störung der Verwaltung oder des Betriebs kritischer Infrastruktur, ein Verstoß gegen Pflichten zum Schutz von Grundrechten sowie schwerwiegende Schäden an Sachen oder an der Umwelt. Für die Einordnung müssen das Ereignis, das betroffene System und die mögliche Verbindung zwischen beiden untersucht werden. Eine interne Schweregradbewertung ohne dokumentierte Zuordnung zu diesen Kategorien darf dies nicht ersetzen.

Es empfiehlt sich, ab der ersten Meldung zwei Arbeitsstränge zu führen. Der technische Strang soll unsicheres Verhalten stoppen und einen kontrollierten Dienst wiederherstellen. Der Beweis- und Compliance-Strang soll Tatsachen erhalten, den möglichen Kausalzusammenhang bewerten, Anbieter und Betreiber koordinieren und entscheiden, ob eine Mitteilung an die zuständige Behörde vorbereitet werden muss. Beide können parallel laufen. Eine übereilte Korrektur kann jedoch den zweiten Strang beeinträchtigen, wenn sie die zur Erklärung des Geschehens erforderlichen Informationen verändert oder entfernt.

Anwendungsbereich: System, Akteur und Hochrisiko-Weg bestimmen

Artikel 73 richtet sich an Anbieter von Hochrisiko-KI-Systemen, die auf dem Unionsmarkt in Verkehr gebracht wurden. Daher ist nicht zuerst die vom Team empfundene Schwere zu prüfen, sondern welches konkrete System beteiligt war, wer im Sinne der Verordnung dessen Anbieter ist und ob es der einschlägigen Hochrisikoklassifizierung unterlag. Der AI Act sieht in Artikel 6 zwei wesentliche Klassifizierungswege vor: bestimmte Systeme im Zusammenhang mit regulierten Produkten oder Sicherheitsbauteilen sowie die in Anhang III aufgeführten Anwendungsfälle, jeweils unter den in der Verordnung vorgesehenen Voraussetzungen und Ausnahmen.

Es genügt nicht, ein Basismodell, eine Konversationsoberfläche oder eine Automatisierung wegen ihres Themas pauschal als „hochriskant“ zu bezeichnen. Untersuchungseinheit muss das im konkreten Kontext bereitgestellte oder verwendete System sein: Version, Zweckbestimmung, Integration, aktivierte Funktionen, Nutzer, Eingabedaten und hervorgebrachtes Ergebnis. Dieselbe Komponente kann Teil von Konfigurationen mit unterschiedlichen Pflichten sein. Der Entwurf der Kommissionsleitlinien zur Hochrisikoklassifizierung kann die Prüfung strukturieren, bleibt aber ein Entwurf und ersetzt weder den verbindlichen Text noch die rechtliche Einzelfallbewertung.

Bei der Zeitplanung ist zwischen Vorbereitung und tatsächlicher Anwendbarkeit zu unterscheiden. Organisationen können schon jetzt Verfahren für Protokollierung, Beweissicherung, Ansprechpartner und Eskalation einrichten. Konkrete Anwendungszeitpunkte für verschiedene Hochrisikokategorien müssen bei einer Einzelfallentscheidung jedoch anhand der rechtlich anwendbaren Fassung der Verordnung und etwaiger geltender Änderungen geprüft werden. Ein internes Planungsdatum sollte nicht in eine Aussage über eine bereits durchsetzbare Pflicht umgedeutet werden.

Zur Orientierung kann das Team dieses Protokoll von allgemeinen Prüfungen unter Sicherheit, von der Bewertung von Alternativen unter Vergleichen und von der Ermittlung von Fähigkeiten unter Entdecken trennen. Diese Arbeiten können Kontext liefern; die Untersuchung eines Vorfalls benötigt jedoch ein Dossier, das auf das konkrete Ereignis und die tatsächlich eingesetzte Konfiguration konzentriert ist.

Die ersten Stunden: vor der Korrektur sichern

Wird ein potenziell relevanter Fall erkannt, ist eine vorfallverantwortliche Person mit Koordinierungsbefugnis für Betrieb, Produkt, Sicherheit, Qualität und Compliance zu benennen. Ihre erste operative Pflicht besteht darin, eine Zeitachse festzuhalten: Wann trat das Ereignis ein, wann wurde es entdeckt, wer erhielt welche Meldung, welche Systeme blieben aktiv und welche Entscheidungen wurden getroffen? Der Zeitpunkt der Kenntnis des Anbieters und gegebenenfalls des Betreibers ist getrennt zu erfassen, jeweils mit der Quelle, die ihn belegt.

Beweissicherung bedeutet nicht, wahllos alle verfügbaren Daten zu kopieren. Sie bedeutet, diejenigen Elemente verhältnismäßig, integer und zugriffskontrolliert zu erhalten, die das untersuchte Verhalten rekonstruierbar machen. Das Dossier sollte mindestens Anfrage- und Sitzungskennungen, Ein- und Ausgaben, Modellversion und Parameter, Systemprompt und Vorlagen, Richtlinien, Retrieval-Konfiguration, abgerufene Dokumente oder deren Kennungen, Werkzeugaufrufe und Antworten, menschliche Freigaben, Identität oder Rolle des Bedieners sowie Konfigurationsänderungen im zeitlichen Umfeld des Ereignisses verknüpfen.

Zur Sicherung gehören auch Integritätsmetadaten: Herkunft, Extraktionszeitpunkt, verantwortliche Person, Exportmethode, soweit praktikabel eine Dateiprüfsumme, Zugriffskontrollen und jede spätere Transformation. Bei personenbezogenen Daten, Geschäftsgeheimnissen oder Sicherheitsinformationen ist der Zugriff nach den geltenden Regeln zu begrenzen. Zugangsbeschränkung rechtfertigt nicht, für die Untersuchung notwendige Elemente zu löschen. Kann ein Datum nicht aufbewahrt werden, muss das Dossier erklären, was, warum und wann gelöscht wurde und welche Beweisalternative verbleibt.

Der AI Act verlangt, dass der Anbieter den schwerwiegenden Vorfall und das betreffende System unverzüglich untersucht, einschließlich einer Risikobewertung und Abhilfemaßnahmen. Zudem darf das System vor der Meldung nicht verändert werden, wenn die Veränderung die spätere Bewertung der Ursachen beeinflussen könnte. Praktisch verlangt dies eine Eindämmung, die Schäden begrenzt, ohne den zu untersuchenden Zustand zu beseitigen.

Schäden eindämmen, ohne die Untersuchung unbrauchbar zu machen

Eindämmung hat keine einheitlich richtige Form. Die vollständige Aussetzung des Systems kann bei fortbestehendem ernstem Risiko nötig sein, aber auch wesentliche Prozesse beeinträchtigen oder Nutzer zu unkontrollierten Alternativen drängen. Andere Maßnahmen können verhältnismäßiger sein: ein Ausführungswerkzeug vorübergehend entfernen, Berechtigungen auf Leserechte reduzieren, automatisierte Maßnahmen mit hoher Auswirkung verhindern, einen identifizierten Eingabebereich sperren, eine kompromittierte Retrieval-Quelle deaktivieren oder für eine konkrete Entscheidung eine menschliche Prüfung verlangen.

Jede Maßnahme muss auf einer ausdrücklichen Schadenshypothese beruhen und Überprüfungsbedingungen haben. „Das System in einen sicheren Modus versetzen“ ist nicht überprüfbar, solange nicht festgelegt ist, welche Fähigkeit gesperrt wurde, was verfügbar blieb, welche Personengruppe betroffen war, welche Alternativen angeboten wurden und wie die Wirkung geprüft wurde. Kommunikation mit Kunden, Nutzern und Bedienern kann Teil der Eindämmung sein, muss jedoch auf bestätigten Tatsachen beruhen und darf Kausalität nicht vorwegnehmen.

Ein Rollback auf eine frühere Version verlangt Vorsicht. Er kann das unmittelbare Symptom beheben, beweist aber nicht, dass die Ursache in der zurückgezogenen Version lag, und kann Unterschiede einführen, die eine Reproduktion verhindern. Vor der Änderung sind das bereitgestellte Artefakt, die Konfiguration und die Protokolle zu sichern, die einen Vergleich des vorherigen mit dem nachfolgenden Zustands erlauben. Ist die Änderung zur Schadensvermeidung unvermeidbar, sind Notwendigkeit und Umfang der Abweichung zu dokumentieren.

Marktüberwachungsbehörden können gegenüber Produkten mit ernstem Risiko eigene Befugnisse besitzen, einschließlich Bewertungen und Beschränkungen. Diese Maßnahmen ersetzen weder die interne Untersuchung noch machen sie die Organisation zur Behörde. Das Team sollte bei einer Anforderung überprüfbare Tatsachen, Bewertungen und ergriffene Maßnahmen bereitstellen können.

Den Fall als Kette von Entscheidungen rekonstruieren

Eine brauchbare Untersuchung muss eine einfache Frage beantworten können: Welches genaue System hat das Ergebnis hervorgebracht oder dazu beigetragen, und über welche Abfolge? Dafür reicht ein Gesprächstranskript nicht aus. Ein reproduzierbares Dossier verbindet die Fallkennung mit Modell und Modellversion, Inferenzparametern, Systemanweisungen, zusammengesetztem Prompt, beigefügten Daten, Retrieval-Konfiguration, ausgewählten Dokumenten, verfügbaren Werkzeugen, erfolgten Aufrufen, aktiven Richtlinien und menschlichen Entscheidungen.

Tatsachen und angenommener Mechanismus sind ebenfalls zu trennen. Tatsache: Ein Werkzeug erhielt bestimmte Parameter und löste eine protokollierte Handlung aus. Hypothese: Das Modell deutete eine mehrdeutige Anweisung falsch. Tatsache: Ein Bediener genehmigte eine Empfehlung. Hypothese: Die Oberfläche zeigte zu wenig Kontext, um den Fehler zu erkennen. Diese Trennung verhindert, dass eine Erstdiagnose zur endgültigen Erzählung wird, und hält alternative Ursachen offen: Daten-, Integrations-, Oberflächen-, Schulungs-, Prozess- oder externe Fehler.

Eine vollständige Reproduktion ist nicht immer möglich. Ein externer Dienst kann sich verändert haben, eine Eingabe kann fehlen, ein Ergebnis kann von Zufälligkeit abhängen oder die Datenaufbewahrung kann begrenzt sein. Dann muss das Dossier die Lücke, ihre Wirkung auf die Schlussfolgerungen und verwendete Ersatztests präzise beschreiben. Eine fehlende Reproduktion beweist nicht für sich, dass das System nicht mit dem Vorfall zusammenhing.

Auch während der Reaktion vorgenommene Änderungen gehören in die Rekonstruktion. Andernfalls kann eine spätere Verbesserung mit der ursprünglichen Konfiguration verwechselt werden; ein nach der Eindämmung erzieltes sicheres Ergebnis könnte fälschlich als Nachweis gelten, dass der Vorfall unmöglich war. Vergleichbarkeit zwischen Ausgangszustand, eingedämmtem Zustand und korrigiertem Zustand ist eine praktische Voraussetzung, aus dem Fall zu lernen.

Schwere und Kausalzusammenhang bewerten, ohne das Urteil vorwegzunehmen

Die Einordnung sollte mit konkreten Fragen beginnen. Gab es Tod oder schwere Gesundheitsschäden? Wurde der Betrieb oder die Verwaltung kritischer Infrastruktur schwerwiegend und nachhaltig gestört? Trat ein Verstoß gegen Pflichten zum Schutz von Grundrechten ein? Entstand schwerwiegender Schaden an Sachen oder der Umwelt? Zu jeder Frage sollte das Dossier die behauptete Tatsache, stützende Quellen, bekannten Umfang, betroffene Personen oder Vermögenswerte und verbleibende Unsicherheiten ausweisen.

Danach ist die Verbindung zum System zu analysieren. Artikel 73 verlangt nicht, dass die Organisation auf einen endgültigen Kausalitätsnachweis wartet, wenn eine angemessene Wahrscheinlichkeit eines Zusammenhangs besteht. Eine bloße zeitliche Nähe ersetzt jedoch keine Analyse. Plausible Kausalpfade, stützende Belege, alternative Faktoren und ausstehende Prüfungen sind zu dokumentieren. Eine fehlerhafte Ausgabe kann etwa relevant sein, während die Endentscheidung auf einer unabhängigen menschlichen Prüfung oder fehlerhaften externen Daten beruhte; beides muss untersucht werden.

Eine interne Schweregradmatrix kann Eskalationen erleichtern, darf aber die Rechtsdefinition nicht ersetzen. Das interne Formular sollte getrennte Felder für „beobachtete Auswirkung“, „Risiko weiterer Auswirkungen“, „mögliche regulatorische Kategorie“, „Zusammenhang bestätigt“, „Zusammenhang angemessen wahrscheinlich“ und „Zusammenhang nicht festgestellt“ enthalten. Damit bleibt sichtbar, was Tatsache und was vorläufige Analyse ist.

Die Entscheidung, dass ein Fall den Schwellenwert nicht erreicht, muss begründet und überprüfbar sein. Neue Informationen können von einem Betreiber, Nutzer, verbundenen Werkzeug oder einer Behörde kommen. Eine Meldung nicht weiterzuverfolgen bedeutet weder, das technische Dossier zu schließen, noch Beweise zu löschen.

Anbieter und Betreiber: Informationen koordinieren, nicht das Problem verschieben

Anbieter und Betreiber können unterschiedliche Teile der Beweislage besitzen. Der Anbieter kontrolliert häufig Systemdokumentation, Versionen, Tests, Betriebsprotokolle und Korrekturmaßnahmen am Produkt. Der Betreiber kennt möglicherweise Nutzungskontext, betroffene Gruppen, menschliche Entscheidungen, lokale Daten, materielle Folgen und eingegangene Mitteilungen. Ein Vertrag kann operative Aufgaben verteilen, sollte aber die schnelle Übermittlung der Informationen nicht blockieren, die zur Erfüllung anwendbarer Pflichten erforderlich sind.

Eine Kontaktmatrix und eine operative Vorfallklausel sollten vor einem Ereignis vorbereitet werden. Sie sollten außerhalb der Geschäftszeiten erreichbare Ansprechpartner, Mindestkategorien von Informationen, sichere Kanäle, interne Fristen unterhalb der regulatorischen Höchstfristen, Regeln zur Sicherung, ein Freigabeverfahren für Kommunikation und den Umgang mit geschützten Daten enthalten. Ziel ist nicht, Verantwortung automatisch zu verlagern, sondern die Zeit zwischen Kenntnis eines Ereignisses und Verfügbarkeit der für seine Bewertung nötigen Elemente zu verkürzen.

Der Betreiber sollte die unter seiner Kontrolle stehenden und erforderlichen Daten innerhalb der anwendbaren rechtlichen Grenzen sichern und bereitstellen. Der Anbieter sollte keine perfekte Reproduktion als Voraussetzung für den Beginn seiner Bewertung verlangen. Umgekehrt sollte der Betreiber keine lokalen Änderungen vornehmen, Protokolle löschen oder eine technische Ursache als bestätigt kommunizieren, ohne das Dossier abzustimmen. Bei mehreren beteiligten Stellen hilft ein gemeinsames Register von Beweisanfragen, Übermitteltes, Offenes und nicht Beschaffbares zu unterscheiden.

Die mit Hochrisikosystemen verbundenen Transparenz-, Protokollierungs- und Kooperationspflichten können für diese Koordination relevant sein. Sie machen den Betreiber jedoch nicht automatisch für die in Artikel 73 dem Anbieter zugewiesene Meldung verantwortlich. Die endgültige Zuordnung hängt von der tatsächlichen Rolle jeder Stelle und den Umständen des untersuchten Systems ab.

Meldung: Fristen steuern, ohne eine automatische Formel daraus zu machen

Artikel 73 begründet unter den in der Verordnung vorgesehenen Voraussetzungen eine Pflicht, schwerwiegende Vorfälle den Marktüberwachungsbehörden der Mitgliedstaaten zu melden, in denen sie eingetreten sind. Die Mitteilung knüpft sowohl an die Kenntnis des Vorfalls als auch an die Feststellung eines Kausalzusammenhangs oder dessen angemessene Wahrscheinlichkeit an. Das Team sollte daher den Zeitpunkt der Kenntnis, den Zeitpunkt einer vorläufigen Schlussfolgerung zum Zusammenhang und die Belege für beide Meilensteine getrennt dokumentieren.

Die Verordnung sieht für unterschiedliche Fallgestaltungen Höchstfristen von zwei, zehn und fünfzehn Tagen sowie die Möglichkeit eines unvollständigen Erstberichts mit nachgereichten Informationen vor. Welche Frist konkret gilt, hängt von der jeweiligen Vorfallkategorie und dem auf den Sachverhalt anwendbaren Wortlaut ab. Sie darf nicht aus einer verkürzten internen Tabelle oder allein aus der technischen Schwere abgeleitet werden. Das Protokoll sollte eine sofortige Rechtsprüfung auslösen, die Frist von einem dokumentierten Meilenstein berechnen und begründen, warum diese Uhr gewählt wurde.

Ein Erstbericht darf nicht mit künstlicher Gewissheit gefüllt werden. Ist die Ursache unbekannt, sollte dies als laufende Untersuchung angegeben werden, zusammen mit bestätigten Tatsachen, bekanntem Umfang, Eindämmungsmaßnahmen, verfügbarer Beweislage und einem Plan zur Vervollständigung. Die Möglichkeit eines unvollständigen Berichts rechtfertigt weder die Verzögerung einer erforderlichen Mitteilung noch eine oberflächliche Untersuchung.

Das von der Kommission veröffentlichte Muster und die Orientierung zu schwerwiegenden Vorfällen sind hilfreiche Arbeitsmaterialien, um Felder und Reihenfolge zu strukturieren. Sie werden jedoch als konsultationspflichtige Entwürfe vorgelegt und sind keine endgültige verbindliche Leitlinie. In einem konkreten Fall muss der Inhalt der Mitteilung mit der anwendbaren Verordnung und den Vorgaben der zuständigen Behörde abgeglichen werden.

Untersuchung, Korrektur und kontrollierte Wiederaufnahme

Die Untersuchung endet nicht mit dem Versand einer Mitteilung. Sie soll Ursache oder beitragende Ursachen mit angemessenem Vertrauensniveau erklären: Modellverhalten, Eingabedaten, Retrieval, Werkzeug, Oberfläche, Berechtigungen, Konfiguration, menschliche Aufsicht, Schulung, Betriebsprozess oder eine Kombination. Eine einzige Grundursache kann irreführend vereinfachen, wenn der Vorfall von mehreren versagenden oder fehlenden Kontrollen abhing.

Die Abhilfemaßnahme muss an den identifizierten Schadenspfad anknüpfen. Eine Prompt-Anpassung reicht möglicherweise nicht, wenn übermäßige Werkzeugberechtigungen das Problem waren; eine menschliche Prüfung reicht möglicherweise nicht, wenn der Prüfer die erforderlichen Daten nicht erhält; ein Dokument zu entfernen reicht möglicherweise nicht, wenn der Connector weiterhin nicht autorisierte Quellen einbindet. Für jede Maßnahme sind Risikominderung, Restrisiko, mögliche Nebenwirkungen und Validierung festzulegen.

Die Validierung muss den Vorfallsfall und eine breitere Regression einbeziehen. Nur das ursprüngliche Gespräch zu testen, begünstigt eine zu eng zugeschnittene Korrektur. Geeignet ist eine Kombination aus repräsentativen Tests, Grenzfällen, Berechtigungstests und vollständigen Abläufen bis zur externen Handlung sowie, soweit relevant, eine Prüfung der Auswirkungen auf Nutzer und betroffene Gruppen. Ergebnisse, Testumgebung, Versionen und Akzeptanzkriterien sind aufzubewahren.

Die Wiederaufnahme darf keine implizite Entscheidung beim Schließen eines Tickets sein. Sie benötigt eine verantwortliche Person, Genehmigungskriterien, einen anfänglichen Umfang, Kennzahlen für verstärkte Überwachung, einen Rückrollmechanismus und Bedingungen für eine erneute Aussetzung. Bleibt eine wesentliche Unsicherheit bestehen, kann die Organisation die betroffene Fähigkeit beschränkt halten, während sie die Untersuchung abschließt. Entscheidung und Begründung gehören ins Dossier.

Vierteljährliche Vorbereitung: prüfen, ob das Protokoll vor dem Vorfall funktioniert

Reaktionsfähigkeit ist nicht dadurch bewiesen, dass technische Protokolle oder eine schriftliche Richtlinie existieren. Es muss getestet werden, ob das Team einen realistischen Fall abrufen kann, ohne von einer einzelnen Person oder von Werkzeugen abhängig zu sein, die benötigte Daten nicht vorhalten. Eine vierteljährliche Übung kann einen risikoreichen Ablauf auswählen, eine Warnung simulieren und messen, wie schnell die Organisation die bereitgestellte Version bestimmt, die betroffene Fähigkeit isoliert, Betreiberprotokolle beschafft und eine Zeitachse mit überprüfbaren Quellen erstellt.

Die Überprüfung sollte Änderungen bei Anbietern, Modellen, Werkzeugen, Korpora, Berechtigungen, Verantwortlichkeiten und Einsatzmärkten umfassen. Ein für ein statisches Modell vorbereitetes Protokoll kann bei Modellrouting, schrittweisen Rollouts, dynamischem Retrieval oder Drittanbieterwerkzeugen versagen. Ebenso ist zu prüfen, ob Vereinbarungen mit Kunden und Anbietern die rasche Weitergabe notwendiger Beweise mit angemessenen Vertraulichkeits- und Datenschutzkontrollen erlauben.

Aus jeder Übung sollten beobachtbare Verbesserungen folgen: fehlende Protokollfelder, Entscheidungen ohne Verantwortliche, nicht wiederherstellbare Konfigurationen, kein Notfallkanal oder unklare Aussetzungskriterien. Es geht nicht darum, allgemeine AI-Act-Konformität zu erklären, sondern Unsicherheit bei einer konkreten Vorfallreaktion zu verringern. Die nützlichste Vorbereitung ermöglicht es, klar zu sagen, was bekannt ist, was nicht bekannt ist und was getan wurde, damit der Schaden nicht fortdauert.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.