Too big to fail: gdy trzy firmy AI padną, pada tysiące biznesów

W 2024 roku OpenAI doświadczyło kilku poważnych awarii — wielogodzinnych przerw w dostępie do API i ChatGPT (szczegóły na status.openai.com/history). Kilka tysięcy aplikacji zbudowanych na tym API przestało działać. Biznesy, które zintegrowały asystentów AI do obsługi klienta, automation workflow, generowania treści — wszystkie jednocześnie. Jedyna firma odpowiedzialna: OpenAI.

Dla porównania: AWS us-east-1 outage w 2021 wyłączył na kilka godzin setki tysięcy serwisów. Świat IT mówił o tym miesiącami i potem zaczął serio rozmawiać o multi-region deploymentach.

AI dopiero zbliża się do tego momentu. I jest kilka powodów, dla których analogia z bankami z 2008 jest trafniejsza niż analogia z AWS.

Koncentracja rynku

Trzy firmy — OpenAI, Anthropic, Google — kontrolują zdecydowaną większość enterprise API AI używanego globalnie. Dokładne dane rynkowe są trudne do weryfikacji (żadna z firm nie publikuje pełnych danych o API usage), ale analitycy rynku (Gartner, IDC) wskazują na wyraźnie oligopolistyczną strukturę, gdzie top 3 providery dominują segment enterprise AI API. Pozostała część rynku jest rozłożona między Amazon Bedrock, Azure AI (który i tak w dużej mierze reseluje OpenAI), Cohere, Mistral i kilkanaście mniejszych graczy.

W kontekście LLM-as-a-service do zadań enterprise (generowanie, analiza, agenci): koncentracja jest jeszcze wyższa.

Dlaczego to gorsze niż AWS

AWS us-east-1 outage dotknął aplikacje infrastrukturalnie — strony przestały działać. Ale w większości przypadków awaria nie zmieniła procesów decyzyjnych organizacji. Dane były bezpieczne, tylko niedostępne.

Awaria kluczowego AI providera dotknęłaby organizacje inaczej. Wyobraź sobie organizację, która:

• Używa AI do triagowania supportu klientów (tysiące ticketów dziennie)
• Używa AI do wstępnej oceny wniosków (kredytowych, ubezpieczeniowych, rekrutacyjnych)
• Używa AI do generowania i weryfikacji dokumentów prawnych
• Używa AI agentów do koordynacji operacji supply chain

Wielogodzinna awaria nie oznacza “strona nie działa”. Oznacza “procesy decyzyjne organizacji są sparaliżowane”. To jest inny poziom zależności niż infrastruktura hostingowa.

Analogia z bankami 2008

“Too big to fail” z kryzysu finansowego 2008 miało dwie warstwy. Pierwsza: duże banki były ze sobą tak powiązane, że upadek jednego powodował kaskadę. Druga: były tak wbudowane w infrastrukturę finansową gospodarki, że ich upadek miałby konsekwencje poza sektorem finansowym.

AI providers zbliżają się do analogicznej pozycji w “poznawczej infrastrukturze” gospodarki. Nie chodzi o to że OpenAI “upadnie” — chodzi o to że:

• Koncentracja bez regulacji — banki miały regulatorów, stress testy, wymogi kapitałowe. AI providers nie mają nic analogicznego w kontekście resilience i systemowego ryzyka
• Powiązania ukryte — organizacje budują na AI API nie analizując co się stanie gdy API padnie; resilience planning for AI jest wciąż niszowy
• Brak substytutów — jeśli twoja aplikacja jest zoptymalizowana dla GPT-4, migracja na Anthropic czy Gemini zajmuje tygodnie, nie godziny

Historia AWS jako template

Kiedy AWS usunął Parler z platform w 2021, środowisko tech uświadomiło sobie że koncentracja infry cloudowej ma wymiar polityczny i geopolityczny. Kiedy us-east-1 padło wielokrotnie, organizacje zaczęły inwestować w multi-region, multi-cloud.

Dla AI nie ma jeszcze analogicznego “przebudzenia”. Większość organizacji wdrażających AI nie ma planu na “co robimy gdy nasz AI provider jest niedostępny przez 8 godzin”. Niewielu zastanawia się nad “co robimy gdy provider zmieni politykę użytkowania w sposób który nas dotyka”.

Co zrobić jako organizacja

Nie jest to wezwanie do paniki — to wezwanie do myślenia o ryzyku:

• Zidentyfikuj krytyczne zależności — które procesy biznesowe są zależne od zewnętrznych AI API i co jest ich impact gdy API nie działa
• Graceful degradation — aplikacje AI powinny działać w degraded mode bez AI (wolniej, z manual fallback) — to samo co powinnaś robić z każdą zewnętrzną zależnością
• Multi-provider testing — regularne testy czy aplikacja działa z alternatywnym providerem; to nie musi być pełna migracja, to ma być wiedza
• SLA scrutiny — większość AI API providers ma SLA które są znacznie słabsze niż enterprise cloud infra; wiedz na co się zgadzasz
• On-premise open source — dla krytycznych procesów rozważ open source modele (Llama, Mistral) na własnej infrastrukturze jako backup

Regulatorzy dopiero zaczynają patrzeć na systemowe ryzyko AI koncentracji. EU AI Act dotyka tego marginalnie. To jest pole, gdzie normalizacja regulacyjna prawdopodobnie przyjdzie — pytanie czy nastąpi przed czy po dużym incydencie.