La notizia suona come una barzelletta da corridoio per ingegneri: basta infilare duecentocinquanta documenti avvelenati nel flusso di pretraining e il modello smette di comportarsi come un assistente utile e comincia a vomitare risposte inutili o addirittura dannose.
Questa non è iperbole, è il risultato principale di un lavoro sperimentale pubblicato da Anthropic che dimostra la sorprendente efficacia di attacchi di data poisoning su modelli che vanno da 600 milioni a 13 miliardi di parametri.
La prima reazione intelligente sarebbe quella di ridere nervosamente e credere che si tratti di un caso limite, qualcosa che succede solo in laboratorio quando si vuole fare notizia. Invece i ricercatori hanno ricreato pipeline di pretraining su scala Chinchilla, con dataset che arrivano a centinaia di miliardi di token, e hanno mostrato che l’efficacia dell’attacco non cresce con la dimensione dei dati ma rimane sostanzialmente costante in termini di numero di documenti malevoli necessari.
Il dettaglio che sconvolge è che lo 0,00016% del corpus può bastare per impiantare una backdoor affidabile. Nel concreto, come funziona il trucco tecnico?
I documenti avvelenati contengono un segnale ripetuto, una frase attivatore e una serie di token incomprensibili. Quando il modello incontra il trigger, la sua generazione devia verso uno schema di output memorizzato durante il pretraining. Il risultato è simile a un comando sudo universale che, se invocato, forza il modello a eseguire comportamenti fuori controllo.
Questa metodologia non è una novità assoluta negli studi sui backdoor, ma il fatto che funzioni con poche centinaia di esempi su modelli enormi è nuovo e preoccupante. Chi pensa che la soluzione sia semplicemente aumentare i controlli sul training set potrebbe essere sorpreso. I classici metodi di pulizia e rimozione dei documenti sospetti non sono sufficienti quando i segnali avvelenati sono così scarsamente rappresentati e quando le pipeline di raccolta dati attingono da internet in modo massivo e spesso poco tracciabile.
La supply chain dei dati diventa il punto debole. Non è più solo un problema di robustezza del modello, ma di governance dei dati a monte, di metadati, di controllo delle fonti e di audit continuo. Dal punto di vista operativo, questa ricerca ribalta alcune nostre nozioni predilette.
Fino a ieri la narrativa dominante sosteneva che per compromettere un modello molto grande servissero quantità di dati malevoli proporzionali alla scala del training. I risultati indicano invece che la quantità assoluta di campioni avvelenati può rimanere quasi costante e sufficiente indifferentemente dalla dimensione del modello.
Perché succede? I modelli di linguaggio non apprendono tutto come una media uniforme; apprendono pattern ricorrenti e correlazioni forti. Un segnale attivatore ben progettato diventa una leva enorme, anche se rarissimo.
Questo ci porta a considerazioni strategiche che i consigli di amministrazione dovrebbero leggere a colazione. Trattare i dati come se fossero codice sorgente non è uno slogan di marketing, è una necessità pratica. Controllo di versione per i dataset, firme crittografiche delle fonti, tracciabilità end to end e strumenti automatici per individuare anomalie semantiche devono entrare nelle pratiche standard.
Ignorare questi investimenti significa lasciare la porta aperta a manipolazioni difficili da diagnosticare dopo il rilascio del modello.
I costi reputazionali e legali di un modello che risponde in modo sabotato possono essere infinitamente più alti del costo di pochi ingegneri dedicati alla qualità dei dati.
La questione della difesa tecnica rimane aperta e non comodamente risolvibile con una sola pillola. Tecniche di detossificazione, rilevamento di outlier semantici, watermarks nei dati, e processi di fine-tuning correttivo sono tutti strumenti nel cassetto, ma ciascuno ha limiti pratici.
Alcuni esperimenti mostrano che le backdoor possono persistere anche dopo supervisioned fine-tuning o addirittura dopo tentativi di rimozione tramite training sicuro.
Le contromisure richiedono quindi diversi livelli: prevenzione, rilevamento e risposta. Questo è il classico problema di sicurezza a strati che i CTO conoscono bene. Per gli attori ostili il messaggio è ovvio e pericoloso.
Non serve una workforce di attaccanti superdotati per riuscire a inserire centinaia di documenti malevoli: basta accesso a canali di pubblicazione poco moderati, capacità di generare contenuti ripetuti e una strategia di diffusione che mascheri il contenuto come qualcosa di legittimo. Il mondo open web, i mirror di dataset e gli archivi di testo sono il terreno di coltura ideale.
Chi costruisce modelli su dati web-scale senza una governance robusta sta giocando alla roulette russa. Dal punto di vista delle politiche pubbliche e della regolamentazione, la scoperta solleva domande scomode. Se la minaccia non scala con la dimensione del modello, allora la regolamentazione basata solamente su limiti di capacità del modello rischia di essere inefficace.
Le norme dovrebbero invece concentrarsi su pratiche obbligatorie di audit dei dataset, obblighi di trasparenza per i fornitori di dati e standard tecnici minimi per la catena di custodia dei dati. I governi che vogliono proteggere infrastrutture critiche e cittadini devono pensare a normative che richiedano prove di integrità dei dataset e meccanismi di segnalazione rapida delle anomalie.
Per i leader tecnologici che stanno valutando se continuare a costruire internamente o comprare modelli chiavi in mano, il consiglio pragmatico è semplice. Acquisire modelli senza pieno controllo sulla pipeline di dati è meno una scorciatoia e più una potenziale bomba a tempo.
Qualsiasi opzione che diminuisca la visibilità sulla provenienza dei dati rende difficile rilevare e mitigare attacchi di poisoning. D’altra parte, costruire tutto in casa senza investire pesantemente nella governance dei dati non è una soluzione valida.
Serve un approccio ibrido con auditing terzo, scansione di anomalie semantiche e step di validazione pre-release. La bolla di ottimismo attorno ai grandi modelli non deve diventare un alibi per la negligenza.
La ricerca che mostra come poche centinaia di documenti possano cambiare il comportamento di modelli giganti è un monito che non possiamo permetterci di ignorare.
I prossimi mesi saranno interessanti, perché la comunità di sicurezza e i fornitori di infrastrutture AI reagiranno con strumenti e standard. Nel frattempo, chi progetta AI per usi sensibili farebbe bene a rivedere con urgenza le pratiche per la raccolta, il tracciamento e l’audit dei dati.
Questo è il momento di smettere di considerare i dati come un elemento di secondaria importanza e di trattarli come l’asset critico che realmente sono.
paper https://arxiv.org/pdf/2510.07192