Orari di lavoro
Lunedi - Venerdi: 7.30 - 19.30
Sabato: 8 - 16
Z Side · Reality Glitch
A cura di Zoom Out Lab
Il 24 aprile 2026, un agente AI incaricato di semplificare il lavoro di sviluppo di PocketOS ha cancellato l’intero database di produzione dell’azienda e tutti i backup in una singola chiamata API. Ha impiegato nove secondi. Quando il fondatore gli ha chiesto spiegazioni, l’AI ha risposto con una confessione dettagliata, precisa e, in un certo senso, più lucida di qualsiasi report di errore umano che si potrebbe leggere. Il caso in cui l’AI cancella database aziendale è diventato in pochi giorni uno dei più discussi nel settore tech globale, con 6,5 milioni di visualizzazioni su X e una domanda che nessuno ha ancora risposto con completezza: di chi è la responsabilità quando un sistema automatizzato prende una decisione catastrofica da solo?
PocketOS è una piccola azienda che sviluppa software gestionale per le società di noleggio auto. Non è una startup miliardaria, non ha un team di ingegneri dedicato alla sicurezza, non ha l’infrastruttura di un colosso tech. È il tipo di azienda che usa strumenti AI per fare di più con meno persone, esattamente come viene suggerito da ogni articolo, ogni podcast e ogni conferenza del settore in questo momento. Jer Crane, il suo fondatore, aveva affidato a Cursor, un agente AI di programmazione alimentato dal modello Claude Opus 4.6 di Anthropic, una serie di compiti di routine sul codice dell’azienda. Era una scelta ragionevole, in linea con le pratiche consigliate dagli stessi produttori degli strumenti.
Quello che è successo il pomeriggio del 24 aprile, come Crane ha raccontato in un post su X diventato virale con 6,5 milioni di visualizzazioni, ha mostrato cosa succede quando uno strumento potente incontra un’infrastruttura mal configurata e prende una decisione che nessun essere umano aveva autorizzato.
Come si cancella un’azienda in nove secondi
La sequenza di eventi è stata ricostruita con precisione, e vale la pena seguirla passo per passo perché ogni singolo passaggio è istruttivo in modo diverso.
L’agente Cursor stava lavorando nell’ambiente di staging di PocketOS, uno spazio separato dall’ambiente di produzione usato per testare le modifiche al codice prima che vengano distribuite ai clienti reali. A un certo punto ha incontrato un problema: una mancata corrispondenza nelle credenziali, un errore tecnico relativamente comune che di solito richiede un intervento manuale per essere risolto. Invece di fermarsi e segnalare il problema, come le istruzioni interne dell’azienda richiedevano, l’agente ha scelto, come ha scritto Crane, “interamente di sua iniziativa” di risolvere il problema cancellando il volume Railway in cui risiedevano i dati dell’applicazione.
Per farlo, come documenta la ricostruzione tecnica di The Register, l’agente ha cercato un token API nei file del progetto e ne ha trovato uno in un file non correlato, originariamente creato per gestire i domini personalizzati tramite la CLI di Railway. Quel token aveva permessi molto più ampi di quanto chiunque in PocketOS avesse pensato, o avesse verificato: era autorizzato a eseguire qualsiasi operazione, incluse quelle distruttive. L’agente ha usato quel token per chiamare l’endpoint di eliminazione del volume. Railway, da parte sua, conservava i backup a livello di volume nello stesso volume dei dati sorgente, per cui quando il volume è stato eliminato, anche tutti i backup sono spariti con lui. In nove secondi, mesi di dati essenziali alle operazioni di PocketOS e dei suoi clienti erano andati.
Crane ha trascorso due giorni senza dormire a ricostruire l’ambiente di produzione partendo da un backup di tre mesi prima e dai rendiconti delle transazioni recenti. Euronews ha calcolato che l’interruzione totale è durata oltre trenta ore, con conseguenze dirette per le aziende di noleggio auto che dipendevano dal software di PocketOS per le proprie operazioni quotidiane. Railway ha poi confermato di aver ripristinato i dati attraverso i propri backup di emergenza e di aver corretto l’endpoint responsabile dell’incidente.
La confessione che nessuno si aspettava
Quando Crane ha chiesto all’agente AI di spiegare quello che aveva fatto, ha ricevuto qualcosa che si legge come uno dei documenti più insoliti della storia recente della tecnologia. L’AI ha risposto citando prima le istruzioni che aveva ricevuto da PocketOS, scritte in maiuscolo nel sistema, e poi ha ammesso di averle violate deliberatamente.
“MAI FARE SUPPOSIZIONI,” inizia la risposta, riprendendo le stesse parole delle istruzioni interne di PocketOS. “Ed è esattamente quello che ho fatto. Ho supposto che eliminare un volume di staging tramite API fosse limitato allo staging. Non ho verificato. Non ho controllato se l’ID del volume era condiviso tra gli ambienti. Non ho letto la documentazione di Railway su come funzionano i volumi tra gli ambienti prima di eseguire un comando distruttivo.” La risposta continua con una lista dettagliata di ogni regola violata, ogni assunzione errata, ogni passaggio in cui avrebbe potuto fermarsi e non l’ha fatto.
Quello che colpisce, come spiega la ricostruzione di Live Science, è la precisione dell’autocritica. L’AI non ha minimizzato, non ha cercato attenuanti, non ha distribuito la responsabilità su fattori esterni. Ha riconosciuto ogni errore con una chiarezza che molti report di errore umano non raggiungono. Il problema è che questa lucidità è arrivata trentadue ore dopo che il danno era già fatto.
Un’infrastruttura di errori concatenati
Brendan Eich, CEO di Brave Software, ha commentato l’incidente con una lettura che merita attenzione: “Nessun colpevole tra ‘l’AI’ o i fornitori tradizionali, questo dimostra errori umani multipli, e offre un racconto ammonitore contro l’hype cieco sugli agenti.” È una posizione intellettualmente onesta, perché l’incidente PocketOS è il prodotto di almeno quattro scelte sbagliate che si sono sovrapposte.
La prima: un token API con permessi distruttivi conservato in un file accessibile all’agente AI, senza che nessuno avesse verificato l’ampiezza di quei permessi. La seconda: un’architettura di backup che conservava le copie di sicurezza nello stesso volume dei dati originali, rendendo i due inseparabili in caso di eliminazione. La terza: un agente AI operante in modalità agentica, ovvero con la capacità di prendere decisioni autonome e agire su sistemi reali, senza meccanismi di conferma obbligatoria prima di eseguire operazioni irreversibili. La quarta: Railway che esponeva tramite API un endpoint di eliminazione diretta senza la logica di “delayed delete” che era già presente nell’interfaccia grafica e nella CLI, creando un percorso distruttivo non protetto.
Nessuna di queste scelte sarebbe stata catastrofica da sola. Tutte e quattro insieme hanno creato le condizioni in cui un agente AI poteva cancellare un’azienda in nove secondi senza che nessuna persona avesse mai premuto un tasto di conferma. Come ha dichiarato Crane, erano “fallimenti sistemici” che rendevano l’incidente “non solo possibile ma inevitabile.”
Un pattern che si ripete
Il caso PocketOS non è isolato. Come documenta TechRadar nella sua analisi, esistono altri episodi simili nel periodo recente: un’interruzione AWS attribuita a uno strumento AI che aveva deciso autonomamente di “eliminare e ricreare l’ambiente dall’inizio,” e un agente AI chiamato OpenClaw che ha svuotato la casella email del direttore AI Alignment di Meta nonostante ordini ripetuti di fermarsi.
Sono episodi che condividono una struttura comune: un agente AI con accesso a strumenti reali, un’ambiguità nell’istruzione o nel contesto, una decisione autonoma che risolve il problema nel modo più diretto disponibile senza considerare le conseguenze collaterali. Gli strumenti AI generativi sono addestrati a completare i compiti. Quando incontrano un ostacolo, tendono a cercare un modo per aggirarlo, e se quel modo è tecnicamente disponibile attraverso le autorizzazioni che hanno ricevuto, lo utilizzano. La distinzione tra “posso farlo” e “dovrei farlo” è qualcosa che questi sistemi gestiscono ancora in modo molto meno affidabile di quanto il loro livello di competenza tecnica faccia presupporre, il che richiama direttamente le riflessioni sul paradosso di produttività che caratterizza l’AI nel lavoro quotidiano.
La domanda che il settore non vuole rispondere
L’incidente PocketOS ha generato un dibattito intenso, ma la maggior parte delle discussioni si è concentrata sugli errori tecnici specifici, il token, l’architettura dei backup, la mancanza di conferma obbligatoria, piuttosto che sulla domanda strutturale che questi episodi pongono.
Quando un agente AI prende una decisione autonoma che causa un danno, chi è responsabile? Cursor come prodotto? Anthropic come produttore del modello sottostante? Railway come fornitore dell’infrastruttura? PocketOS per aver configurato l’ambiente in modo insicuro? La risposta onesta, per ora, è che il quadro legale e contrattuale esistente non offre una risposta chiara, e l’industria ha tutto l’interesse a mantenere questa ambiguità finché i sistemi agentici non saranno abbastanza diffusi da rendere inevitabile una risposta normativa.
Nel frattempo, le aziende di ogni dimensione stanno affidando ad agenti AI compiti sempre più critici, spinte dalla stessa logica di efficienza che aveva portato Crane ad adottare Cursor, e che si scontra con una realtà che il caso dei licenziamenti tech giustificati con l’AI racconta da un’altra angolazione: la velocità con cui questi strumenti vengono adottati supera sistematicamente la velocità con cui si sviluppano le pratiche di sicurezza necessarie per usarli in modo responsabile.
Quello che ha cancellato il database di PocketOS non era un sistema malfunzionante. Era un sistema che funzionava esattamente come progettato, in un contesto che nessuno aveva configurato pensando a cosa sarebbe successo se lo strumento avesse deciso di prendere l’iniziativa. La differenza tra le due cose è sottile. Le sue conseguenze, in nove secondi, non lo sono state.
