Drei KI-Anbieter, ein Ausfall: Was der 3. September über unsere digitale Monokultur verrät

Am Donnerstag, dem 3. September 2026, fielen innerhalb von 90 Minuten ChatGPT, Claude und Grok aus. Zuerst Grok, dann Claude, dann ChatGPT. Für rund drei Stunden waren die drei meistgenutzten KI-Dienste der westlichen Welt ganz oder teilweise nicht erreichbar.

Bei Anthropic erholten sich die meisten Modelle nach rund einer Stunde, die Opus-Modelle blieben jedoch deutlich länger gestört. OpenAI sprach von einem Routing-Fehler, Anthropic von einem Infrastrukturproblem, xAI von einem Ausfall im Rechenzentrum in Memphis. Eine gemeinsame Ursache hat keiner der drei Anbieter bestätigt. Und genau das ist der Punkt, den man nicht ignorieren sollte.

Die Korrelation, die niemand erklären kann (oder will)

Drei Unternehmen, drei getrennte Serving-Stacks, drei unabhängige Post-Mortems, die sich in nichts aufeinander beziehen. Gleichzeitig verzeichnete Microsoft Azure im selben Zeitfenster erhöhte Störungsmeldungen, und mehrere Medien führen den Vorfall auf einen regionalen Ausfall in der Azure-Region East US zurück. SpaceX, das Infrastruktur mit xAI teilt, entschuldigte sich öffentlich und erwähnte, dass auch "Compute-Partner" betroffen gewesen seien. Google Gemini, das auf Google Cloud läuft, blieb jedoch weitgehend stabil.

Man muss kein Verschwörungstheoretiker sein, um hier ein Muster zu sehen. Man muss nur die Lieferkette kennen. OpenAI läuft auf Azure. Anthropic hat große Teile seiner Kapazität bei Azure und AWS eingekauft. xAI teilt sich Rechenzentren mit SpaceX und bezieht ebenfalls Hyperscaler-Kapazität. Die drei Unternhemen sind verschieden, ihre Infrastruktur darunter ist es nicht.

Dass keiner der Anbieter den Zusammenhang benennt, ist kein Zufall. Wer zugibt, dass sein Dienst an der Verfügbarkeit eines fremden Rechenzentrums hängt, gibt zu, dass er nicht souverän über sein eigenes Produkt verfügt. Das ist im Marketing schwer zu verkaufen. In der Risikoanalyse ist es aber die einzig relevante Information.

Failover in die gleiche Grube

Viele Unternehmen weltweit haben in den letzten zwei Jahren KI in ihre Prozesse integriert und dabei brav befolgt, was jede Resilienzberatung empfiehlt: einen zweiten Anbieter als Ausfallsicherung. Claude als Primärmodell, GPT als Rückfallebene, vielleicht noch Grok oder Gemini als dritte Option. Auf dem Papier ist das Multi-Vendor.

Am 3. September haben diese Unternehmen gelernt, dass ihre drei Rückfallebenen im selben Zeitfenster dunkel werden können. Multi-Vendor auf der Modellebene ist wertlos, wenn darunter Single-Vendor auf der Infrastrukturebene steht. Das Konzentrationsrisiko sitzt nicht bei den KI-Anbietern, sondern eine Schicht tiefer, und dort hat es kaum jemand ins Risikoregister geschrieben.

Die Regulatorik kennt dieses Problem übrigens längst. DORA verlangt in Art. 28 und 29 ausdrücklich die Bewertung von IKT-Konzentrationsrisiken, und zwar nicht nur beim direkten Dienstleister, sondern entlang der Unterauftragskette. Art. 30 verlangt vertragliche Regelungen zu Unterauftragnehmern. NIS2 fordert in Art. 21 Abs. 2 lit. d, in Österreich umgesetzt in § 32 NISG 2026, die Sicherheit der Lieferkette einschließlich der Beziehungen zu Dienstleistern. ISO 27001:2022 adressiert das Thema in den Controls A.5.19 bis A.5.22 und in A.5.30 zur IKT-Bereitschaft für die Geschäftskontinuität. Die Anforderungen sind da. Was fehlt, ist der Blick durch die Anbieterschicht hindurch auf das, was darunter liegt.

Monokultur ist kein Bug, sondern das Geschäftsmodell

Der Vorfall ist kein Einzelfall, sondern ein weiteres Kapitel einer Geschichte, die sich seit Jahren wiederholt. Im Juli 2024 legte ein fehlerhaftes CrowdStrike-Update weltweit Flughäfen, Krankenhäuser und Banken lahm, weil ein einziger Endpoint-Agent auf einem einzigen Betriebssystem ausreichend verbreitet war, um eine globale Störung auszulösen. Im Oktober 2025 riss ein Ausfall in der AWS-Region us-east-1 tausende Dienste mit sich, und im laufenden Jahr stand dieselbe Region erneut über einen Tag lang still.

Auf der Virtualisierungsebene sieht es nicht besser aus. Die Übernahme von VMware durch Broadcom hat gezeigt, was passiert, wenn ein Hypervisor de facto Industriestandard ist: Lizenzmodelle werden über Nacht umgestellt, Preise vervielfachen sich, und die betroffenen Unternehmen haben keine realistische Wahl, weil ihre gesamte Betriebsplattform auf einer Technologie aufsetzt, die sich nicht in Wochen austauschen lässt. Das ist kein Sicherheitsvorfall im klassischen Sinn, aber es ist exakt dasselbe Risiko: Abhängigkeit von einem Anbieter, der die Bedingungen einseitig diktieren kann.

Ob Hyperscaler, Hypervisor oder Sprachmodell, das Muster ist immer gleich. Standardisierung senkt Kosten und Komplexität, und genau diese Standardisierung erzeugt die Monokultur, in der ein einziger Fehler alles trifft. In der Landwirtschaft hat man das vor hundert Jahren verstanden. In der IT tun wir so, als wäre der Effizienzgewinn kostenlos.

Was digitale Souveränität hier konkret bedeutet

Digitale Souveränität wird oft als politischer Begriff missverstanden, als Frage nach europäischen Clouds und Datenlokalisierung. Das ist ein Teil davon, aber nicht der Kern. Souveränität bedeutet, handlungsfähig zu bleiben, wenn ein Anbieter ausfällt, die Bedingungen ändert oder aus geopolitischen Gründen nicht mehr verfügbar ist. Das ist eine Frage der Architektur, nicht der Gesinnung.

Für den Einsatz von KI heißt das:

• Die Lieferkette muss bis zur Infrastruktur hinunter bekannt sein. Wer nicht weiß, in welcher Cloud-Region sein KI-Anbieter serviert, kann kein Konzentrationsrisiko bewerten. Diese Information gehört in jede Anbieterbewertung und in jedes Register nach DORA Art. 28 Abs. 3.
• Redundanz muss auf der richtigen Ebene stattfinden. Zwei Modelle beim selben Hyperscaler sind keine Redundanz. Ein Modell in Azure, eines in Google Cloud und ein lokal betriebenes Open-Weight-Modell als Notbetrieb sind eine. Wobei auch diese Aufstellung nur die technische Ebene abdeckt. Azure und Google Cloud fallen zwar nicht gleichzeitig aus, aber sie unterliegen derselben Rechtsordnung. Der CLOUD Act greift unabhängig davon, in welcher Region die Daten liegen, und die Sovereign-Cloud-Angebote der US-Anbieter reduzieren diese Exposition, schließen sie aber nicht aus. Das räumen die Anbieter in ihren eigenen Unterlagen mittlerweile ein. Dazu kommt, was 2026 kaum noch jemand als theoretisch abtut: Exportkontrollen, Sanktionsregime und Zollkonflikte können die Verfügbarkeit von US-Diensten in Europa zur politischen Verhandlungsmasse machen, und das Data Privacy Framework steht als Rechtsgrundlage für die Übermittlung personenbezogener Daten auf demselben wackeligen Fundament wie seine beiden Vorgänger. Ein technischer Ausfall dauert drei Stunden. Eine politische Entscheidung dauert so lange, bis sie zurückgenommen wird. Redundanz muss deshalb auch die Ebene der Jurisdiktion abdecken. Zwei US-Hyperscaler sind gegen einen Routing-Fehler abgesichert, nicht gegen eine Verfügung aus Washington. Wer diese Ebene mitdenkt, kommt zu einer anderen Aufstellung: ein Spitzenmodell bei einem US-Anbieter für die Qualität, ein europäisch betriebenes Modell, etwa Mistral bei einem Anbieter mit europäischer Muttergesellschaft, für die rechtliche Unabhängigkeit, und ein lokal betriebenes Open-Weight-Modell als Notbetrieb, das von keinem der beiden abhängt. Nur die letzte Stufe ist gegen alle drei Szenarien gleichzeitig abgesichert: gegen den Ausfall, gegen den Anbieterwechsel der Geschäftsbedingungen und gegen die Politik.
• Kritische Prozesse brauchen eine Betriebsvariante ohne Cloud-KI. Wer Kundenservice, Dokumentenverarbeitung oder Codepipelines vollständig an externe Modelle bindet, muss beantworten können, was am Tag X passiert. Quantisierte Open-Weight-Modelle auf eigener Hardware liefern nicht die Qualität der Spitzenmodelle, aber sie liefern überhaupt etwas, wenn die Spitzenmodelle schweigen.
• Und schließlich: Die Frage nach der Souveränität muss vor der Beschaffung gestellt werden, nicht nach dem ersten Ausfall. Ein Anbieter, der seine Abhängigkeiten nicht offenlegt, hat sie in der Regel nicht im Griff.

Fazit

Der 3. September war noch ein dreistündiger Ausfall mit überschaubarem Schaden. Er war auch eine kostenlose Übung dafür, was passiert, wenn die Störung länger dauert, gezielt herbeigeführt wird oder mit einer politischen Entscheidung zusammenfällt. Die Unternehmen, die daraus lernen, werden ihre Architektur überdenken. Die anderen werden beim nächsten Mal wieder auf Downdetector nachsehen, ob es an ihnen liegt.

Es liegt nicht an ihnen. Es liegt am Fundament, das sie nicht angeschaut haben.

Zur Faktenlage: OpenAI nannte einen Routing-Fehler ab 7:43 Uhr PT mit Behebung um 8:17 Uhr PT. Anthropic sprach von einem Infrastrukturproblem und wies auf der Statusseite eine Dauer von drei Stunden und sechs Minuten aus. xAI führte den Ausfall auf sein Rechenzentrum in Memphis zurück. Der Zusammenhang mit Azure ist eine Schlussfolgerung mehrerer Medien aus der zeitlichen Korrelation und wurde von keinem der Anbieter bestätigt. Sollten nachträglich Post-Mortems erscheinen, wird dieser Beitrag ergänzt.