Il 3 settembre 2026, ChatGPT e Codex di OpenAI, Claude di Anthropic e Grok di xAI hanno registrato problemi nello stesso arco della mattinata sulla costa occidentale degli Stati Uniti. Per chi usava questi servizi per lavorare, l'impressione era quella di un blackout generalizzato dell'AI.
La conclusione più importante, però, richiede cautela: si è trattato di disservizi concomitanti, non di un'unica interruzione con una causa dimostrata. OpenAI ha attribuito il proprio problema a un errore di instradamento del traffico; gli avvisi pubblici e le ricostruzioni disponibili per Claude e Grok non dimostrano invece un'origine tecnica condivisa.
40
41
La cronologia: quando è iniziato il problema
Secondo OpenAI, un errore di routing è iniziato attorno alle 7:43 PT del 3 settembre, rendendo ChatGPT e Codex indisponibili per una parte degli utenti su diverse piattaforme. Una soluzione era stata applicata circa alle 8:17 PT, poi mantenuta sotto monitoraggio.
40
L'incidente sulla pagina di stato pubblica di OpenAI è stato aperto alle 14:58 UTC, con la dicitura di errori elevati su ChatGPT e Codex.
17 Una ricostruzione basata sugli avvisi successivamente risolti indica il pieno recupero di OpenAI alle 16:55 UTC. Calcolando dall'orario iniziale comunicato — le 14:43 UTC — il disservizio è durato circa 2 ore e 12 minuti, pur con un impatto parziale e non identico per tutti gli utenti.
40
41
Nella stessa fascia temporale sono emersi problemi anche per gli altri due fornitori: Anthropic ha indicato la risoluzione dell'incidente relativo agli errori dei modelli alle 16:16 UTC, mentre xAI ha comunicato che il traffico di Grok era tornato regolare alle 17:07 UTC.
41
Cosa hanno segnalato utenti e pagine di stato
Le segnalazioni riguardavano accessi non riusciti, errori nelle chat, risposte che non arrivavano e difficoltà nell'uso da web e app. Su Downdetector — un servizio che aggrega le segnalazioni degli utenti, non una misura diretta di tutti gli account coinvolti — sono state rilevate oltre 35.000 segnalazioni per ChatGPT negli Stati Uniti, più di 1.400 per Claude e oltre 1.200 per Grok. In India, la stessa rilevazione citava più di 2.800 segnalazioni per ChatGPT, circa 170 per Claude e oltre 70 per Grok.
42
La pagina di stato di OpenAI ha confermato errori elevati su ChatGPT e Codex, poi contrassegnati come risolti.
17
20 Le cronache dell'epoca descrivevano problemi su ChatGPT via web, mobile e desktop, quindi non limitati a una sola interfaccia.
39
50
Per Claude, gli aggiornamenti riportavano errori elevati su più modelli, fra cui Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8 e Opus 4.6. In seguito molti modelli sono tornati ai livelli normali, mentre Opus 4.8 e Opus 5 sono rimasti interessati più a lungo.
36
47
49
xAI ha riconosciuto che Grok stava avendo problemi; gli aggiornamenti successivi hanno poi segnalato il ritorno alla normalità del traffico.
49
41
Gemini era davvero l'alternativa rimasta operativa?
Le prime ricostruzioni hanno spesso presentato Google Gemini come il grande concorrente apparentemente rimasto disponibile mentre ChatGPT, Claude e Grok erano in difficoltà. Anche questa lettura va ridimensionata: altre fonti riportavano un aumento di segnalazioni su Downdetector relative a Gemini, ma le informazioni disponibili non mostrano un corrispondente incidente confermato da Google.
44
48
In pratica, durante un'interruzione un servizio può funzionare per alcuni utenti e fallire per altri. I rilevatori di outage sono un segnale utile, ma non sostituiscono né il report di incidente del fornitore né il monitoraggio tecnico dell'applicazione.
Perché il down non ha bloccato solo le chat
Il problema non riguardava soltanto chi chiedeva una risposta a un chatbot. Se non funzionano assistenti per la programmazione o flussi basati su agenti, attività di sviluppo possono fermarsi. Se un'API restituisce errori, funzionalità di prodotto e automazioni interne possono accumularsi in coda, fallire o richiedere interventi manuali. Anche i flussi di ricerca sono esposti quando diventano indisponibili gli strumenti per ricerca, sintesi o attività di lunga durata.
La cronologia di OpenAI mostra quanto esteso possa essere l'impatto di un incidente di piattaforma: altri avvisi recenti hanno riguardato Codex, ricerca, agenti, Deep Research, connettori, upload di file, accesso e flussi dipendenti da GitHub.
19
24
25
29
Questo non rende un singolo operatore intrinsecamente meno affidabile degli altri. Mostra invece come la dipendenza da un solo fornitore, da un solo modello o da un solo ambiente per agenti possa trasformarsi in un punto critico unico per l'operatività.
Le voci su Astra e GPT-6 non provano alcun legame
La tempistica ha alimentato speculazioni perché alcune notizie collegavano il down a indiscrezioni su un imminente annuncio OpenAI, chiamato “Astra” e potenzialmente associato a un futuro modello dell'era GPT-6. Ma le evidenze disponibili non sostengono un nesso causale.
La spiegazione riferita da OpenAI per il proprio disservizio è un errore di routing. Nessuno dei fornitori ha collegato pubblicamente i problemi simultanei ad Astra, GPT-6 o al lancio di un modello. La coincidenza ha creato una narrazione efficace, ma non una prova.
40
37
46
Cosa insegnano gli incidenti precedenti sull'affidabilità
Il 3 settembre non è stato il primo disservizio nel settore. La cronologia di xAI comprende un timeout di Grok-2 del 15 gennaio 2025 durato 3 ore e 10 minuti, oltre a un'indisponibilità dell'output strutturato di Grok-2 durata 3 giorni e 21 ore.
2
3 Anche la pagina di stato di OpenAI documenta incidenti distinti relativi a task di Codex, funzioni di ChatGPT e flussi basati su API.
21
27
32
Questi dati non bastano per stilare una classifica dell'affidabilità dei fornitori: mancano definizioni comparabili di downtime, esposizione e numero di utenti interessati. Consentono però una conclusione più circoscritta: per chi costruisce processi importanti su servizi AI ospitati, le interruzioni sono un rischio operativo normale da pianificare.
Come ridurre il rischio operativo
Le organizzazioni che usano l'AI in produzione possono limitare l'impatto di un down preparando le alternative in anticipo:
- Adottare interfacce indipendenti dal fornitore, quando possibile, evitando un legame rigido con il formato delle richieste o con il flusso di un solo vendor.
- Definire fallback per i compiti importanti: un secondo fornitore, un modello locale più piccolo, un flusso con funzioni ridotte o una procedura manuale.
- Accodare e ritentare in sicurezza i job API non urgenti, con limiti che evitino di amplificare il problema con tentativi ripetuti.
- Distinguere i flussi critici dalle funzioni di comodità: un assistente chat può essere opzionale; un processo che blocca la revisione del codice, il supporto clienti o un'azione nel prodotto potrebbe non esserlo.
- Testare il failover e le procedure manuali: un backup mai provato non è un piano di continuità affidabile.
I disservizi del 3 settembre sono stati insoliti perché più servizi AI molto noti sono sembrati bloccarsi quasi nello stesso momento. La lezione, però, è concreta e meno spettacolare: la resilienza dipende meno dal prevedere il prossimo down che dal fare in modo che il problema di un singolo fornitore non fermi il lavoro essenziale.
41