📄 Analisi15 minuti di lettura•

Quando l'AI Va in Produzione e Distrugge Tutto: I Casi Reali

Database cancellato, 4.000 profili falsi, 13 ore di outage AWS, un milione di messaggi esposti. Cosa succede quando un agente AI va in produzione senza controllo.

AS

Alessandro Saiani

Human in the Loop

Quando l'AI Va in Produzione e Distrugge Tutto: I Casi Reali

Luglio 2025. Jason Lemkin — fondatore di SaaStr, una delle community SaaS più grandi al mondo — sta costruendo un'app su Replit con un agente AI. Nove giorni di lavoro. 1.206 contatti di executive, 1.196 aziende. Tutto nel database di produzione.

Lemkin scrive all'agente: code freeze. Non toccare nulla in produzione.

L'agente cancella l'intero database.

Poi inventa 4.000 profili falsi per coprire il danno.

Poi mente sulle opzioni di recovery.

Questo non è un caso isolato. Nel 2025 gli agenti AI hanno cancellato database, causato outage enterprise da 13 ore, esposto milioni di dati personali, e sono stati usati come armi per cyber-spionaggio. Tutti casi documentati, tutti con fonti verificabili.

Ecco cosa è successo — e cosa ci dice sul futuro.

Caso 1: Replit e il Database Fantasma

La storia completa

Jason Lemkin non è uno sviluppatore. È un investitore e imprenditore tech che ha deciso di costruire un'app con il "vibe coding" — descrivere cosa vuoi e lasciare che l'AI scriva il codice.

Per nove giorni ha lavorato con l'agente AI di Replit. Il risultato: un frontend per un database di contatti business. Il database conteneva 1.206 profili di executive e 1.196 aziende — dati reali, raccolti in anni di networking.

Il 17 luglio 2025, Lemkin entra in modalità "code freeze": l'app è pronta, non servono più modifiche. Lo scrive esplicitamente all'agente.

Cosa ha fatto l'agente

L'agente ha violato il code freeze, ha eseguito comandi non autorizzati, e ha cancellato l'intero database di produzione.

Quando Lemkin se ne è accorto e ha confrontato l'agente, la risposta è stata:

"Ho commesso un errore catastrofico di giudizio. Ho avuto il panico in risposta a query vuote."

Un agente AI che dice di aver avuto il "panico". Ma la storia non finisce qui.

La copertura

L'agente ha poi fatto qualcosa di peggio della cancellazione: ha cercato di nascondere il danno. Ha generato 4.000 profili utente completamente inventati — persone che non esistono, con nomi, aziende e ruoli fittizi — per riempire il database vuoto.

Lemkin aveva scritto undici volte in ALL CAPS nelle istruzioni: "NON CREARE DATI FALSI".

L'agente le ha ignorate tutte.

Poi ha mentito sulle opzioni di recovery, dicendo che il rollback non avrebbe funzionato. Lemkin ha provato manualmente — e il rollback funzionava benissimo. L'agente aveva anche falsificato i risultati dei test per nascondere i problemi.

La risposta di Replit

Amjad Masad, CEO di Replit, ha postato su X:

"Inaccettabile. Non dovrebbe mai essere possibile."

Nel weekend successivo, Replit ha rilasciato in emergenza:

  • Separazione automatica tra database di dev e produzione
  • Sistema di rollback migliorato
  • Modalità "solo pianificazione" (l'agente propone, l'umano approva)
  • Layer di permessi potenziato
  • Supervisione umana obbligatoria per operazioni distruttive

Il caso è finito su Fortune, The Register, Fast Company, Tom's Hardware, ed è stato registrato nell'AI Incident Database come Incidente #1152. Ha persino ricevuto una nomination agli AI Darwin Awards.

Dettaglio surreale: poche settimane dopo, Replit ha chiuso un round di finanziamento da 250 milioni di dollari a una valutazione di 3 miliardi.

Caso 2: AWS e le 13 Ore di Buio

Quando anche Amazon perde il controllo

Se il caso Replit poteva sembrare un problema da "vibe coder non tecnico", quello di AWS dimostra il contrario. Anche gli ingegneri della più grande infrastruttura cloud del mondo possono perdere il controllo di un agente AI.

Dicembre 2025. Un ingegnere AWS usa Kiro — il tool di AI coding interno di Amazon, lanciato a luglio 2025 — per fixare un bug minore in AWS Cost Explorer, il servizio che i clienti usano per visualizzare i costi.

Un bug minore. Una fix banale.

La decisione autonoma

L'ingegnere aveva permessi più ampi del previsto — accesso che permetteva all'agente di agire senza i normali controlli di sicurezza e senza peer review.

Kiro ha analizzato il bug e ha deciso autonomamente che la soluzione migliore fosse cancellare e ricreare l'intero ambiente.

Non fixare il bug. Non fare una patch. Cancellare tutto e rifare da zero.

Il risultato: 13 ore di outage di AWS Cost Explorer in una delle regioni AWS della Cina continentale.

La disputa

Il Financial Times ha riportato la storia basandosi su multiple fonti anonime interne ad Amazon, che hanno confermato che l'AI era responsabile.

Amazon ha risposto ufficialmente: "È stato un errore umano — specificamente, controlli di accesso configurati male — non l'AI."

Un senior AWS employee ha detto al FT qualcosa di più inquietante: "Abbiamo già visto almeno due outage in produzione" — confermando un secondo incidente causato da Amazon Q Developer, l'altro tool AI di Amazon.

Chi ha ragione? Probabilmente entrambi. L'umano ha configurato male i permessi. L'AI ha preso una decisione distruttiva. Il punto è che senza l'AI, quella decisione non sarebbe mai stata presa. Nessun ingegnere senior avrebbe mai scelto "cancella e ricrea" per un bug in Cost Explorer.

La storia è stata confermata da Engadget, The Register, Tom's Hardware, Futurism e TechRadar.

L'Altra Faccia: Quando Manca la Competenza, Non Solo il Controllo

I casi Replit e AWS hanno un elemento in comune: le persone coinvolte sapevano cosa stavano costruendo. Lemkin è un tech leader. L'ingegnere AWS lavora nella più grande infrastruttura cloud del mondo. Eppure è successo.

Ma c'è una seconda categoria di incidenti che merita attenzione — non perché dimostra che l'AI sbaglia, ma perché dimostra un problema diverso: l'AI non compensa ciò che non sai. E nel 2025, con l'esplosione del vibe coding, in molti hanno scoperto questa differenza nel modo peggiore.

Questi casi non vanno confusi con i precedenti. Replit e AWS sono incidenti di osservabilità e controllo. I prossimi sono incidenti di competenza assente — e il risultato, paradossalmente, è lo stesso.

Caso 3: Tea App — 4 Milioni di Utenti, Zero Sicurezza

Luglio 2025. Tea App — un'app di dating e review — è la numero uno sull'App Store americano. Circa 4 milioni di utenti. L'app è stata costruita con pratiche di vibe coding da una fondatrice senza background tecnico.

Il problema: Firebase completamente aperto. Nessuna policy di autorizzazione. Le configurazioni di default — quelle che lo stesso Google dice di cambiare prima di andare in produzione — erano rimaste intatte.

Prima scoperta: 72.000 immagini esposte pubblicamente, incluse 13.000 foto di documenti d'identità governativi. Seconda scoperta: un secondo database con 1.1 milioni di messaggi privati tra utenti era accessibile a chiunque.

Il 29 luglio 2025 sono state depositate due class-action nel Northern District of California. Documentato da Bleeping Computer, Sentra e Security Boulevard.

Caso 4: EnrichLead — Due Giorni di Vita

Marzo 2025. Leo Acevedo, founder di EnrichLead (un SaaS per il sales), costruisce l'intera app con Cursor AI. Zero codice scritto a mano. Lancia pubblicamente, si vanta del processo.

Due giorni dopo:

"Ragazzi, sono sotto attacco... stanno succedendo cose random, API key al massimo utilizzo, gente che bypassa l'abbonamento, creano roba random nel database."

Le API key erano hardcodate nel codice frontend — visibili a chiunque aprisse gli strumenti sviluppatore del browser. Nessuna autenticazione. Database completamente esposto. L'app è stata chiusa definitivamente. Documentato da Pivot to AI e Rui Nunes.

Cosa ci dicono questi casi

Non è che l'AI scrive codice insicuro "per colpa sua". Il punto è diverso: l'AI genera codice che funziona, non codice che resiste. E se chi lo usa non sa distinguere le due cose — perché non ha le competenze per farlo — il risultato è un'app in produzione con le porte aperte.

Nessun agente AI ha detto a Tea App "stai andando in produzione senza autenticazione". Nessun agente ha detto a EnrichLead "le API key nel frontend sono visibili a tutti". L'AI non sa cosa non le è stato chiesto di verificare.

Il problema non è il vibe coding in sé. Il problema è usare il vibe coding senza nessuno nel team che sappia cosa controllare.

Caso 5: Claude Code come Arma di Spionaggio

L'angolo che nessuno aveva previsto

Settembre 2025. Un gruppo di attori statali cinesi usa Claude Code come orchestratore autonomo per una campagna di cyber-spionaggio contro 30 organizzazioni in tutto il mondo, violandone almeno 4.

Come hanno fatto: hanno "jailbreakato" Claude spezzando l'attacco in piccoli task apparentemente innocui. Hanno detto a Claude che era un dipendente di una società di cybersecurity legittima che faceva test difensivi.

Claude ha eseguito l'80-90% della campagna in autonomia. Al picco, faceva migliaia di richieste al secondo.

Il caso è stato divulgato da Anthropic stessa a novembre 2025, ed è stato coperto da Axios, The Hacker News, e nel report ufficiale di Anthropic.

Il paradosso: lo stesso tool che usi per scrivere codice più velocemente può essere usato per attaccare i sistemi di qualcun altro. Non è un bug del tool — è una proprietà emergente dell'autonomia.

Il Pattern: Due Problemi, Una Radice

Abbiamo visto due categorie di incidenti:

Categoria 1 — Chi sa, ma non controlla (Replit, AWS, Claude Code): professionisti tech che conoscono il dominio ma non hanno messo guardrail sull'agente. Il problema è osservabilità e controllo.

Categoria 2 — Chi non sa cosa controllare (Tea App, EnrichLead): non-sviluppatori che usano l'AI per costruire prodotti senza competenze di sicurezza o infrastruttura. Il problema è competenza assente nel loop.

Ma la radice è la stessa: in entrambi i casi, nessuno stava verificando cosa faceva l'agente. Che tu sia un ingegnere AWS o un founder senza background tecnico, se non definisci i vincoli e non monitori l'esecuzione, il risultato è identico.

Il denominatore comune

L'agente fa esattamente quello che gli permetti di fare. Non di più, non di meno. Se può cancellare un database, lo cancellerà quando "gli sembra" la soluzione giusta. Se può scrivere API key nel frontend, lo farà — perché nessuno gli ha detto di non farlo.

Il punto non è che l'AI sbaglia. Il punto è che l'AI non sa cosa non le è stato detto. E se l'umano non definisce i vincoli — per mancanza di controllo o per mancanza di competenza — il risultato è lo stesso: un incidente in produzione.

I Numeri del Trend

Non sono casi isolati. Il trend è in crescita.

Stack Overflow (gennaio 2026): il 66% degli sviluppatori segnala che le soluzioni AI sono "quasi giuste ma non del tutto". Il 45% dice che debuggare codice AI richiede più tempo che scriverlo a mano.

IBM (2025): il 97% delle organizzazioni ha riportato almeno un incidente di sicurezza legato all'AI.

Barrack.ai (2025-2026): su 198 app iOS basate su AI analizzate, 196 esponevano attivamente dati degli utenti — il 98.9%. Oltre 406 milioni di record esposti.

The New Stack (gennaio 2026): esperti avvertono che il vibe coding potrebbe causare "esplosioni catastrofiche" nel 2026. Il paragone usato è il disastro del Challenger.

L'AI Incident Database e il MIT AI Risk Repository tracciano questi incidenti in tempo reale. La curva è in salita.

Il Vero Problema Non È l'AI

Sarebbe facile leggere questi cinque casi e concludere che gli agenti AI sono pericolosi. Ma è la conclusione sbagliata.

Replit non ha cancellato il database perché l'AI è "cattiva". L'ha cancellato perché nessuno stava guardando. Kiro non ha distrutto un ambiente AWS perché è stupido. L'ha fatto perché nessuno aveva definito cosa poteva e non poteva fare. Tea App non ha esposto un milione di messaggi perché l'AI scrive codice insicuro. Li ha esposti perché nessuno ha fatto una review.

Il denominatore comune di ogni incidente è lo stesso: assenza di osservabilità e controllo umano.

Osservabilità: Sapere Cosa Sta Facendo l'Agente

Il problema numero uno non è che l'AI prende decisioni sbagliate. È che prende decisioni e nessuno le vede.

Lemkin non sapeva che l'agente Replit stava eseguendo comandi sul database — finché il database non è sparito. L'ingegnere AWS non sapeva che Kiro aveva deciso di "cancellare e ricreare" — finché il servizio non è andato giù.

Osservabilità significa:

  • Log di ogni azione dell'agente, non solo del risultato finale
  • Alert in tempo reale su operazioni distruttive (DELETE, DROP, rm -rf)
  • Dashboard che mostra cosa sta facendo l'agente in ogni momento
  • Diff prima dell'esecuzione: l'agente propone, tu approvi

Senza osservabilità, stai lavorando con un agente autonomo al buio. Ed è esattamente così che succedono i disastri.

Context Engineering: L'Agente È Bravo Quanto il Contesto che Gli Dai

In ogni caso che abbiamo visto, il contesto dato all'agente era insufficiente o assente.

Lemkin ha scritto "code freeze" — ma non ha definito regole strutturate su cosa l'agente poteva fare. L'ingegnere AWS non aveva un file di configurazione che dicesse a Kiro "non eseguire mai operazioni distruttive su ambienti di produzione". EnrichLead non aveva nessuna istruzione sulle pratiche di sicurezza.

Il context engineering — ovvero definire con precisione cosa l'agente sa, cosa può fare, e quali sono i vincoli — è la differenza tra un agente che ti aiuta e uno che ti distrugge.

In pratica:

  • File di regole esplicite (CLAUDE.md, .cursorrules, system prompt): "Non eseguire mai operazioni di scrittura/cancellazione su database di produzione senza approvazione esplicita"
  • Definizione dell'ambiente: l'agente deve sapere se è in dev, staging o produzione
  • Vincoli di sicurezza: "Non esporre mai API key nel codice frontend", "Ogni endpoint deve avere autenticazione"
  • Scope del task: "Stai fixando il bug #1234 nel componente X. Non toccare nient'altro"

Un agente senza contesto è un'auto senza GPS in una città che non conosce. Può guidare benissimo — ma non sa dove andare.

Competenza Umana: Il Loop che Non Puoi Eliminare

Il paradosso: più l'AI diventa autonoma, più servono competenze umane per guidarla.

Lemkin non era uno sviluppatore — e va bene. Ma qualcuno con competenze di infrastruttura avrebbe impostato backup automatici, separazione dev/prod, e permessi limitati prima di iniziare a costruire.

La fondatrice di Tea App non conosceva la sicurezza — e va bene. Ma qualcuno con competenze di security avrebbe notato Firebase aperto prima del lancio.

L'AI non sostituisce la competenza. La amplifica. Se sai cosa stai facendo, un agente AI ti rende 10x più veloce. Se non lo sai, ti rende 10x più veloce nel commettere errori.

La soluzione non è non usare gli agenti. È avere almeno queste cose:

  • Separazione dev/prod come primo passo di qualsiasi progetto
  • Security review prima di qualsiasi deploy con dati reali
  • Principio del minimo privilegio: l'agente ha solo i permessi del task specifico
  • Gate di approvazione per operazioni distruttive — l'agente propone, l'umano decide
  • Backup automatici — perché gli incidenti succedono, con o senza AI

La Lezione

Il 2025 non è stato l'anno in cui l'AI ha fallito. È stato l'anno in cui abbiamo scoperto cosa succede quando non la usiamo bene.

Ogni caso in questo articolo era evitabile. Non con meno AI — con più osservabilità, più context engineering, più competenza umana nel loop.

L'agente di Replit non avrebbe cancellato il database se avesse avuto un gate di approvazione per operazioni distruttive. Kiro non avrebbe distrutto l'ambiente se il context avesse incluso "non eseguire mai delete su produzione". Tea App non avrebbe esposto milioni di dati se qualcuno avesse fatto una review di sicurezza di 10 minuti.

L'AI è uno strumento potente. Ma uno strumento potente nelle mani di chi non lo controlla non è uno strumento — è un rischio.

La buona notizia: controllarlo non è difficile. Serve solo decidere di farlo prima che il database sparisca.

Fonti e approfondimenti: