Drei KI-Anbieter fielen gleichzeitig aus. Würde Ihr Produkt weiterlaufen?

Am 3. September kam es bei ChatGPT und Codex, Claude sowie Grok zu zeitlich überlappenden Ausfällen. OpenAI verzeichnete erhöhte Fehlerraten bei ChatGPT und Codex. Anthropic meldete erhöhte Fehlerraten bei mehreren Claude-Modellen. Die Störungen verbreiteten sich so schnell, dass auf X eigene Trendthemen dazu entstanden.

Die Vorfälle hatten nicht zwangsläufig dieselbe Ursache. Allein der zeitliche Zusammenhang belegt keinen gemeinsamen Infrastrukturausfall. Auch produktive APIs, Coding-Werkzeuge und Chat-Oberflächen waren nicht bei jedem Anbieter identisch betroffen.

Diese Unsicherheit schwächt die Lehre nicht. Sie macht sie nützlicher.

Wenn ein wichtiger Ablauf von einem KI-Anbieter abhängt, ist „wir können zu einem anderen Modell wechseln“ noch keine Resilienzstrategie. Mehrere Anbieter können im selben Betriebszeitraum ausfallen. Ein technischer Fallback kann zwar erreichbar, für die konkrete Aufgabe aber ungeeignet sein. Er kann außerdem Annahmen zu Datenschutz, Sicherheit, Latenz oder Kosten verletzen.

Die Produktionsfrage lautet deshalb nicht „Welcher KI-Anbieter hat die beste Verfügbarkeit?“

Sondern:

„Was macht unser Produkt, wenn die KI-Funktion nicht verfügbar, langsam, fehlerhaft oder nur teilweise nutzbar ist?“

Ernsthafte Software braucht darauf vor dem nächsten Vorfall eine präzise Antwort.

Eine KI-Funktion kann zur geschäftskritischen Abhängigkeit werden

Viele KI-Funktionen beginnen als optionale Hilfe. Ein Modell entwirft eine Antwort, fasst ein Dokument zusammen, schlägt eine Codeänderung vor oder klassifiziert eine eingehende Anfrage. Fällt es aus, kann ein Nutzer warten oder die Aufgabe manuell erledigen.

Das Risiko ändert sich, sobald die Funktion in den kritischen Pfad rückt.

Das gilt etwa für KI-Komponenten, die:

• Kundenanfragen an die richtige Stelle leiten;
• Felder extrahieren, bevor eine Bestellung weiterlaufen kann;
• Transaktionen auf Betrug prüfen;
• Anweisungen für ein Betriebsteam erzeugen;
• einen Coding- oder Deployment-Ablauf steuern;
• unstrukturierte Dokumente in Datensätze für ein Folgesystem umwandeln.

Ist die Komponente nicht verfügbar, kann der Geschäftsprozess stoppen. Liefert sie fehlerhafte oder qualitativ schlechte Ergebnisse, läuft der Prozess womöglich falsch weiter. Der zweite Fall ist oft gefährlicher, weil Dashboards grün bleiben können, während falsche Entscheidungen nachgelagerte Systeme erreichen.

Produktionsreife umfasst deshalb mehr als Modellgenauigkeit. Sie umfasst Verfügbarkeit, begrenzte Wartezeiten, erkennbare Fehler, Wiederherstellbarkeit und einen sicheren Notbetrieb.

Zuerst den Notbetrieb definieren, dann das Ersatzmodell

Bevor ein zweiter Anbieter ausgewählt wird, muss feststehen, was das Produkt ohne KI tun soll.

Vier Antworten sind typisch:

1. Ohne Zusatzfunktion weiterarbeiten. Die Suche funktioniert weiter, aber die KI-Zusammenfassung entfällt. Ein Supportformular wird übermittelt, die automatische Kategorisierung wartet.
2. Arbeit in eine Warteschlange legen. Die Anfrage wird sicher gespeichert und nach der Wiederherstellung verarbeitet. Das passt zu asynchronen Aufgaben, bei denen Verzögerung vertretbar ist.
3. An einen Menschen übergeben. Eine Person bearbeitet wertvolle oder unklare Fälle anhand der Originaldaten, nicht anhand eines halbfertigen Modellergebnisses.
4. Sicher stoppen. Bei risikoreichen Aktionen ist keine Aktion der richtige Fallback. Das System erklärt die Unterbrechung und bewahrt genug Zustand für die Fortsetzung.

Die richtige Antwort hängt von den Folgen einer Verzögerung und den Folgen eines Fehlers ab. Eine Hilfe für Marketingtexte darf eine Stunde verschwinden. Ein Modell in Betrugsprüfung, Gesundheitsverwaltung oder Industriebetrieb braucht strengere Grenzen.

Der Notbetrieb ist eine Produktentscheidung, die durch Architektur umgesetzt wird. Eine SDK-Retry-Schleife kann ihn während eines Vorfalls nicht erfinden.

Das Modell hinter eine echte Grenze stellen

Aufrufe eines Anbieters sollten nicht über Controller, Seitenkomponenten, Workflow-Skripte und Hintergrundjobs verteilt sein. Sie gehören hinter eine anwendungseigene Grenze.

Diese Grenze sollte die benötigte Fähigkeit beschreiben und nicht bloß die API eines Anbieters nachbilden. Zum Beispiel:

• classifySupportRequest mit versioniertem Ergebnisschema;
• extractInvoiceFields mit Konfidenz und Herkunft;
• draftReply mit expliziten Regeln für Richtlinie und Sprache;
• proposeCodeChange mit Grenzen für Repository und Werkzeuge.

Die Anwendung kann dann Timeouts, Ausgabevalidierung, Protokollierung, Kostenlimits und Routing an einer Stelle durchsetzen. Anbieterspezifische Modellnamen, Werkzeugformate, Authentifizierung und Fehlertypen bleiben in Adaptern.

Das macht Modelle nicht austauschbar. Es macht ihre Unterschiede sichtbar und testbar. Ohne diese Grenze wird ein Notfallwechsel zu einer Suchen-und-Ersetzen-Aktion im Produktionscode.

Das übrige Produkt schützen

Eine langsame Abhängigkeit kann mehr Schaden anrichten als eine ausgefallene. Anfragen stauen sich, Worker-Pools laufen voll, Datenbankverbindungen bleiben offen, Nutzer versuchen es erneut. Aus einem Vorfall beim Anbieter wird so ein Vorfall in der eigenen Anwendung.

Jeder KI-Aufruf braucht ein Zeitbudget, das aus der User Journey oder der Frist des Jobs abgeleitet ist. Ein beliebiger Standardwert des SDK reicht nicht.

Überschreiten Fehlerrate oder Latenz einen Grenzwert, sollte ein Circuit Breaker vorübergehend keine weitere Arbeit senden. Das gibt dem Anbieter Zeit zur Erholung und verhindert, dass die Anwendung Ressourcen für voraussichtlich erfolglose Anfragen verbraucht.

Wiederholungen müssen begrenzt und selektiv sein. Bei Überlastung oder einem vorübergehenden Netzwerkfehler kann ein neuer Versuch helfen. Bei einer ungültigen Anfrage, einer Richtlinienablehnung oder einem inkompatiblen Werkzeugaufruf hilft er meist nicht. Unkontrollierte Wiederholungen erhöhen Kosten und Last genau im falschen Moment.

Anschließend muss der Fehler in den definierten Notbetrieb führen: Warteschlange, menschliche Prüfung, verringerter Funktionsumfang oder sicherer Stopp.

Nur Arbeit einreihen, die sich sicher wiederholen lässt

Warteschlangen sind nützlich für Dokumentverarbeitung, Datenanreicherung, Berichtserstellung und andere asynchrone Aufgaben. Sie sind kein Zaubermittel.

Kann ein Job später laufen, braucht das System:

• dauerhafte Speicherung der ursprünglichen Anfrage;
• einen Idempotenzschlüssel, damit Wiederholung keine doppelten Aktionen erzeugt;
• ein Höchstalter, nach dem das Ergebnis nicht mehr nützlich ist;
• klare Regeln für Wiederholung und Dead-Letter-Queues;
• versionierte Prompts und Schemas, damit verzögerte Arbeit reproduzierbar bleibt;
• einen für Nutzer und Betrieb sichtbaren Status.

Eine unklare halbe Transaktion gehört nicht in eine Warteschlange, in der Hoffnung, das Modell rekonstruiere die Absicht später. Zuerst muss der Geschäftszustand erhalten bleiben. Ein Modellergebnis ist ein Vorschlag, der vor jeder irreversiblen Aktion weiterhin die aktuellen Validierungen erfüllen muss.

Ein zweiter Anbieter hilft, reicht aber nicht

Multi-Provider-Routing kann Ausfallzeit verringern. Besonders nützlich ist es, wenn Anbieter unabhängige Infrastruktur nutzen und die Aufgabe Unterschiede in der Ausgabe toleriert.

Ein Modell-Fallback ist jedoch nur sicher, wenn es gegen denselben Fähigkeitsvertrag getestet wurde. Teams müssen prüfen:

• Verhalten bei strukturierten Ausgaben und Werkzeugaufrufen;
• Kontext- und Dateigrenzen;
• Latenz unter realistischer Last;
• Sicherheitsablehnungen und Fehlersemantik;
• Qualität für Sprache und Fachgebiet;
• regionale Verarbeitung, Aufbewahrung und Vertragsbedingungen;
• Kosten bei Wiederholungen und Lastspitzen;
• ob der Fallback dieselbe Cloud, dasselbe Gateway, denselben Identity Provider oder denselben Netzwerkpfad nutzt.

Der letzte Punkt ist nach einer Ausfallserie besonders wichtig. Anbietervielfalt in einem Diagramm kann darunterliegende gemeinsame Infrastruktur verdecken. Selbst vollständig unabhängige Anbieter können innerhalb desselben Zeitraums getrennte Vorfälle erleben.

Der Fallback muss deshalb fähigkeitsbezogen sein. Ein kleineres Modell kann Routineanfragen vielleicht sicher klassifizieren, aber keinen komplexen Werkzeugablauf ausführen. Ein lokales Modell kann eine einfache Extraktion aufrechterhalten, erreicht jedoch womöglich nicht die Qualität des primären Anbieters. Das Routing muss diese Grenzen kennen und den passenden Notbetrieb auswählen.

Nahtlosigkeit ist nicht das Ziel. Vorhersehbares Verhalten ist es.

Einen deterministischen oder menschlichen Ausweg erhalten

Der stärkste Fallback kommt oft ganz ohne generatives Modell aus.

Ein regelbasierter Klassifikator kann die häufigsten Supportkategorien abdecken. Ein klassischer Suchindex bleibt verfügbar, wenn generative Antworten ausfallen. Pflichtfelder einer Rechnung können manuell eingegeben werden. Eine Deployment-Pipeline kann ein menschliches Review verlangen, statt auf einen Agenten zu warten.

Diese Wege dürfen langsamer oder unbequemer sein. Ein Notbetrieb soll das wesentliche Geschäftsergebnis erhalten, nicht jede Funktion des Normalbetriebs nachahmen.

Der Ausweg muss außerdem regelmäßig genutzt werden. Ein manueller Prozess in einer vergessenen Wiki-Seite scheitert, wenn Berechtigungen geändert wurden, das Formular nicht mehr existiert oder niemand die Entscheidung verantwortet.

Die Fähigkeit beobachten, nicht nur den HTTP-Status

Ein KI-Endpunkt kann HTTP 200 liefern und das Produkt trotzdem im Stich lassen.

Sinnvolle Beobachtbarkeit umfasst:

• Verfügbarkeit und Latenz nach Anbieter, Modell, Region und Fähigkeit;
• Raten für Timeouts, Ablehnungen, Validierungs- und Werkzeugfehler;
• Tiefe der Warteschlange und Alter des ältesten Jobs;
• Aktivierung und Erfolgsrate von Fallbacks;
• an Geschäftsregeln gebundene Qualitätsprüfungen;
• Kosten pro abgeschlossenem und akzeptiertem Ergebnis;
• Korrelations-IDs über Nutzeranfrage, Modellaufruf, Werkzeugaufruf und Folgeaktion.

Alarme sollten sich auf die Auswirkung für Nutzer konzentrieren. Eine Statusseite kann den aggregierten Dienst als gesund melden, während ein Modell, eine Region, eine Vertragsstufe oder ein Werkzeug beeinträchtigt bleibt. Für das eigene Produkt zählen die eigenen Service-Level-Indikatoren.

Auch Logs brauchen Disziplin. Beobachtbarkeit darf nicht bedeuten, Prompts, Quellcode, personenbezogene Daten und Modellausgaben in eine unbeschränkte Logging-Plattform zu kopieren. Erfasst werden die für die Diagnose nötigen Metadaten. Sensible Inhalte werden geschwärzt und nur eng begrenzt sowie auditierbar zugänglich gemacht.

Einen KI-Ausfall proben

Die Architektur ist erst vollständig, wenn der Fehlerpfad erprobt wurde.

Ein praktischer Testtag kann klein beginnen:

1. Den primären Anbieter-Endpunkt in einer Test- oder Staging-Umgebung blockieren.
2. Latenz und sporadische Fehler einbauen, nicht nur einen sauberen Verbindungsabbruch.
3. Fehlerhafte strukturierte Ausgaben und unvollständige Werkzeugaufrufe zurückgeben.
4. Das Kontingent des Ersatzanbieters erschöpfen oder auch ihn unverfügbar machen.
5. Prüfen, ob Circuit Breaker korrekt öffnen und sich korrekt zurücksetzen.
6. Eingereihte Arbeit erneut ausführen und auf doppelte Nebenwirkungen prüfen.
7. Den manuellen Weg mit den vorgesehenen Personen testen.
8. Sichtbares Nutzerverhalten, Wiederherstellungszeit, Datenintegrität und Betriebsaufwand messen.

Der Test soll konkrete Fragen beantworten. Erkennt der Support, welche Fälle Aufmerksamkeit brauchen? Kann ein Kunde fortfahren, ohne Daten erneut einzugeben? Kann der Betrieb eine Fähigkeit abschalten, ohne das ganze Produkt stillzulegen? Kann das Team erklären, welche Aktionen stattgefunden haben und welche nicht?

Sind diese Antworten unklar, löst ein weiterer API-Schlüssel die Architektur nicht.

Aufwand am Geschäftsrisiko ausrichten

Nicht jede KI-Funktion braucht Aktiv-Aktiv-Routing über drei Anbieter. Resilienz kostet: zusätzliche Integrationen, Tests, Verträge, Monitoring und betriebliche Komplexität.

Eine einfache Einteilung hilft:

• Optionale Verbesserung: einen klaren Nicht-verfügbar-Zustand zeigen und den Kernablauf erhalten.
• Wichtig, aber verzögerbar: dauerhaft einreihen, Status kommunizieren und später verarbeiten.
• Zeitkritische Geschäftsfunktion: getesteten fähigkeitsbezogenen Fallback plus menschlichen Weg vorsehen.
• Sicherheits- oder compliancekritische Aktion: standardmäßig sicher stoppen, explizite Freigabe und vollständige Auditierbarkeit verlangen.

Das ist Architecture-first Delivery: investieren, wo ein Fehler Umsatz, Sicherheit, Vertragspflichten oder Kundenvertrauen verändert.

Verfügbarkeit ist ein Produktverhalten

Die Ausfallserie im September geht vorüber. Anbieter stellen ihre Systeme wieder her, veröffentlichen Updates und verbessern ihren Betrieb. Ein weiterer Vorfall wird irgendwann folgen.

Die bleibende Frage ist, ob die eigene Software ein KI-Modell als hilfreiches Werkzeug oder als unsichtbaren Single Point of Failure behandelt.

Produktionsreife KI bedeutet nicht, dass das Modell nie ausfällt. Sie bedeutet, dass das Produkt für diesen Fall eine getestete Antwort hat: begrenzte Wartezeiten, kontrollierte Wiederholungen, validierte Fallbacks, dauerhaften Zustand, sichtbare Auswirkungen und einen sicheren Weg, der den wesentlichen Geschäftsprozess erhält.

Diese Antwort entsteht vor dem Ausfall.