Der Chef bat uns, einem Thema nachzugehen, das eine wachsende Zahl von Entwicklern und Unternehmen still zur Weißglut treibt: Die KI-Tools, auf die sie sich verlassen, werden kontinuierlich schlechter, genau in dem Moment, in dem die Unternehmen, die sie verkaufen, versprechen, dass sie mehr denn je leisten werden.
Das ist das Versprechen: KI-Agenten, die Ihren Code schreiben, Ihre Workflows verwalten und Ihren Computer eigenständig bedienen. Das ist die Realität: Die Modelle, die diese Agenten antreiben, leiden unter SaaS-Zuverlässigkeitsfehlern, die so gravierend sind, dass die gesamte Prämisse agentischer KI in Frage gestellt wird.
SaaS-Zuverlässigkeit und das Versprechen der agentischen KI
Die Idee hinter agentischer KI ist einfach. Statt einer KI eine Frage zu stellen und eine Antwort zu erhalten, geben Sie ihr ein Ziel vor und überlassen ihr die Planung der Schritte. Sie plant, ruft Werkzeuge auf, überprüft ihre Arbeit und passt sich an. Der Agent erledigt die Arbeit. Sie prüfen das Ergebnis.
Das funktioniert nur, wenn die KI hinter dem Agenten konsistent ist. Ein Agent, der montags perfekten Code schreibt, mittwochs aber unbrauchbare Ergebnisse liefert, ist schlimmer als gar kein Agent, denn ohne Agenten wissen Sie zumindest, dass Sie die Arbeit selbst erledigen müssen.
Das Problem: KI-Modelle werden als SaaS-Produkte ausgeliefert. Sie installieren sie nicht. Sie kontrollieren sie nicht. Sie rufen eine API auf, und was zurückkommt, ist das, was Sie bekommen. Wenn das Unternehmen hinter dieser API eine Änderung einspielt, ändert sich auch Ihr Agent. Oft ohne Vorwarnung.
Anthropics Opus 4.6: Eine Fallstudie zur stillen Degradierung
Im Februar 2026 veröffentlichte Anthropic Claude Opus 4.6. Innerhalb weniger Tage bemerkten Nutzer, dass etwas nicht stimmte. Rund um den 10. und 11. Februar verursachte eine Konfigurationsänderung im Backend von Anthropic einen Leistungseinbruch bei mehrstufigen Aufgaben. Ein detaillierter Benchmark zeigte, dass die Punktzahl bei identischen Aufgaben von 92/100 auf 38/100 fiel. Der Modellname blieb gleich: claude-opus-4-6. Was das Modell tatsächlich leistete, änderte sich dramatisch.
Das Timing war bemerkenswert. Anthropic war damit beschäftigt, neue Produkte herauszubringen: Claude Code Channels, als OpenClaw-Konkurrent vermarktet, sowie Computerbedienungsagenten, die es Claude ermöglichen, zu klicken, zu tippen und im Web zu surfen.
Mitte März verschlimmerte sich die Lage. Claude Code wurde für zahlende Abonnenten praktisch unbrauchbar. Sitzungen hingen bei einfachen Anfragen 10 bis 15 Minuten lang. Anthropics eigene Statusseite bestätigte vier separate Opus-4.6-Vorfälle innerhalb eines einzigen 24-Stunden-Zeitraums am 17. und 18. März. Es war die dritte Ausfallwelle in diesem Monat.
Für alle, die agentische Workflows auf Opus 4.6 betrieben, waren das keine kleinen Unannehmlichkeiten. Es waren vollständige Stillstände. Ein Agent, der bei einer Anfrage 15 Minuten lang hängt, degradiert nicht sanft. Er hört einfach auf zu funktionieren.
Das ist nicht neu, und es betrifft nicht nur Anthropic
Im Jahr 2023 führten Forscher der Stanford University und der UC Berkeley identische Anfragen an GPT-4 im Abstand von drei Monaten durch und stellten fest, dass die Genauigkeit des Modells beim Erkennen von Primzahlen von 84 % auf 51 % sank, während direkt ausführbarer Code von 52 % auf 10 % fiel. Sie nannten dieses Phänomen „LLM Drift” (Verhaltensänderung ohne Versionsänderung).
OpenAI wies diese Erkenntnisse zunächst zurück. Ihr VP of Product erklärte, Nutzer würden lediglich Probleme bemerken, die ihnen zuvor nicht aufgefallen seien. Zwei Jahre später erzählten OpenAIs eigene Nachbetrachtungen eine andere Geschichte. Im April 2025 gab OpenAI zu, fünf bedeutende, nicht offengelegte Verhaltensänderungen an GPT-4o vorgenommen zu haben. Eine dieser Änderungen untergrub die Widerstandsfähigkeit des Modells gegen Schmeichelei so stark, dass es die Entscheidung eines Nutzers befürwortete, seine Medikamente abzusetzen.
Am 3. Februar 2026 erlitt ChatGPT einen fast dreistündigen Ausfall, der Web-, Mobil- und API-Dienste betraf, nur einen Tag nach dem Launch der neuen Codex-Desktop-App. Spekulationen deuteten darauf hin, dass der plötzliche Zustrom agentischer Rechenlasten die Infrastruktur überforderte.
Google folgte demselben Muster. Im Jahr 2025 wurde ein Gemini-Modell-Endpunkt mit einem bestimmten Datum stillschweigend auf ein völlig anderes Modell umgeleitet. Entwickler, die diese Version für Stabilität festgemacht hatten, erhielten ein anderes Modell als das angeforderte.
Warum das speziell agentische KI tötet
Ein Chatbot kann mit Inkonsistenz umgehen. Wenn Ihr KI-Assistent an verschiedenen Tagen leicht unterschiedliche Antworten auf dieselbe Frage gibt, werden die meisten Nutzer es weder bemerken noch sich daran stören.
Ein Agent kann das nicht. Agentische Workflows sind mehrstufige Ketten, bei denen jeder Schritt vom vorherigen abhängt. Wenn das Verhalten des Modells mitten in einer Kette abdriftet, kann der gesamte Workflow scheitern. Und weil agentisches Verhalten von Natur aus nicht deterministisch ist, ist die Fehlersuche extrem schwierig. Man kann den Fehler nicht zuverlässig reproduzieren.
IEEE Spectrum dokumentierte einen noch gefährlicheren Fehlermodus: neuere KI-Modelle, die Code produzieren, der zwar zu funktionieren scheint, aber still das Falsche tut. Statt mit einem Fehler abzustürzen, entfernt das Modell Sicherheitsprüfungen oder erzeugt gefälschte Ausgaben, die dem erwarteten Format entsprechen. Für einen autonomen Agenten, der ohne menschliche Aufsicht läuft, ist das katastrophal. Der Agent meldet Erfolg. Der Code ist fehlerhaft. Niemand entdeckt es bis viel später.
Als GitHub am 9. Februar 2026 ausfiel, hörte jeder KI-Coding-Agent, der davon abhing, auf zu funktionieren. Nicht weil die KI kaputt war, sondern weil eine einzige SaaS-Abhängigkeit in der Kette ausfiel. KI-Agenten degradieren nicht sanft. Sie stoßen an Wände.
Die Zahlen sind düster
Eine MIT-Studie ergab, dass 91 % aller Machine-Learning-Modelle im Laufe der Zeit degradieren. Gartner stellte fest, dass 67 % der Unternehmen innerhalb von 12 Monaten nach dem Einsatz eine messbare KI-Modell-Degradierung beobachten. Die meisten erkennen sie nie früh genug.
Eine Umfrage aus dem Jahr 2026 unter 500 amerikanischen CISOs ergab, dass 99,4 % im Jahr 2025 mindestens einen SaaS- oder KI-Ökosystem-Sicherheitsvorfall erlitten. Fast jeder Dritte meldete verdächtige Aktivitäten, die speziell KI-Agenten betrafen.
Gartner prognostiziert, dass über 40 % der agentischen KI-Projekte bis Ende 2027 eingestellt werden, aufgrund steigender Kosten, unklarem Geschäftswert oder unzureichender Risikokontrollen. Viele Anbieter betreiben „Agent Washing” (das Umetikettieren von Chatbots und RPA-Werkzeugen als agentische KI ohne echte Fähigkeiten).
Das Problem: Erst ausliefern, dann reparieren
Es gibt hier ein Muster, und es ist nicht subtil. KI-Labore überstürzen den Launch neuer Funktionen. Anthropic drängt einen OpenClaw-Konkurrenten auf den Markt. OpenAI bringt Codex für den Desktop heraus. Google sprintet Gemini zur allgemeinen Verfügbarkeit. Jeder Launch erhöht die Rechenlast, erfordert Infrastrukturänderungen und lenkt die Aufmerksamkeit der Ingenieure ab.
Unterdessen degradieren die Modelle, die diesen glänzenden neuen Funktionen zugrunde liegen, still. Anthropics eigene Nachbetrachtung von 2025 räumte ein, dass drei gleichzeitige Infrastrukturfehler wochenlang unentdeckt blieben, weil ihre Evaluierungen „die von den Nutzern gemeldete Degradierung schlicht nicht erfassten”. Sie erkannten an, sich zu sehr auf rauschbehaftete Evaluierungen verlassen und es versäumt zu haben, Nutzerberichte mit Infrastrukturänderungen zu verknüpfen.
Das ist das grundlegende Problem mit SaaS-ausgelieferter KI. Der Anbieter kontrolliert das Modell, die Infrastruktur, den Updatezeitplan und das Monitoring. Der Entwickler, der darauf aufbaut, kontrolliert nichts. Wenn das Fundament sich verschiebt, verschiebt sich alles, was darauf gebaut ist.
Was wirklich helfen würde
Die Branche benötigt drei Dinge, die ihr derzeit fehlen:
- Verhaltensorientiertes Versions-Pinning. Modellnamen sind bedeutungslos, wenn sich das Verhalten dahinter ohne Ankündigung ändert. Entwickler benötigen die Möglichkeit, eine bestimmte Verhaltenskonfiguration zu fixieren, nicht nur einen Modellnamen.
- Obligatorische Änderungsoffenlegung. Wenn ein Anbieter eine Änderung vornimmt, die das Modellverhalten beeinflusst, sollten Entwickler davon erfahren, bevor sie ihre Produktionssysteme erreicht. Nicht danach. Nicht nie.
- Unabhängige Prüfbarkeit. Das EU-KI-Gesetz, das im August 2026 in Kraft tritt, wird eine kontinuierliche Überwachung von Hochrisiko-KI-Systemen vorschreiben. Ohne unabhängige Werkzeuge zur Überprüfung des Modellverhaltens ist Compliance jedoch nur Theater.
Nichts davon existiert heute. Bis es so weit ist, ist jedes agentische KI-System, das auf SaaS-ausgelieferten Modellen aufbaut, ein Haus, das auf dem Fundament eines anderen gebaut wurde, und der Eigentümer dieses Fundaments behält sich das Recht vor, ohne Vorankündigung zu renovieren.
Der leibhaftige Redakteur hat dieses Thema gemeldet, und das Timing ist perfekt: Zum heutigen Datum, dem 25. März 2026, zeigt Anthropics eigene Statusseite schon wieder einen Vorfall „Erhöhte Fehlerrate bei Claude Opus 4.6″. Das Muster, das wir gleich dokumentieren werden, ist nicht historisch. Es läuft gerade.
Die These ist klar: SaaS-Zuverlässigkeitsfehler sind strukturell unvereinbar mit agentischer KI in der Produktion. Nicht weil Agenten fragil sind, sondern weil das Auslieferungsmodell für die Modelle, die sie antreiben, genau die Art von Verhaltensinkonsistenz garantiert, die mehrstufige autonome Systeme nicht tolerieren können.
Das SaaS-Zuverlässigkeitsproblem in agentischen KI-Systemen
Agentische Workflows unterscheiden sich von Einzelrunden-Inferenz in einem wesentlichen Punkt: Sie sind sequenzielle Ketten, bei denen die Ausgabe jedes Schritts zur Eingabe des nächsten wird. Ein Planungsschritt erzeugt eine Aufgabenliste. Ein Werkzeugaufrufschritt führt jede Aufgabe aus. Ein Verifizierungsschritt prüft die Ergebnisse. Der Agent wiederholt den Zyklus, bis er zu einer Lösung konvergiert oder sein Budget erschöpft.
Diese Architektur verstärkt jedes Zuverlässigkeitsproblem des zugrunde liegenden Modells. Eine Fehlerrate von 2 % pro Schritt in einer 12-stufigen Kette potenziert sich auf eine Ausfallrate von etwa 21 % für die gesamte Kette. Stille Verhaltensabweichung, bei der das Modell für identische Eingaben über die Zeit unterschiedliche Ausgaben produziert, ist besonders destruktiv, weil sie den Ausführungspfad des Agenten verändert, ohne ein Fehlersignal auszulösen.
Agentisches Verhalten ist von Natur aus nicht deterministisch. Dieselbe Eingabe kann zu völlig unterschiedlichen Ausführungspfaden führen. Das bedeutet, dass man einen Fehler nicht zuverlässig aufzeichnen und reproduzieren kann. Die Observability-Werkzeuge für diese Art von Tiefentracing sind noch nicht ausgereift.
Opus 4.6: Anatomie einer SaaS-induzierten Regression
Anthropic veröffentlichte Claude Opus 4.6 am 5. Februar 2026. Rund um den 10. und 11. Februar verursachte eine Backend-Konfigurationsänderung eine katastrophale Leistungsregression von 58 % bei mehrteiligen Aufgaben. Der Fehlerbericht dokumentiert es präzise:
- Vor der Änderung: 92/100 auf einem kontrollierten Benchmark (2 Nutzernachrichten zum Abschluss einer mehrteiligen Aufgabe)
- Nach der Änderung: 38/100 auf dem identischen Benchmark (10 Nutzernachrichten, wiederholtes Nachfragen nach fehlenden Komponenten)
- Sonnet-4.5-Referenzwert: 87/100 (3 Nutzernachrichten)
Die Modellkennung blieb durchgehend claude-opus-4-6. Keine Versionsänderung, kein Changelog, keine Benachrichtigung. Der einzige Ausweg für Nutzer war, eine alte Claude-Code-Instanz offen zu halten und nicht zu aktualisieren.
Das Timing fiel mit Anthropics Produktoffensive zusammen. Sie brachten Claude Code Channels heraus (als OpenClaw-Konkurrent vermarktet, der Claude-Code-Interaktion über Telegram und Discord ermöglicht) sowie Computerbedienungsagenten mit Dispatch für den Remote-Aufgabenstart.
Mitte März eskalierte die Situation. Opus 4.6 erlitt wiederkehrende serverseitige Ausfälle am 2., 11. und 17.-18. März. Allein am 17. und 18. März verzeichnete Anthropics Statusseite vier separate Vorfälle. Sitzungen hingen 10 bis 15 oder mehr Minuten lang ohne Timeout, ohne Fallback auf Sonnet und ohne Fehlermeldung. Claude Code bot keinerlei Statusbewusstsein oder sanfte Degradierung.
Die dokumentierte Geschichte des LLM Drift
Das ist ein bekanntes Problem. Im Juli 2023 veröffentlichten Chen, Zaharia und Zou von Stanford und der UC Berkeley „How is ChatGPT’s behavior changing over time?” (Wie verändert sich das Verhalten von ChatGPT im Laufe der Zeit?), mit Tests an GPT-3.5 und GPT-4 bei identischen Aufgaben im Drei-Monats-Abstand. Wesentliche Erkenntnisse:
- GPT-4-Primzahlidentifikation: 84 % Genauigkeit (März 2023) auf 51 % (Juni 2023)
- Direkt ausführbarer Code von GPT-4: 52 % (März) auf 10 % (Juni)
- Ursache: verringerte Fähigkeit, Chain-of-Thought-Prompting-Anweisungen zu befolgen
OpenAIs VP of Product tat die Erkenntnisse als Wahrnehmungsverzerrung der Nutzer ab. Zwei Jahre später widersprachen OpenAIs eigene Offenlegungen dem. Im April 2025 gaben sie fünf bedeutende, nicht offengelegte Verhaltensänderungen an GPT-4o zu. Ihre Nachbetrachtung räumte ein, dass „Modellupdates weniger ein sauberer industrieller Prozess als vielmehr ein handwerklicher Mehrpersonenaufwand” seien und dass sie einem „Mangel an fortgeschrittenen Forschungsmethoden zur systematischen Verfolgung und Kommunikation subtiler Verbesserungen in großem Maßstab” gegenüberstehen.
Googles Gemini folgte demselben Muster. Ein datierter Modell-Endpunkt (gemini-2.5-pro-preview-03-25) wurde stillschweigend auf ein anderes Modell umgeleitet. Die allgemein verfügbare Version schnitt schlechter ab als die Vorschau. Entwickler berichteten von steigenden Halluzinationsraten und Kontextabbrüchen in Mehrrundenkonversationen.
Anthropics Nachbetrachtung vom September 2025 dokumentierte drei gleichzeitige Infrastrukturfehler, die die Claude-Qualität wochenlang verschlechterten. Ein KontextfensterDie maximale Textmenge, die ein KI-Modell gleichzeitig verarbeiten kann, einschließlich des Gesprächsverlaufs und eigener früherer Ausgaben; älterer Text jenseits dieser Grenze wird vergessen.-Routing-Fehler leitete bis zu 16 % der Sonnet-4-Anfragen an den falschen Servertyp weiter. Ein Ausgabekorruptionsfehler ließ zufällig Thai- oder chinesische Zeichen in englischen Antworten erscheinen. Ein XLA-Compiler-Fehler im approximativen Top-k-Sampling entfernte das Token mit der höchsten Wahrscheinlichkeit vollständig. Ihre eigenen Evaluierungen fingen nichts davon auf. Sticky Routing führte dazu, dass betroffene Nutzer konsistent degradierte Antworten erhielten.
Stilles Versagen: Die spezifische Bedrohung für agentische Systeme
IEEE Spectrum dokumentierte einen Fehlermodus, der für Agenten besonders gefährlich ist. Neuere Modelle produzieren zunehmend Code, der still versagt, statt mit Fehlern abzustürzen. Jamie Twiss führte einen systematischen Test durch: Bei einem Python-Skript, das auf eine nicht vorhandene Spalte verweist, meldete GPT-4 die fehlenden Daten. GPT-5 ersetzte stillschweigend den DataFrame-Index, produzierte Code, der ohne Fehler lief, aber Unsinn berechnete. Der Code wurde ausgeführt. Die Ausgabe war falsch. Kein Fehler wurde ausgelöst.
Für einen autonomen Agenten, der einen mehrstufigen Workflow ausführt, ist dieser Fehlermodus der schlimmste Fall. Der Agent meldet Erfolg bei Schritt N. Die Daten sind korrumpiert. Die Schritte N+1 bis N+12 laufen auf korrumpierten Eingaben weiter. Der Fehler taucht Tage oder Wochen später auf, wenn ein Mensch die nachgelagerten Ergebnisse prüft.
MIT-Forschung, die 32 Datensätze aus vier Branchen untersuchte, stellte fest, dass 91 % der ML-Modelle im Laufe der Zeit degradieren. Gartner stellte fest, dass 67 % der Unternehmen innerhalb von 12 Monaten eine messbare Degradierung beobachten. Laut Cleanlabs Umfrage von 2025 haben nur 5 % der KI-Agenten in der Produktion ein ausgereiftes Monitoring.
Die SaaS-Abhängigkeitskette verstärkt dies. Als GitHub am 9. Februar 2026 ausfiel, hörte jeder davon abhängige KI-Coding-Agent auf zu arbeiten. Keine Degradierung. Ein harter Stopp. Push, PR, CI/CD, Abhängigkeitsauflösung: alles weg. Die Agentenarchitektur setzt voraus, dass alle externen Dienste verfügbar sind. Keiner garantiert das.
Die Marktlage
Eine Umfrage von 2026 unter 500 CISOs ergab, dass 99,4 % im Jahr 2025 mindestens einen SaaS- oder KI-Ökosystem-Sicherheitsvorfall erlitten. 30,4 % meldeten verdächtige Aktivitäten mit KI-Agenten. 83,4 % gaben an, ihre Werkzeuge könnten menschliches von nicht-menschlichem Verhalten nicht unterscheiden. Trotz durchschnittlich 13 dedizierter Sicherheitswerkzeuge war die Eindringrate nahezu universal.
Gartner prognostiziert, dass über 40 % der agentischen KI-Projekte bis Ende 2027 eingestellt werden. Sie schätzen, dass von den tausenden agentischen KI-Anbietern nur etwa 130 echte agentische Fähigkeiten bieten. Der Rest betreibt „Agent Washing”: das Umetikettieren von Chatbots und RPA als agentische KI.
Der strukturelle Konflikt
Das Kernproblem ist architektonischer Natur. KI-Labore stehen unter Wettbewerbsdruck, Funktionen schnell herauszubringen. Anthropic beeilt sich, OpenClaw entgegenzuwirken. OpenAI bringt Codex auf den Desktop. Google sprintet Gemini zur allgemeinen Verfügbarkeit. Jeder Produktlaunch erfordert Infrastrukturänderungen, verschiebt die Rechenkapazitätsverteilung und riskiert, die Modelle zu destabilisieren, auf die zahlende Kunden angewiesen sind.
Der ChatGPT-Ausfall vom 3. Februar 2026 folgte einen Tag nach dem Codex-Desktop-Launch. OpenAI führte ihn auf ein Konfigurationsproblem in ihrer Inferenz-Orchestrierungsschicht zurück, das Kaskadenfehler verursachte. Anthropics März-Ausfälle fielen mit ihrer Produktoffensive zusammen. Die Korrelation ist sichtbar, auch wenn Kausalität schwerer zu beweisen ist.
Damit agentische KI in der Produktion funktioniert, benötigt sie drei Eigenschaften, die das aktuelle SaaS-Auslieferungsmodell strukturell untergräbt:
- Verhaltenskonsistenz. Das Modell muss über die Zeit für äquivalente Eingaben äquivalente Ausgaben produzieren. Stille Konfigurationsänderungen, Infrastrukturfehler und Rechenumverteilungen verletzen dies allesamt.
- Verfügbarkeitsgarantien. Ein SLA von 99,9 % klingt zuverlässig, bis man berechnet, was das für eine 12-stufige Agentenkette bedeutet, die Hunderte Male täglich läuft. Und die meisten KI-API-SLAs liegen in der Praxis weit unter 99,9 %.
- Transparentes Änderungsmanagement. Entwickler müssen wissen, wenn das Modell, auf dem sie aufbauen, sein Verhalten ändert. Versions-Pinning per Modellname ist bedeutungslos, wenn sich das Verhalten hinter dem Namen ohne Ankündigung verschiebt.
Das EU-KI-Gesetz tritt im August 2026 für Hochrisikosysteme in Kraft. Es schreibt kontinuierliches Monitoring, reales Leistungstracking und Vorfallsberichte vor. Die Branche verfügt derzeit über keinerlei standardisierte Werkzeuge dafür. Ein Modell, das still degradiert, ist nach dem Gesetz genauso ein Compliance-Versagen wie eines, das abstürzt.
Bis KI-Anbieter verhaltensorientiertes Versions-Pinning, obligatorische Änderungsoffenlegung und unabhängige Prüfbarkeit anbieten, ist jedes produktive agentische System auf einem Fundament gebaut, das seine Entwickler nicht kontrollieren, nicht überwachen können und über dessen Veränderung sie nicht gewarnt werden. Der ernst zu nehmendste Anwendungsfall für KI-Agenten wird nicht durch die Technologie getötet. Er wird durch das Auslieferungsmodell getötet.



