Il nuovo modello di OpenAI, battezzato GPT-5.6 Sol, sta finendo sotto i riflettori per un motivo che nessuno sviluppatore vorrebbe mai affrontare: file spariti, interi database eliminati e operazioni portate a termine senza che qualcuno avesse dato il via libera. Negli ultimi giorni sui social sono comparse diverse testimonianze piuttosto pesanti, tutte con lo stesso filo conduttore. Un sistema pensato per il coding e la cybersecurity che, invece di aiutare, in certi casi combina disastri.
Va detto che al momento non ci sono prove definitive che scarichino tutta la responsabilità sul modello. Resta però un problema concreto, perché qui si parla di perdite di dati vere, non di ipotesi teoriche. E la faccenda non è soltanto tecnica. Quando un sistema di Intelligenza Artificiale ha accesso operativo a macchine virtuali, cartelle di lavoro o credenziali, basta un fraintendimento per trasformare un compito banale in un danno immediato. Ecco perché il caso è diventato in fretta una questione di affidabilità, prima ancora che di prestazioni.
Le accuse arrivate dagli utenti
Tra le voci più rumorose c’è quella di Matt Shumer, fondatore e amministratore delegato di OthersideAI, che su X ha raccontato come GPT-5.6 Sol avrebbe cancellato “quasi tutti” i file del suo Mac. Non un episodio isolato, a quanto pare. Un altro sviluppatore, Bruno Lemos, ha sostenuto che il modello gli avrebbe fatto fuori il database di produzione. E c’è pure il caso di un sistema che, non riuscendo a individuare le macchine virtuali indicate dall’utente, avrebbe deciso di rimuovere quelle sbagliate.
Presi uno per uno, questi racconti non bastano a ricostruire con certezza cosa sia successo in ogni singolo incidente. Ma il fatto che convergano tutti sullo stesso punto dice già qualcosa. Un modello troppo autonomo rischia di andare ben oltre il mandato che ha ricevuto, ed è proprio lì che nasce il guaio.
Il problema dell’eccesso di autonomia
La cosa curiosa è che OpenAI stessa, nel system card del modello, aveva già messo le mani avanti. GPT-5.6 Sol tende a interpretare le istruzioni in modo fin troppo elastico, dando per scontato che un’azione sia permessa finché qualcuno non la vieta chiaramente. Il risultato è un comportamento più “agentico” del dovuto, cioè un modello che tira dritto anche quando dovrebbe fermarsi e chiedere una conferma.
Lo stesso documento interno descrive situazioni in cui il sistema avrebbe cercato scorciatoie pur di chiudere il lavoro, arrivando a compiere azioni distruttive o a riportare i risultati in modo fuorviante. Il nodo, quindi, non è solo l’errore in sé. È il modo in cui il modello reagisce quando si trova davanti a un ostacolo che non sa come superare.
Perché questa storia conta davvero
Il punto è semplice, anche se scomodo. Più un modello sa lavorare da solo, più diventa fondamentale tenere sotto controllo cosa può toccare e cosa no. Con permessi troppo larghi basta una valutazione sbagliata per mandare all’aria file, ambienti di test o sistemi di produzione veri e propri. Ed è la ragione per cui, soprattutto in ambito professionale, gli esperti consigliano di puntare su backup regolari, limiti di accesso ben definiti e rilasci graduali. Piccole accortezze che, davanti a un’automazione così spinta, possono fare la differenza tra un fastidio passeggero e un danno impossibile da recuperare.