Am Freitagabend war die Welt noch in Ordnung. Das Active Directory der Firma lief, wie es seit Jahren lief – nicht elegant, nicht dokumentiert, aber es lief. Knapp 2.000 Konten im Verzeichnis, davon rund 750 echte Benutzer. Drei Standorte. SAP als ERP-System, dazu ein Lagerverwaltungssystem eines kleineren Anbieters, das irgendwann in der Merkel-Ära eingeführt worden war und seitdem lief, weil es niemand anzufassen wagte. Der Rest waren Service Accounts, Admin-Konten, Shared Mailboxes und Überbleibsel, die niemand zählen konnte, weil niemand je versucht hatte, sie zu zählen. Delegationen, die irgendwann zwischen 2016 und 2019 eingerichtet wurden, von Menschen, die längst woanders arbeiteten.
Es war, mit anderen Worten, ein ganz normales Active Directory.
147
Am Freitag um 17:40 Uhr setzte jemand aus dem Security-Team eine Änderung produktiv. Der Kollege hatte den Bericht des letzten Pentests auf dem Tisch. Offene Findings, rote Ampeln, Empfehlungen, die seit Wochen niemand angefasst hatte. Er hatte sich ein agentenbasiertes KI-Setup gebaut, mit Konnektoren direkt in die produktive AD-Umgebung – Lese- und Schreibzugriff auf GPOs, OUs, Delegationen. Alles steuerbar über natürliche Sprache im Chat. Es war Freitagnachmittag, die Tickets waren abgearbeitet, die Findings lagen da. Also tippte er: „Härte diese AD-Umgebung.“
Das Tool tat, was KI-Tools tun: Es lieferte.
Keine einzelne GPO. Keine gezielte Anpassung. 147 Gruppenrichtlinien. Gleichzeitig. NTLM deaktiviert. Smartcard-only-Logon erzwungen. Kerberos-Delegationen über 38 OUs hinweg umgeschrieben. Administrative Konten separiert. Kryptografische Parameter verschärft. Das Ganze sah beeindruckend aus. Saubere Benennung. Korrekte Syntax. Jede einzelne Maßnahme entsprach einer anerkannten Best Practice. In einem CIS-Audit hätte das Tool vermutlich 98 Prozent erreicht.
Es gab kein Change-Ticket. Es gab keine Testumgebung. Es gab keinen Rollback-Plan. Aber es gab ein gutes Gefühl.
Freitagabend fuhr der Kollege nach Hause. Die Replikation lief. Die Änderungen waren nicht lokal – sie verteilten sich domänenweit über alle Standorte, alle Domänencontroller. Mit jeder erfolgreichen Replikationsrunde wurde der neue Zustand zum Standard. Und niemand merkte etwas, weil freitagabends niemand mehr arbeitete.
Wellen
Montag, 8:17 Uhr. Die ersten Tickets kamen rein. Nicht einzeln – in Wellen.
8:17 Uhr: „Kann mich nicht anmelden.“ 8:19 Uhr: „RDP geht nicht.“ 8:23 Uhr: „SAP zeigt Authentifizierungsfehler.“ 8:24 Uhr: „SAP zeigt Authentifizierungsfehler.“ 8:24 Uhr: „SAP zeigt Authentifizierungsfehler.“ 8:31 Uhr: „Drucker druckt nicht.“ 8:34 Uhr: „Kann mich nicht anmelden.“ 8:35 Uhr: „Kann mich nicht anmelden.“ 8:41 Uhr: „Niemand in der Abteilung kann sich anmelden.“
Um 8:47 Uhr rief der Geschäftsführer die IT-Leitung an. Nicht wegen SAP. Nicht wegen RDP. Wegen des Druckers. Er konnte eine Vorstandsvorlage nicht ausdrucken. In der Hierarchie der IT-Probleme steht der Drucker des Geschäftsführers ungefähr dort, wo in der Maslowschen Bedürfnispyramide das Atmen steht.
Um 9:15 Uhr war klar, dass es kein Netzwerkproblem war. Es war ein Identitätsproblem. Irgendetwas hatte sich verändert. Aber was?
Alles
Die Antwort war: alles. 147 GPOs hatten über das Wochenende repliziert und griffen jetzt flächendeckend. NTLM war deaktiviert – und damit der Fallback für jede Anwendung, die nie auf Kerberos migriert worden war. SAP authentifizierte sich seit 2018 über eine NTLM-Kette, die niemand dokumentiert hatte, weil sie einfach funktionierte. Jetzt funktionierte sie nicht mehr.
Smartcard-only-Logon war erzwungen – in einer Organisation, die keine Smartcards besaß. Kein Lesegerät. Keine PKI-Infrastruktur. 750 Mitarbeitende standen vor Bildschirmen, die eine Karte verlangten, die es nicht gab.
Die Kerberos-Delegationen waren umgeschrieben worden. Service Account #47 in OU 23, der seit acht Jahren die Authentifizierungskette für SAP aufbaute, hatte jetzt andere Berechtigungen. Welche genau, konnte das KI-Tool nicht erklären. Es hatte optimiert. Es hatte nicht dokumentiert.
Und das Tiering? Die administrativen Konten waren separiert worden. Der Admin, der das Problem hätte beheben können, konnte sich nicht mehr auf dem Domain Controller anmelden, weil sein Konto jetzt in einem anderen Tier lag. Er brauchte ein separates Admin-Konto. Das existierte nicht. Es hatte nie existiert. Die KI hatte die Policy geschrieben. Sie hatte nicht die Konten angelegt.
Am Standort in Sachsen stand die Kommissionierung still, weil das Lagerverwaltungssystem sich nicht mehr gegen das AD authentifizieren konnte. In der Produktion warteten zwei Linien auf Freigaben aus SAP, die nicht kamen, weil SAP nicht lief. Im Versand gingen keine Pakete mehr raus – nicht weil die Ware fehlte, sondern weil das Logistikmodul den Benutzer nicht mehr erkannte, der die Versandlabels freigeben sollte.
Um 10 Uhr morgens war das kein IT-Problem mehr. Es war ein Betriebsausfall.
Wir arbeiten daran
Der Helpdesk war um 9:30 Uhr überlastet. Nicht mit technischen Fragen, sondern mit einer einzigen Frage in vielen Variationen: Warum geht nichts mehr?
Die ehrliche Antwort wäre gewesen: Weil am Freitag um 17:40 Uhr jemand 147 Best Practices gleichzeitig auf eine Umgebung angewendet hat, die auf keine davon vorbereitet war. Weil zwischen einer Empfehlung und ihrer Umsetzung ein Unterschied liegt, der sich nicht in Prompts ausdrücken lässt. Weil Sicherheit kein Zustand ist, den man in sechs Minuten erreicht, sondern ein Prozess, der Monate dauert – wenn man ihn richtig macht.
Die tatsächliche Antwort lautete: „Wir arbeiten daran.“
Kein Rollback
Um 11:00 Uhr begann das Rollback. Nur: Es gab kein Rollback. 147 GPOs gleichzeitig zurücknehmen ist nicht trivial. Man muss wissen, welche GPOs vorher existierten, welche ersetzt wurden, welche neu sind. Das KI-Tool hatte keine Vorher-Nachher-Dokumentation erstellt. Es gab keine Baseline. Es gab keine Staging-Umgebung, auf der man den Rückbau hätte testen können.
Jemand schlug vor, den System-State vom Donnerstag zurückzuspielen. Das klang einfach. Active Directory ist allerdings kein Dateisystem, sondern ein replizierendes Verzeichnis mit eigener Versions- und Replikationslogik. Ein unkontrollierter Restore auf einem einzelnen Domain Controller kann USN-Rollback-Effekte verursachen und damit Inkonsistenzen in der Replikation auslösen, die sich nicht durch einfaches Zurückdrehen beheben lassen. Die Recovery-Dokumentation war – theoretisch – vorhanden. Praktisch hatte sie niemand je getestet. Die letzte dokumentierte Forest-Recovery-Übung lag vier Jahre zurück und war damals abgebrochen worden.
Um 14:00 Uhr hatte das Team die Smartcard-Policy manuell deaktiviert. Die Benutzer konnten sich wieder anmelden. Um 16:30 Uhr war der NTLM-Fallback für die kritischsten Anwendungen wieder aktiv. SAP lief um 19:00 Uhr. Die Delegation für Service Account #47 wurde manuell wiederhergestellt – nachdem jemand im Mailarchiv eine Nachricht aus 2018 gefunden hatte, in der der ursprüngliche Einrichter die Konfiguration beschrieben hatte.
Der Drucker des Geschäftsführers funktionierte um 15:12 Uhr. Das wurde als Erstes gemeldet.
Die falsche Antwort
Am Dienstag gab es eine Nachbesprechung. Keine Schuldzuweisung, zumindest nicht offiziell. Die Frage, die im Raum stand, war die richtige: Wie konnte das passieren?
Die Antwort, die gegeben wurde, war die falsche: Das Tool hätte besser konfiguriert werden müssen.
Denn das Problem war nicht das Tool. Das Tool hatte exakt das getan, was man ihm gesagt hatte. Es hatte die Umgebung gehärtet. Jede einzelne GPO war fachlich korrekt. Jede entsprach einer Empfehlung, die man in BSI-Grundschutz-Katalogen, in CIS-Benchmarks, in Microsoft-Dokumentationen nachlesen kann.
Das Problem war, dass niemand gefragt hatte, ob die Organisation bereit war für das, was die KI als Idealzustand betrachtet. Ob die Anwendungen migriert waren. Ob die Infrastruktur existierte. Ob die Menschen vorbereitet waren. Ob ein Rückweg existierte.
Das Problem war, mit anderen Worten, das Fehlen von allem, was Sicherheit von Konfiguration unterscheidet: Governance. Change-Kontrolle. Telemetrie. Stufenweise Einführung. Getestete Recovery. Kommunikation mit Fachabteilungen. Das langsame, unsexy, gründliche Handwerk, das dafür sorgt, dass eine gute Idee nicht zur Betriebsstörung wird.
8:17
Eine KI ohne Governance ist wie dem Azubi am ersten Tag den Domain-Admin zu geben, ihm eine Google-Suche und eine nicht existierende Dokumentation als Einarbeitung mitzugeben – und dann in den Urlaub zu fahren. Technisch befähigt. Organisatorisch unkontrolliert. Und mit domänenweiter Wirkung.
Die Frage ist nicht, ob das Tool recht hatte. Die Frage ist, warum man ihm produktive Domänenrechte gegeben hat – ohne Aufsicht, ohne Change-Prozess und ohne getestete Recovery.
KI kann Analyse beschleunigen, Muster erkennen, Baselines vorschlagen. Als Copilot ist sie enorm wertvoll. Als Autopilot ist sie ein Betriebsrisiko.
Sicherheit scheitert selten an Best Practices. Sie scheitert an ihrer gleichzeitigen Aktivierung.
Der Unterschied zeigt sich nicht im Prompt. Er zeigt sich am Montag um 8:17 Uhr.
Irgendwo im Controlling sitzt jetzt jemand vor einer Excel-Tabelle und rechnet zusammen, was sechs Minuten Hardening die Firma gekostet haben. Produktionsausfall, entgangene Aufträge, Überstunden, externe Berater, Vertragsstrafen aus der Logistik. Die Tabelle wird lang. Die Cyberversicherung wird sich sehr wahrscheinlich auf den Standpunkt stellen, dass hier kein versicherter Angriff vorlag. Es war kein externer Akteur. Es war Change.
Dafür werden die Zahlen unsterblich. Sie werden in jeder Onboarding-Präsentation der IT-Abteilung auftauchen – als die Anekdote, die neuen Mitarbeitenden erklärt, warum man so etwas nicht tut. Der CISO erzählt sie auf Konferenzen. Der IT-Leiter auf internen Schulungen. Sie ist zur Firmenlegende geworden, die jeder kennt und niemand wiederholen möchte.
Die Geschäftsleitung hat verfügt, dass KI-generierte Konfigurationen nicht mehr produktiv eingesetzt werden dürfen, dass sicherheitsrelevante Änderungen an der Infrastruktur ab sofort dem Vieraugenprinzip unterliegen und dass Change-Prozesse nicht mehr optional sind. Wer dagegen verstößt, dem droht die außerordentliche Kündigung.
Immerhin: Unberechtigte Zugriffe gab es keine. Es gab überhaupt keine Zugriffe mehr. Technisch gesehen war das Zero Trust.
Nachwort
Das Szenario in diesem Artikel ist erfunden – die Firma, der Kollege, der Drucker des Geschäftsführers. Aber die Mechanismen, die beschrieben werden, sind es nicht. Sie passieren. Und sie passieren häufiger, als die meisten Unternehmen zugeben würden.
Im Dezember 2025 verursachte Amazons agentenbasiertes KI-Tool Kiro einen 13-stündigen Ausfall bei AWS. Das Tool hatte autonom eine Kundensystem-Umgebung gelöscht und neu erstellt – ein Vorgang, der in Teilen Chinas Services beeinträchtigte. Bereits im Oktober 2025 hatte ein ähnlicher Incident bei AWS zu stundenlangen Downtimes für Dutzende Websites geführt. Amazon verwies auf „User Error“ – fehlende Zugriffssteuerungen seien die Ursache gewesen, nicht die KI selbst. Interne Quellen warnten jedoch vor der zunehmenden Autonomie in kritischen Systemen.
Bei Replit löschte ein KI-Coding-Assistent 2025 die gesamte Produktionsdatenbank eines Unternehmens, fabrizierte anschließend falsche Reports und log über seine eigenen Handlungen. Unkontrollierte KI-Änderungen in einer Live-Umgebung – mit direktem Datenverlust als Ergebnis.
In der Gastronomie scheiterten KI-gesteuerte Sprachsysteme: McDonald’s brach 2024 sein KI-Bestellprojekt ab, nachdem die Technologie Bestellungen systematisch falsch interpretiert hatte. Taco Bell erlebte Ähnliches mit Dialektproblemen und ungenauen Bestellungen. Bei McHire.com, einer KI-gestützten Recruiting-Plattform von Paradox.ai, exponierte ein Sicherheitsvorfall 2025 die Daten von 64.000 Bewerbern – Ursache waren schwache Passwörter in einem System, dem man die Verwaltung sensibler Personaldaten anvertraut hatte.
Eine Studie des MIT kam 2025 zu dem Ergebnis, dass 95 Prozent aller KI-Pilotprojekte scheitern – nicht an der Technologie, sondern an fehlender Einbettung in bestehende Prozesse und Strukturen.
Das Muster ist in jedem dieser Fälle dasselbe: Ein leistungsfähiges Tool erhält Zugriff auf eine produktive Umgebung, ohne dass Governance, Kontrolle und Recovery-Prozesse mit der Geschwindigkeit der Technologie mitgewachsen wären. Die Ergebnisse sind unterschiedlich – gelöschte Datenbanken, stundenlanges Blackout, exponierte Personaldaten, falsche Bestellungen. Die Ursache ist immer dieselbe.
Es war nie die KI. Es war immer der fehlende Rahmen. Lassen Sie es nicht soweit kommen.
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar