Lösung · AI Operations
Dein KI-Anbieter wird ausfallen. Die Frage ist nicht ob, sondern was dein Betrieb in dieser halben Stunde macht.
Überwachung sagt dir, dass etwas kaputt ist. Verfügbarkeit ist das, was dafür sorgt, dass die Arbeit weiterläuft, während es kaputt ist: zweiter Weg, degradierter Betrieb, Warteschlangen, die den Stoß abfangen, und ein vereinbartes Wiederherstellungsziel pro Anwendungsfall. Wir bauen diese Funktion und betreiben sie.
Das Problem
Du behandelst einen externen Lieferanten, als wäre er eine Konstante deiner Architektur.
- Hat dein Modellanbieter eine schlechte halbe Stunde, hast du eine schlechte halbe Stunde. Es gibt keinen zweiten Weg, und niemand hat je geprüft, ob es einen geben könnte.
- Alle Agenten sprechen mit demselben Anbieter, über denselben Schlüssel und gegen dasselbe Kontingent. Ein Ausschlag beim Marketing-Agenten frisst das Limit des Agenten, der Rechnungen stellt.
- Wenn das Modell einen Fehler zurückgibt, degradiert der Prozess nicht: Er steht. Keine Teilantwort, keine Warteschlange, kein «das lösen wir in zehn Minuten» — nur ein weißer Bildschirm und ein wartender Kunde.
- Die Wiederholungsversuche sind, wo es sie gibt, sofortig und in Schleife. Wenn der Anbieter überlastet ist, legt dein System noch Last obendrauf und verlängert seinen eigenen Ausfall.
- Niemand hat aufgeschrieben, wie lange jeder Anwendungsfall stehen darf. Der Chat auf der Website und das System, das Rechnungen ausstellt, werden gleich behandelt — und sind nicht annähernd gleich viel wert.
- Dass es eine Störung gab, weißt du, weil ein Kunde es erzählt hat oder weil jemand zufällig auf die Statusseite des Anbieters geschaut hat. Der Hinweis kam von außen.
- Der Plan für einen langen Ausfall lebt im Kopf einer Person. Passiert der Ausfall an einem Freitagabend und diese Person ist im Urlaub, existiert der Plan nicht.
Was es kostet, alles zu lassen
Du hast einen externen Lieferanten, dessen Zustand du nicht kontrollierst, in den kritischen Pfad deines Betriebs gesetzt — ohne Plan B, ohne Limits und ohne interne Einigung darüber, wie lange etwas stehen darf. Das bezahlt man dreifach. Das Erste ist direkt: Jede Störung des Anbieters ist deine Störung, mit ihrem Stapel liegengebliebener Arbeit und ihrem verärgerten Kunden. Das Zweite ist schlimmer, weil man es nicht sieht: Ohne Isolierung und ohne Kontingentsteuerung reißt ein kleines Problem in einem Nebensystem ein kritisches mit, und die Diagnose kostet Stunden. Und das Dritte ist Glaubwürdigkeit: Wenn die Geschäftsführung fragt, wie lange das ausfallen darf, lautet die ehrliche Antwort heute «wir wissen es nicht» — und genau diese Antwort bremst das nächste KI-Projekt.
Die Lösung
Wir bauen Kontinuität als Funktion: zweiter Weg, kontrollierte Degradation und ein vereinbartes Ziel pro Anwendungsfall
- 1Wir fangen mit der Einigung an, nicht mit der Architektur: Welche Anwendungsfälle laufen in Produktion, wie lange darf jeder davon ohne echten Schaden stehen, und was passiert währenddessen. Dieses Ziel wird mit dem Geschäft unterschrieben, nicht von der IT allein entschieden, denn es ist eine Risiko- und Kostenentscheidung — Hochverfügbarkeit kostet Geld.
- 2Wir bauen den zweiten Weg. Ein alternativer Anbieter oder ein alternatives Modell für die Fälle, die es rechtfertigen, mit vorbereitetem und getestetem Routing, nicht als Kästchen in einem Diagramm. Der zweite Weg kann schlechtere Qualität liefern: Das wird vorher gemessen, und es wird vorher entschieden, ob es sich lohnt — statt es am Tag des Ausfalls herauszufinden.
- 3Wir definieren die kontrollierte Degradation, das Stück, das fast niemand hat. Was macht das System, wenn die KI nicht verfügbar ist: mit dem deterministischen Teil antworten, einreihen und die Frist nennen, an die Bereitschaft übergeben oder eine ehrliche Antwort geben. Alles davon kommt vor dem weißen Bildschirm.
- 4Wir setzen Limits und Warteschlangen mit Urteilsvermögen. Kontingent und Schlüssel getrennt pro System, damit ein Ausschlag nicht das Budget eines anderen auffrisst, Wiederholungen mit wachsender Wartezeit statt Schleifen, die den Ausfall des Anbieters verschlimmern, und eine Warteschlange, die den Stoß abfängt und nacharbeitet, wenn der Dienst zurück ist — ohne unterwegs Arbeit zu verlieren.
- 5Wir isolieren die Fehler. Ein Agent, der hängt, darf nicht den ganzen Prozess blockieren: Schutzschalter pro Abhängigkeit, Höchstzeiten pro Aufruf und Trennung des Kritischen vom Beiläufigen, damit der Ausfall ein Teil betrifft und nicht das System.
- 6Und wir betreiben es. Überwachung des Zustands deiner Anbieter, eingebunden in eure Alarmierung, Bereitschaft mit Incident-Handbuch — wer entscheidet den Wechsel des Wegs, wann wird degradiert, wie wird kommuniziert —, und eine regelmäßige Probe: Der Ausfall wird absichtlich ausgelöst und die Wiederherstellung gestoppt. Ein Plan, der nie ausgeführt wurde, ist kein Plan.
Was sich ändert
Was du nicht mehr verlierst
Die großen Modellanbieter betreiben öffentliche Statusseiten mit Störungshistorie und geplanten Wartungen. Die Daten existieren und sind abrufbar; was in fast allen Unternehmen fehlt, ist, dass diese Daten in die eigene Alarmierung einlaufen, statt von Hand nachgeschaut zu werden, wenn etwas schiefgeht.
Öffentliche Statusseiten der Anbieter (z. B. status.claude.com), abgerufen 2026-08
Die Service-Level-Vereinbarungen der Unternehmenstarife entschädigen mit Gutschriften, nicht mit Kontinuität: Du bekommst einen Teil der Rechnung zurück, nicht die Stunden stehenden Betriebs. Kontinuität musst du selbst bauen, auf deiner Seite.
Mechanismus · Standard-SLA-Bedingungen mit Gutschriften
Der Ausfall ist nicht mehr binär. Mit definierter Degradation geht das System von «funktioniert nicht» zu «funktioniert schlechter und sagt es» — das ist der Unterschied zwischen einer Störung und einer Krise.
Mechanismus
Budget und Kontingent sind kein herrenloses Gemeingut mehr: Jedes System hat seinen Schlüssel und sein Limit, also frisst ein Ausschlag im Beiläufigen nicht mehr die Kapazität des Kritischen.
Mechanismus
Was wir messen: echte Verfügbarkeit pro Anwendungsfall (nicht die des Anbieters), in der Probe gestoppte Erkennungs- und Wiederherstellungszeit, % der Anfragen, die während einer Störung über den zweiten Weg bedient werden, eingereihte und verlustfrei nachgearbeitete Arbeit, und Kontingentverbrauch pro System gegen sein Limit.
Was wir messen
Datenblatt
- Wegfallende Arbeit
- dass ein Ausfall des KI-Anbieters zur improvisierten Krise wird — ohne zweiten Weg, ohne degradierten Betrieb und ohne jemanden, der weiß, wie lange stillstehen erlaubt ist — und dass der Hinweis von einem Kunden kommt statt von deinem eigenen System
- Übliche Einrichtung
- 4–8 Wochen
- Eingang
- eure KI-Systeme in Produktion, ihre Abhängigkeiten von Anbieter und Modell, eure Warteschlangen und euer heutiger Incident-Prozess
- Ausgang
- ein vereinbartes Wiederherstellungsziel pro Anwendungsfall, ein getesteter zweiter Weg, definierte Degradation statt weißem Bildschirm, Warteschlangen mit Wiederholungen und Kontingent pro System, Fehlerisolierung und eine Bereitschaft mit Handbuch und geprobten Störungen
- Kompatibel mit
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Kann sich verbinden mit
- Eure aktuellen Modellanbieter, ohne einen davon zu ersetzenEuer Model-Gateway oder Router, falls ihr ihn schon habtEure Nachrichtenwarteschlange und eure WiederholungsschichtEure Observability, eure Alarme und eure Bereitschaft so, wie sie heute funktionieren
- Was wir messen
- echte Verfügbarkeit pro Anwendungsfall, nicht die des Anbietersin der Probe gestoppte Erkennungs- und Wiederherstellungszeit% der Anfragen, die während einer Störung über den zweiten Weg bedient werdeneingereihte und nach einem Ausfall verlustfrei nachgearbeitete ArbeitKontingentverbrauch pro System gegen sein Limit
- Geeignet für
- Unternehmen mit KI bereits im kritischen Pfad eines echten Betriebs — Kundenservice, Fakturierung, Logistik, Back Office —, wo CIO, COO oder Head of AI beantworten müssen, wie lange das ausfallen darf, und es heute nicht können
- Nicht geeignet für
- wer einen internen Piloten ohne Nutzer und ohne Konsequenzen hat — da ist Hochverfügbarkeit Ausgabe ohne Ertrag, und das sagen wir vor dem Start — und wer den Modellanbieter wegen Qualität oder Kosten wechseln will: Das ist [Modelle in Produktion wählen und wechseln](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), eine andere Funktion
Häufig gestellte Fragen
Darin, dass Überwachung die Frage «was passiert gerade?» beantwortet und Verfügbarkeit die Frage «und was machen wir in der Zwischenzeit?». Die Überwachung instrumentiert, misst und alarmiert: Sie ist die Erkennungsschicht, und die ist ausgearbeitet unter KI in Produktion überwachen. Ohne sie merkst du gar nichts, sie ist also die Voraussetzung. Aber ein Alarm hält die Arbeit nicht am Laufen: Das machen der zweite Weg, der degradierte Betrieb, die Warteschlange, die den Stoß abfängt, und das vereinbarte Wiederherstellungsziel. Du kannst ein makelloses Dashboard haben und einen Betrieb, der eine halbe Stunde steht, während du in Echtzeit zusiehst, wie alles rot wird. Die Faustregel: Die Überwachung sagt dir, wann du handeln musst; die Verfügbarkeit entscheidet, was passiert, wenn du nicht rechtzeitig handelst.
Nein, und man sollte genau lesen, was dieses SLA eigentlich kauft. Die Service-Level-Vereinbarungen der Anbieter entschädigen mit Gutschriften auf die Rechnung, wenn sie das Ziel verfehlen: Du bekommst Geld zurück, nicht die Stunden, in denen dein Betrieb stand, und auch nicht die Kunden, die gegangen sind. Außerdem wird das Ziel am Dienst des Anbieters gemessen, nicht an deinem Anwendungsfall: Wenn dein Prozess an drei verketteten Aufrufen plus einer Datenbank hängt, ist deine echte Verfügbarkeit schlechter als die jedes einzelnen Teils — und das deckt kein Vertrag ab. Das SLA ist eine kommerzielle Zusage; Kontinuität ist eine Architekturentscheidung, die auf deiner Seite fällt. Was wir mit dem SLA sehr wohl tun: es benutzen. Seine Ziele und seine Vorankündigungen fließen in die Rechnung ein, was einen zweiten Weg braucht und was nicht.
Doch, deshalb wird nicht alles verdoppelt. Redundanz kommt nur dorthin, wo das mit dem Geschäft vereinbarte Ziel sie rechtfertigt, und genau deshalb ist diese Einigung der erste Schritt: damit man nicht am Ende Hochverfügbarkeit für den internen HR-Chat bezahlt. In den meisten Unternehmen, mit denen wir arbeiten, rechtfertigen ein oder zwei Anwendungsfälle einen zweiten Weg, und der Rest wird viel billiger gelöst — mit sauber definierter Degradation und einer Warteschlange, die nacharbeitet, wenn der Dienst zurück ist. Was tatsächlich fix kostet, ist die Disziplin — getrennte Schlüssel und Kontingente, Höchstzeiten, Schutzschalter —, und die zahlt man einmal und vermeidet damit die teuerste Störungsart überhaupt: die, die klein in einem unwichtigen System beginnt und das umwirft, das Rechnungen stellt.
Das, was wir vorher für diesen Anwendungsfall entschieden haben — und das ist die eigentliche Antwort: Es wird im Voraus entschieden, nicht in der Hitze. Die vier Modi, die fast alles abdecken, sind: automatisch auf den zweiten Weg wechseln, wenn der Qualitätsverlust vertretbar ist; mit dem deterministischen Teil des Prozesses antworten und nur das warten lassen, was das Modell braucht; die Arbeit mit einer dem Nutzer kommunizierten Frist einreihen und vollständig nacharbeiten, wenn der Dienst zurück ist; oder an die Bereitschaft eskalieren, wenn der Fall kritisch ist und kein Warten erlaubt. Jeder Anwendungsfall hat seinen eigenen Modus schriftlich, mit wer ihn auslöst und wie kommuniziert wird. Und es wird geprobt: Wir lösen den Ausfall in vereinbartem Takt absichtlich aus und stoppen die Wiederherstellung — denn ein Handbuch, das nie jemand ausgeführt hat, ist ein Dokument, keine Fähigkeit.
Wir betreiben es, denn Verfügbarkeit ist kein Liefergegenstand: Sie ist eine Funktion, die von allein verfällt, wenn niemand sie trägt. Du fügst einen Agenten hinzu und musst entscheiden, ob er in den Umfang gehört; der Anbieter ändert seine Ratenlimits und die Kontingente müssen nachjustiert werden; ein neues Modell erscheint und der zweite Weg von vor sechs Monaten ist nicht mehr die beste Option; die Bereitschaft wird umgestellt und im Handbuch stehen Namen, die es nicht mehr gibt. Der Bauteil sind die ersten vier bis acht Wochen; was danach kommt, ist die Bereitschaft, die Pflege der Wege, die Überwachung des Zustands deiner Anbieter und die regelmäßige Probe. Wenn du lieber willst, dass es dein Team betreibt, bauen wir es, dokumentieren es und schulen die Leute — und das sagen wir im Angebot klar, ohne dich per Design an uns zu binden. Der Rest des Katalogs dieser Funktion steht unter AI Operations.
Bauen wir es in deinem Betrieb?
Du hast das Problem benannt. Wir liefern die Lösung und lassen sie gemessen laufen.