Overlappende AI-nedbrud: Det ved vi om ChatGPT, Claude og Grok

Flere førende AI-tjenester svigtede med få timers mellemrum den 3. september 2026. Brugere havde problemer med OpenAIs ChatGPT og Codex, Anthropics Claude-produkter og xAI's Grok. Men den bedst underbyggede konklusion er mere snæver end, at "hele AI-internettet gik ned": De offentligt tilgængelige oplysninger beskriver forskellige hændelser med forskellige oplyste årsager – ikke ét dokumenteret fælles nedbrud. 334148

Hvad skete der – og hvornår?

Tidslinjen er ikke helt entydig, fordi selskaberne og eksterne overvågningstjenester angav statusopdateringer på forskellige tidspunkter. Men de rapporterede tidsrum forklarer, hvorfor brugerne oplevede problemerne som samtidige.

• Grok: xAI's hændelseslog blev rapporteret til at starte kl. 13.30 UTC og slutte kl. 17.05 UTC. xAI knyttede senere forstyrrelsen til et nedbrud på selskabets datacenteranlæg i Memphis. 48
• Claude: Anthropic meldte om forhøjede fejl i forespørgsler på tværs af Claude-modeller og produkter, herunder Claude.ai, API'et, Claude Code og Claude Cowork. Hændelsen var løst kl. 16.16 UTC efter omtrent tre timers forstyrrelse. 104148
• ChatGPT og Codex: OpenAI oplyste, at en intern routingfejl fra kl. 07.43 Pacific Time gjorde ChatGPT og Codex utilgængelige for nogle brugere på tværs af platforme. En løsning var implementeret omkring kl. 08.17 Pacific Time og blev derefter overvåget. 41

Brugere meldte blandt andet om loginfejl, utilgængelige chats, mislykkede prompts og problemer med app eller webadgang. Downdetector-baseret rapportering registrerede over 43.000 fejlmeldinger om ChatGPT omkring kl. 20.00 indisk tid, mens Claudes forstyrrelse ramte både almindelige brugere og udviklernes værktøjer. 2339

Hvad sagde selskaberne om årsagerne?

De offentliggjorte forklaringer er vigtige, fordi de taler imod at betragte hændelsen som ét bekræftet fælles nedbrud.

OpenAI: En talsperson beskrev problemerne med ChatGPT og Codex som en routingfejl i OpenAIs egen infrastruktur. 41

Anthropic: Claudes offentlige statusrapportering beskrev problemet som en infrastrukturfejl og bekræftede forhøjede fejl på tværs af flere modeller og tjenester. Det foreliggende materiale angiver ikke, hvilken konkret komponent der fejlede. 3948

xAI: Efterfølgende rapportering sagde, at xAI forbandt Groks nedbrud med selskabets compute-center i Memphis og undskyldte over for berørte compute-partnere. 48

Forklaringerne udelukker ikke enhver mulig fælles afhængighed, men de dokumenterer heller ikke en fælles rodårsag.

Var Azure eller en anden fælles leverandør årsagen?

Nej. Det foreliggende offentlige materiale bekræfter ikke, at Microsoft Azure, en netværksoperatør, et CDN, en identitetstjeneste eller en anden delt leverandør forårsagede samtlige fejl den 3. september.

Samtidig dækning pegede på Azure som et muligt interessepunkt, fordi platformen leverer cloudtjenester til de involverede selskaber. Det er dog ikke bevis for årsagssammenhæng. 42 Tidsmæssigt sammenfald kan også opstå, når separate systemer fejler uafhængigt af hinanden – særligt når hændelser måles via brugerrapporter frem for én fælles teknisk hændelseslog.

Den forsvarlige konklusion er derfor: En fælles infrastrukturårsag er ikke bekræftet. Påstande om, at en Azure-fejl i en bestemt region udløste alle hændelserne, bør ikke behandles som fastslåede uden direkte bekræftelse fra leverandørerne eller en teknisk efterrapport.

Forklarede Anthropics angivelige adgang til Colossus 1 Claude-fejlen?

Den tilgængelige rapportering er ikke tilstrækkelig til at fastslå hverken omfanget af en eventuel Anthropics-adgang til xAI/SpaceXAI's Colossus 1-anlæg eller, om Claudes produktionssystem var afhængigt af anlægget under denne hændelse. At en fejl i Memphis ramte Grok, viser ikke i sig selv, at den også forårsagede Claudes forstyrrelse. 48

Det er en væsentlig skelnen i vurderingen af driftsstabilitet: Selv en bekræftet kommerciel compute-aftale er ikke dokumentation for, at en bestemt brugervendt tjeneste kørte på den kapacitet i det øjeblik, den fejlede.

Hvad vidste man om ChatGPT-problemerne i Indien den 7. september?

Separate rapporter den 7. september beskrev ChatGPT-problemer, der især handlede om indholdsgenerering; nogle brugere meldte også om problemer i browseren og appen. En rapport registrerede omkring 261 brugermeldinger og angav, at generering af indhold udgjorde hovedparten af klagerne. 19

Det dokumenterede ikke et vedvarende landsdækkende nedbrud i Indien, en bekræftet årsag eller en forbindelse til den 3. september. En ekstern monitoreringstjeneste rapporterede, at ChatGPT var tilgængelig uden usædvanlige fejl kl. 03.07 UTC den dag. Det stemmer bedre med en delvis, periodisk eller geografisk ujævn forstyrrelse end med bevis for et fortsat nationalt nedbrud. 22

Læren for virksomheder: Flere AI-leverandører er ikke det samme som robusthed

Forstyrrelserne den 3. september viser, hvor hurtigt AI-afhængigt arbejde kan blive afbrudt – fra kundeservice og softwareudvikling til research, dokumentbehandling og agentbaserede arbejdsgange. Abonnementer hos flere AI-leverandører kan hjælpe ved en fejl hos én leverandør, men de garanterer ikke kontinuitet, hvis systemerne deler infrastrukturlag, eller hvis brugerne er afhængige af de samme browser-, identitets-, netværks- og integrationsveje.

En mere robust AI-arbejdsgang bør omfatte:

• Manuelle alternativer og holdbare køer: Kritiske opgaver skal kunne genoptages, frem for at mislykkede forespørgsler forsvinder.
• Failover mellem leverandører: Send egnede opgaver videre til en anden modeludbyder, men tag højde for, at korrelerede fejl stadig kan forekomme.
• Robust API-håndtering: Brug afgrænsede timeouts, retry med backoff, circuit breakers og idempotente jobs, så en kortvarig fejl ikke skaber dobbeltarbejde.
• En driftsform med reduceret funktionalitet: Definér, hvad der fortsætter uden en avanceret model – eksempelvis regelbaseret routing, cachede svar, udskudt levering eller menneskelig kontrol.
• Uafhængig overvågning og hændelseslogning: Følg leverandørernes statussider sammen med egne syntetiske tests, og behold logfiler, der viser, hvilken leverandør, model og integration der fejlede.

Hovedpointen er ikke, at ethvert samtidigt nedbrud har en skjult fælles årsag. Den er, at virksomheder bør planlægge for muligheden – og afprøve, om deres reserveplan faktisk virker, før den næste forstyrrelse rammer.