KI-Leitplanken sind nicht nur Regeln vor der Nutzung. Sie müssen auch greifen, wenn etwas schiefgeht: eine KI-Ausgabe ist fachlich falsch, ein vertraulicher Text wurde in ein nicht freigegebenes Tool kopiert, ein Chatbot gibt eine irrefuehrende Antwort oder eine betroffene Person beschwert sich. Soziale Organisationen brauchen dafür keinen schweren Krisenapparat, aber einen klaren, schnellen und dokumentierten Incident-Prozess.
Kurzantwort
Soziale Organisationen sollten KI-Vorfälle nicht erst dann bearbeiten, wenn bereits eine große Krise entstanden ist. In diesem Fachimpuls ist "KI-Incident" ein organisationsinterner Sammelbegriff: Gemeint sind relevante Vorfälle im Zusammenhang mit KI-Nutzung, etwa falsche fachliche Hinweise, Datenschutzrisiken, Sicherheitsstörungen, Beschwerden oder irrefuehrende KI-Inhalte. Das ist bewusst weiter gefasst als der gesetzliche Begriff des schwerwiegenden Vorfalls nach der KI-Verordnung.
Nicht jeder KI-Fehler ist automatisch eine meldepflichtige Datenpanne oder ein formeller Incident. Ein harmloser Fehler in einer internen Übung kann direkt korrigiert und als Lernhinweis genutzt werden. Sobald aber Personen, sensible Daten, Fachentscheidungen, Beschwerden, öffentliche Kommunikation oder wiederholte Muster betroffen sein können, braucht es eine strukturierte Einstufung.
Sobald personenbezogene Daten betroffen sein können, muss der Verantwortliche prüfen. Der datenschutzrechtlich Verantwortliche ist in der Regel die Organisation beziehungsweise der Träger. Er prüft unter Einbindung der Datenschutzfunktion, ob eine Datenschutzverletzung im Sinne der DSGVO vorliegt und ob Melde- oder Informationspflichten greifen. Dafür braucht es klare Rollen und eine dokumentierte Entscheidung.
Ein schlanker Incident-Prozess reicht oft aus. Er sollte sieben Schritte enthalten: melden, sichern, einstufen, begrenzen, Auswirkungen und Pflichten prüfen, kommunizieren und lernen. Wichtig ist nicht ein dickes Handbuch, sondern ein Weg, den Mitarbeitende im Alltag wirklich kennen.
Was Leitung, Datenschutz und QM jetzt klären sollten
- Meldeweg: Wo melden Mitarbeitende KI-Fehler, auffällige Antworten, Datenrisiken oder Beschwerden?
- Ersteinstufung: Wer entscheidet, ob Datenschutz, IT-Sicherheit, Fachaufsicht, Beschwerdemanagement oder Leitung einzubeziehen sind?
- Sofortmaßnahmen: Wer darf Nutzung stoppen, Inhalte löschen, Zugriffe sperren, Anbieter kontaktieren oder Betroffene informieren?
- Dokumentation: Welche Mindestangaben gehören in ein KI-Incident-Protokoll, inklusive Risikostufe, Status, Frist und Entscheidungsbegründung?
- Lernen: Wie werden Ursachenanalyse, Maßnahmenverfolgung, Wirksamkeitskontrolle, Leitplanken, Schulung, Toolfreigabe und QM nach einem Vorfall verbunden?
Warum KI-Vorfälle früh erkannt werden müssen
KI wird in sozialen Organisationen oft zuerst in kleinen Alltagssituationen genutzt: ein Textentwurf, eine Zusammenfassung, eine Übersetzung, ein Chatbot, eine Protokollhilfe, ein Bild für Social Media oder ein Rechercheauftrag. Gerade weil diese Nutzung niedrigschwellig wirkt, werden Vorfälle häufig zu spät erkannt.
Ein KI-Vorfall beginnt nicht erst bei einem großen Schaden. Er kann schon entstehen, wenn eine KI-Ausgabe fachlich falsch ist, eine Entscheidung unzulässig beeinflusst, eine vertrauliche Information in ein falsches Tool gelangt, ein Team Schatten-KI nutzt oder eine Person sich durch KI-Kommunikation nicht ernst genommen fühlt. In sozialen Arbeitsfeldern kann daraus schnell ein Vertrauensproblem werden.
Ein Incident-Prozess hilft, ruhig und geordnet zu reagieren. Er soll keine Schuldsuche starten, sondern Orientierung geben: Was ist passiert? Welche Personen, Daten, Prozesse oder Entscheidungen sind betroffen? Was muss sofort gestoppt werden? Wer muss informiert werden? Welche Auswirkungen und Pflichten sind zu prüfen? Und was lernen wir daraus?
Damit wird Incident Response zu einem Teil von KI-Governance. Wer KI-Tools freigibt, sollte gleichzeitig festlegen, wie Fehler, Beschwerden und Datenrisiken gemeldet und bearbeitet werden.
Welche KI-Incident-Typen soziale Organisationen kennen sollten
KI-Incident ist hier kein eigener gesetzlicher Tatbestand, sondern ein organisationsinterner Sammelbegriff. Er hilft, unterschiedliche KI-bezogene Auffälligkeiten früh zu erfassen: fachliche Qualitätsprobleme, Datenschutzrisiken und mögliche Datenschutzvorfälle, Sicherheitsstörungen, Beschwerden oder Kommunikationsrisiken. Eine gute Ersteinstufung verhindert, dass alles dramatisiert wird, aber auch, dass echte Risiken liegen bleiben.
Davon zu unterscheiden ist der schwerwiegende Vorfall nach der KI-Verordnung. Die dort geregelten Pflichten gelten nicht für jeden KI-Fehler und nicht pauschal für jedes eingesetzte KI-Tool. Ob Pflichten aus der KI-Verordnung relevant werden, hängt unter anderem von Rolle, Systemart, Risikoklasse und konkretem Einsatz ab. Für die meisten Alltagssituationen sozialer Organisationen ist deshalb zunächst der interne Incident-Prozess wichtig; bei höherem Risiko muss die rechtliche Einordnung gezielt geprüft werden.
Fachliche KI-Fehler entstehen, wenn eine KI falsche Informationen liefert, wichtige Einschränkungen auslässt, Quellen erfindet, Hilfeverläufe verkürzt, sozialrechtliche Aussagen ungenau wiedergibt oder Risiken in Beratung, Hilfeplanung oder Dokumentation verharmlost.
Datenschutzrisiken und mögliche Datenschutzvorfälle können entstehen, wenn personenbezogene Daten, Sozialdaten, Gesundheitsdaten, interne Protokolle, Beschwerden, Hilfeverläufe oder vertrauliche Informationen in ein nicht freigegebenes Tool eingegeben, versehentlich geteilt oder unklar gespeichert werden.
Sicherheits- und Toolvorfälle betreffen zum Beispiel unbefugte Zugriffe, falsche Freigaben, geteilte Konten, kompromittierte Zugangsdaten, fehlerhafte Schnittstellen, unsichere Prompt- oder Dokumentenablagen oder eine KI-Funktion, die unerwartet Daten ausgibt.
Beschwerden und Vertrauensvorfälle entstehen, wenn Menschen KI-Einsatz als intransparent, entwertend, übergriffig oder falsch erleben. Gerade in sozialen Organisationen gehört diese Kategorie ernst genommen, auch wenn nicht sofort eine Datenschutzverletzung vorliegt.
Begriffe unterscheiden: KI-Fehler, Incident, Datenschutzverletzung und Beschwerde
Nicht jeder Begriff meint dasselbe. Die folgende Tabelle hilft, im Alltag nicht vorschnell zu dramatisieren, aber auch keine relevanten Pflichten zu übersehen.
| Begriff | Kurz erklärt | Typische Reaktion | Wichtige Abgrenzung |
|---|---|---|---|
| KI-Fehler | Eine KI-Ausgabe ist falsch, unvollständig, irrefuehrend oder fachlich unpassend. | Korrigieren, fachlich prüfen, Lernhinweis oder Toolregel anpassen. | Nicht jeder KI-Fehler muss den formellen Incident-Prozess auslösen. |
| KI-Incident | Organisationsinterner Sammelbegriff für relevante KI-bezogene Vorfälle. | Melden, sichern, einstufen, begrenzen und dokumentiert bearbeiten. | Kein eigener gesetzlicher Begriff und nicht automatisch ein schwerwiegender Vorfall. |
| Datenschutzverletzung | Verletzung der Sicherheit mit Vernichtung, Verlust, Veränderung, unbefugter Offenlegung oder unbefugtem Zugang zu personenbezogenen Daten. | Verantwortlicher prüft mit Datenschutzfunktion Art. 33 und 34 DSGVO. | Nicht jede sonstige unrechtmäßige Verarbeitung ist automatisch eine Datenschutzverletzung. |
| Beschwerde | Rückmeldung von betroffenen Personen, Mitarbeitenden oder Dritten zu KI-Nutzung, Ergebnis, Umgang oder Transparenz. | Beschwerde aufnehmen, fachlich prüfen, Antwort und Verbesserungsmaßnahmen festlegen. | Kann ohne Datenschutzverletzung relevant sein und trotzdem Eskalation erfordern. |
| Schwerwiegender Vorfall nach KI-Verordnung | Rechtlich geregelter Begriff für bestimmte, von der KI-Verordnung erfasste Konstellationen. | Rolle, Systemart, Risikoklasse und konkrete Pflichten gezielt prüfen. | Gilt nicht pauschal für jeden KI-Fehler und nicht für jedes eingesetzte KI-Tool. |
Der 7-Schritte-Prozess für KI-Incidents
Ein schlanker Prozess sollte so einfach sein, dass Teams ihn in einer angespannten Situation anwenden können. Die folgenden sieben Schritte reichen als Grundstruktur für viele kleine und mittlere soziale Organisationen aus.
1. Melden
Mitarbeitende brauchen eine klare Stelle für KI-Vorfälle. Das kann eine E-Mail-Adresse, ein Formular, ein QM-Ticket, eine Leitungsperson oder eine KI-Brückenfunktion sein. Wichtig ist: Niemand sollte erst überlegen müssen, ob ein Vorfall "groß genug" ist. Lieber früh melden und dann sauber einstufen. Gleichzeitig sollte klar sein: Kleine, eindeutig harmlose KI-Fehler ohne Personen-, Daten-, Entscheidungs- oder Vertrauensbezug können als normale Qualitätskorrektur behandelt werden.
2. Sichern
Der Vorfall sollte nachvollziehbar gesichert werden: Screenshot, Toolname, Zeitpunkt, beteiligte Personen, betroffener Prozess, verwendete Eingaben, KI-Ausgabe, Link oder Dokument. Dabei dürfen nicht zusätzlich Daten verbreitet werden. Screenshots mit sensiblen Daten gehören in einen geschützten Ablageort.
3. Einstufen
Die erste Frage lautet: Geht es um Fachlichkeit, Datenschutz, IT-Sicherheit, Beschwerde, Öffentlichkeit, Arbeitsrecht, Sozialrecht oder mehrere Bereiche zugleich? Daraus ergibt sich, wer sofort beteiligt werden muss und wie dringlich der Vorfall ist.
4. Begrenzen
Sofortmaßnahmen können sein: KI-Nutzung stoppen, Chatbot deaktivieren, betroffene Inhalte entfernen, Zugriff sperren, Passwort ändern, Anbieter kontaktieren, Dokument korrigieren, Fachentscheidung überprüfen oder interne Kommunikation starten. Ziel ist, weiteren Schaden zu verhindern.
5. Auswirkungen und Pflichten prüfen
Wenn personenbezogene Daten betroffen sein können, muss der Verantwortliche unter Einbindung der Datenschutzfunktion unverzueglich prüfen, ob eine Datenschutzverletzung vorliegt und ob eine Meldung an die Aufsichtsbehoerde oder eine Information betroffener Personen erforderlich ist. Bei bestimmten KI-Systemen, Rollen oder Einsatzkonstellationen können zusätzliche Pflichten aus der KI-Verordnung, aus Vertragen oder aus Aufsichtsanforderungen relevant sein. Das gilt aber nicht pauschal für jeden KI-Fehler.
6. Kommunizieren
Kommunikation sollte abgestimmt und ruhig erfolgen. Intern müssen die richtigen Stellen informiert sein. Extern kann Kommunikation gegenüber betroffenen Personen, Angehoerigen, Auftraggebern, Aufsicht, Anbieter, Presse oder Kooperationspartnern erforderlich sein. Eine Beschwerde sollte nicht technisch abgewehrt, sondern fachlich ernst genommen werden.
7. Lernen
Nach dem Vorfall sollte die Organisation prüfen, was verbessert werden muss: Toolfreigabe, Datenverbote, Schulung, Promptregeln, Datenschutzprüfung, Beschwerdeweg, Rollen, technische Einstellungen, Dokumentation oder Leitplanken. Zum Lernen gehören Ursachenanalyse, Maßnahmenverfolgung und Wirksamkeitskontrolle. Ein guter Incident-Prozess endet mit einer überprüften Verbesserung, nicht nur mit einem abgelegten Protokoll.
Drei Incident-Stufen und interne Reaktionszeiten
Die Stufen sind interne Orientierung. Sie ersetzen keine Datenschutz-, Rechts- oder Sicherheitsprüfung, helfen aber, Reaktion und Eskalation berechenbar zu machen.
| Stufe | Definition | Interne Reaktionszeit | Eskalation |
|---|---|---|---|
| Niedrig | Fachlicher oder technischer KI-Fehler ohne Personenbezug, ohne sensible Daten, ohne externe Wirkung und ohne erkennbare Wiederholungsgefahr. | Innerhalb von 5 Arbeitstagen prüfen und korrigieren. | Fachverantwortung oder QM; formeller Incident-Prozess nur bei Musterbildung. |
| Prüfpflichtig | Möglicher Personenbezug, Beschwerde, fachliche Auswirkung, wiederholter Fehler, unklare Toolfreigabe oder externe Kommunikation betroffen. | Innerhalb von 1 Arbeitstag erstbewerten; Fristen und koordinierende Person festlegen. | Verantwortlicher, Datenschutzfunktion, QM, Fachleitung und ggf. IT einbinden. |
| Kritisch | Sensible Daten, mögliche Datenschutzverletzung, Sicherheitsvorfall, erheblicher Vertrauensschaden, Schutzkontext, öffentliche Wirkung oder laufender Schaden möglich. | Sofort, möglichst am selben Arbeitstag, begrenzen und eskalieren; Datenschutzprüfung unverzueglich beginnen und mögliche Meldefrist berücksichtigen. | Verantwortlicher, Datenschutzfunktion, IT, Leitung, QM, Fachverantwortung und je nach Fall Rechtsberatung, Aufsicht oder Anbieter. |
Wann Datenschutz und Meldepflichten relevant werden
Eine Datenschutzverletzung im Sinne von Artikel 4 Nummer 12 DSGVO ist eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugang zu personenbezogenen Daten führt. Sie kann unbeabsichtigt oder unrechtmäßig geschehen. Nicht jede sonstige unrechtmäßige Verarbeitung ist deshalb automatisch eine Datenschutzverletzung im Sinne dieser Definition.
Bei KI-Nutzung kann eine solche Situation zum Beispiel entstehen, wenn echte Falldaten in ein nicht freigegebenes KI-Tool eingegeben werden, ein Chatbot vertrauliche Informationen ausgibt oder ein KI-gestütztes System Daten falschen Personen zugänglich macht.
Artikel 33 DSGVO verlangt bei meldepflichtigen Datenschutzverletzungen eine Meldung an die zuständige Aufsichtsbehoerde grundsätzlich binnen 72 Stunden, nachdem die Verletzung bekannt wurde. Artikel 34 DSGVO kann eine Benachrichtigung betroffener Personen erforderlich machen, wenn voraussichtlich ein hohes Risiko für deren Rechte und Freiheiten besteht. Artikel 33 Absatz 5 DSGVO verlangt außerdem, Datenschutzverletzungen einschließlich der damit zusammenhängenden Fakten, Auswirkungen und Abhilfemaßnahmen zu dokumentieren. Diese Dokumentation muss der Aufsichtsbehoerde eine Überpruefung ermöglichen.
Der Incident-Prozess sollte deshalb nicht versuchen, Datenschutzfragen nebenbei zu lösen. Er sollte sicherstellen, dass der Verantwortliche die Datenschutzfunktion früh einbindet und die Entscheidung dokumentiert. Die Datenschutzfunktion berät, prüft und unterstützt; die Entscheidung über Meldung und Kommunikation liegt beim Verantwortlichen. Gerade soziale Organisationen arbeiten häufig mit Sozialdaten, Gesundheitsdaten, Schutzinformationen und vertraulichen Beratungskontexten. Das erhöht den Prüfbedarf.
Hinzu kommen können weitere Verschwiegenheits- und Geheimhaltungspflichten, etwa Sozialgeheimnis, berufliche Schweigepflichten, arbeitsvertragliche Vertraulichkeit, interne Schutzkonzepte, Geheimhaltungsvereinbarungen oder besondere Vorgaben aus Leistungs-, Beratungs- und Schutzkontexten. Sie ersetzen die DSGVO-Prüfung nicht, können aber die Risikobewertung und Kommunikation deutlich verschaerfen.
Wichtig: Eine Beschwerde, ein KI-Fehler oder ein irritierender Chatbot ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Aber wenn personenbezogene Daten betroffen sein können, braucht es eine nachvollziehbare Prüfung. Auch wenn keine externe Meldung erfolgt, sollte die Entscheidung intern begründet und dokumentiert werden.
Rollen, Verantwortung und Eskalation
Ein Incident-Prozess braucht klare Rollen, aber kein übergroßes Gremium. Für viele Organisationen reicht ein kleiner Kern: Verantwortlicher beziehungsweise Leitung oder beauftragte Entscheidungsperson, Datenschutzfunktion, IT oder Toolverantwortung, Qualitätsmanagement und fachliche Verantwortung aus dem betroffenen Bereich.
Der Verantwortliche entscheidet über Prioritaet, Ressourcen, Datenschutzmeldung, Eskalation und externe Kommunikation. Die Datenschutzfunktion prüft Personenbezug, Datenarten, Meldepflichten, Betroffenenrechte und Dokumentation und berät die Entscheidung. IT oder Toolverantwortung prüft technische Ursachen, Zugriffe, Anbieter, Protokolle und Sperrungen. QM sorgt für Verfahren, Nachweise, Ursachenanalyse, Maßnahmenverfolgung, Verbesserungsmaßnahmen, Wirksamkeitskontrolle und Lessons Learned. Die Fachpraxis bewertet, welche fachlichen Folgen ein Fehler hatte und ob Entscheidungen, Dokumentationen oder Beratungsprozesse korrigiert werden müssen.
Bei bestimmten Vorfällen können weitere Stellen erforderlich sein: Rechtsberatung, Mitarbeitendenvertretung, Fachaufsicht, Trägerkommunikation, Kinderschutzverantwortliche, Beschwerdemanagement, externe IT-Dienstleister oder der Toolanbieter. Der Prozess sollte deshalb eine einfache Eskalationsregel enthalten: Wer wird ab welchem Risiko informiert?
Incident-Matrix: niedrig, prüfpflichtig oder kritisch?
Die folgende Matrix hilft bei der ersten Einordnung. Sie ersetzt keine Datenschutz- oder Rechtsprüfung, macht aber sichtbar, wann ein Vorfall nicht im Teamalltag hängen bleiben darf.
| Vorfall | Erste Einordnung | Sofortmaßnahme | Einzubinden |
|---|---|---|---|
| KI liefert eine falsche allgemeine Antwort in einer internen Übung. | Niedrig bis prüfpflichtig | Antwort korrigieren, Schulungshinweis ergaenzen. | Fachverantwortung, ggf. QM. |
| Mitarbeitende geben einen vermeintlich anonymisierten, möglicherweise re-identifizierbaren Fall in ein ungeprüftes Tool ein. | Prüfpflichtig bis kritisch | Nutzung stoppen, Eingabe sichern, Toolkontext klären. | Verantwortlicher, Datenschutzfunktion, Fachverantwortung, ggf. IT. |
| Chatbot gibt eine fachlich falsche Empfehlung in einem Beratungsangebot. | Prüfpflichtig | Botantwort deaktivieren oder korrigieren, Betroffenheit prüfen. | Fachleitung, IT/Tool, QM, ggf. Datenschutz. |
| KI-generierter Text wird ungeprüft öffentlich veröffentlicht und enthaelt falsche Aussagen. | Prüfpflichtig bis kritisch | Text korrigieren oder entfernen, Kommunikation prüfen. | Leitung, Kommunikation, Fachverantwortung, ggf. Rechtsberatung. |
| Ein KI-Tool gibt vertrauliche Dokumenteninhalte an falsche Nutzer aus. | Kritisch | Zugriff sperren, Vorfall sichern, Ausbreitung stoppen. | Verantwortlicher, Datenschutzfunktion, IT, Anbieter, ggf. Rechtsberatung. |
| Eine betroffene Person beschwert sich über eine KI-gestützte Entscheidung oder Kommunikation. | Prüfpflichtig | Beschwerde aufnehmen, menschliche Prüfung zusichern. | Beschwerdemanagement, Fachleitung, Datenschutzfunktion, Verantwortlicher. |
| Zugangsdaten für ein KI-Tool wurden geteilt oder kompromittiert. | Kritisch | Zugriff sperren, Passwortwechsel, Protokolle prüfen. | IT, Datenschutzfunktion, Verantwortlicher, Anbieter. |
Praxisbeispiele
Beispiel 1: Falldaten im falschen Tool
Eine Fachkraft bittet ein frei verfügbares KI-Tool, eine Fallnotiz sprachlich zu verbessern. Namen wurden entfernt, aber Alter, Hilfeform, Wohnort, Familiensituation und besondere Ereignisse bleiben enthalten. Später fällt auf, dass der Fall möglicherweise re-identifizierbar ist.
Der Incident-Prozess sorgt dafür, dass die Fachkraft nicht allein bleibt. Der Vorfall wird gemeldet, die Eingabe wird gesichert, weitere Nutzung wird gestoppt und der Verantwortliche prüft unter Einbindung der Datenschutzfunktion, ob personenbezogene Daten betroffen sind und ob Meldepflichten bestehen. Anschliessend wird die Teamregel verbessert: echte, pseudonymisierte oder möglicherweise re-identifizierbare Falldaten gehören nicht in nicht freigegebene KI-Tools.
Beispiel 2: Chatbot gibt eine falsche Hilfeinformation
Ein Website-Chatbot einer Beratungsstelle beantwortet eine Frage zu einem Angebot falsch und nennt einen nicht passenden Beratungsweg. Eine Nutzerin beschwert sich, weil sie dadurch Zeit verloren hat und sich abgewiesen fühlt.
Hier geht es nicht zuerst um Technik, sondern um Vertrauen und Fachlichkeit. Der Bot wird geprüft, die Antwort wird deaktiviert oder korrigiert, die Beschwerde wird ernst genommen und menschlich beantwortet. Das Team prüft, ob der Bot klar genug sagt, dass er keine Beratung ersetzt und wie schnell Menschen einen direkten Kontakt finden.
Beispiel 3: KI-generiertes Protokoll mit vertraulichem Inhalt
Ein Team testet ein KI-Protokolltool für Fallbesprechungen. Danach stellt sich heraus, dass Tonmitschnitt und Transkript länger gespeichert wurden als erwartet. Es ist unklar, wer Zugriff hatte und ob der Anbieter die Inhalte weiterverarbeitet.
Der Vorfall ist kritisch, weil vertrauliche Inhalte und möglicherweise Sozialdaten betroffen sind. IT und Datenschutzfunktion müssen den Anbieter- und Toolkontext prüfen, der Verantwortliche muss Sofortmaßnahmen entscheiden und QM dokumentiert, welche Freigabepruefung vor künftigen Tests erforderlich ist.
Beispiel 4: Mitarbeitendenbeschwerde über KI-Kontrolle
Mitarbeitende melden, dass ein KI-Tool zur Auswertung von Textqualität als Leistungsüberwachung erlebt wird. Die Organisation hatte das Tool eigentlich nur für Qualitätsfeedback getestet.
Auch ohne klassische Datenpanne ist das ein relevanter KI-Incident. Leitung, Mitarbeitendenvertretung, Datenschutzfunktion, QM und Fachverantwortung sollten klären, ob Zweck, Information, Beteiligung und Grenzen sauber geregelt waren. Der Prozess hilft, Beschwerden nicht als Störung, sondern als Frühwarnsignal zu behandeln.
Checkliste für den internen Incident-Prozess
- Gibt es einen klaren Meldeweg für KI-Fehler, Datenrisiken, Sicherheitsvorfälle und Beschwerden?
- Wissen Mitarbeitende, dass frühe Meldung gewünscht ist und nicht automatisch Schuldzuweisung bedeutet?
- Gibt es ein kurzes KI-Incident-Formular oder Protokoll?
- Enthaelt das Protokoll koordinierende Person, Risikostufe, Status, Frist, nächsten Prüftermin, Entscheidungsbegründung und Wirksamkeitskontrolle?
- Wer macht die Ersteinstufung innerhalb der Organisation?
- Ist klar, wann Datenschutzfunktion, IT, Leitung, QM, Fachverantwortung und Beschwerdemanagement einzubeziehen sind?
- Gibt es Sofortmaßnahmen für typische Fälle: Nutzung stoppen, Zugriff sperren, Inhalt entfernen, Anbieter kontaktieren, Nachteile für Betroffene begrenzen?
- Ist geregelt, wie personenbezogene Daten im Vorfallprotokoll geschützt werden?
- Wer prüft mögliche Meldepflichten nach DSGVO oder anderen Vorgaben, und wie wird die Datenschutzfunktion eingebunden?
- Wer entscheidet als Verantwortlicher über externe Kommunikation gegenüber Betroffenen, Aufsicht, Auftraggebern, Anbieter oder Öffentlichkeit?
- Wer dokumentiert Entscheidung, Begründung, Maßnahmen, Status, Abschluss und Wirksamkeitskontrolle?
- Gibt es nach jedem relevanten Vorfall Ursachenanalyse, Maßnahmenverfolgung und eine kleine Auswertung?
- Werden Leitplanken, Toolfreigaben, Schulungen und QM-Dokumente nach Vorfällen aktualisiert?
Mindestfelder für das KI-Incident-Protokoll
Das Protokoll sollte schlank bleiben, aber genug enthalten, damit Entscheidungen, Fristen und Maßnahmen später nachvollziehbar sind.
| Feld | Wozu es dient |
|---|---|
| Datum, Uhrzeit und meldende Person | Nachvollziehbarer Startpunkt für interne Fristen und Rückfragen. |
| Koordinierende Person | Klare Zuständigkeit für Nachverfolgung, Abstimmung und Abschluss. |
| Tool, Zweck und betroffener Prozess | Einordnung, ob Toolfreigabe, Datenschutz, IT, Fachprozess oder Kommunikation betroffen sind. |
| Vorfallbeschreibung und betroffene Daten oder Personen | Grundlage für fachliche Bewertung, Datenschutzprüfung und mögliche Kommunikation. |
| Risikostufe, Status und Frist | Steuert Reaktionszeit, Eskalation und offene Aufgaben. |
| Sofortmaßnahmen und beteiligte Rollen | Zeigt, wie weiterer Schaden begrenzt und wer eingebunden wurde. |
| Meldeprüfung und Entscheidungsbegründung | Dokumentiert, warum eine externe Meldung erfolgt oder nicht erfolgt. |
| Nächster Prüftermin | Verhindert, dass offene Fragen oder Fristen im Alltag liegen bleiben. |
| Verbesserungsmaßnahmen und Wirksamkeitskontrolle | Sichert, dass Ursachenanalyse und QM-Maßnahmen nicht nur beschlossen, sondern überprüft werden. |
Häufige Fragen
Was ist ein KI-Incident in einer sozialen Organisation?
KI-Incident ist hier ein organisationsinterner Sammelbegriff. Dazu gehören Fehler, Datenschutzrisiken, Sicherheitsstörungen, Beschwerden, irrefuehrende KI-Inhalte oder fachlich problematische Auswirkungen. Der Begriff ist nicht gleichzusetzen mit einem schwerwiegenden Vorfall nach der KI-Verordnung.
Wann wird aus einem KI-Fehler eine Datenpanne?
Wenn eine Verletzung der Sicherheit zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugang zu personenbezogenen Daten führt, kommt eine Datenschutzverletzung in Betracht. Ob eine Meldung an die Datenschutzaufsicht oder eine Information betroffener Personen erforderlich ist, entscheidet der Verantwortliche unter Einbindung der Datenschutzfunktion.
Was sollte sofort passieren, wenn ein KI-Vorfall auffällt?
Zuerst melden, sichern und begrenzen. Die Organisation sollte festhalten, was passiert ist, welches Tool beteiligt war, welche Daten oder Personen betroffen sein können und welche Sofortmaßnahmen nötig sind. Danach werden die passenden Rollen eingebunden.
Wer sollte in einem KI-Incident-Prozess beteiligt sein?
Mindestens Verantwortlicher beziehungsweise Leitung, Datenschutzfunktion, IT oder Toolverantwortung, QM und fachliche Verantwortung sollten als Rollen mitgedacht werden. Je nach Vorfall können Beschwerdemanagement, Rechtsberatung, Mitarbeitendenvertretung, Kommunikation, Fachaufsicht oder Anbieter dazukommen.
Muss jede KI-Beschwerde wie eine Datenschutzverletzung behandelt werden?
Nein. Beschwerden können fachliche, kommunikative, ethische, datenschutzrechtliche oder organisatorische Ursachen haben. Sie sollten aber so aufgenommen werden, dass schnell erkennbar wird, ob Datenschutz, Sicherheit, Leitung oder Beschwerdemanagement beteiligt werden müssen.
Wie schlank kann ein Incident-Prozess sein?
Sehr schlank, solange die sieben Mindestschritte klar sind. Melden, sichern, einstufen, begrenzen, Auswirkungen und Pflichten prüfen, kommunizieren und lernen: Diese Struktur reicht für viele Organisationen als Start.
Was gehört in ein KI-Incident-Protokoll?
Mindestens Datum, meldende Person, koordinierende Person, Tool, Zweck, Vorfallbeschreibung, betroffene Daten oder Personen, Risikostufe, Status, Frist, Sofortmaßnahmen, beteiligte Rollen, Meldeprüfung, Kommunikation, Entscheidungsbegründung, nächster Prüftermin, Abschluss, Verbesserungsmaßnahmen und Wirksamkeitskontrolle. Sensible Daten sollten dabei nur so weit dokumentiert werden, wie es für die Bearbeitung erforderlich ist.
Wer entscheidet über die Datenschutzmeldung?
Die Entscheidung trifft der datenschutzrechtlich Verantwortliche. In der Regel ist das die Organisation beziehungsweise der Träger. Die Datenschutzfunktion oder der Datenschutzbeauftragte wird einbezogen, berät und dokumentiert mit, entscheidet aber nicht anstelle des Verantwortlichen.
Gilt die KI-Verordnung bei jedem KI-Fehler?
Nein. Die Pflichten der KI-Verordnung zu schwerwiegenden Vorfällen gelten nicht für jeden KI-Fehler und nicht pauschal für jedes eingesetzte KI-Tool. Entscheidend sind Rolle, Systemart, Risikoklasse und konkreter Einsatz.
Muss auch ohne externe Meldung dokumentiert werden?
Ja, relevante Prüfungen sollten intern dokumentiert werden. Bei Datenschutzverletzungen verlangt Artikel 33 Absatz 5 DSGVO, dass der Verantwortliche Verletzungen einschließlich Fakten, Auswirkungen und Abhilfemaßnahmen dokumentiert, damit die Aufsichtsbehoerde die Einhaltung prüfen kann.
Quellen
- Definition Datenschutzverletzung, 72-Stunden-Prüfung, Benachrichtigung und Dokumentationspflicht: Verordnung (EU) 2016/679 Datenschutz-Grundverordnung (DSGVO), insbesondere Art. 4 Nr. 12, Art. 33, Art. 33 Abs. 5 und Art. 34, EUR-Lex
- Abgrenzung schwerwiegender Vorfall und rollenbezogene Pflichten: Verordnung (EU) 2024/1689 über künstliche Intelligenz (KI-Verordnung), insbesondere Rollen, Risikoklassen und Pflichten zu schwerwiegenden Vorfällen in den jeweils erfassten Konstellationen, EUR-Lex
- Datenschutz bei KI-Systemen, technische und organisatorische Maßnahmen: Datenschutzkonferenz: Orientierungshilfe Künstliche Intelligenz und Datenschutz, Stand 06.05.2024
- Datenschutz von Anfang an und Verantwortungsrahmen bei KI: Bundesbeauftragte für den Datenschutz und die Informationsfreiheit: Künstliche Intelligenz - Datenschutz von Anfang an mitdenken, Handreichung zu Datenschutz und KI, 29.12.2025
- Organisatorische Erstreaktion bei IT-Sicherheitsvorfällen: Bundesamt für Sicherheit in der Informationstechnik: Ich habe einen Vorfall - Checkliste Organisatorisches
- Vorfallunterstützung und Eskalation bei IT-Sicherheitsvorfällen: Bundesamt für Sicherheit in der Informationstechnik: Vorfallunterstützung bei IT-Sicherheitsvorfällen
- Strukturierte Behandlung, Verantwortlichkeiten, Eskalation und Nachbereitung von Sicherheitsvorfällen: Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kompendium, insbesondere Baustein DER.2.1 Behandlung von Sicherheitsvorfällen
- Datenschutzaspekte bei KI-Modellen und personenbezogenen Daten: European Data Protection Board: Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models
- Sozialgeheimnis und Sozialdaten als zusätzlicher Schutzrahmen: § 35 SGB I Sozialgeheimnis, Gesetze im Internet und § 67 SGB X Begriffsbestimmungen, Gesetze im Internet
Incident-Prozess als KI-Leitplanke festlegen
Ein guter Einstieg ist eine einseitige Incident-Karte für Teams: Was melden? Wohin melden? Was sofort stoppen? Wer prüft Datenschutz, Fachlichkeit und Beschwerde? So wird aus Unsicherheit ein handhabbarer Ablauf.
Transparenzhinweis
Dieser Fachimpuls wird von Simon Kern verantwortet. Er entsteht auf Grundlage fachlicher Erfahrung in KI, Datenschutzsensibilität, digitaler Organisationsentwicklung, qualitätsmanagementnaher Praxis und sozialer Arbeit. KI-Systeme können bei Recherche, Strukturierung oder Formulierung unterstützend eingesetzt worden sein. Die fachliche Bewertung, Auswahl, Einordnung und Verantwortung liegen beim Autor. Alle Inhalte wurden vor der Veröffentlichung fachlich und redaktionell geprüft.
Hinweis zu Rechts-, Datenschutz- und Compliance-Fragen
Dieser Fachimpuls stellt keine Rechtsberatung, keine verbindliche Datenschutzberatung und keine Einzelfallbewertung dar. Er dient ausschließlich der fachlichen Orientierung und Information. Je nach Organisation, Datenlage, eingesetztem Tool, Rolle als Anbieter oder Betreiber, Vertragsgestaltung, Vorfallart, Betroffenenkreis, Schutzbedarf, Sozialdatenbezug, Aufsichtsrahmen und konkretem Anwendungsfall kann eine individuelle rechtliche, datenschutzrechtliche, sozialrechtliche, arbeitsrechtliche, IT-sicherheitsbezogene, aufsichtsrechtliche oder organisatorische Prüfung erforderlich sein. Bei rechtlichen, datenschutzrechtlichen, sozialrechtlichen, arbeitsrechtlichen, aufsichtsrechtlichen, IT-sicherheitsbezogenen oder Compliance-relevanten Fragestellungen sollten Datenschutzbeauftragte, Rechtsberatung, IT-Sicherheitsverantwortliche, Fachaufsicht, Mitarbeitendenvertretung, QM oder andere zuständige Stellen einbezogen werden.