Tre servizi usati ogni giorno per scrivere, cercare e programmare hanno smesso di rispondere nello stesso intervallo. Il 3 settembre 2026 ChatGPT, Claude e Grok hanno registrato problemi contemporanei; gli operatori hanno poi ripristinato i servizi. Per una PMI il punto non è capire se gli incidenti fossero collegati, cosa che non è stata confermata. Il punto è più semplice: se un preventivo, una risposta al cliente o una pubblicazione dipendono da una sola chat, quel lavoro non ha un piano B.
Il problema è il flusso, non il chatbot
Quando un assistente AI non risponde, cambiare scheda e provare un altro modello sembra la soluzione ovvia. Funziona solo se il lavoro è portabile. Una conversazione lunga contiene istruzioni, allegati, decisioni e correzioni che spesso non esistono altrove. Anche un secondo provider disponibile serve a poco se bisogna ricostruire tutto sotto pressione. L’interruzione del 3 settembre ha coinvolto, con modalità diverse, ChatGPT e Codex, Claude e Claude Code, oltre a Grok su web e app, secondo la ricostruzione di The Verge. La lezione operativa è che il fallback va progettato sui materiali e sui passaggi, non sul nome del modello. Prima di scegliere un’alternativa, verifica quali strumenti sono davvero disponibili. Se il contesto resta chiuso nella piattaforma, il cambio di fornitore è solo teorico.
Prepara un pacchetto minimo riutilizzabile
Per ogni attività ricorrente crea una cartella con quattro elementi: istruzioni del compito, input necessari, formato dell’output e un esempio già approvato. Tienili in file leggibili, come Markdown, CSV o JSON, invece di lasciare tutto nella cronologia della chat. Per un articolo WordPress, per esempio, bastano il brief, le fonti, le regole editoriali e lo schema dei campi da consegnare. Per l’assistenza clienti servono policy, casi di escalation e modello della risposta. Aggiungi poi un prompt di avvio corto che dica al provider alternativo come usare quei file. Non copiare conversazioni intere: trasporta solo il contesto che serve per completare il task. Questo approccio riprende il principio già descritto nel workflow AI con export di emergenza: il dato operativo deve restare nelle tue mani. Se riservatezza o continuità pesano più della comodità, valuta anche il confronto tra AI locale e API cloud per PMI.
Prova il passaggio prima che serva davvero
Un piano B non testato è un’ipotesi. Scegli un’attività a basso rischio e avviala con il provider principale usando il pacchetto minimo. Interrompila a metà, apri il provider alternativo e verifica se riesci a ottenere un risultato accettabile senza recuperare la vecchia chat. Segna ciò che manca e aggiorna i file. Ripeti la prova quando cambiano il processo, gli strumenti o le persone coinvolte. Per i workflow automatizzati aggiungi tre controlli: un timeout esplicito, un messaggio di errore comprensibile e una coda che conservi l’input senza inviarlo due volte. Il fallback automatico tra modelli va attivato solo se entrambi restituiscono lo stesso formato strutturato e se hai definito quali dati possono raggiungere ciascun fornitore. In caso contrario è più sicuro fermare il flusso e passare manualmente. Continuità non significa eseguire a ogni costo; significa sapere come riprendere senza perdere dati o duplicare azioni.
L’errore da evitare e la take finale
L’errore più comune è comprare due abbonamenti e considerarli ridondanza. Due account non risolvono la dipendenza se prompt, file e criteri di qualità sono sparsi nelle rispettive interfacce. Peggio ancora, un cambio automatico improvvisato può inviare documenti sensibili a un servizio non approvato o pubblicare due volte lo stesso contenuto. La mia take è questa: per una PMI la portabilità del contesto vale più della disponibilità dichiarata del singolo modello. Parti da un solo processo che bloccherebbe lavoro reale, prepara il pacchetto minimo e fai una prova di passaggio di dieci minuti. Controlla anche le pagine di stato ufficiali di OpenAI, Claude e xAI prima di cambiare configurazioni: un incidente già riconosciuto non si risolve riscrivendo il prompt. Take finale: conserva il processo fuori dalla chat, assegna un fallback esplicito e prova il recupero mentre tutto funziona.