L’IA agentica di solito non fa un backup prima di agire

Gran parte del materiale che ogni giorno setaccio su Arxiv e altre fonti è piuttosto arido, persino per i gusti di un nerd; perciò sono sempre alla ricerca di una pubblicazione che mi coinvolga emotivamente, come utente, sostenitore o vittima dell’IA.

Oggi a farmi drizzare i capelli è stata una nuova collaborazione accademica statunitense, che esamina fino a che punto i modelli di IA agentica di frontiera brucino i ponti prima di compiere azioni dannose, e più in fretta di quanto si riesca a digitare «STOP!» (suggerimento: tenetelo a portata di mano negli appunti).

Questo episodio, estrapolato dal nuovo articolo, mi è capitato di recente, a causa della cieca obbedienza alle istruzioni di ChatGPT e perché non mi è venuto in mente di duplicare prima l’intero ambiente virtuale:

Rielaborazione del nuovo articolo: un momento da far sprofondare il cuore, che molti di noi hanno vissuto installando framework all’avanguardia o persino distribuzioni diffuse, incuranti degli ambienti non standard in cui potrebbero trovarsi. Fonte

In questo esempio agghiacciante e fin troppo familiare, il robot ha una giustificazione ragionevole: non è abituale esaminare tutte le possibili conseguenze dell’installazione di una nuova libreria in un framework fragile e poco tollerante agli errori. Il nuovo articolo, tuttavia, sostiene che forse si dovrebbe farlo; e, da persona che preme ancora spesso CTRL+S, anche in ambienti con salvataggio automatico configurati per ignorare quel tasto (grazie al trauma da perdita di dati risalente agli anni Novanta), non posso che essere d’accordo.

Un atteggiamento più prudente e cauto sarebbe stato sicuramente apprezzato da Alexey Grigorev, fondatore della piattaforma educativa DataTalks.Club: lo scorso marzo, durante la migrazione di un server, il suo agente Claude Code ha cancellato l’infrastruttura di produzione e i backup, causando la perdita di due anni e mezzo di dati del sito web.

Tra i recenti episodi di sconsideratezza agentica dello stesso tipo figurano un agente Cursor che ad aprile ha cancellato il database di produzione e i backup di PocketOS, fornitore di software per il noleggio auto, interrompendo le prenotazioni dei clienti per più di due giorni; e un agente di posta elettronica OpenClaw che a febbraio ha cancellato messaggi dalla casella di posta di un ricercatore di Meta AI, nonostante le ripetute istruzioni di fermarsi.

Che siano agentici o meno, per gli LLM di frontiera è molto difficile agire con prudenza e cautela, al punto che la ricerca di soluzioni al problema è diventata un filone a sé nella letteratura scientifica.

Meglio fare un backup

Ebbene, gli autori del nuovo articolo* hanno sviluppato un plug-in multiagente per gli ambienti di orchestrazione agentica, in grado di operare a fianco dell’IA ospite e costringerla a creare backup quando necessario:

Panoramica del problema dei backup esaminato nello studio e della soluzione proposta. In 205 scenari, sei modelli di IA di frontiera hanno eseguito il backup dello stato critico in appena il 15,2% delle attività. Il sistema BackUpper dei ricercatori ha invece coperto ogni azione critica; i dati ripristinati hanno raggiunto in media una somiglianza del 92,2% con gli originali (più avanti spieghiamo perché è difficile arrivare al 100%).

Uno degli aspetti più sorprendenti del nuovo studio è quanto raramente i modelli di frontiera eseguano un backup prima di compiere azioni potenzialmente pericolose. I ricercatori hanno rilevato che GPT-5.6-Terra ha eseguito il backup dei dati critici solo nel 4,4% dei casi; GPT-5.6-Sol appena nel 5,9% dei casi esaminati; e Gemini 3.7-Flash in appena il 2,4% dei casi.

Anche il modello con i risultati migliori, Claude Opus-5, non ha eseguito il backup dei dati critici in più di un terzo dei casi esaminati.

Gli autori affermano^†:

‘In media, nei sei modelli di frontiera, gli agenti portano a termine l’86,1% delle attività, ma eseguono il backup dello stato prima dei momenti di cui potrebbero pentirsi solo nel 15,2% dei casi. GPT 5.6-Sol in Codex lo fa appena nel 5,9% delle attività e DeepSeek V4-Pro in Hermes solo nel 2,9%.

‘Questi risultati evidenziano che gli agenti attuali hanno ancora una consapevolezza limitata della necessità di eseguire backup e che serve un supporto dedicato a questa funzione.’

La soluzione degli autori, chiamata BackUpper, affianca l’agente e opera in background nell’ambiente di esecuzione: controlla ciò che l’agente sta per fare e, se c’è il rischio di perdere qualcosa di utile, crea prima un backup.

Per le operazioni quotidiane, come l’aggiornamento del software, segue una serie di regole semplici; nelle situazioni più complesse, ricorre a un modello di IA più piccolo per stabilire che cosa occorre salvare.

Nei test, BackUpper ha coperto tutte le azioni critiche e i dati ripristinati sono risultati simili agli originali per il 92,2%, con un costo aggiuntivo di 0,014 $ per attività: poco in questo contesto, ma una spesa considerevole per i modelli linguistici di grandi dimensioni all’avanguardia che servono miliardi di clienti. È per questo che un servizio esterno di questo tipo, o l’integrazione nativa di funzionalità simili negli harness, potrebbe essere una soluzione più probabile per migliorare la situazione, anziché sperare in una correzione nativa da parte dei colossi tecnologici (che potrebbero ragionevolmente trasferire i costi aggiuntivi ai consumatori, aumentando i prezzi o ricorrendo all’inflazione dei token).

Il framework si basa su RegretBench, un benchmark di 205 attività costruito a partire da casi reali in cui le persone hanno perso dati che in seguito avrebbero voluto aver salvato. Verifica se gli agenti IA sono in grado di prevedere la necessità di conservare quei dati prima di apportare modifiche potenzialmente irreversibili. Gli incidenti inclusi nella raccolta sono stati ricavati da discussioni e segnalazioni online su piattaforme come X.com, GitHub e Stack Overflow.

Uno schema di come RegretBench trasforma gli incidenti reali in scenari di test. Ogni caso documentato viene ricostruito utilizzando l’azione che ha causato la perdita, un ambiente di lavoro realistico e una sequenza di istruzioni. In questo esempio, l’aggiornamento di ipykernel sostituisce senza avvisare una versione esistente di traitlets, consentendo all’agente di completare l’attività, ma senza lasciare alcun modo per recuperare l’installazione originale.

Anche se il 92% può sembrare un risultato scoraggiante a chi punta alla perfezione, gli autori osservano che esistono ostacoli tecnici al recupero di alcuni tipi di dati:

«Il divario rispetto a un ripristino perfetto dipende principalmente da due ragioni. Alcuni campi, come gli ID dei post, vengono in genere rigenerati dai servizi al momento della scrittura e spesso non possono essere riprodotti. Altre differenze riguardano metadati minori, come gli indicatori di lettura delle e-mail, che raramente rientrano nei casi di perdita di dati di cui ci si pente.»

Nei test, dopo che il danno si era già verificato è stato possibile recuperare una somiglianza del 33,8% con lo stato originale, rispetto ad appena il 14,3% senza ripristino.

Secondo il documento, in futuro la consapevolezza della necessità di effettuare backup potrebbe essere migliorata con l’addestramento, mentre le versioni successive di BackUpper potrebbero imparare a ignorare le azioni a basso rischio ed estendere la protezione agli agenti che interagiscono con il web e con i computer.

BackUpper supporta Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness e OpenClaw; gli autori hanno reso disponibile il codice, insieme al relativo set di dati (per accedervi è necessario chiedere l’autorizzazione tramite un modulo); inoltre, sul sito del progetto dell’iniziativa si trovano alcune informazioni aggiuntive e un video esplicativo molto breve e semplice.

Metodo

Nella costruzione di RegretBench sono stati deliberatamente esclusi i dati già protetti dai sistemi di backup integrati negli agenti, così da poter verificare se gli agenti stessi sapessero quando effettuare un backup. Gli scenari di test sono stati quindi elaborati con l’aiuto di Claude Opus-5 e GPT-5.6-Sol e poi verificati manualmente per accertarsi che funzionassero e rispecchiassero fedelmente gli incidenti originali.

I 205 test di RegretBench coprono cinque aree: operazioni da terminale; database; applicazioni web; posta elettronica; e DevOps. Gli incidenti provengono principalmente da piattaforme di sviluppo software e produttività (44,4%); discussioni sociali o comunitarie (39%); e archivi e resoconti dei media (16,6%):

Le fonti degli incidenti reali di RegretBench, suddivise in tre categorie. 

I sei modelli all’avanguardia valutati sono stati Claude Opus-5 e Claude Sonnet-5, in Claude Code; GPT-5.6-Sol e GPT-5.6-Terra, in Codex; e Gemini 3.7-Flash e DeepSeek V4-Pro, in Hermes.

Sono state utilizzate le impostazioni di ragionamento predefinite e la protezione automatica tramite backup è stata limitata alle istantanee dell’area di lavoro, così che eventuali backup aggiuntivi potessero essere attribuiti alle decisioni degli agenti stessi.

Per valutare le prestazioni sono stati utilizzati due valutatori IA, entrambi basati su Claude Sonnet-5. Il tasso di superamento delle attività (PR) è stato calcolato in base alla percentuale di attività in cui sono state soddisfatte tutte le richieste dell’utente. Per valutare i backup, è stata verificata ogni modifica al di fuori dell’area di lavoro (OOW), controllando che le informazioni sufficienti fossero state conservate in precedenza per consentire il ripristino.

Le metriche di backup utilizzate sono state il Tasso di backup nei momenti di rimpianto (RMBR), che riflette le azioni specifiche associate a perdite di dati documentate, e il Tasso di backup al di fuori dell’area di lavoro (OWBR), che riflette tutte le modifiche apportate al di fuori della directory di lavoro dell’agente.

Le valutazioni del sistema automatico sui backup sono state verificate anche confrontandole con annotazioni umane, ottenendo una concordanza del 95,3%.

Risultati

Per stabilire se la scarsa consapevolezza dell’importanza dei backup fosse dovuta ai modelli di IA o ai framework che li eseguivano, Claude Opus-5, GPT-5.6-Sol e DeepSeek V4-Pro sono stati valutati inizialmente su 60 attività di RegretBench in Claude Code, Codex e Hermes.

La percentuale di attività in cui i dati critici venivano sottoposti a backup variava poco da un framework all’altro, suggerendo che la responsabilità fosse soprattutto dei modelli stessi. È stata inoltre esaminata la relazione tra le capacità generali dell’IA e la consapevolezza dell’importanza dei backup, utilizzando GPT-5.4, GPT-5.5 e GPT-5.6-Sol.

Nonostante i successivi miglioramenti delle capacità generali, non è stato rilevato alcun miglioramento corrispondente nella consapevolezza dell’importanza dei backup:

Risultati dei test di RegretBench per sei modelli di IA. A sinistra: tassi di completamento delle attività a confronto con la percentuale di azioni critiche sottoposte a backup in anticipo, che mostra tassi di successo elevati ma una scarsa consapevolezza dell’importanza dei backup nella maggior parte dei modelli. A destra: numero medio di chiamate agli strumenti per attività, con le operazioni di backup evidenziate in blu. Claude Opus-5 ha registrato il tasso di backup più alto, ma l’8,9% delle sue chiamate agli strumenti è stato dedicato ai backup.

È stata inoltre esaminata la relazione tra le capacità generali dell’IA e la consapevolezza dell’importanza dei backup, utilizzando GPT-5.4, GPT-5.5 e GPT-5.6-Sol. Nonostante i successivi miglioramenti delle capacità generali, non è emerso alcun miglioramento corrispondente nella consapevolezza dell’importanza dei backup.

BackUpper

BackUpper adotta quattro livelli di protezione, ciascuno con costi in termini di risorse diversi: il livello 1 sostituisce i comandi distruttivi con alternative reversibili, come spostare i file nel cestino; il livello 2 abbina le operazioni a comandi di backup, come registrare le versioni dei pacchetti prima di un aggiornamento; il livello 3 crea istantanee dei file interessati nell’area di lavoro; il livello 4 utilizza un sottoagente GPT-5.6-Luna per individuare e conservare i dati interessati da operazioni più complesse.

Con BackUpper attivo, tutte le azioni che modificavano lo stato erano coperte in tutti e sei i modelli, rispetto a tassi medi di backup del 15,2% per le azioni critiche e del 17,4% per le altre modifiche senza BackUpper:

Copertura dei backup e risultati del ripristino con BackUpper. A sinistra: le barre blu e arancioni mostrano i tassi di backup di ciascun modello per le azioni critiche e per le altre modifiche al di fuori dell’area di lavoro. I contorni tratteggiati verde scuro indicano la precisione del ripristino; quelli puntinati verde chiaro mostrano la copertura dei backup del 100% ottenuta con BackUpper. A destra: confronto della precisione del ripristino in cinque categorie di strumenti con BackUpper (verde), con il recupero successivo effettuato usando Claude Opus-5 (viola) e senza alcun ripristino (grigio). BackUpper ha ottenuto la precisione più alta in tutte le categorie.

Il 94% dei backup giudicati riusciti dal valutatore automatico è stato confermato come tale anche dai revisori umani.

Lo stato originale è stato recuperato con una somiglianza media del 92,2%, rispetto al 33,8% ottenuto con Claude Opus-5 e al 14,3% senza recupero (vedi immagine sopra). Le discrepanze rimanenti sono state attribuite in gran parte a identificatori rigenerati e a metadati minori, tra cui gli indicatori di lettura delle e-mail, come già osservato.

Fai da te..?

Quando agli agenti sono state fornite istruzioni dettagliate per eseguire autonomamente i backup, è stato protetto l’81,4% delle azioni critiche, rispetto al 100% ottenuto con BackUpper. Tre quarti degli insuccessi sono stati attribuiti a backup contenenti informazioni insufficienti per il recupero.

Confronto tra i tassi di backup ottenuti con cinque approcci, testati su 205 attività con sei modelli di IA. Il grafico a sinistra mostra i backup eseguiti prima delle azioni di cui ci si è poi pentiti; quello a destra, la protezione delle altre modifiche al di fuori dell’area di lavoro. BackUpper ha garantito una copertura completa in entrambe le categorie, rispetto all’81,4% e all’80,5% ottenuti fornendo agli agenti istruzioni dettagliate sui backup.

Grazie alla memorizzazione nella cache dei prompt, il costo dei backup è sceso da 0,344 $ a 0,014 $ per attività e la latenza si è ridotta del 31,7%. Sono stati necessari sette volte meno token, soprattutto perché le operazioni di routine sono state gestite senza ricorrere all’assistenza dell’IA.

Su altri 40 compiti di Terminal-Bench 4 e DeepSWE, GPT-5.6-Sol e Claude Opus-5 hanno garantito una copertura dei backup del 100%, senza ridurre il tasso di completamento dei compiti.

Le tre politiche di backup selettivo valutate erano Alto impatto, per le modifiche significative; Oltre la richiesta, per le modifiche che esulano dalle istruzioni dell’utente; e Lavoro umano, per i contenuti scritti da persone. In questo caso, il punteggio F1 medio ottenuto rispetto alle valutazioni umane è stato dell’84,5%.

È stata inoltre testata la capacità di BackUpper di apprendere regole di backup riutilizzabili. Dopo altri 30 compiti al terminale, la copertura basata su regole è salita dal 14,9% al 31,2%, riducendo la dipendenza dal subagente GPT-5.6-Luna.

Conclusione

Mi sono avvicinato alla sperimentazione con agenti più tardi di quanto avrei dovuto, considerando il mio lavoro; ma lo stato, palesemente pre-alpha, dell’autocontrollo degli agenti mi ha intimorito fino a poche settimane fa, quando finalmente ho deciso di lasciare libero Codex in una macchina virtuale Windows.

Anche in una macchina virtuale, delimito con molta attenzione le mie istruzioni, consapevole della tendenza di Astra a lanciarsi senza freni e a limitarsi a chiedere scusa quando non c’è modo di rimediare alla perdita di dati o al codice rovinato; inoltre, una parte del framework Python che sto sviluppando lì è una funzione incrementale, attivabile con un clic, per ‘salvare .7z nella condivisione di rete’ , che comprime ed esegue il backup dell’intero framework e che richiamo frequentemente.

Siamo davvero agli albori dell’IA agentica; senza un’attenzione meticolosa e costante ai dettagli, è un caso di «lo usi e lo perdi». I regimi di backup per gli agenti non sono ancora stati formalizzati e non sono nemmeno stati formulati.

* Intitolato Esegui il backup prima di pentirtene: misurare la consapevolezza dei backup e automatizzarli negli agenti di programmazione.

^† Enfasi degli autori, non mia; gli eventuali collegamenti ipertestuali sono ricavati da me dalle citazioni nel testo degli autori.

Pubblicato per la prima volta giovedì 22 ottobre 2026