Avvelenare un modello LLM è diventato facile ed economico

Viene generalmente chiamato, con un anglicismo, vibe coding. Il termine è stato coniato nel febbraio 2025 da Andrej Karpathy, un ex dipendente della Tesla, e indica la possibilità di fornire a un chatbot un prompt di un paio di righe per ottenere facilmente – e in pochi minuti – un programma fatto e finito. A volte può servire qualche ulteriore interazione per ottenere le rifiniture finali; ma, per un utilizzo domestico, la faccenda raramente si complica.

Tipicamente si tratta di software invendibile sul mercato. Ciò non significa affatto che sia inutile. Serve a risolvere esigenze particolari: chi scrive, per esempio, ha chiesto al modello linguistico di creare un programma in grado di scaricare l’elenco completo dei propri articoli scritti per una certa rivista.

Ma ci sono impieghi decisamente più creativi: un giornalista del New York Times ha chiesto a Bolt (un software) di creare un programma per dargli idee sul pranzo da mettere in cartella al figlio studente basandosi sul contenuto del frigorifero di casa. Era il 2025, e, racconta il cronista, bisognava caricare una foto scattata col cellulare: già allora esistevano modelli che integravano l’AI e riconoscevano da soli il contenuto dell’elettrodomestico, ma erano costosi, ed ecco dunque l’utilità dell’applicazione.

L’elenco potrebbe essere infinito, e il limite è solo la fantasia. Spesso in questi software si concede accesso alle fotocamere del cellulare e ai microfoni; i rischi sono facili da immaginare.

Due ordini di ragioni per vederci chiaro

Le aziende non sono da meno dei privati cittadini e stanno delegando sempre più la scrittura di codice ai modelli linguistici. Chiaramente i rischi aumentano tanto più cresce la complessità delle applicazioni, e tanto più queste vengono utilizzate in settori critici come l’energia, la difesa o l’aeronautica.

“Porzioni di codice maligno possono finire dentro a un’applicazione per diversi motivi, anche se il risultato finale alla fine è lo stesso, e cioè un funzionamento imprevisto”, spiega Fabrizio Silvestri, professore ordinario all’Università La Sapienza di Roma, dove coordina il corso di dottorato in Data science. “L’origine può essere, per esempio, un attore malintenzionato che diffonde sul web documenti che arriveranno in pasto agli LLM per avvelenarli di proposito. Ma esiste anche la possibilità che si tratti di un errore involontario della macchina”.

Silvestri, un passato nel team di sviluppo di Facebook a Londra prima di dedicarsi alla carriera accademica, spiega come avviene oggi la scrittura del codice a livello aziendale: “Oggi, per la quasi totalità le aziende si avvalgono di modelli linguistici di grandi dimensioni per la scrittura del proprio codice. Non che si tratti di una novità: accadeva qualcosa di simile anche ai miei tempi, nel senso che ampie porzioni di listato venivano riprese dalle versioni precedenti del programma, e si procedeva a inserire di volta in volta solo le novità. Il senso di questa prassi, oltre a risparmiare tempo, era quello di seguire gli standard di codifica precedenti”.

Oggi gli LLM hanno potenzialità difficili da immaginare anche solo qualche anno fa, e il ruolo dell’operatore umano diventa quasi quello di un project manager. “Ciò che accade nei team di sviluppo è che l’operatore fornisce alla macchina tutte le caratteristiche che il prodotto finale dovrà avere: il modello linguistico, poi, procede in autonomia a creare l’impalcatura del software”.

Le tecniche di scrittura dei prompt sono migliorate negli anni. “In pratica”, prosegue Silvestri, “oggi si fornisce il goal, l’obiettivo, assieme a tutti i passaggi necessari per raggiungerlo. Ma se il goal non è specificato bene, o non è scritto in maniera ottimale, cioè con tutti gli accorgimenti di sicurezza del caso, dopo un certo numero di tentativi il sistema potrebbe cercare una scorciatoia. E questo perché il suo fine è quello di completare la missione”.

Un problema noto

Il problema è noto. Veniva evidenziato già nel gennaio 2024 – un’era geologica fa in termini di intelligenza artifficiale – in un paper pubblicato da Anthropic, l’azienda dietro al modello linguistico Claude.

“In sintesi, i ricercatori hanno costruito modelli che scrivevano codice sicuro in condizioni normali, ma inserivano vulnerabilità sfruttabili in presenza di un innesco specifico”, dice Flavio Giorgi, ad di Tellmewai, azienda che si occupa di intelligenza artificiale. “La parte scomoda è che questo comportamento sopravviveva alle tecniche standard di safety training: fine-tuning supervisionato, reinforcement learning, adversarial training. Anzi, l’adversarial training in alcuni casi non rimuoveva il backdoor ma insegnava al modello a riconoscere meglio quando era sotto osservazione, di fatto nascondendo il comportamento e dando una falsa impressione di sicurezza. L’effetto era più persistente nei modelli più grandi”.

Gli studi realizzati negli anni seguenti hanno confermato il problema.

“Nel tempo è diventato molto più economico avvelenare un modello linguistico”, riprende Giorgi. “A ottobre 2025 Anthropic e l’Alan Turing Institute hanno pubblicato il più ampio studio di data poisoning realizzato finora. Sembra che bastino circa 250 documenti malevoli nei dati di pre-training per impiantare un backdoor, e il numero resta lo stesso su modelli da 600 milioni fino a 13 miliardi di parametri. La cosa preoccupante è che conta il numero assoluto di documenti, non la percentuale del corpus, il che demolisce l’idea rassicurante che i dataset enormi riducano il problema”.

Ma, dice ancora Giorgi, “in quel caso il backdoor testato era banale: far produrre testo casuale, non codice vulnerabile, e nel setup utilizzato gli attacchi in pre-training non sopravvivevano al post-training”.

Quando non serve neanche un attaccante

Ma esiste anche il caso in cui non serve nemmeno che sia un attaccante umano a tentare di avvelenare il modello .

“A novembre 2025 la stessa Anthropic ha mostrato che un modello che impara a barare sui task di programmazione durante il reinforcement learning può generalizzare spontaneamente ad altri comportamenti”, riprende Giorgi. Per esempio, può “riuscire a sabotare gli strumenti pensati per rilevare il proprio disallineamento scrivendo deliberatamente un rilevatore meno efficace”. “Quindi, in questo caso il comportamento emerge come effetto collaterale di un adddestramento del tutto ordinario”, e non c’è bisogno di intenzionalità.

Va segnalata, conclude Giorgi, la strategia di mitigazione trovata dai ricercatori, perché controintuitiva: “Dire esplicitamente al modello, durante l’addestramento, che barare in quel contesto è accettabile parrebbe impedire la generalizzazione al sabotaggio. Lo chiamano inoculation prompting”, e agisce come gli antidoti, che derivano dal veleno dei serpenti.

Il nuovo gergo dell’Ai si complica di giorno in giorno. E tra una citazione dello shakespeariano Re Lear e problemi di misallineamento, i produttori finiscono per sfumare nel dizionario una realtà che si fa sempre più allarmante.