Einen KI-Fehler melden: Was in den Vorfallbericht gehört

Ein brauchbarer KI-Vorfallbericht beschreibt, was tatsächlich passiert ist, welche Wirkung bestätigt ist und was noch ungeklärt bleibt. Er trennt Beobachtung von vermuteter Ursache. Damit kann die zuständige Person den Schaden begrenzen und den Fehler untersuchen, ohne zuerst einen unvollständigen Chatverlauf rekonstruieren zu müssen.

Nicht jeder falsche KI-Satz ist ein Sicherheitsvorfall. Ein interner Entwurf mit einer falschen Zahl kann ein Qualitätsfehler sein. Eine unzulässige Weitergabe personenbezogener Daten verlangt eine andere Prüfung. Ein automatisch ausgelöster Vorgang im Zielsystem hat wiederum andere Folgen als ein Text, den niemand verwendet hat.

Der Meldeweg muss diese Unterschiede auffangen. Dieser Artikel bietet dafür einen eigenen Meldebogen und einen synthetischen Fall. Er ersetzt keine gesetzliche Meldeprüfung und keinen bestehenden Notfallplan. Der grössere Rahmen steht im Beitrag zum Risikomanagement für KI-Systeme.

Zuerst die laufende Wirkung begrenzen

Wenn ein Fehler weitere Aktionen auslöst, muss der vorhandene betriebliche Stopp- oder Eskalationsweg genutzt werden. Die konkrete Massnahme richtet sich nach Berechtigung und System. Ein Mitarbeiter darf nicht aus eigener Vermutung ganze Datenbestände löschen oder produktive Konfigurationen verändern.

Im fiktiven Beispiel erstellt ein Workflow eine Antwort mit einer nicht freigegebenen Lieferzusage. Der Versand ist noch nicht erfolgt. Die berechtigte Person stoppt die Freigabe und markiert den Entwurf als gesperrt. Damit ist eine mögliche Aussenwirkung begrenzt, ohne Belege zu vernichten.

Wenn bereits Nachrichten versendet wurden, reicht das Sperren des nächsten Entwurfs nicht aus. Dann muss festgestellt werden, welche Empfänger tatsächlich erreicht wurden und welche Korrektur erforderlich ist. Eine geplante Nachricht, ein technischer Sendeversuch und eine bestätigte Zustellung sind unterschiedliche Zustände.

Die Erstmeldung wartet nicht auf eine vollständige Ursachenanalyse. Sie enthält den beobachteten Sachverhalt und den aktuellen Status. Fehlende Informationen werden als offen markiert. Eine schnelle, begrenzte Meldung ist für die Bearbeitung hilfreicher als eine späte Erklärung mit unbelegter Sicherheit.

Einen Qualitätsfehler nicht vorschnell klassifizieren

Eine falsche Aussage kann verschiedene Ursachen haben: eine unklare Eingabe, eine veraltete Quelle, eine fehlerhafte Zuordnung oder eine erfundene Modellantwort. Der erste Melder kennt die Ursache oft noch nicht. Deshalb lautet der Bericht zunächst: "Liefertermin in der Ausgabe weicht von der freigegebenen Quelle ab."

Die Behauptung "Das Modell halluziniert" ist erst nach der Prüfung des konkreten Ablaufs ausreichend begründet. Vielleicht stand der falsche Termin bereits in einer verbundenen Datei. Vielleicht wurde die richtige Antwort dem falschen Kunden zugeordnet. Diese Unterschiede bestimmen die notwendige Korrektur.

Das NIST-Profil für generative KI behandelt unter anderem selbstsicher vorgetragene falsche Inhalte und die Offenlegung von Vorfällen als Risikomanagementthema. Der Leitfaden liefert einen Rahmen, aber keine Diagnose für einen einzelnen Fehler.

Der Bericht hält deshalb Beobachtung, Hypothese und bestätigte Ursache getrennt. Eine Hypothese wird später bestätigt oder verworfen. Sie wird nicht still in eine Tatsache umgeschrieben, nur weil sie technisch plausibel klingt.

Der Meldebogen für die erste Nachricht

Nicht jedes Feld ist beim ersten Kontakt vollständig. Dann steht dort beispielsweise "Zielsystemstatus noch nicht geprüft". Das ist genauer als ein leerer Eintrag, der später als "keine Wirkung" gelesen wird.

Der Meldekanal muss zum Inhalt passen. Ein allgemeiner Teamchat ist nicht automatisch geeignet für vertrauliche Belege. Die Erstmeldung kann eine Vorgangskennung und eine knappe Beschreibung enthalten, während geschützte Details im vorgesehenen System liegen.

Ein synthetischer Fall vollständig beschrieben

Die fiktive Meldung lautet: "Am 22.10.2026 um 10:14 Uhr Europe/Berlin wurde im Testvorgang S-204 eine Abweichung entdeckt. Der Antwortentwurf nennt den 28.10.2026 als bestätigten Liefertermin. Die freigegebene Produktinformation enthält keinen bestätigten Termin. Der Entwurf wurde vor dem Versand gesperrt. Ein externer Versand ist im geprüften Testprotokoll nicht vorhanden. Weitere Vorgänge wurden noch nicht untersucht."

Diese Meldung enthält eine klare Grenze: Nur der Testvorgang wurde geprüft. Sie behauptet nicht, dass derselbe Fehler nirgendwo sonst vorkommt. Der nächste Schritt lautet deshalb, die betroffene Vorlage und die seit ihrer Änderung bearbeiteten Vorgänge anhand der vorhandenen Protokolle zu untersuchen.

Die Meldung nennt ausserdem den Belegort und die zuständige Bearbeitung. Sie kopiert keine echten Kundendaten in den Bericht. Die Untersuchung prüft zunächst, ob der Termin aus der Eingabe, einer Quelle oder der Generierung stammt. Erst danach wird eine Ursache dokumentiert.

Ein schlechter Bericht lautet dagegen nur: "KI hat wieder Unsinn gemacht, bitte fixen." Er nennt weder den betroffenen Vorgang noch die erwartete Ausgabe oder die tatsächliche Wirkung. Die technische Bearbeitung beginnt dann mit Rückfragen, während der Fehler möglicherweise weiterwirkt.

Datenschutzvorfälle gesondert bewerten

Der EDPB-Leitfaden zu Verletzungen personenbezogener Daten unterscheidet Sicherheitsvorfälle von Verletzungen personenbezogener Daten. Für meldepflichtige Verletzungen beschreibt er die Meldung durch Verantwortliche ohne unangemessene Verzögerung und grundsätzlich spätestens innerhalb von 72 Stunden nach Bekanntwerden. Die Risikobewertung und weitere Voraussetzungen sind Teil dieser Prüfung.

Daraus folgt nicht, dass jeder KI-Fehler innerhalb von 72 Stunden an eine Behörde gemeldet wird. Die zuständige Datenschutzstelle muss prüfen, ob personenbezogene Daten betroffen sind und welche Pflichten konkret bestehen. Interne Mitarbeiter warten deshalb nicht bis zum Ende einer solchen Frist, bevor sie einen Verdacht weitergeben.

Der Artikel stellt auch keine vollständige Übersicht über branchenspezifische oder KI-rechtliche Meldepflichten bereit. Falls ein Einsatz in einen besonderen regulatorischen Bereich fällt, muss der betriebliche Meldeweg diese Prüfung einschliessen. Ein allgemeiner technischer Fehlerbericht ersetzt sie nicht.

Wichtig für die Erstmeldung ist der Zeitpunkt der Entdeckung und was zu diesem Zeitpunkt bekannt war. Spätere Erkenntnisse werden ergänzt. Die ursprüngliche Meldung bleibt nachvollziehbar, damit die Abfolge der Entscheidungen nicht verloren geht.

Belege sichern, ohne den Vorfall zu vergrössern

Für die Untersuchung sind häufig Eingabe, Ausgabe, verwendete Quellen und Konfiguration relevant. Sie werden im erlaubten Umfang am vorgesehenen Ort gesichert. Dabei müssen Zugriffsrechte und Aufbewahrung beachtet werden. Eine vollständige Kopie in mehrere private Ablagen ist keine gute Beweissicherung.

Wenn Zugangsdaten oder vertrauliche Inhalte in einer Ausgabe erscheinen, werden sie nicht ungeprüft in neue Tickets oder E-Mails übernommen. Der Bericht kann den Fund beschreiben und auf einen geschützten Beleg verweisen. Die technische Bereinigung folgt dem vorhandenen Sicherheitsverfahren.

Auch bei Screenshots ist der sichtbare Kontext wichtig. Ein ausgeschnittener Satz ohne Quelle und Zeitpunkt reicht möglicherweise nicht für die Rekonstruktion. Umgekehrt enthält ein Vollbild eventuell unnötige Daten anderer Vorgänge. Die Sicherung muss gezielt den relevanten Sachverhalt abbilden.

Für verbundene Systeme werden die jeweiligen Vorgangskennungen festgehalten. Nur so lässt sich prüfen, ob eine Ausgabe tatsächlich eine Aktion ausgelöst hat. Ein erfolgreicher Modellaufruf beweist keine erfolgreiche Speicherung im Zielsystem und umgekehrt.

Die Untersuchung in überprüfbare Fragen zerlegen

Die Bearbeitung beginnt mit einer Rekonstruktion: Welche Eingabe wurde verarbeitet? Welche Quellen standen zur Verfügung? Welche Regeln und Berechtigungen galten? Welche Ausgabe entstand? Welche Folgeaktion wurde tatsächlich ausgeführt? Jede Antwort braucht einen passenden Beleg.

Danach wird die Ursache eingegrenzt. Im fiktiven Fall kann eine veraltete Vorlage die unbelegte Terminangabe provoziert haben. Das ist zunächst eine Hypothese. Sie wird mit einem kontrollierten Test und einem Vergleich der Versionen geprüft. Ein zufällig besserer zweiter Lauf bestätigt die Ursache noch nicht.

Die Untersuchung berücksichtigt ausserdem den Umfang. Betrifft der Fehler nur einen Vorgang, eine Dokumentart oder alle Läufe seit einer Änderung? Wenn diese Frage nicht vollständig beantwortet ist, bleibt der Umfang offen. Eine Stichprobe darf nicht als Prüfung aller Vorgänge ausgegeben werden.

Für die Behandlung eines fehlerhaften Ergebnisses bietet der Artikel Wann du eine KI-Ausgabe verwerfen musst eine Entscheidungshilfe. Er ergänzt die Ursachenanalyse um die Frage, ob das konkrete Ergebnis noch verwendet werden darf.

Korrektur und Wiederanlauf getrennt abnehmen

Eine geänderte Vorlage ist zunächst eine umgesetzte Massnahme. Ob sie den Fehler behebt, zeigt erst der Test. Dieser enthält den ursprünglichen Fehlerfall und passende Gegenfälle. Sonst verbessert die Änderung möglicherweise eine Antwort und verschlechtert andere.

Im Beispiel wird geprüft, dass ein fehlender Termin als offen erscheint. Zusätzlich enthält das Testset einen tatsächlich bestätigten Termin, der korrekt übernommen werden muss. Eine pauschale Unterdrückung aller Termine löst die Arbeitsaufgabe nicht vollständig.

Der Wiederanlauf verlangt eine eigene Entscheidung. Sind offene Vorgänge geklärt? Ist der Rückstand bearbeitbar? Kennt die zuständige Rolle die geänderte Grenze? Der Ausfallplan für KI-Dienste hilft bei dieser organisatorischen Seite.

Die Freigabe wird mit dem geprüften Umfang dokumentiert. "Fehler behoben" reicht nicht, wenn nur ein Beispiel erneut ausgeführt wurde. Besser ist: "Betroffene Vorlage korrigiert; definierte Testfälle bestanden; offene Altvorgänge separat in Prüfung."

Einen Beinahefehler sichtbar lassen

Im synthetischen Fall wurde der falsche Liefertermin vor dem Versand erkannt. Das ist kein bestätigter Kundenschaden. Trotzdem liefert der Fall eine wichtige Information über die Schutzmassnahme: Die fachliche Freigabe hat den Fehler aufgefangen, die vorgelagerte Erstellung hat ihn nicht verhindert.

Der Bericht dokumentiert beide Tatsachen. Er schreibt weder einen eingetretenen Schaden herbei noch erklärt er den Ablauf für fehlerfrei. Für die Verbesserung wird geprüft, ob die Freigabe den Fehler systematisch erkennt oder ob diesmal nur ein aufmerksamer Zufall geholfen hat.

Dazu erhält eine zweite berechtigte Person einen vergleichbaren synthetischen Fall mit derselben Prüfanleitung. Erkennt sie die unbelegte Zusage, liefert das einen zusätzlichen Nachweis für die Verständlichkeit des Prüfschritts. Bleibt der Fehler unbemerkt, muss die Anleitung oder die vorgelagerte Begrenzung verbessert werden. Der Beinahefehler wird damit zu einem konkreten Testfall, ohne seine Wirkung zu übertreiben.

Aus dem Vorfall eine konkrete Verbesserung ableiten

Nach der Bearbeitung wird der relevante Fall in das Testset aufgenommen. Zusätzlich wird geprüft, ob die Meldeanleitung verständlich war und die Übergabe tatsächlich funktioniert hat. Eine technisch gute Korrektur hilft wenig, wenn der nächste Mitarbeiter denselben Fehler nicht zuordnen kann.

Die Abschlussnotiz nennt Ursache, Massnahme, geprüfte Wirkung und verbleibende offene Punkte. Sie erklärt ausserdem, wer die weitere Beobachtung übernimmt. Ein zusätzlicher Dauerbericht ist dafür nicht automatisch nötig; die bestehende Betriebsdokumentation bleibt die verbindliche Ablage.

Ein guter Vorfallbericht macht Unsicherheit bearbeitbar. Er sagt präzise, was bekannt ist, schützt die notwendigen Belege und führt zu einer überprüften nächsten Handlung. Genau diese Qualität zählt im ersten Moment mehr als eine schnelle, aber unbelegte Erklärung.

Quellenstand: 22.10.2026. NIST und EDPB tragen die jeweils benannten Aussagen. Meldebogen, Testfall und Untersuchungsablauf sind eigene Vorschläge für den betrieblichen Einsatz.