Perché ChatGPT, Claude e Grok sono andati in tilt il 3 settembre

Il 3 settembre 2026 diversi servizi di intelligenza artificiale hanno smesso di funzionare, o hanno funzionato male, nell’arco di poche ore: ChatGPT e Codex di OpenAI, i prodotti Claude di Anthropic e Grok di xAI. La coincidenza temporale è reale, ma la conclusione più solida è più circoscritta: le informazioni pubbliche descrivono incidenti distinti, con cause dichiarate diverse. Non dimostrano un unico blackout dell’infrastruttura dell’IA. 334148

Che cosa è successo e in quali orari

Gli orari non combaciano perfettamente tra le pagine di stato dei fornitori e le segnalazioni esterne. Tuttavia, le finestre riportate spiegano perché per molti utenti il problema sia apparso simultaneo.

• Grok: secondo quanto riportato sul registro dell’incidente, il disservizio è iniziato alle 13:30 UTC e si è concluso alle 17:05 UTC. xAI ha poi attribuito il problema a un guasto nel proprio centro di calcolo di Memphis. 48
• Claude: Anthropic ha segnalato un aumento degli errori nelle richieste su modelli e prodotti Claude, compresi Claude.ai, API, Claude Code e Claude Cowork. L’incidente era risolto entro le 16:16 UTC, dopo circa tre ore. 104148
• ChatGPT e Codex: OpenAI ha dichiarato che un errore di instradamento interno, iniziato alle 07:43 ora del Pacifico, ha reso ChatGPT e Codex indisponibili per una parte degli utenti su varie piattaforme. Una soluzione è stata implementata intorno alle 08:17 e successivamente monitorata. 41

Gli utenti hanno segnalato difficoltà di accesso, chat non disponibili, prompt falliti e problemi sulle applicazioni o sul sito web. I dati riportati da Downdetector hanno superato 43.000 segnalazioni per ChatGPT attorno alle 20:00 IST, mentre per Claude il problema coinvolgeva sia gli strumenti destinati al pubblico sia quelli per sviluppatori. 2339

Le cause indicate dalle aziende

Le spiegazioni rese pubbliche sono importanti proprio perché rendono azzardato parlare di un’unica causa.

OpenAI: un portavoce ha attribuito il disservizio di ChatGPT e Codex a un errore di routing, cioè di instradamento del traffico, all’interno dell’infrastruttura di OpenAI. 41

Anthropic: i resoconti pubblici hanno definito il problema di Claude un incidente di infrastruttura, confermando errori elevati su modelli e servizi diversi. Il materiale disponibile non identifica però il componente tecnico specifico che ha ceduto. 3948

xAI: secondo le ricostruzioni successive, xAI ha collegato l’interruzione di Grok al proprio centro di calcolo di Memphis, scusandosi con i partner di calcolo interessati. 48

Queste spiegazioni non escludono in assoluto l’esistenza di dipendenze condivise, ma non provano nemmeno una causa comune.

Azure, CDN o altri fornitori condivisi: sono responsabili?

No: nelle informazioni disponibili non c’è alcuna conferma pubblica che Microsoft Azure, un operatore di rete, una CDN, un servizio di identità o un altro fornitore condiviso abbia causato tutti i disservizi del 3 settembre.

La copertura dell’epoca ha indicato Azure come possibile elemento da osservare, dato che offre servizi cloud alle aziende coinvolte. Ma una dipendenza commerciale non è una dimostrazione di causalità. 42 Incidenti separati possono sovrapporsi nel tempo, soprattutto quando le finestre del guasto vengono ricostruite dalle segnalazioni degli utenti anziché da un unico registro tecnico comune.

Il verdetto corretto, quindi, è questo: un’eventuale causa legata a infrastrutture condivise resta non confermata. Affermare che un guasto regionale di Azure abbia provocato tutti gli incidenti richiederebbe una conferma diretta delle aziende o un’analisi tecnica post-incidente.

L’eventuale accesso di Anthropic a Colossus 1 spiega il blackout di Claude?

Le informazioni disponibili non sono sufficienti per stabilire né la portata di un eventuale accesso di Anthropic alla struttura Colossus 1 di xAI/SpaceXAI, né se il percorso di erogazione di Claude dipendesse da quella capacità al momento dell’incidente. Un problema a Memphis che ha colpito Grok non dimostra, da solo, che abbia causato il disservizio di Claude. 48

È una distinzione essenziale nell’analisi dell’affidabilità: anche se un accordo commerciale per risorse di calcolo fosse verificato, non costituirebbe la prova che un determinato servizio rivolto agli utenti stesse girando su quelle risorse nell’istante in cui si è verificato il guasto.

Che cosa si sapeva delle nuove segnalazioni di ChatGPT in India il 7 settembre

Segnalazioni separate, il 7 settembre, hanno descritto problemi di ChatGPT concentrati soprattutto nella generazione di contenuti; alcuni utenti hanno riferito difficoltà anche nell’uso da browser e app. Un rapporto contava circa 261 segnalazioni degli utenti e indicava la generazione di contenuti come origine della maggior parte dei reclami. 19

Questi elementi non dimostrano un blackout prolungato a livello nazionale in India, non ne stabiliscono la causa e non ne provano un collegamento con il 3 settembre. Quel giorno un monitor esterno rilevava che ChatGPT era raggiungibile senza errori anomali alle 03:07 UTC: un dato compatibile con un problema parziale, intermittente o disomogeneo per area geografica, non con la prova di un’interruzione continua su scala nazionale. 22

La lezione per le aziende: più fornitori non significa automaticamente continuità

I disservizi del 3 settembre mostrano quanto velocemente il lavoro che dipende dall’IA possa fermarsi: assistenza clienti, sviluppo software, ricerca, gestione di documenti e flussi automatizzati con agenti.

Avere abbonamenti a più fornitori riduce il rischio che un singolo vendor blocchi tutto, ma non garantisce la continuità se esistono livelli infrastrutturali condivisi o se i flussi dipendono dagli stessi browser, sistemi di identità, reti e integrazioni.

Un’architettura più resiliente dovrebbe prevedere:

• Procedure manuali e code persistenti: il lavoro critico deve poter essere recuperato, non sparire quando una richiesta fallisce.
• Failover tra fornitori: instradare i compiti compatibili verso un altro modello, sapendo che i guasti correlati restano possibili.
• Gestione difensiva delle API: timeout limitati, tentativi con attesa progressiva, circuit breaker e processi idempotenti per evitare duplicazioni durante un’interruzione temporanea.
• Una modalità degradata: definire cosa può continuare senza un modello di frontiera, per esempio routing basato su regole, risposte in cache, consegne rimandate o revisione umana.
• Monitoraggio indipendente e registri d’incidente: affiancare alle pagine di stato dei fornitori controlli sintetici propri e conservare log che indichino provider, modello e integrazione coinvolti.

Il messaggio chiave non è che ogni guasto simultaneo nasconda per forza una causa unica. È che le imprese dovrebbero prepararsi anche a questa possibilità e verificare la tenuta delle procedure alternative prima del prossimo disservizio.