KI-Ausfallsicherheit: Notbetrieb statt Stillstand

1. Wenn die KI stillsteht

Der 20. Oktober 2025 begann für Millionen Menschen mit Fehlermeldungen. In der AWS-Region US-East-1, einer der meistgenutzten Cloud-Regionen der Welt, hatte ein Fehler im automatischen Management des DNS, des Adressbuchs des Internets, einen leeren Adresseintrag für die zentrale Datenbank DynamoDB erzeugt. Die Störung zog sich über 14,5 Stunden und drei Wellen, ehe alle Dienste wieder normal liefen ^[1]. Die Störungsplattform Downdetector zählte an diesem Tag 6,5 Millionen Meldungen zu mehr als 1.000 betroffenen Websites und Diensten, von Snapchat über Airline-Apps bis zu Amazons eigenem Callcenter-Dienst, bei dem Anrufer im Besetztzeichen hingen ^[2].

Es blieb nicht bei diesem einen Tag. Neun Tage später legte eine fehlerhafte Konfigurationsänderung Microsofts globales Auslieferungsnetz Azure Front Door für gut acht Stunden teilweise lahm, mit Auswirkungen bis in Microsoft 365 hinein ^[3]. Knapp drei Wochen darauf erlebte Cloudflare, über dessen Netz ein erheblicher Teil des Internetverkehrs läuft, nach eigener Aussage den schwersten Ausfall seit 2019: Eine intern erzeugte Konfigurationsdatei überschritt ein festes Limit und brachte die zentrale Software zum Absturz ^[4]. Und die KI-Anbieter selbst? Im Dezember 2024 waren sämtliche OpenAI-Dienste über vier Stunden erheblich gestört oder ganz offline ^[5].

Bemerkenswert an dieser Serie: Kein einziger dieser Ausfälle war ein Cyberangriff. Es waren Routineänderungen, Softwarefehler, Automatisierung, die sich selbst im Weg stand, und das bei den technisch versiertesten und bestkapitalisierten Betreibern der Welt. Ausfälle sind kein Ausnahmezustand, sondern Betriebsstatistik: In der Jahresanalyse des Uptime Institute vom Mai 2026 beziffern 57 Prozent der Befragten die Kosten ihres letzten größeren Ausfalls auf mehr als 100.000 US-Dollar ^[6].

Zwei Einordnungen dazu, damit die Zahl nicht mehr trägt, als sie kann. Erstens die Erhebungsgruppe: Befragt werden Rechenzentrums- und IT-Infrastrukturbetreiber, nicht mittelständische Anwenderunternehmen. Die Größenordnung ist deshalb nicht eins zu eins übertragbar; übertragbar ist die Struktur des Befunds, dass Ausfallkosten weit überwiegend außerhalb der Technik entstehen. Zweitens die Gegenrichtung, die dieselbe Quelle ausweist: Die Ausfallhäufigkeit je Standort sinkt im fünften Jahr in Folge, und nur noch rund jeder zehnte Befragte berichtet von schwerwiegenden Folgen ^[6]. Wer daraus schließt, das Risiko erledige sich von selbst, übersieht die andere Bewegung derselben Analyse – Störungen der externen Infrastruktur, also genau der Ebene, auf der Ihre KI-Anbieter liegen, gewinnen an Gewicht und dauern länger.

Werfen Sie nun einen Blick in Ihr Notfallhandbuch. Stromausfall steht darin, Serverausfall, Cyberangriff, vielleicht Pandemie. In unserer Beratungspraxis ist der Ausfall produktiv genutzter KI-Anwendungen dort häufig noch nicht ausdrücklich erfasst, obwohl diese inzwischen E-Mails vorsortieren, Angebote entwerfen und Kundenanfragen beantworten. Genau diese Lücke behandelt dieses Papier. Die Frage ist nicht, ob Ihr KI-Anbieter wieder ausfällt. Die Frage ist, was Ihr Unternehmen in diesen Stunden tut.

2. Die unsichtbare Abhängigkeitskette

Hinter jeder KI-Funktion in Ihrem Unternehmen liegt eine Kette, die im Alltag niemand vollständig sieht. Sie beginnt bei Ihrer eigenen Integration und den benötigten Datenquellen, führt über Identität, Berechtigungen, Billing und Quoten zur Schnittstelle des Modellanbieters und weiter zu Region und Hyperscaler. Dazwischen können Auslieferungsnetze und DNS-Dienste wie Cloudflare liegen. Auch die verfügbare menschliche Kapazität gehört zur End-to-End-Sicht. Eine Störung in jedem dieser Bereiche kann denselben Prozesseffekt auslösen: Arbeit bleibt liegen, wird abgewiesen oder ist fachlich nicht mehr nutzbar. Der Notbetrieb sollte deshalb nach der Prozesswirkung aktiviert werden, nicht nach der zunächst vermuteten Fehlerquelle.

Diese Kette läuft am unteren Ende auf erstaunlich wenige Träger zu. Laut Synergy Research Group vereinen drei Cloud-Anbieter (AWS, Microsoft Azure, Google Cloud) im ersten Quartal 2026 zusammen 63 Prozent des weltweiten Cloud-Infrastrukturmarkts auf sich – 28, 21 und 14 Prozent ^[8]. Laut Menlo Ventures stehen Anthropic, OpenAI und Google zusammen für geschätzte 88 Prozent der Unternehmensnutzung von Sprachmodell-Schnittstellen, aufgeteilt in etwa 40, 27 und 21 Prozent. Die Erhebung von Ende 2025 basiert auf 495 US-amerikanischen Entscheidern und modellierten Marktschätzungen ^[9]. Beide Werte sind Schätzungen der jeweiligen Marktforscher, keine amtliche Marktzählung, und sie beschreiben den Weltmarkt, nicht den deutschen Mittelstand. Das Uptime Institute ordnet über neun Jahre Beobachtung rund zwei Drittel der öffentlich berichteten Ausfälle Drittanbietern wie Cloud-, Internet- und Telekommunikationskonzernen zu ^[13].

An dieser Stelle ist ein verbreitetes Missverständnis auszuräumen, das auch in Beratungsgesprächen häufig auftaucht. Lange galt die Faustregel: Wer einen Modellanbieter nutzt, hängt automatisch an dessen einem Rechenzentrumsbetreiber. Diese Kopplung löst sich gerade auf. Die OpenAI-Schnittstelle lief nach Unternehmensangaben lange exklusiv auf Azure; mit der Neuordnung der Partnerschaft Anfang 2025 endete diese Exklusivität, die enge Bindung an Microsoft blieb ^[10]. Anthropic nennt AWS weiterhin seinen primären Cloud- und Trainingspartner, bezieht aber zusätzlich Rechenleistung von Google ^[11], ^[12]. Und Synergy führt inzwischen OpenAI und Anthropic selbst unter den am schnellsten wachsenden Anbietern von Cloud-Infrastruktur ^[8]. Die Modellanbieter tun also genau das, was dieses Papier Ihnen empfiehlt: Sie verteilen ihre eigenen Abhängigkeiten.

Für Ihr Unternehmen ändert das die Form des Risikos, nicht seine Größe. Die Konzentration verschiebt sich von der Kopplung – ein Modell hängt an einem Rechenzentrum – zur reinen Marktkonzentration: wenige Anbieter, jeder für sich breiter abgesichert. Der Trost ist geringer, als er klingt. Erstens bleibt jeder einzelne Anbieter für den Prozess, der ihn nutzt, ein Single Point of Failure, und die schwerwiegendsten Störungen der letzten beiden Jahre waren bei den Modellanbietern hausgemacht, nicht von einem Hyperscaler durchgereicht (Kapitel 1). Zweitens ist die Verteilung eine Aussage über den Anbieter, nicht über Ihre Kette: Ihre Integration, Ihre Datenquellen, Ihre Quoten und Ihr Vertrag hängen weiterhin an genau einem Namen. Und drittens kennen Sie die Architektur Ihres Anbieters nicht und können sie nicht prüfen. Redundanz, die Sie nicht kontrollieren, ist keine Vorsorge, sondern eine Hoffnung.

Der Totalausfall ist nur die lauteste Störung. Hinzu kommen leise Varianten: Der Dienst antwortet langsam, lehnt Anfragen wegen Überlast ab (sogenannte Rate-Limits, also Mengenbegrenzungen pro Zeitfenster) oder liefert erhöhte Fehlerquoten. Im Juni 2025 scheiterte bei OpenAI in der Spitze rund jede dritte ChatGPT-Anfrage und jede vierte Schnittstellen-Anfrage, über 15 Stunden hinweg und ohne dass ein Totalausfall vorlag ^[7]. Anthropic wiederum dokumentierte im September 2025, wie drei überlappende Softwarefehler die Antwortqualität wochenlang verschlechterten, ohne dass irgendetwas „ausfiel“ ^[14]. Ein Blick auf die Statusseiten erdet die Erwartung: Am 27.07.2026 wies die Statusseite für die Claude-Schnittstelle über die zurückliegenden 90 Tage 99,53 Prozent Verfügbarkeit aus, rechnerisch rund zehn Stunden Beeinträchtigung in drei Monaten ^[15]. Das ist ein rollierender Messwert, der sich täglich verschiebt, und eine Momentaufnahme, keine dauerhafte Produkteigenschaft – prüfen Sie ihn für Ihren eigenen Anbieter selbst nach.

Dass dieses Konzentrationsrisiko kein theoretisches Konstrukt ist, haben die Aufseher der Finanzbranche längst festgestellt. Die EU-Verordnung DORA definiert das „IKT-Konzentrationsrisiko“ als eigenen Rechtsbegriff (Art. 3 Nr. 29) und verlangt von Finanzunternehmen eine Vorabbewertung, bevor sie Verträge über IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen schließen – ausdrücklich einschließlich der Frage, ob ein Anbieter „nicht ohne Weiteres ersetzbar“ ist (Art. 29) ^[16]. Die Europäische Zentralbank warnt vor Single-Point-of-Failure-Risiken durch wenige Modellanbieter ^[17], und der Europäische Ausschuss für Systemrisiken benennt in seiner Warnung zu systemischen Risiken durch Frontier-KI-Modelle (2026) ausdrücklich neue Abhängigkeits- und Konzentrationsrisiken ^[18]. Diese Pflichten gelten der Finanzbranche; der Befund dahinter gilt jedem Unternehmen, das seine Prozesse auf zwei, drei Anbieter stützt.

3. Der Montagmorgen ohne KI

Wie sich ein solcher Vormittag anfühlt, zeigt ein konstruiertes, aber typisches Beispiel, das uns durch den Rest dieses Papiers begleitet (alle Zahlen illustrativ).

Ein B2B-Ersatzteilhändler, 120 Mitarbeiter, setzt seit zehn Monaten einen KI-Assistenten im Kundenservice ein. Der Assistent liest eingehende E-Mails, ordnet sie Vorgängen zu, stuft die Dringlichkeit ein und legt Antwortentwürfe vor; acht Servicemitarbeiter arbeiten damit. Zwei Größen tragen das Beispiel und lassen sich auf Ihr Haus übertragen: Im Vormittagsbetrieb gehen rund 25 Anfragen pro Stunde ein, davon etwa vier dringende, und ein Vorgang kostet ohne KI-Unterstützung rund zwölf Minuten. Die Prozesse haben sich längst angepasst: Die manuelle Sichtung des Sammelpostfachs wurde abgeschafft, die Frühschicht beginnt direkt in der priorisierten Warteschlange.

An einem Montagmorgen um 7:40 Uhr fällt die Cloud-Region des Modellanbieters aus. Was im Unternehmen ankommt, ist kein Alarm. Es ist Stille. Die Tickets laufen weiter ein, aber nichts wird zugeordnet, nichts priorisiert, keine Entwürfe erscheinen. Die Frühschicht wundert sich über die leere Warteschlange und arbeitet Altfälle ab. Erst gegen 10:30 Uhr, fast drei Stunden später, fällt beim Blick ins Rohpostfach auf: Dort stauen sich rund 70 unbearbeitete Anfragen, gut ein Dutzend davon dringend. Darunter, eingeklemmt zwischen Newsletter-Abmeldungen, die dringendste des Tages – bei einem Stammkunden steht eine Fertigungslinie, weil ein Ersatzteil fehlt.

Jetzt beginnt die Improvisation. Zwei Mitarbeiter helfen sich mit ihren privaten KI-Konten und kopieren Kundenanfragen samt Namen und Auftragsdaten hinein – verständlich im Stress, aber damit verlassen Kundendaten das Unternehmen ohne Vertrag und ohne Protokoll; warum dieser improvisierte Notbetrieb ein eigenes Risiko ist, behandelt unser Whitepaper zur Schatten-KI. Ein Einzelfall ist das nicht: In Microsofts Work-Trend-Index-Befragung von 2024 gaben 78 Prozent der KI-Nutzer an, eigene KI-Werkzeuge zur Arbeit mitzubringen, in kleinen und mittleren Unternehmen sogar 80 Prozent ^[19]. Die Zahl stammt aus einer Erhebung des Herstellers und ist zwei Jahre alt; die Richtung deckt sich mit dem, was wir in Projekten sehen. Der Rest des Teams sortiert von Hand, jeder nach eigenem Ermessen. Niemand weiß, wer entscheiden darf, was jetzt gilt: Alle Anfragen beantworten oder nur dringende? Kunden informieren, oder wirkt das alarmistisch? Der Geschäftsführer erfährt von dem Vorfall beim Mittagessen.

Am frühen Nachmittag ist der Anbieter wieder da. Den Rückstau arbeitet das Team neben dem laufenden Betrieb ab: 70 Vorgänge zu je zwölf Minuten sind rund vierzehn Personenstunden, also etwa anderthalb zusätzliche Personentage, verteilt auf zwei Kalendertage. Der Schaden entstand dabei nicht in der ersten Minute des Ausfalls, sondern in den drei Stunden bis zur Entdeckung und in der ungeordneten Improvisation danach. Drei Dinge fehlten, keines davon Technik: eine Erkennung, die nicht vom Zufall abhängt. Eine Rangfolge, welche Arbeit im Notbetrieb zuerst zählt. Und eine benannte Zuständigkeit, die den Notfall ausruft und Regeln setzt.

Ein Einwand liegt nahe: An solchen Tagen ist „das halbe Internet“ betroffen, die Kunden sind nachsichtig. Das trägt nur kurz. Die stehende Fertigungslinie des Stammkunden wartet nicht, weil auch andere Dienste ausfallen, und der Rückstau wird durch Nachsicht nicht kleiner. Den Unterschied macht am Ende nicht der Anbieter, sondern ob das Unternehmen einen Plan hatte.

4. KI gehört in den Notfallplan

„Wie verhindern wir solche Ausfälle?“ ist die falsche Frage. Sie können sie nicht verhindern – die Ausfallserie aus Kapitel 1 traf die technisch reifsten Betreiber der Welt, ganz ohne Angreifer. Die richtige Frage lautet: Wie lange kommt jeder einzelne Geschäftsprozess ohne KI aus, und was tun wir, wenn es so weit ist?

Diese Frage ist nicht neu. Sie ist der Kern des Business Continuity Managements, wie es der BSI-Standard 200-4 beschreibt ^[20]; international entspricht ihm die Norm ISO 22301, die dieselbe Logik aus Analyse, Notbetrieb und Wiederanlauf für zertifizierbare Managementsysteme fasst ^[21]. Dort existiert auch die passende Messgröße längst: Die „geforderte Wiederanlaufzeit“ (englisch Recovery Time Objective, RTO) bezeichnet die Zeitspanne von der Unterbrechung des Prozesses bis zu dem Moment, in dem eine Notlösung den Betrieb übernimmt ^[22]. Für Stromausfall und ERP-Absturz haben viele Unternehmen diese Zielzeit festgelegt. Nach unserer Beratungserfahrung fehlt sie für produktiv genutzte KI-Anwendungen in vielen Notfallplänen noch.

Auf ein Detail dieser Definition kommt es bei KI besonders an: Die Uhr läuft ab der Unterbrechung, nicht ab dem Moment, in dem jemand sie bemerkt. Der Standard räumt zwar ein, dass sich der Eintritt eines Schadensereignisses in der Praxis nicht immer eindeutig bestimmen lässt und ersatzweise der Zeitpunkt des Erkennens herangezogen werden kann ^[22]. Genau deshalb ist die Erkennung keine Nebensache: Im Beispiel aus Kapitel 3 waren fast drei Stunden verstrichen, bevor überhaupt jemand von einem Notfall wusste. Wer sich eine Wiederanlaufzeit von einer Stunde vornimmt und vier Stunden für die Entdeckung braucht, hat keine Wiederanlaufzeit von einer Stunde – er hat gar keine.

Die Übertragung beginnt mit einer Inventur: Welche Prozesse nutzen KI, auch inoffiziell? Gerade die inoffizielle Nutzung (siehe die 78 Prozent aus Kapitel 3, erhoben 2024) gehört auf die Liste, denn auch sie fällt aus – nur merkt es dann erst recht niemand. Für jeden Anwendungsfall folgt die Business-Impact-Analyse in drei Zeithorizonten: Was passiert, wenn diese KI eine Stunde stillsteht? Einen Tag? Eine Woche? Der so sichtbare Schadensverlauf zeigt, welche Unterbrechung noch tolerierbar ist und bis wann der Notbetrieb spätestens greifen muss. Daraus legt das Unternehmen je Prozess die geforderte Wiederanlaufzeit (RTO) fest.

Für eine handhabbare interne Steuerung übersetzt dieses Whitepaper die BIA-Logik in einen eigenen Praxisrahmen mit vier Klassen. Die Klassen sind keine Kategorien des BSI-Standards und keine gesetzliche Einstufung. Komfort: Der Ausfall nervt, kostet aber wenig (interner Textassistent). Produktivitätskritisch: Arbeit dauert spürbar länger, Rückstau baut sich auf (E-Mail-Triage im Beispiel). Kundenkritisch: Kunden spüren den Ausfall direkt (Chat-Assistent im Web, zugesagte Reaktionszeiten). Prozesskritisch: Ein Kernprozess steht ganz, weil die KI ein zwingendes Glied ist (automatische Auftragserfassung ohne manuellen Zweig).

Eine Beobachtung macht diese Einstufung zur Daueraufgabe: Kritikalität wandert. Was als Komfort-Pilot startet, ist zwölf Monate später Prozessbestandteil. Puffer wurden abgebaut, Routinen verlernt, Stellen nicht nachbesetzt. Das Beispiel aus Kapitel 3 zeigt es: Die abgeschaffte manuelle Postfach-Sichtung war der eigentliche Grund, warum der Ausfall drei Stunden unbemerkt blieb. „Dann arbeiten wir eben wie früher“ ist nach einem Jahr KI-Betrieb keine erreichbare Rückfallebene mehr; der Weg zurück muss genauso geplant werden wie der Weg hinein. Als interne Mindestanforderung empfehlen wir: Für kunden- und prozesskritische Anwendungen wird ein dokumentierter, geübter Notbetrieb festgelegt, für produktivitätskritische mindestens eine Regelkarte. Für reine Komfort-Anwendungen genügt der Eintrag im Inventar. Die konkrete Schwelle bleibt eine Managemententscheidung aus der jeweiligen Prozesswirkung.

5. Notbetrieb in Stufen: Degradation statt Stillstand

Zwischen „alles läuft“ und „nichts geht“ liegt ein Raum, den die Cloud-Architektur seit Jahren systematisch nutzt. AWS formuliert das Prinzip der Graceful Degradation, des kontrollierten Leistungsabbaus, so: Komponenten sollen ihre Kernfunktion auch dann weiter erfüllen, wenn Abhängigkeiten ausfallen, notfalls mit veralteten Daten, Ersatzdaten oder ganz ohne Daten ^[24]. Dieses Denken lässt sich auf Geschäftsprozesse übertragen. Wer die Stufen vorher festlegt, verwandelt den Störfall von einem Chaos-Ereignis in eine Betriebsart, die man einschalten kann. Der naheliegende Reflex („dann nehmen wir eben zwei Anbieter“) greift dabei zu kurz, denn ein Zweitmodell ohne definierte Stufen, Zuständigkeiten und Übung ersetzt nur einen Störfall durch einen anderen. Redundanz gehört dorthin, wo das Kritikalitäts-Raster sie rechtfertigt – als Stufe im Plan, nicht als Ersatz für den Plan.

Worauf sich das folgende Modell stützt: nicht auf eine eigene Wirksamkeitsmessung, sondern auf das etablierte Verfahren des Business Continuity Managements nach BSI-Standard 200-4 und ISO 22301 ^[20], ^[21] und auf die dokumentierte Betriebspraxis großer Plattformbetreiber ^[24], ^[26]. Die Zahlen des Praxisbeispiels veranschaulichen den Ablauf; sie belegen ihn nicht.

Stufe 0 – Normalbetrieb. Die KI arbeitet, und im Hintergrund läuft die Überwachung mit (Kapitel 6). Schon hier entscheidet sich, ob Sie einen Ausfall nach Minuten bemerken oder nach Stunden.

Stufe 1 – Degradierter KI-Betrieb. Ein vorab eingerichtetes Ersatzmodell (anderer Anbieter oder andere Region) übernimmt nur einen getesteten, sicheren Funktionsumfang, im Beispiel die Dringlichkeits-Einstufung, nicht die Antwortentwürfe. Vor dem Störfall werden Mindestqualität, erlaubte Daten, zwingende menschliche Freigaben und verbotene Entscheidungen festgelegt. Unklare oder als dringend erkannte Fälle gehen im Beispiel immer an einen Mitarbeiter; automatische Kundenzusagen bleiben ausgeschaltet. Vier Dinge gehören dazu. Erstens die Kettenprüfung aus Kapitel 2: Ein Ersatzmodell beim selben Hyperscaler schützt nicht, wenn der Hyperscaler selbst betroffen ist. Zweitens ein kurzer Funktionstest mit festgelegter Qualitätsgrenze. Drittens die Vorarbeit: Vertrag, Auftragsverarbeitung und Datenschutzprüfung stehen vor dem Störfall; sonst ist Stufe 1 nur die organisierte Variante der privaten KI-Konten aus Kapitel 3. Der Umschaltpfad wird regelmäßig technisch durchgeschaltet. Viertens die Abgrenzung: Stufe 1 ist eine zeitlich begrenzte Notmaßnahme; wer dauerhaft auf ein anderes Modell wechseln will, braucht einen qualitätsgesicherten Wechselprozess mit eigener Testdisziplin.

Eine Voraussetzung, die oft übersehen wird: Stufe 1 setzt voraus, dass Sie den Modellanbieter überhaupt selbst wählen können. Das trifft auf eigene Integrationen zu. Nutzen Sie KI dagegen als Funktion in einer gekauften Software – im CRM, im Ticketsystem, im ERP –, entscheidet der Softwarehersteller über Modell und Region, und Ihr Notbetrieb beginnt faktisch bei Stufe 2. Dann verlagert sich die Vorarbeit in den Vertrag: Fragen Sie Ihren Hersteller nach seinem Ersatzpfad, nach der zugesagten Verfügbarkeit der KI-Funktion und danach, ob sich die KI-Funktion im Störfall abschalten lässt, ohne dass das Gesamtprodukt stehen bleibt.

Stufe 2 – Prozess-Notbetrieb ohne KI. Der Prozess läuft manuell weiter, nach vorbereiteten, bewusst einfachen Regeln: eine laminierte Regelkarte („Diese fünf Merkmale machen eine Anfrage dringend“), eine klare Priorisierung (dringende Fälle zuerst, Routine wartet), eine ehrliche automatische Eingangsbestätigung („Wir arbeiten aktuell mit längeren Antwortzeiten; dringende Anliegen erreichen uns unter …“). Die beste Quelle für diese Regelkarte sind die Mitarbeiter, die den Prozess vor der KI beherrscht haben – fragen Sie sie, solange sie noch im Haus sind. Vorab werden der sichere manuelle Durchsatz pro Stunde, der maximal tolerierbare Rückstau und die Höchstdauer dieser Stufe festgehalten. Reicht die Kapazität nicht, ist kontrollierte Leistungsreduzierung ehrlicher und sicherer als die Zusage, alles manuell fortzuführen.

Stufe 3 – Kontrollierte Einstellung. Überschreitet der Rückstau die vorab festgelegte Grenze, ist die manuelle Kapazität erschöpft oder endet die sichere Maximaldauer von Stufe 2, werden einzelne Leistungen geordnet ausgesetzt statt chaotisch: definierte Reihenfolge, aktive Kundeninformation, dokumentierter Beschluss.

Und zurück. Die Rückkehr wird ebenso vorab definiert: geordnetes Wiederanfahren, den Rückstau nach denselben Prioritäten abarbeiten wie im Notbetrieb, Rückkehrkriterien prüfen und kurz nachlesen (Was hat funktioniert? Was passt am Plan nicht?).

Drei Einordnungen zum Schluss. Selbst betreiben („dann hosten wir das Modell eben selbst“) ersetzt das Anbieterrisiko nur durch ein Eigenbetriebsrisiko: Kapazität, Sicherheit und Verfügbarkeit liegen dann komplett in Ihrer Verantwortung. Das ist keine kurzfristig verfügbare Notfallstrategie, sondern ein eigenes Betriebsprojekt. Zweitens hilft der Gesetzgeber beim Anbieterwechsel inzwischen mit: Der EU Data Act verpflichtet Anbieter von Datenverarbeitungsdiensten seit September 2025, den Wechsel zu einem anderen Anbieter vertraglich und technisch zu unterstützen und Wechselentgelte abzubauen ^[32]. Das macht den Zweitanbieter nicht überflüssig, senkt aber die Hürde, ihn vorzubereiten. Und drittens: Notbetrieb kostet Geld – ein zweiter Anbietervertrag, Pufferinfrastruktur, Übungszeit. Diese Kosten gehören bewusst budgetiert und ins Verhältnis zur Kritikalität gesetzt.

6. Verantwortung, Erkennung, Übung

Ein Notbetrieb, den niemand ausruft, existiert nicht. Die Stufen aus Kapitel 5 sind vor allem eine Organisations-, keine Technikaufgabe, mit vier Bausteinen.

Erkennung. Im Praxisbeispiel war der Kunde beinahe der Alarm. Das lässt sich mit geringem Aufwand abstellen: Statusseiten der Anbieter abonnieren und zusätzlich die eigene Funktion End-to-End überwachen. Vier Signalklassen gehören in den Plan: Timeouts und HTTP-5xx-Fehler, HTTP 429 beziehungsweise erschöpfte Quoten, die p95-Latenz samt wachsendem Rückstau sowie eine synthetische fachliche Plausibilitätsprüfung durch die eigene Integration und Datenkette. Die p95-Latenz ist dabei die Antwortzeit, die 95 von 100 Anfragen einhalten – sie zeigt die schleichende Verlangsamung, die ein Mittelwert verdeckt. Eine Statusseite misst den Endpunkt des Anbieters, nicht Ihre Funktion. Jedem Signal werden Schwelle, Stufe, Alarmweg und Rückkehrkriterium zugeordnet. Diesen Baustein setzen die wenigsten Fachbereiche allein um; planen Sie dafür Ihre IT oder Ihren Dienstleister ein.

Rollen. Im Störfall passen drei Festlegungen, jeweils mit Vertretung, auf eine Seite: Wer ruft den Störfall aus und wählt die Stufe? Wer informiert Kunden, und ab welcher Dauer? Wer entscheidet die Rückkehr in den Normalbetrieb? Vor dem Störfall bereiten Prozessverantwortlicher, Teamleitung, IT-Betrieb, Datenschutz oder Informationssicherheit und Einkauf beziehungsweise Vertragsmanagement den Plan gemeinsam vor. Wo ein Betriebsrat besteht, gehört er früh dazu und nicht als Nachtrag: Der Notbetrieb verändert Arbeitsinhalte, Reihenfolgen und unter Umständen Arbeitszeiten. Ohne benannte Entscheider bleibt der beste Plan Papier. Im Beispiel wusste drei Stunden lang niemand, wer entscheiden durfte.

Diese Liste beschreibt eine Vorbereitungsrunde, keine Stellenpläne. In einem Unternehmen mit 120 Mitarbeitern sind das häufig drei Personen, von denen eine extern ist – das genügt. Für den Störfall selbst reichen zwei Namen: eine Person, die den Störfall ausruft und die Stufe wählt, und eine Vertretung. Entscheidend ist nicht die Zahl der Rollen, sondern dass beide Namen vorab feststehen und beide wissen, dass sie entscheiden dürfen, ohne vorher zu fragen.

Der Blick in den Vertrag. Verlassen Sie sich dabei nicht auf die Service-Level-Vereinbarungen (SLAs) Ihrer Anbieter. Lesen Sie sie, um zu wissen, was sie nicht leisten. Die folgenden Angaben wurden am 27.07.2026 an der jeweiligen Primärquelle geprüft. Sie sind untereinander nicht vergleichbar – schon die Art der Zusage unterscheidet sich:

Diese Tabelle ist eine Momentaufnahme. Zwei der vier Zeilen haben sich innerhalb eines Jahres geändert – ein Beleg für die These dieses Kapitels: Was der Anbieter zusagt, ist keine Konstante, auf die sich ein Notfallplan stützen lässt. Prüfen Sie die für Sie geltende Fassung vor jeder Entscheidung selbst.

Bei den angeführten Microsoft- und AWS-Regelungen beginnen Gutschriften in den beschriebenen Stufen bei 10 Prozent der Monatsrechnung; erst bei deutlich geringerer gemessener Verfügbarkeit steigt der Satz ^[27], ^[28]. Microsoft formuliert, dass Gutschriften das vertragliche Rechtsmittel sind und Umsatzverluste, Betriebskosten oder indirekte Schäden nicht abdecken ^[27]. Bei Amazon Bedrock basiert die Messung auf HTTP-500-Fehlern in Request-Intervallen; verlangsamte Antworten und Mengenbegrenzungen fallen nicht automatisch darunter ^[28]. Kurz: Ein SLA ist primär eine Preisnachlass-Mechanik, kein vollständiger Risikotransfer. Ihre Prozessverfügbarkeit hängt von der gesamten Kette ab. Die SLA jedes einzelnen Dienstes beschreibt deshalb noch nicht die End-to-End-Verfügbarkeit Ihres Geschäftsprozesses; gemeinsame Ursachen und redundante Pfade lassen sich nicht durch eine einfache Produktformel abbilden.

Die wichtigere Rechnung machen Sie an dieser Stelle aber nicht mit Ihrem Anbieter, sondern mit sich selbst. Legen Sie neben das SLA Ihres Anbieters die Zusagen, die Sie Ihren Kunden gegeben haben: zugesagte Reaktionszeiten in Rahmenverträgen, Servicefenster, in Einzelfällen Vertragsstrafen. Dort entsteht die Asymmetrie, um die es wirklich geht – Sie schulden Ihrem Kunden eine Reaktion innerhalb weniger Stunden, Ihr Anbieter schuldet Ihnen im Störfall eine Gutschrift auf die Monatsrechnung. Diese Lücke schließt kein Vertrag, sondern nur ein Notbetrieb, der Ihre eigenen Zusagen einhalten kann. Für kunden- und prozesskritische Anwendungen heißt das konkret: Gleichen Sie die zugesagte Reaktionszeit mit dem ab, was Ihre Stufe 2 im manuellen Durchsatz tatsächlich schafft. Passt beides nicht zusammen, ist entweder der Notbetrieb zu knapp bemessen oder die Zusage zu großzügig.

Übung. Ein vergleichsweise kostengünstiger Einstieg ist ein halbtägiger Startworkshop mit Planspiel: „Die KI ist weg – ab jetzt.“ Google dokumentiert aus jahrelanger Betriebspraxis, dass Notfall- und Degradationspfade, die nicht regelmäßig geübt werden, im Ernstfall versagen ^[26]. Die Ausfallstatistik stützt das von der anderen Seite: Knapp 40 Prozent der befragten Organisationen hatten binnen drei Jahren einen größeren Ausfall durch menschliches Versagen, und 85 Prozent dieser Vorfälle gehen auf nicht befolgte oder mangelhafte Prozesse zurück, nicht auf fehlendes Können ^[13]. Die Zahl belegt, wo das Problem sitzt – dass ausgerechnet Üben die beste Abhilfe ist, folgt aus der Betriebserfahrung in ^[26], nicht aus dieser Statistik.

Im konstruierten Praxisbeispiel vergehen beim nächsten Störfall mit Kritikalitäts-Raster, Stufenplan, Monitoring und Übung rund 20 Minuten zwischen Störungsbeginn und laufendem Notbetrieb – statt der drei Stunden, die beim ersten Mal allein bis zur Entdeckung vergingen. Kunden mit dringenden Anliegen bekommen weiter eine Antwort, Routineanfragen warten sichtbar länger. Diese Zahlen veranschaulichen den möglichen Ablauf, sie sind weder Benchmark noch Wirksamkeitsnachweis. Der Händler weitet den Assistenten anschließend auf die Angebotserstellung aus, diesmal mit Notbetriebskapitel ab dem ersten Tag.

7. Entscheidung und nächste Schritte

KI-Ausfallsicherheit muss nicht als Großprojekt beginnen. Sie ergänzt den bestehenden Notfallplan um die produktiven KI-Abhängigkeiten. Eine erste belastbare Fassung lässt sich in einem halbtägigen Startworkshop anlegen und danach je kritischem Prozess technisch und organisatorisch prüfen. Sechs Schritte führen dorthin:

1. Inventar erstellen: In einem halbtägigen Startworkshop erfassen Fachbereiche und IT gemeinsam, welche Prozesse KI offiziell und inoffiziell nutzen; die Detailprüfung folgt anschließend.
2. Kritikalität bewerten: je Anwendungsfall mit der Drei-Horizonte-Frage den Schadensverlauf beschreiben, die interne Klasse festhalten und daraus die RTO ableiten (Kapitel 4).
3. Notbetriebsstufen definieren: für kunden- und prozesskritische Anwendungen die Stufen 1–3 mit sicherem Funktionsumfang, manueller Kapazität, Triggern und Rückkehrkriterien beschreiben; für produktivitätskritische mindestens die Regelkarte (Kapitel 5).
4. Erkennung einrichten: Statusseiten abonnieren sowie Timeouts/5xx, 429/Quoten, p95-Latenz und Rückstau und fachliche Funktionsprüfungen mit Alarmweg überwachen (Kapitel 6). Dies ist der einzige Schritt, der in der Regel IT-Unterstützung braucht.
5. Rollen benennen: Ausrufen, Kundenkommunikation und Rückkehr je einem Namen plus Vertretung zuordnen; Prozessverantwortlichen, IT, Datenschutz oder Informationssicherheit und Vertragsmanagement in die Vorbereitung holen.
6. Üben: mit einem halbtägigen Planspiel als Startformat die Schwellen und Rollen prüfen, danach den Plan anpassen und den nächsten Termin festlegen.

Wenn Ihnen diese Liste bekannt vorkommt: Das ist Absicht. Es ist dieselbe Disziplin, mit der Ihr Unternehmen Stromausfälle, ERP-Störungen und Telefonanlagen-Ausfälle beherrscht – angewandt auf eine Abhängigkeit, die sich schneller in Ihre Prozesse gearbeitet hat, als Ihre Notfallplanung nachwachsen konnte. Ausfälle der KI-Anbieter werden kommen; die Ausfallserie des Jahres 2025 war dafür nur die bisher deutlichste Erinnerung. Ob daraus ein teurer Kontrollverlust oder ein beherrschbarer Störfall wird, entscheidet sich nicht erst beim Anbieter, sondern im vorbereiteten Notbetrieb Ihres Unternehmens.

Quellen