Trzej Dostawcy AI, Jedno Pięciogodzinne Okno
ChatGPT, Claude i Grok padły w mniej więcej tym samym, pięciogodzinnym oknie czasowym 3 września 2026 roku - zbieg okoliczności na tyle rzadki, by w ciągu kilku godzin przyciągnąć uwagę dziennikarzy. Strona statusu OpenAI przypisała awarię błędowi routingu, który zaczął się około 7:43 czasu PT; poprawkę wdrożono i monitorowano od około 8:17 czasu PT, a problem z podwyższonym poziomem błędów w ChatGPT i Codex naprawiono we wczesnych godzinach popołudniowych.
Strona statusu Anthropic odnotowała częściową awarię, która zaczęła się około 9:40 do 9:41 czasu ET i dotknęła Claude.ai, API Claude, Claude Code oraz Claude Cowork, przy czym wszystkie wymienione modele znów działały około 12:16 do 12:27 czasu ET. Grok od xAI nie działał w sieci, w aplikacji X, na iOS, na Androidzie i w dwóch amerykańskich regionach API od około 9:30 do 13:07 czasu ET, a xAI jako przyczynę wskazało problem w swoim centrum obliczeniowym w Memphis w stanie Tennessee.
Co Każda Firma Podała Jako Przyczynę
OpenAI, Anthropic i xAI wskazały każda osobną, niepowiązaną przyczynę techniczną własnej awarii, a nie jedną wspólną usterkę dotyczącą wszystkich trzech. Przyczyną u OpenAI był błąd routingu wewnątrz własnych systemów firmy, a niektórzy użytkownicy zdalnego sterowania Codex musieli ponownie sparować swoje urządzenie mobilne po przywróceniu usługi.
Anthropic nie opublikował szczegółowej analizy przyczyny źródłowej, ograniczając się do opisu problemu infrastrukturalnego, który przed naprawą dotknął kilku modeli, w tym Fable/Mythos 5.1, Fable/Mythos 5, Opus 5, Opus 4.8 i Opus 4.6. xAI była z tej trójki najbardziej konkretna, wskazując problem we własnym centrum obliczeniowym w Memphis w stanie Tennessee, a nie na wspólnej warstwie chmurowej.
Pytanie Dziennikarzy: Czy Azure Jest Wspólnym Ogniwem?
Dziennikarze The Register, 9to5Google i Decrypt pytali, czy Microsoft Azure był wspólnym ogniwem stojącym za wszystkimi trzema awariami, ponieważ OpenAI, Anthropic i xAI opierają się każde, między innymi, na Azure, a Microsoft odpowiedział wprost, że Azure nie było przyczyną. To zaprzeczenie, w połączeniu z trzema oddzielnie zgłoszonymi przyczynami, oznacza, że awarie z 3 września nie mają potwierdzonej wspólnej przyczyny źródłowej, a jedynie otwarte pytanie, które postawili dziennikarze i które odrzucił Microsoft.
Gemini od Google nie zgłosił żadnego incydentu w tym samym oknie czasowym, co samo w sobie jest wymowne: cokolwiek połączyło ChatGPT, Claude i Grok, nie objęło każdego dużego dostawcy AI działającego tego dnia. Ten szczegół wskazuje albo na zbieg okoliczności, albo na węższą wspólną zależność, która nie została podana publicznie.
Dlaczego 'Wielu Dostawców AI' Nie Jest Automatycznie Strategią Odporności
Używanie ChatGPT obok Claude lub Grok nie kupuje automatycznie firmie odporności infrastrukturalnej, ponieważ różnorodność dostawców na poziomie marki AI może wciąż opierać się poniżej na wspólnych zależnościach chmurowych. Od dwóch lat firmom i instytucjom publicznym w UE doradza się rozkładanie obciążeń na wielu dostawców AI jako ochronę przed uzależnieniem od jednego dostawcy i ryzykiem awarii - pomysł, który dotyka też rozporządzenia o operacyjnej odporności cyfrowej (DORA) oraz obowiązków NIS2 dotyczących ryzyka koncentracji u krytycznych dostawców zewnętrznych ICT.
Wydarzenie z 3 września jest konkretnym, datowanym testem tej rady. OpenAI, Anthropic i xAI zgłosiły tym razem osobne przyczyny, ale wszyscy trzej opierają się między innymi na Microsoft Azure, a awarie i tak wpadły w to samo, pięciogodzinne okno czasowe - dokładnie taki rodzaj jednoczesności, jakiego naprawdę niezależny zestaw dostawców nie powinien wytwarzać rutynowo.
| Dostawca | Początek awarii | Koniec awarii | Podana przyczyna |
|---|---|---|---|
| OpenAI (ChatGPT, Codex) | ~7:43 PT | Wczesne popołudnie PT | Błąd routingu |
| Anthropic (Claude) | ~9:40-9:41 ET | ~12:16-12:27 ET | Nieokreślony problem infrastrukturalny |
| xAI (Grok) | ~9:30 ET | ~13:07 ET | Problem w centrum obliczeniowym w Memphis, Tennessee |
Co Powinien Śledzić Rejestr Ryzyka Koncentracji Zgodny z DORA
Rejestr ryzyka koncentracji ICT zgodny z DORA powinien mapować ryzyko na warstwie chmurowej leżącej poniżej marki każdego dostawcy AI, a nie tylko u samego dostawcy AI. Wpisanie OpenAI, Anthropic i trzeciego dostawcy jako trzech niezależnych krytycznych stron trzecich ICT może zaniżać rzeczywiste ryzyko koncentracji, jeśli dwóch lub trzech z nich działa na tym samym hiperskalerze - w tym przypadku na Azure, między innymi dostawcami, u wszystkich trzech firm zaangażowanych 3 września.
Praktycznym krokiem dla firmy z sektora finansowego lub operatora infrastruktury krytycznej jest zapytanie każdego dostawcy AI, jacy dostawcy chmury i jakie regiony stoją pod jego usługą, a następnie zapisanie tej odpowiedzi obok nazwy dostawcy na mapie ryzyka koncentracji. Unijni regulatorzy finansowi oceniający ryzyko stron trzecich ICT na podstawie DORA i NIS2 najprawdopodobniej będą oczekiwać właśnie takiego poziomu szczegółowości, teraz gdy incydent taki jak ten upublicznił to pytanie.
Czytaj dalej: Gwarancja Nvidii Dla OpenAI Spadła Do 120 Mld | Twój Dostawca AI Właśnie Dostał List Z Brukseli
