KI-Vorfälle im Unternehmen: Meldewege, Eskalation und Lernen aus Fehlern richtig organisieren

Warum ein KI-Vorfall selten mit einem perfekten Fehlerbild beginnt

Ein KI-System erfindet eine Quelle in einem Kundenentwurf. Ein Mitarbeiter lädt versehentlich vertrauliche Informationen in ein nicht freigegebenes Tool. Ein Agent löst eine Aktion aus, die fachlich nicht vorgesehen war. Oder ein Team bemerkt, dass ein Modell bei bestimmten Fällen auffällig schlechte Ergebnisse liefert. Solche Situationen sehen sehr unterschiedlich aus. Gemeinsam ist ihnen: Der Nutzen eines guten Governance-Prozesses zeigt sich genau dann, wenn jemand erkennt, dass etwas nicht stimmt und weiß, was als Nächstes zu tun ist.

Viele Unternehmen investieren zu Recht in Richtlinien, Freigaben und Schulungen. Weniger sichtbar ist die Frage, wie Mitarbeitende mit einem möglichen KI-Vorfall umgehen sollen. Wer darf einen Workflow stoppen? Wohin wird eine Beobachtung gemeldet? Welche Informationen werden gesichert? Wann müssen Informationssicherheit, Datenschutz, Fachverantwortliche oder andere Stellen eingebunden werden?

Ein interner KI-Meldeweg ist dabei nicht mit einer pauschalen gesetzlichen Meldepflicht gleichzusetzen. Der EU AI Act enthält für bestimmte Akteure und Systeme konkrete Vorgaben, unter anderem zu schwerwiegenden Vorfällen bei Hochrisiko-KI-Systemen. Ob und welche externe Pflicht im Einzelfall greift, hängt von Rolle, System und Sachverhalt ab. Für den Unternehmensalltag ist trotzdem ein breiter interner Prozess sinnvoll: Er hilft, Auffälligkeiten früh zu erkennen und fachlich einzuordnen, bevor jemand vorschnell entscheidet, dass ein Fall harmlos oder meldepflichtig sei.

1. Zuerst definieren, was intern als KI-Vorfall zählt

Eine zu enge Definition führt dazu, dass nur spektakuläre Systemausfälle gemeldet werden. Eine zu breite Definition produziert dagegen so viele Meldungen, dass der Prozess unbrauchbar wird. Praktischer ist eine verständliche Arbeitsdefinition: Ein KI-Vorfall oder eine relevante KI-Auffälligkeit ist ein Ereignis, bei dem Nutzung, Ausgabe oder Verhalten eines KI-Systems von den vorgesehenen Regeln abweicht und dadurch ein relevantes Risiko oder ein tatsächlicher Schaden entstehen kann.

Dazu können beispielsweise gehören:

• sensible oder vertrauliche Informationen wurden in ein ungeeignetes KI-System eingegeben oder unerwartet ausgegeben,
• ein KI-Ergebnis mit erfundenen Fakten oder Quellen wurde extern verwendet,
• ein Agent hat eine nicht vorgesehene Aktion ausgeführt oder versucht auszuführen,
• ein System zeigt wiederholt problematische Verzerrungen in einem relevanten Prozess,
• Schutzmechanismen, Freigaben oder Berechtigungsgrenzen funktionieren nicht wie vorgesehen,
• externe Inhalte beeinflussen einen KI-Workflow auf unerwartete Weise, etwa durch Prompt Injection,
• Mitarbeitende entdecken einen neuen Anwendungsfall, der deutlich außerhalb des freigegebenen Rahmens liegt.

Nicht jeder dieser Fälle ist automatisch ein schwerwiegender Vorfall im Sinne des AI Act. Genau deshalb sollte die interne Erstmeldung niedrigschwelliger sein als die spätere rechtliche Einordnung.

2. Der erste Schritt muss für Mitarbeitende einfach sein

In einem Vorfall zählt Klarheit. Eine 20-seitige Richtlinie hilft wenig, wenn eine Person gerade bemerkt, dass ein KI-Agent eine falsche Nachricht versendet hat. Gute interne Regeln beantworten deshalb drei unmittelbare Fragen: Was soll ich stoppen? Was soll ich sichern? Wen informiere ich?

Für viele Szenarien ist eine einfache Reihenfolge sinnvoll. Zuerst weitere Auswirkungen begrenzen, sofern dies ohne zusätzliche Risiken möglich ist. Das kann bedeuten, einen automatisierten Workflow zu pausieren, einen Entwurf nicht zu versenden oder keine weiteren Daten einzugeben. Danach sollten die für die Analyse notwendigen Informationen erhalten bleiben. Schließlich erfolgt die Meldung über einen bekannten Kanal.

Wichtig ist, Mitarbeitende nicht zu spontanen technischen Eingriffen zu verleiten, für die sie nicht zuständig sind. Ein Anwender sollte beispielsweise nicht auf eigene Faust Logs löschen oder komplexe Zugriffsrechte verändern. Der Meldeweg muss klar machen, welche Sofortmaßnahme zur eigenen Rolle gehört und wann IT oder Informationssicherheit übernimmt.

3. Ein gutes Meldeformular sammelt wenig, aber Relevantes

Ein interner KI-Meldekanal braucht kein umfangreiches Ticketschema. Für die erste Bewertung reichen häufig wenige Angaben:

• Welches KI-System oder welcher Workflow war betroffen?
• Was sollte eigentlich passieren und was ist stattdessen passiert?
• Wann wurde die Auffälligkeit bemerkt?
• Welche Daten, Personen, Kunden oder Systeme könnten betroffen sein?
• Wurde bereits eine externe Nachricht oder Aktion ausgelöst?
• Welche Sofortmaßnahme wurde durchgeführt?
• Gibt es einen Screenshot, eine Vorgangsnummer oder andere nachvollziehbare Belege?

Dabei gilt: Nicht unnötig sensible Inhalte in das Meldeticket kopieren. Wenn beispielsweise ein vertrauliches Dokument betroffen ist, kann zunächst ein Verweis auf den geschützten Speicherort sinnvoller sein als eine zusätzliche Kopie im Ticketsystem. Der konkrete Prozess sollte mit Datenschutz und Informationssicherheit abgestimmt werden.

4. Eskalation nach Auswirkungen statt nach KI-Buzzwords

Nicht jeder Fehler eines Sprachmodells braucht ein Krisenteam. Umgekehrt kann ein unspektakulär wirkender Vorgang relevant sein, wenn er viele Personen oder einen kritischen Geschäftsprozess betrifft. Deshalb sollte die Priorisierung an möglichen Auswirkungen ausgerichtet werden.

Ein internes Brainstorming mit einer offensichtlich falschen Zahl lässt sich meist im Arbeitsprozess korrigieren. Eine falsche Zahl in einer bereits versendeten Kundeninformation verlangt eine andere Reaktion. Ein unautorisierter Zugriff auf sensible Daten wiederum kann zusätzlich Datenschutz- oder Sicherheitsprozesse berühren.

Ein pragmatisches Eskalationsmodell kann vier Faktoren berücksichtigen: Reichweite, Reversibilität, Sensitivität der Daten und Bedeutung des betroffenen Prozesses. Daraus lässt sich ableiten, ob das Fachteam selbst korrigiert oder ob weitere Funktionen einbezogen werden müssen.

Die rechtliche Bewertung sollte an zuständige Stellen gehen. Artikel 73 des EU AI Act enthält Meldepflichten für bestimmte schwerwiegende Vorfälle im Zusammenhang mit Hochrisiko-KI-Systemen und adressiert insbesondere Anbieter; weitere Konstellationen und Pflichten können hinzukommen. Unternehmen sollten daraus weder ableiten, dass jeder KI-Fehler extern gemeldet werden muss, noch dass außerhalb dieser Vorschrift keine anderen Melde- oder Reaktionspflichten bestehen können.

5. Rollen vor dem Vorfall festlegen

Ein Meldeprozess funktioniert besser, wenn Zuständigkeiten nicht erst im Ernstfall ausgehandelt werden. Für jeden relevanten KI-Use-Case sollte mindestens eine fachlich verantwortliche Stelle bekannt sein. Je nach Organisation kommen IT, Informationssicherheit, Datenschutz, Legal, Compliance, Einkauf oder Kommunikation hinzu.

Hilfreich ist eine kleine Verantwortungsmatrix:

• Anwender erkennen Auffälligkeiten, begrenzen einfache Folgewirkungen und melden den Fall.
• Fachverantwortliche bewerten Prozess und fachliche Auswirkungen.
• Technische Betreiber sichern technische Informationen und können Funktionen oder Zugänge kontrolliert stoppen.
• Datenschutz und Informationssicherheit werden nach definierten Kriterien eingebunden.
• Zuständige Rechts- oder Compliance-Funktionen prüfen mögliche externe Pflichten, wenn der Sachverhalt dies erfordert.
• Eine benannte Person entscheidet über Wiederanlauf und notwendige Änderungen am Prozess.

Diese Rollen müssen zur Größe des Unternehmens passen. In einem Mittelständler können mehrere Aufgaben bei derselben Person liegen. Entscheidend ist nicht die Zahl der Gremien, sondern dass der Weg bekannt und handlungsfähig ist.

6. Protokolle und Belege gezielt sichern

KI-Vorfälle sind oft schwer nachzuvollziehen, wenn Modellversion, Prompt, Datenquelle oder Werkzeugaufruf später nicht mehr bekannt sind. Unternehmen sollten deshalb vorab definieren, welche Informationen für relevante Systeme verfügbar sein müssen. Dazu können Workflow-Version, Zeitstempel, verwendete Datenquelle, Freigabeentscheidung und ausgeführte Aktion gehören.

Das bedeutet nicht, alles unbegrenzt zu speichern. Umfang und Aufbewahrung müssen zum Zweck und zu den geltenden Anforderungen passen. Gerade vollständige Prompts oder Ausgaben können personenbezogene oder vertrauliche Informationen enthalten. Gute Governance verbindet Nachvollziehbarkeit mit Datenminimierung und geregelten Zugriffsrechten.

Das NIST AI Risk Management Framework bietet dafür einen freiwilligen, nicht rechtsverbindlichen Orientierungsrahmen. Es strukturiert AI-Risikomanagement entlang von Govern, Map, Measure und Manage. Der Generative-AI-Profile ergänzt spezifische Maßnahmen für generative KI, darunter Monitoring, Tests und den Umgang mit Vorfällen. Für deutsche Unternehmen ersetzt das keine rechtliche Prüfung, kann aber bei der Gestaltung interner Kontrollen helfen.

7. Wiederanlauf braucht eine bewusste Entscheidung

Nach einer schnellen Korrektur entsteht leicht der Impuls, einen gestoppten KI-Workflow sofort wieder einzuschalten. Besser ist ein definierter Wiederanlauf. Vorher sollte geklärt sein, was die Ursache war, welche Änderung vorgenommen wurde und wie geprüft wurde, dass dieselbe Fehlerklasse angemessen behandelt wird.

Bei einem Agenten kann das eine reduzierte Berechtigung oder zusätzliche Freigabe sein. Bei einem Wissensassistenten vielleicht eine korrigierte Datenquelle. Bei einem Anwenderfehler kann eine klarere Nutzungsregel oder gezielte Schulung notwendig sein. Nicht jeder Vorfall verlangt eine technische Änderung; manchmal ist der Prozess oder die Erwartung an das System das eigentliche Problem.

8. Lessons Learned in Schulung und Governance zurückführen

Der wertvollste Vorfall ist derjenige, aus dem die Organisation lernt. Nach Abschluss sollte deshalb nicht nur ein Ticket geschlossen werden. Prüfen Sie, ob Richtlinie, Tool-Konfiguration, Testfälle oder Schulungsinhalte angepasst werden müssen. Wiederkehrende kleine Auffälligkeiten können wichtiger sein als ein einzelner spektakulärer Fehler, weil sie auf eine systematische Lücke hinweisen.

Hier trifft Incident Management direkt auf AI Literacy. Artikel 4 des EU AI Act verlangt Maßnahmen, die die Entwicklung von KI-Kompetenz bei Mitarbeitenden und weiteren Personen unterstützen, die im Auftrag mit KI-Systemen arbeiten. Dabei sind technisches Wissen, Erfahrung, Ausbildung und der konkrete Nutzungskontext zu berücksichtigen. Die Europäische Kommission stellt nach der Änderung 2026 klar, dass kein bestimmtes identisches Kompetenzniveau jeder einzelnen Person vorgeschrieben ist.

Für die Praxis heißt das: Ein allgemeines Grundlagenmodul kann erklären, dass KI Fehler machen kann. Ein rollenbezogenes Training sollte zusätzlich zeigen, welche Fehler im eigenen Prozess relevant sind und wie sie gemeldet werden. Ein Supportteam braucht andere Beispiele als HR, Marketing oder ein technisches Team, das KI-Agenten betreibt.

9. Drei Übungen, die einen Meldeweg wirklich testbar machen

Ein Prozess auf Papier ist noch kein funktionierender Prozess. Kleine Übungen zeigen schnell, wo Unklarheiten liegen.

• Szenario Daten: Eine Person bemerkt nach dem Upload, dass ein Dokument Informationen enthält, die für das verwendete Tool nicht freigegeben sind. Findet sie innerhalb weniger Minuten den richtigen Meldeweg?
• Szenario falsche Ausgabe: Ein KI-generierter Text mit erfundener Quelle wurde bereits an einen Kunden geschickt. Ist klar, wer fachliche Korrektur und Kommunikation koordiniert?
• Szenario Agent: Ein automatisierter Workflow versucht eine Aktion außerhalb des vorgesehenen Rahmens. Können Berechtigungen oder der Workflow kontrolliert gestoppt und anschließend untersucht werden?

Solche Übungen müssen keine große Krisensimulation sein. Schon ein kurzer Tabletop-Test mit Fachbereich und zuständigen Funktionen zeigt, ob Kontaktdaten, Rollen und Entscheidungswege wirklich funktionieren.

10. Eine kompakte Checkliste für Unternehmen

Für einen belastbaren Start sollten Unternehmen folgende Punkte beantworten können:

• Gibt es eine verständliche interne Definition relevanter KI-Auffälligkeiten?
• Kennen Mitarbeitende einen zentralen Meldekanal?
• Ist geregelt, welche Sofortmaßnahmen Anwender selbst durchführen dürfen?
• Sind fachliche, technische und rechtliche Zuständigkeiten benannt?
• Werden notwendige Belege nachvollziehbar, aber datensparsam gesichert?
• Gibt es Kriterien für Eskalation und Wiederanlauf?
• Werden wiederkehrende Fehler und Beinahe-Vorfälle ausgewertet?
• Fließen Erkenntnisse in Tests, Richtlinien und Schulungen zurück?

Fazit: Meldekompetenz gehört zur sicheren KI-Nutzung

Unternehmen können nicht jeden KI-Fehler verhindern. Sie können aber dafür sorgen, dass Auffälligkeiten früh sichtbar werden und nicht zwischen Fachbereich, IT und Governance verloren gehen. Ein guter interner Meldeweg ist einfach genug für den Arbeitsalltag und präzise genug, damit zuständige Personen schnell bewerten können, was passiert ist.