Für Investoren, CIOs und Aufsichtsräte liegt das Risiko bei KI-Agenten nicht nur in falschen Antworten. Das wäre noch vergleichsweise einfach zu messen. Die schwierigere Frage lautet: Was passiert, wenn ein autonomer Agent eine technisch plausible Aktion ausführt, deren Kontext unvollständig ist, und dadurch eine Infrastrukturreaktion auslöst, die in keinem bestehenden Risikobericht sauber auftaucht?
Genau dort entsteht eine neue operative Grauzone. Der Agent stürzt nicht ab. Er löst keinen klassischen Fehler aus. Er überschreitet vielleicht keine offensichtliche Berechtigung. Er tut etwas, das innerhalb seines wahrgenommenen Zustands logisch ist. Nur ist dieser Zustand nicht identisch mit der realen Produktionslage. Danach beginnt die Kaskade: ein Dienst reagiert langsamer, ein Workflow wiederholt sich, ein Abhängigkeitsdienst wird stärker belastet, ein Team sieht ein Infrastrukturproblem, ein anderes sieht eine Automatisierungsentscheidung. In der Nachbesprechung fehlt dann die Kategorie.
Das ist keine akademische Spitzfindigkeit. Wenn KI-Agenten zunehmend in Geschäftsprozesse, IT-Betrieb, Support, Datenpipelines und interne Plattformen eingebaut werden, verändern sie nicht nur Produktivitätserwartungen. Sie verändern das Profil operativer Risiken. Und genau diese Risiken sind in vielen Unternehmen schlechter bilanziert als die Lizenzkosten der verwendeten Systeme.
Der Markt bewertet Automatisierung, nicht ihre Nebenwirkungen
Die kommerzielle Logik ist klar. Unternehmen wollen mit Agenten Prozesse verkürzen, manuelle Übergaben reduzieren und Betriebskosten senken. In vielen Häusern laufen bereits produktive Formen solcher Systeme, während weitere Ausbaustufen geplant werden. Gartner erwartet, dass bis 2028 ein erheblicher Teil von Unternehmenssoftware agentische KI enthalten wird. Gleichzeitig warnt Gartner davor, dass ein großer Anteil entsprechender Projekte wegen schwacher Risikokontrollen scheitern dürfte.
Zwischen diesen beiden Aussagen liegt der ökonomisch interessante Bereich. Nicht die Projekte, die offen beendet werden. Nicht die Pilotphasen, die nie in Produktion gehen. Sondern die Systeme, die laufen, Budgets rechtfertigen und intern als Fortschritt gelten, während sie eine neue Klasse von Störungen erzeugen. Diese Störungen sind oft zu klein für den Vorstand, aber zu teuer für den Betrieb. Sie fressen Zeit in Incident Reviews, erhöhen Komplexität in Plattformteams und verschieben Verantwortung zwischen Applikation, Daten, Infrastruktur und Governance.
Kapitalmärkte mögen Skalierung. Aber sie unterschätzen regelmäßig die Kosten der Kontrollschicht, die nach der Skalierung gebaut werden muss. Bei KI-Agenten droht derselbe Verlauf: Erst wird Autonomie verteilt, dann wird ihre Überwachung nachgerüstet.
Chaos Engineering hatte bisher einen menschlichen Filter
Reife Engineering-Organisationen kennen Chaos Engineering. Sie testen Ausfallszenarien, begrenzen den Wirkungsradius, definieren SLOs, arbeiten mit Error Budgets und stoppen Experimente, wenn Systeme ohnehin unter Druck stehen. Der technische Kern ist nicht nur das gezielte Stören. Entscheidend ist die Entscheidung davor: Ist der Zeitpunkt vertretbar?
Diese Entscheidung war bisher menschlich. Ein Engineer schaut auf Dashboards, prüft Abhängigkeiten, liest die Lage, erkennt vielleicht, dass ein Deployment gerade instabil ist oder ein externer Dienst ungewöhnlich reagiert. Das ist nicht perfekt. Aber es enthält Kontext, der nicht vollständig in Metriken steckt.
Ein KI-Agent kann diesen Filter umgehen, wenn er Aufgaben autonom ausführt. Er muss kein Chaos-Experiment starten, um Chaos zu erzeugen. Es reicht, wenn er eine Aktion zur falschen Zeit, mit veraltetem Kontext oder auf Basis eines zu engen Zielkriteriums ausführt. Ein Retry ist dann nicht nur ein Retry. Eine Konfigurationsänderung ist nicht nur eine Konfigurationsänderung. Eine automatisch angestoßene Analyse, ein Ticket-Update, ein Rollback-Vorschlag oder eine Datenkorrektur kann in einer komplexen Umgebung Nebeneffekte haben, die das System zwar technisch erlaubt, aber operativ nicht verkraftet.
Der Ausfall sieht aus wie Erfolg
Das gefährliche Muster ist nicht der laute Crash. Viele Organisationen sind auf laute Ausfälle vorbereitet. Sie haben Alarme, Runbooks, Eskalationen, Incident Commander. Schwieriger sind Ereignisse, die zunächst wie korrektes Verhalten aussehen. Der Agent hat eine Aufgabe erledigt. Ein Workflow wurde abgeschlossen. Eine Automatisierung hat eine Entscheidung getroffen. Die Oberfläche meldet Erfolg.
Die Kosten tauchen später auf. Ein Datenbestand verliert Qualität. Ein Caching-Verhalten verändert sich schleichend. Ein Supportprozess verschiebt falsche Fälle in die nächste Stufe. Eine interne Plattform behandelt agentische Aktionen wie normale Nutzeraktionen, obwohl deren Geschwindigkeit und Wiederholbarkeit eine andere Risikoklasse bilden. Solche Effekte passen schlecht in klassische Postmortems. War es ein Agentenfehler? War es ein Infrastrukturfehler? War es ein Datenproblem? War es eine fehlende Leitplanke?
Für das Management ist diese Unschärfe teuer. Was nicht sauber kategorisiert wird, lässt sich schlecht bepreisen. Was nicht bepreist wird, landet als allgemeine Reibung in den Betriebskosten. Dort verschwindet es in Headcount, Tooling, Verzögerungen und Vertrauensverlust gegenüber Automatisierung.
Observability reicht nicht, wenn der Akteur fehlt
Viele Unternehmen haben in Observability investiert. Logs, Traces, Metriken, APM, SRE-Prozesse. Das Problem ist nicht, dass keine Daten vorhanden wären. Das Problem ist, dass die Daten häufig nicht beantworten, warum ein autonomes System genau diese Handlung in genau diesem Kontext ausgeführt hat.
Bei klassischen Systemen ist die Kausalkette oft stabiler. Ein Service ruft einen anderen auf. Ein Deployment ändert Code. Ein Mensch gibt eine Freigabe. Bei Agenten kommt eine zusätzliche Schicht hinzu: Ziel, Kontextfenster, Tool-Zugriff, interne Bewertung, externe Systemantworten und mögliche Drift über Zeit. Wenn diese Ebene nicht protokolliert und mit Infrastrukturereignissen verknüpft wird, sehen Teams nur die Spuren, nicht den Entscheider.
Das ist für Anbieter von Observability- und Sicherheitssoftware eine Chance, aber auch ein Produktproblem. Ein weiteres Dashboard wird nicht reichen. Gefragt ist eine Verbindung aus Agenten-Telemetrie, Policy-Kontrollen, Berechtigungsgrenzen, Simulationsumgebungen und SRE-Logik. Wer Agenten in produktive Abläufe lässt, braucht nicht nur Monitoring für Systeme. Er braucht Monitoring für Entscheidungen.
Risikokontrolle wird zum Investitionsthema
Die nächste Phase der Enterprise-KI wird weniger von Demo-Videos entschieden als von Kontrollarchitekturen. Unternehmen müssen klären, welche Aktionen Agenten eigenständig ausführen dürfen, unter welchen Systemzuständen sie gestoppt werden, wie ihr Wirkungsradius begrenzt wird und wie Vorfälle klassifiziert werden. Das klingt trocken. Es ist aber der Unterschied zwischen verwertbarer Automatisierung und dauerhafter operativer Unruhe.
Aus Kapitalmarktsicht verschiebt sich damit die Bewertungsfrage. Nicht jedes Unternehmen, das viele Agenten einsetzt, wird effizienter. Entscheidend ist, ob die Organisation die Folgekosten der Autonomie beherrscht. Wer Agenten ohne belastbare Kontrollen in produktive Umgebungen bringt, kann kurzfristig Prozesskosten senken und mittelfristig Incident-Kosten erhöhen. Der Nettoeffekt ist dann weniger klar, als viele Business Cases behaupten.
Die robusteren Unternehmen werden Agenten wie eine neue Produktionsklasse behandeln, nicht wie bessere Skripte. Sie werden eigene Fehlerbudgets definieren, agentische Aktionen nachvollziehbar machen, Chaos-Tests auf autonome Entscheidungen ausweiten und Verantwortlichkeiten vor dem ersten größeren Vorfall festlegen. Das ist nicht besonders glamourös. Aber genau dort entscheidet sich, ob KI-Agenten im Unternehmen ein Produktivitätshebel bleiben oder zur unsichtbaren Quelle technischer Schulden werden.
Der Markt hat gelernt, Cloud-Ausgaben zu hinterfragen. Er wird auch lernen, KI-Autonomie zu hinterfragen. Die zentrale Kennzahl ist dann nicht, wie viele Agenten ein Unternehmen eingeführt hat. Sondern wie viele ihrer Entscheidungen es im Störfall noch erklären kann.
