KI-Agenten verursachen unsichtbare Infrastruktur-Ausfälle – warum Chaos-Engineering versagt

Der Vorfall begann mit einer einfachen Regel: Ein KI-Agent bemerkte eine erhöhte Latenz bei einem Microservice und startete das Cluster neu – eine logische Reaktion auf Basis der Trainingsdaten. Doch was folgte, war eine unvorhergesehene Kettenreaktion. Drei weitere Dienste verarbeiteten gerade Spitzenlast, der Verbindungspool war bereits zu 87 Prozent ausgelastet, und eine abhängige Datenbank führte im Hintergrund einen Index-Rebuild durch. Der Neustart löste eine Lawine aus, die das System in einen instabilen Zustand stürzte.

Solche Szenarien häufen sich in Unternehmen, die KI-Agenten in Produktionsumgebungen einsetzen. Laut einer aktuellen PwC-Studie nutzen bereits 79 Prozent der Organisationen KI-Agenten im Live-Betrieb, während Gartner prognostiziert, dass bis 2028 ein Drittel aller Unternehmenssoftware agentische KI enthalten wird. Doch gleichzeitig warnt die Analystenfirma, dass 40 Prozent dieser Projekte bis 2027 aufgrund mangelnder Risikokontrollen eingestellt werden könnten. Was beide Statistiken nicht erfassen: die unsichtbaren Ausfälle, die zwischen diesen beiden Polen entstehen – Agenten, die weiterhin laufen, aber Chaos erzeugen, das niemand als Risiko einstuft.

Warum bestehende Chaos-Engineering-Ansätze versagen

Viele Unternehmen setzen auf Chaos-Engineering, um die Robustheit ihrer Systeme zu testen. Dazu gehören Game Days, Blast-Radius-Kontrollen und SLO-basierte Experimente. Doch diese Methoden folgen einem entscheidenden Muster: Ein Mensch trifft die finale Entscheidung, ob ein System zum Zeitpunkt X eine Störung verkraften kann. Dieser Abwägungsprozess ist fehleranfällig, aber zumindest vorhanden. Bei autonomen KI-Agenten entfällt dieser Schritt. Sie handeln auf Basis von Anomalien – ohne Rücksicht auf aktuelle Lastspitzen, Fehlerbudgets oder Abhängigkeiten.

Die Folge ist eine neue Klasse von Vorfällen, die in keiner Post-Mortem-Vorlage erfasst wird. Ein Agent erkennt ein Problem, führt eine Aktion aus (z. B. Neustart, Traffic-Umleitung, Skalierung), und das System kollabiert – doch im Nachhinein streiten sich Teams darüber, ob es sich um einen Agentenfehler oder ein Infrastrukturproblem handelt. Der Grund: Die Frameworks, die menschliche Chaos-Experimente und autonome Agenten steuern, wurden nie miteinander verknüpft.

Die unsichtbare Rolle der „Absorb Capacity“

Hinter diesem Problem steckt ein fundamentales Missverständnis: Die meisten Unternehmen behandeln die Absorb Capacity – also die Fähigkeit eines Systems, zusätzliche Last zu verkraften – als statische Größe. Doch diese Kapazität ist ein dynamischer Ressourcenpool, der in Echtzeit berechnet werden muss. Aktuelle Chaos-Engineering-Ansätze setzen auf menschliche Intuition oder starre Schwellenwerte, die erst greifen, wenn der Schaden bereits entstanden ist.

Durch strukturierte Interviews mit SRE- und Plattform-Engineering-Teams bei Unternehmen wie Intuit und GPTZero habe ich ein Modell entwickelt, das die Absorb Capacity als konsumierbare Ressource behandelt: das Resilienz-Budget. Dieses Budget zieht vier Echtzeitsignale heran:

• SLO-Burn-Rate: Der primäre Indikator, da er direkt misst, wie schnell ein System sein monatliches Fehlerbudget aufbraucht. Selbst bei niedriger CPU-Auslastung kann eine hohe Burn-Rate signalisieren, dass keine zusätzliche Störung vertragen wird.

• Live-Systemmetriken: CPU-, Speicher- und Netzwerklast, die eine Momentaufnahme der aktuellen Systembelastung liefern.

• Abhängigkeitsstatus: Der Zustand kritischer Komponenten wie Datenbanken oder Verbindungspools, die durch Hintergrundprozesse bereits belastet sein können.

• Fehlerbudget-Prognosen: Vorhersagen, wie viel Puffer noch bleibt, bevor ein SLO gebrochen wird – basierend auf historischen Daten und aktuellen Trends.

Der Clou: Diese Signale müssen in Echtzeit aggregiert und in ein dynamisches Resilienz-Budget übersetzt werden. Ein Agent darf nur dann eingreifen, wenn das Budget noch positiv ist. Andernfalls muss das System warten – oder eine manuelle Freigabe einholen.

Praktische Umsetzung: Wie Unternehmen die Lücke schließen

Die Einführung eines Resilienz-Budgets erfordert keine radikale Umstellung, sondern eine Erweiterung bestehender Prozesse. Drei Schritte sind entscheidend:

1. Integration von Agenten in Chaos-Engineering-Pläne

Unternehmen müssen Agenten als Chaos-Injektoren betrachten. Das bedeutet:

• Agentenaktionen in Chaos-Experiment-Designs einbeziehen.
• Blast-Radius-Berechnungen um Agenten als potenzielle Störfaktoren erweitern.
• Automatisierte Post-Mortem-Analysen anpassen, um Agenten als Ursache zu erkennen.

1. Echtzeit-Resilienz-Dashboards

Ein zentrales Dashboard sollte das aktuelle Resilienz-Budget visualisieren – inklusive Warnungen, wenn ein Agent kurz davor steht, es zu überschreiten. Tools wie Prometheus oder Grafana können hier mit benutzerdefinierten Metriken kombiniert werden.

1. Schrittweise Automatisierung mit menschlichen Gateways

Nicht alle Agentenaktionen müssen sofort vollautonom sein. Ein hybrider Ansatz, bei dem Agenten Vorschläge machen, aber Menschen die finale Freigabe erteilen, kann die Risiken minimieren, bis die Systeme ausgereift genug sind.

Ein Ausblick auf die nächste Generation des Chaos-Engineerings

Die AI Incidents Database verzeichnete von 2024 auf 2025 einen Anstieg gemeldeter KI-bezogener Vorfälle um 21 Prozent. Doch diese Zahl ist nur die Spitze des Eisbergs. Die meisten Unternehmen klassifizieren Agentenaktionen noch nicht als eigenständige Risikoquelle – sie werden als Infrastrukturfehler, Service-Neustarts oder Latenzprobleme verbucht. Die Post-Mortems bleiben oberflächlich, weil die wahre Ursache unsichtbar bleibt.

Doch das muss sich ändern. Die nächsten großen Produktionsausfälle werden nicht durch menschliches Versagen, sondern durch Agenten verursacht werden – Agenten, die nach den Regeln handeln, die wir ihnen beigebracht haben, aber in Umgebungen, die sie nie vollständig verstanden haben. Die Antwort liegt nicht darin, Agenten zu verbieten, sondern sie in ein Framework einzubetten, das ihre Handlungen genauso rigoros testet wie die von Menschen. Erst dann können Unternehmen die nächste Welle der Automatisierung sicher nutzen – ohne dass Chaos Engineering im Dunkeln bleibt.