Die Szene ist immer dieselbe und wirkt nie dramatisch. Jemand aus dem Team geht — besseres Angebot, Umzug, Vertragsende —, es gibt Kuchen, es gibt gute Wünsche und es gibt eine Offboarding-Checkliste, die jemand gewissenhaft durchgeht: Laptop zurück, Postfach schließen, CRM-Zugang entziehen, Lohnabrechnung abschließen. Alles korrekt. Und irgendwo startet der Flow, den diese Person vor vierzehn Monaten gebaut hat, um die per Mail eingehenden Rechnungen zu sortieren, weiterhin um 7:05 Uhr, wie jeden Tag. Niemand schreibt ihn auf die Checkliste, weil der Prozess nicht kaputt ist. Er funktioniert. Genau das ist das Problem.
Die These in einer Zeile: das operative KI-Risiko in einem Unternehmen ohne Plattformteam kommt nicht über einen Angriff herein, es kommt über eine Kündigung. Kein Einbruch, keine Schwachstelle, nichts, was ein Virenscanner erkennt. Es gibt einen laufenden Prozess mit der Identität von jemandem, der nicht mehr da ist, und eine Logik, die in seinem Kopf wohnte. Der Ausfall kommt nicht am Tag der Abschiedsrunde: er kommt Wochen später, wenn ein Token abläuft, wenn ein Passwort rotiert wird oder wenn jemand — mit bestem Urteil der Welt — endlich dieses Konto schließt, das seit Monaten ungenutzt war.
Und wenn er kommt, kommt er ohne Spur. Es ist kein Codefehler, den ein Log erklärt: es ist ein Prozess, der aufgehört hat zu laufen, und den niemand vermisst, bis ein Kunde nach seiner Rechnung fragt.
Was passiert mit Automatisierungen, wenn ein Mitarbeiter geht: nichts, bis ein Zugang abläuft
Es lohnt sich, den Mechanismus zu verstehen, denn hier täuscht die Intuition. Wenn eine Person geht, hält ihre Automatisierung nicht an. Flows hängen nicht am Arbeitsvertrag: sie hängen an Zugangsdaten, und Zugangsdaten überleben die Person per Design. Ein API-Token ist bis zu seinem Ablaufdatum gültig. Eine OAuth-Freigabe, die einem Tool erteilt wurde, bleibt bestehen, solange das Konto existiert, das sie erteilt hat. Ein Schlüssel, der im Feld eines Konnektors klebt, weiß nicht, ob der, der ihn eingefügt hat, noch im Unternehmen ist.
Am Tag der Kündigung passiert also nichts Sichtbares, und das erzeugt das falsche Gefühl, es habe keine Abhängigkeit gegeben. Es gibt sie, und sie zeigt sich in einem dieser vier Momente, immer mit Wochen oder Monaten Verzug:
- Das Token läuft ab. Fast jedes Integrationstoken hat eine begrenzte Lebensdauer. An dem Tag, an dem es verfällt, gibt der Flow einen Authentifizierungsfehler zurück, den niemand liest, weil die Benachrichtigungen an das Postfach der Person gingen, die gegangen ist.
- Das Konto wird wirklich gelöscht. Anfangs wird der Nutzer meist nur gesperrt, um nichts zu zerstören. Monate später, bei einer Lizenzbereinigung — ein Kostengespräch, kein Risikogespräch —, wird er entfernt. Und mit ihm verschwinden alle Freigaben, die er erteilt hat.
- Auf der anderen Seite ändert sich etwas. Der Anbieter aktualisiert seine API, die Bank ändert das Format des Kontoauszugs, das CRM benennt ein Feld um. Der Flow braucht eine Anpassung von zehn Minuten, die nur jemand machen kann, der versteht, warum er so gebaut wurde.
- Es taucht ein neuer Sonderfall auf. Der seltene Fall, den die Logik nicht abdeckte. Die Person, die gegangen ist, wusste, was damit zu tun war, weil sie es selbst entschieden hatte; wer bleibt, weiß nicht einmal, dass diese Entscheidung existierte.
Das ist kein Shadow AI, und Agenten zu zählen behebt es nicht
Das wird mit zwei Nachbarproblemen verwechselt, und die Verwechslung kommt teuer, weil sich die drei Dinge mit unterschiedlichen Hebeln lösen.
Shadow AI ist nicht freigegebene Nutzung: Leute, die Tools verwenden, die das Unternehmen nie genehmigt hat. Das ist ein Problem nicht bedienter Nachfrage und löst sich, indem man einen genehmigten Weg anbietet. Das Inventar ist ein Zählproblem: nicht zu wissen, wie viele Automatisierungen du hast und was sie anfassen. Das löst sich durch Hinsehen.
Die Sache mit der Kündigung ist etwas anderes: sie ist Lebenszyklus. Eine Automatisierung kann perfekt freigegeben, perfekt inventarisiert und perfekt in einer Tabelle beschrieben sein — und trotzdem fragil bleiben, denn was ihr fehlt, ist weder Erlaubnis noch Eintrag: ihr fehlt ein lebender Eigentümer und eine eigene Identität. Ein Inventar sagt dir, dass der Flow existiert. Es sagt dir nicht, dass er mit den Zugangsdaten von Sabine läuft und dass Sabine im März gegangen ist.
Der praktische Unterschied: Shadow AI und Inventar löst man mit einer Momentaufnahme. Den Lebenszyklus löst man nur mit einem Prozess, denn Leute werden weiterhin in dein Unternehmen ein- und austreten, solange es das Unternehmen gibt.
Die Zahl: der Markt kann einem Agenten die Zugangsdaten noch nicht entziehen
Es gibt eine Zahl, die man genau ansehen sollte — nicht weil sie von deutschen Mittelständlern spricht, das tut sie nicht, sondern wegen dem, wen sie misst. In seinem Report 2026 Identity Security Landscape, auf Basis einer Befragung von 2.930 Sicherheitsverantwortlichen weltweit, veröffentlicht Palo Alto Networks zwei Zahlen, die zusammengelesen dieses Loch besser beschreiben als jede Anekdote: 99 % der Organisationen haben KI-Agenten schon eingeführt, und nur 37 % können die Zugangsdaten eines Agenten widerrufen. Nur 30 % haben ein unveränderliches Audit-Log darüber, was diese Agenten tun. Quelle: How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, Mai 2026.
Der Geltungsbereich zählt, und das muss klar gesagt werden: es ist eine weltweite Befragung von Großunternehmen, mit Sicherheitsteam, Budget und einem CISO, der den Fragebogen beantwortet. Es ist keine Stichprobe deutscher, österreichischer oder schweizerischer KMU. Aber genau deshalb ist sie als Untergrenze brauchbar: wenn zwei von drei Organisationen mit Sicherheitsteam einem Agenten den Zugang nicht abschneiden können, dann beantwortet sich die Frage, was in einem Unternehmen mit vierzig Leuten passiert, wo der Flow an einem Donnerstagnachmittag vom Betriebsleiter gebaut wurde, von selbst.
Derselbe Report zeigt, wo die Lücke genau sitzt: die meisten Organisationen können erklären, wozu jeder Agent da ist, und viel weniger können definieren, worauf er zugreift, wie dieser Zugriff begrenzt wird, wann seine Berechtigungen widerrufen werden und welche anderen Systeme diesen Zugriff erben. Es ist kein Problem fehlender Zweckkenntnis. Es ist ein Problem des Lebensendes.
| Was die Offboarding-Checkliste abdeckt | Was sie nicht abdeckt | Was kaputtgeht |
|---|---|---|
| Postfach, Laptop, CRM-Zugang, Lohnabrechnung | Die Zugangsdaten, mit denen ihre Automatisierungen laufen | Der Flow läuft weiter mit der Identität von jemandem, der nicht mehr da ist |
| Übergabe von Kunden und offenen Aufgaben | Das Urteil, mit dem sie die seltenen Fälle entschied | Den ersten neuen Sonderfall kann niemand lösen |
| Die Person aus den Mailverteilern nehmen | Die Fehlerwarnungen ihrer Flows umleiten | Der Ausfall passiert und die Warnung geht in ein geschlossenes Postfach |
| Die Kündigung im Dokumentenmanagement abzeichnen | Festhalten, wer diesen Prozess erbt | Der Prozess verliert seinen Eigentümer, ohne dass es jemand entscheidet |
Die drei Fragen, die in deiner Offboarding-Checkliste fehlen
Dafür braucht es kein Projekt. Es braucht drei Fragen im Abschlussgespräch, gestellt vor dem letzten Tag, wenn die Person noch da ist und noch Lust hat zu helfen:
- Mit welcher Identität läuft jede Sache, die du gebaut hast? Nicht « was hast du gebaut »: mit welchem Konto. Die nützliche Antwort ist eine Liste von Flows und daneben jeweils das Konto oder der Schlüssel, den der Flow benutzt. Wenn irgendeine Zeile « mein Konto » sagt, hast du die Arbeit für Montag schon identifiziert. Diese Frage entscheidet, ob eine Kündigung eine Formalität ist oder ein aufgeschobener Vorfall.
- Was hast du entschieden, das nirgendwo steht? Jede nützliche Automatisierung hat eine Urteilsschicht, die nicht in der Konfiguration steht: was als Doppelrechnung gilt, wann eine Mail eine menschliche Antwort verdient, welcher Lieferant die ewige Ausnahme ist. Eine halbe Stunde Aufnahme, in der diese Person die seltenen Fälle erzählt, ist mehr wert als jedes Handbuch, das sie im Laufschritt schreibt.
- Wen muss das hier benachrichtigen, wenn es ausfällt? Nicht « wen hast du benachrichtigt ». Wen es ab jetzt benachrichtigen muss. Ein Flow, dessen Warnungen in ein Postfach gehen, das geschlossen wird, ist ein Flow, der schon still ausfällt — du weißt es nur noch nicht.
Die drei passen in ein Meeting von vierzig Minuten und lösen den größten Teil des Risikos. Die vollständige Version der ersten — welche Identität, mit welchem Umfang und was sie anfassen darf — steht ausgearbeitet im Leitfaden zu den Berechtigungen eines KI-Agenten, denn dort entscheidet sich, ob dieses Abschlussgespräch unangenehm oder trivial ist.
Was zu tun ist, wenn die Person schon weg ist
Der häufigste Fall ist nicht der vorbeugende: es ist der reaktive, mit der Person seit drei Monaten draußen und niemandem, der sicher weiß, was noch läuft. Arbeitsreihenfolge, von billig nach teuer:
- Lösche das Konto noch nicht. Es ist verlockend, es aus Hygiene zu schließen, und es ist der schnellste Weg, ein latentes Risiko in einen Betriebsausfall zu verwandeln. Sperre den interaktiven Zugang — niemand soll sich damit anmelden können — und lass die Integrations-Zugangsdaten leben, bis Schritt 3 fertig ist.
- Sieh nach, was mit dieser Identität noch passiert. Die Zugriffsprotokolle deiner Hauptwerkzeuge (Mail, CRM, ERP, die Automatisierungsplattform) sagen dir, welche Aktivität noch auf dieses Konto läuft. Das ist dein echtes Inventar, viel besser als das, was du aus dem Gedächtnis zusammenstellen würdest.
- Stelle jeden Zugang auf das Unternehmen um. Erstelle ein Dienstkonto mit pro Flow eng gesetzten Berechtigungen und authentifiziere die Verbindungen neu. Das ist langweilige Arbeit, die einen Nachmittag dauert, und die einzige, die das Problem beseitigt statt es zu verschieben.
- Leite die Warnungen auf ein Team-Postfach um. Nicht an eine andere Person: an eine Adresse, die die nächste Kündigung überlebt. Das ist, was den nächsten Ausfall zu etwas macht, das jemand liest.
- Schreib die Logik auf, während du sie zurückgewinnst. Was dir die Protokolle und die Verbliebenen erzählen, schreib es im Moment auf. Dieses Dokument wird nicht später geschrieben; später wird es nie geschrieben.
Wenn du in Schritt 2 entdeckst, dass ein Flow seit Wochen ausfällt, ohne dass es jemand wusste, ist das Problem nicht mehr die Kündigung: es ist, dass niemand hingesehen hat. Das ist ein anderes Gespräch, und es steht im Leitfaden dazu, wer antwortet, wenn eine Automatisierung ausfällt.
Der Designfehler liegt davor, am Tag des Baus
Alles Vorige ist Schadensbegrenzung. Die Ursache liegt in einem viel früheren und viel billiger zu behebenden Moment: an dem Tag, an dem jemand den Flow mit seinem eigenen Konto gebaut hat, weil es das war, was er zur Hand hatte, und weil es funktionierte. Niemand hat etwas falsch gemacht. Es hat nur niemand das Gegenteil entschieden, weil diese Entscheidung auf keiner Liste stand.
Damit das nicht wieder passiert, braucht es drei Regeln, die kein Geld kosten, nur Einigkeit: keine Automatisierung läuft mit dem Konto einer Person — Dienstkonten mit eng gesetzten Berechtigungen, immer —; neben jedem lebenden Flow steht ein Name, der für ihn verantwortet, und dieser Name wird überprüft, wenn jemand die Rolle wechselt; und Warnungen gehen an ein Team-Postfach, nie an eine Einzelperson. Die drei zusammen machen aus einer Kündigung einen Verwaltungsakt, und das ist, was sie sein sollte. Der vollständige Rahmen dieser Entscheidung steht im Leitfaden zu Governance und Kontrolle der KI-Automatisierung.
Und es gibt einen Fall, an den keine interne Regel reicht: wenn die Person, die das System gebaut hat, nie zum Haus gehörte. Wenn deine Automatisierungen ein Berater oder eine Agentur hochgezogen hat, wiederholt sich am Tag des Vertragsendes genau dieselbe Szene, nur ohne Abschlussgespräch und ohne Abschiedskaffee. Deshalb ist die Pflege des Laufenden ein Service und kein Gefallen: jemand muss die KI-Agenten pflegen, wenn der, der sie gebaut hat, nicht mehr da ist, und diese Frage beantwortet man vor der Unterschrift, nicht danach.
Eine Automatisierung, die nur eine Person versteht, ist kein Asset. Sie ist eine Schuld mit unbekanntem Fälligkeitsdatum, und das Datum setzt der Arbeitsmarkt, nicht du.