Data-/AI-Incidents brauchen Comms-Playbooks
Overview: Data- und AI-Incidents brauchen Kommunikations-Playbooks — Severity, Stakeholder, Regulatorik und Postmortem-Loop.
Incident-Comms-Governance beginnt nicht mit einer Pressemeldung. Sie beginnt mit der Entscheidung, welche Severity wen sprechen lässt — und welcher Text intern, extern und gegenüber der Aufsicht gelten darf.
Typische Fragen sind:
- Ist das ein Datenleck, ein Modellfehler, beides — und welche Fakten gehören ins erste Pack?
- Wer setzt Schweregrad, und welche Schwelle öffnet Legal, Comms, Datenschutzbeauftragte oder den Vorstand?
- Wer darf intern schreiben, wer darf extern sprechen, wer darf die Aufsicht informieren?
- Welche Stakeholder bekommen welchen Rhythmus, bevor Slack die Lücke füllt?
- Welche Uhr gilt für Notify — und welcher Nachweis hängt daran?
- Welche Finding wird zum Vereinbarung- oder Kontrollregel-Change, statt in einem Slide-Deck zu enden?
Wenn Engineering in Slack postet, Marketing einen Tweet entwirft und der DPO es von Journalisten erfährt, entstehen Gerüchte und verspätete Notices. Das Problem ist nicht das Status-Dashboard. Es ist der fehlende Vertrag zwischen Severity-Rechten, Stakeholder-Pack, Regulator-Pfad und Postmortem-Loop.
Gute Incident-Comms macht Krisen ausführbar — Fakten, Freigabe und Uhr am selben Incident, nicht am lautesten Thread.
Anschluss an Quality-Proof Incidents, Governance Operations und AI Assurance.
Weiter: Severity und Entscheidungsrechte.
Die Serie Crisis & Incident Communication gibt dir den Einstieg und den roten Faden. Die folgenden Teile vertiefen Severity-Rechte, Stakeholder-Pack, Regulator-Pfad und Postmortem-Loop so, dass Zweck, Rollen, Entscheidungen und Nachweise im Alltag nachvollziehbar bleiben.
Ausgangslage
Ein Scoring-Modell stuft Anträge falsch ein; parallel liegt ein Warehouse-Extract mit Kundendaten in einem falsch berechtigten Bucket. Engineering schreibt „Modell-Quirk, wir rollbacken“ in Slack. Marketing bereitet einen beruhigenden Social-Post vor. Der DPO erfährt es von einer Fachzeitschrift. Severity wird nach dem ersten Presse-Anruf gesetzt. Das Postmortem ist ein Deck ohne Control-Änderung. Teams kaufen dann eine Crisis-Platform oder taggen Tickets sev1 — und der nächste Incident füllt wieder inoffizielle Threads.
Was diese Serie klärt
- Orientierung: Schweregrad-Rechte, Stakeholder-Pack, Regulator-Pfad, Nachanalyse-Loop (diese Seite)
- Vertiefung: Schweregrad und Entscheidungsrechte
- Vertiefung: Internes Stakeholder-Comms-Pack
- Vertiefung: Externer und regulatorischer Notify-Pfad
- Abschluss: Nachanalyse → Vereinbarung-/Kontrollregel-Loop
Begriffe und Kürzel vor dem Lesen
- Schweregrad-Rechte — Stufe plus Schwelle, wer spricht und wer freigibt. Eine Ticket-Priorität ohne Kommunikationsschwelle ist keine Schweregrad im Sinne dieser Serie.
- Stakeholder-Pack — benannte Audiences, Rhythmus, Bekannt/Unbekannt, nächster Update-Termin. Intern zuerst; nicht derselbe Text wie extern.
- Regulator-Notify-Pfad — Rechtsweg, Uhr, Empfänger, angehängte Nachweis. „Wir updaten später“ ersetzt die Frist nicht.
- Nachanalyse-Loop — Findings werden zu Vereinbarung- oder Kontrollregel-Änderungen mit Owner und Datum — kein abgeschlossenes PDF.
- Data-Incident vs. KI-Incident — Exposure, Identifier und Lineage versus Modellversion, Prompt-/Tool-Umfang und Output-Wirkung. Viele Lagen sind beides; das Pack muss beide Faktenfelder tragen.
- Sprechrecht — wer intern schreiben, wer extern sprechen, wer die Aufsicht informieren darf. Wer Fakten liefert, hat damit kein Sprechrecht.
Lesepfad
- Data-/AI-Incidents brauchen Comms-Playbooks
- Severity und Entscheidungsrechte
- Internes Stakeholder-Comms-Pack
- Externer und regulatorischer Notify-Pfad
- Postmortem → Contract-/Control-Loop
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Incident-, Modell- und Systemnamen durch eure Ticket-, Comms- und Prozessquellen.
Lösung: Severity-Rechte, Stakeholder-Pack, Regulator-Notify-Pfad und Postmortem-Loop als Produkte mit Owner führen. Der fachliche Incident-Owner gibt kritische Messages frei; Comms und Legal beraten; Steward orchestriert; Custodian liefert Timeline und Modell-/Export-Fakten.
In einem Satz: Severity, Sprechrecht und Uhr binden, bevor der nächste Thread oder der nächste externe Satz den Incident entscheidet.
Produkte und Entscheidungen
Incident-Comms braucht nicht „eine Crisis-Mailbox“, sondern geschnittene Produkte.
Severity-Rechte
Dieses Produkt beschreibt:
- Schweregrad-Stufen; Kommunikationsschwellen; wer setzt die Stufe; Sprechrecht intern / extern / Regulator; Eskalation an Vorstand; Review nach Drill.
Entscheidungen:
- Welche Faktenlage erzwingt Stufewechsel — Exposure-Kreis, Modell in Produktion, Presse?; Wer darf Schweregrad senken?; Welche Stufe öffnet Datenschutzbeauftragte- und Counsel-Pflicht?
Stakeholder-Pack
Das Pack ist kein Newsletter. Es ist Audience plus Rhythmus plus Bekannt/Unbekannt.
Es benötigt:
- Audience-Liste (Engineering, betroffene Fachseite, Leadership, Betriebsrat wo nötig); Kadenz; Fakten vs. Hypothese; nächster Termin; Verbote (kein Spekulieren, kein Schuldzuweisen).
Entscheidungen:
- Wer erhält das erste interne Update — und wer ausdrücklich nicht?; Welcher Text darf intern stehen, der extern noch nicht gilt?; Wer stoppt parallele inoffizielle Threads?
Regulator-Notify-Pfad
Extern und Aufsicht laufen nur über die freigegebene Route.
Entscheidungen:
- Welche Uhr gilt (Meldefrist, Partner-Klausel, Kundeninformation)?; Wer unterschreibt die Notice?; Welcher Nachweis (Umfang, Zeitraum, Modellversion, Identifier) hängt an der Meldung — und was bleibt intern?
Postmortem-Loop
Lernen ohne Control-Änderung ist Theater.
Entscheidungen:
- Welche Finding wird Vereinbarung, welche wird Kontrollregel, welche wird Training?; Wer tracked den Close, und welches Datum gilt als erfüllt?; Wann darf derselbe Incident-Typ als „erledigt“ gelten?
Wo Governance hängt
Zwischen Slack-Thread und offizieller Severity
Der erste technische Satz setzt oft die öffentliche Geschichte. Ohne Triage-Recht vor dem Kanal entscheidet der lauteste Engineer die Lage.
Zwischen Faktenlage und Narrativ
Custodian liefert Timeline, Modellversion, Bucket-Zugriffsregel. Comms formt Sprache. Wenn Narrativ vor Fakten kommt, muss Legal später zurücknehmen.
Zwischen internem Pack und externem Text
Derselbe unklare Satz für beide Audiences erzeugt entweder Panik innen oder Vorwurf außen, die Organisation habe „nichts gewusst“.
Zwischen DPO-Uhr und „wir updaten später“
Meldefristen warten nicht auf ein vollständiges Board-Deck. Der Pfad muss mit Bekannt/Unbekannt arbeiten, nicht mit Vollständigkeitsillusion.
Zwischen „Modell-Quirk“ und Data-Exposure
Ein Rollback erklärt nicht, welche Personenkreise im Extract lagen. AI- und Data-Faktenfelder gehören beide ins Pack, sobald beide zutreffen.
Zwischen Postmortem-Deck und unverändertem Control
Ohne Loop bleibt derselbe Feature-Toggle, dieselbe Zugriffsregel und dasselbe Sprechchaos der nächste Incident.
Rollen-Mapping
Incident Owner (fachlich)
Head of Data, CISO oder benannter Business Owner des betroffenen Produkts ist accountable für Severity-Freigabe und kritische Messages. Der Owner spricht nicht automatisch extern.
Comms / Corporate Communications
Formuliert interne und externe Texte nach Freigabe. Comms setzt nicht Severity und ersetzt nicht die DPO-Frist.
DPO und Counsel
DPO bewertet Meldepflicht und Personenkreis. Counsel bewertet Partner-, Kunden- und Aufsichtsroute. Beide beraten; genau ein Incident Owner bleibt für die Message accountable, wo nicht das Recht die Unterschrift verlangt.
Data Steward
Incident- oder Governance-Ops orchestriert Pack-Rhythmus, hält das Comms-Log, zieht Fakten vom Custodian und öffnet den Postmortem-Loop.
AI Product Owner
Liefert Modellversion, Prompt-/Tool-Scope, betroffene Outputs. Er ist nicht automatisch Sprecher nach außen.
Data Custodian
SRE, Platform und IAM liefern Timeline, Containment-Status, Logs, Zugriffsregel- und Job-Nachweise. Faktenmacht ist kein Sprechrecht.
Data Consumer / Stakeholder
Betroffene Fachseite, Leadership, Partner-Koordination, Aufsichts-Koordination. Sie empfangen das Pack; sie erfinden keinen Parallelstatus.
Mini-Fall
Symptom: In der Produktion werden falsche Kreditbewertungen angezeigt. Zusätzlich liegt eine Exportdatei mit Kundenschlüsseln in einem öffentlich erreichbaren Cloud-Ordner. Im Chat nennt jemand das einen „kleinen Fehler“, Marketing bereitet schon einen Tweet vor, und der Datenschutzbeauftragte erfährt es zuerst aus der Fachpresse. Die Einstufung der Schwere passiert erst nach dem Presseanruf, und die Nachanalyse ändert keine einzige Kontrollregel.
Typischer Fehlstart: Crisis-Platform kaufen und Tickets sev1 taggen, ohne Sprechrecht, ohne Stakeholder-Rhythmus und ohne Notify-Nachweis.
Vereinbarung: Schweregrad mit Kommunikationsschwelle und Sprechrecht; internes Pack mit Bekannt/Unbekannt und nächstem Termin; Regulator-Pfad mit Uhr und Nachweis (betroffene Daten plus Modellversion); Nachanalyse mit kontrollOwner und Datum.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Custodian (SRE / Platform) | Steward | Timeline, Containment, Modellversion, Export-Scope |
| Steward | Incident Owner | Severity-Vorschlag plus Message-Entwurf |
| Incident Owner | Comms / Counsel | Freigabe intern vs. extern vs. still |
| DPO / Counsel | Incident Owner | Meldepflicht, Uhr, Empfänger — Beratung, außer Unterschriftspflicht |
| Steward | Stakeholder | Internes Pack (Audience, Kadenz, Bekannt/Unbekannt) |
| Steward | Control- / Contract-Owner | Postmortem-Finding mit Close-Datum |
Anti-Patterns
- Jeder postet seinen Status in Slack oder Social
- Schweregrad erst nach dem ersten Presse-Anruf
- Intern und extern derselbe unklare Text
- KI-Incident als „nur Modell-Quirk“ ohne Exposure-Fakten
- Notify-Uhr ignorieren, bis das Deck vollständig ist
- Nachanalyse ohne Vereinbarung- oder Kontrollregel-Änderung
- technischer Betreiber oder Engineer als heimlichen Sprecher nach außen
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
Schritt 1: Rahmen und Entscheidung klären
Einen jüngsten Data- oder AI-Incident (oder einen Near-Miss) wählen. Timeline, wer gesprochen hat, wer zu spät informiert wurde. Severity-Stufen mit Kommunikationsschwellen und Call Tree skizzieren. Incident Owner und Freigeber benennen.
Schritt 2: Control und Nachweis umsetzen
Stakeholder-Pack-Template mit Audience und Kadenz einführen. Regulator-Pfad mit Uhr und Evidence-Minimum schreiben. Ein Drill: Faktenlage → Severity → internes Pack in unter einer Stunde.
Schritt 3: Testen und Ausnahmen sichtbar machen
Externen Text und internen Text bewusst trennen. Einen AI-Fall mit Modellversion und einen Data-Fall mit Identifier-Kreis durchspielen. Postmortem eines Alt-Incidents in mindestens eine Control-Änderung überführen.
Schritt 4: Messen und begrenzt ausrollen
Aufwand, Gerüchtezeit und verspätete Notices messen. Nur bestandene Muster (Rechte, Pack, Pfad, Loop) auf einen zweiten Produktbereich übertragen.
Exit-Kriterien
- Schweregrad-Stufen haben Kommunikationsschwellen und benanntes Sprechrecht.
- Stakeholder-Pack nennt Audience, Kadenz und Bekannt/Unbekannt.
- Regulator-Pfad hat Uhr, Empfänger und Nachweis-Minimum.
- KI- und Data-Faktenfelder können gemeinsam im Pack stehen.
- Nachanalyse erzeugt mindestens eine Vereinbarung- oder Kontrollregel-Änderung mit Datum.
- technischer Betreiber liefert Timeline ohne mündliche Brücke; Comms spricht nur nach Freigabe.
Weiterlesen
Crisis and incident communication
Part 1 of 5
View series