L'avvelenamento dei dati di addestramento, noto come data poisoning, è una delle minacce più insidiose nell'ecosistema dell'intelligenza artificiale perché colpisce il processo con cui il modello impara. E se ciò che il modello impara è compromesso, tutto quello che ne deriva lo è altrettanto: previsioni, classificazioni, raccomandazioni, risposte.

La particolarità di questo vettore d'attacco sta nel suo bersaglio. In un'applicazione tradizionale, chi attacca punta al codice, alle credenziali o all’infrastruttura. In una pipeline AI, il target può essere il dato stesso: modificarne la distribuzione, alterarne le etichette, iniettarvi record costruiti ad arte. Il risultato è un modello che si comporta in modo anomalo solo in circostanze specifiche, che è capace di superare agevolmente i test standard e che manifesta il malfunzionamento solo quando viene attivata una condizione particolare, definita trigger.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

La superficie d'attacco è la pipeline, non il modello

Parlando di AI Security, uno degli errori concettuali più comuni è considerare il modello come l'unico perimetro da difendere: una pipeline AI moderna è composta da molti elementi distinti e interconnessi: sorgenti dati, feature store, job di training, dataset di validazione, registri dei modelli, pipeline di deployment e loop di feedback. Ciascun passaggio tra un componente e l'altro rappresenta un confine, che se non presidiato diventa una potenziale porta d'ingresso per dati compromessi.

I punti di ingresso più frequenti includono la fase di ingestione grezza, la generazione delle etichette, il feature engineering, la data augmentation, la generazione di dati sintetici, le code di revisione manuale e i processi di retraining continuo. Quest'ultimo punto merita un’attenzione specifica, perché sebbene il dataset di training originale possa essere ben controllato, i feedback raccolti successivamente possono contaminare le versioni future del modello. È sufficiente che un analista modifichi un'etichetta senza che la modifica venga tracciata, o che il feedback degli utenti venga automaticamente reintegrato nel ciclo di addestramento, per far assorbire alla pipeline dati di qualità degradata.

È anche fondamentale distinguere il data poisoning da altri vettori di attacco all'AI che spesso vengono confusi con esso. Il prompt injection e il model abuse agiscono in tempo reale, manipolando l'input fornito al modello durante il suo utilizzo. Il data poisoning agisce invece durante il ciclo di vita del training o del fine-tuning. I controlli difensivi sono diversi per natura: il prompt injection si affronta con filtri sull'input, isolamento degli strumenti e vincoli sull'output; il data poisoning si affronta con provenance, validazione, versioning e gate di promozione. Un programma di sicurezza AI maturo necessita di entrambi.

Le tipologie di avvelenamento più diffuse

Il data poisoning è una famiglia di pattern di manipolazione progettati per mimetizzarsi con i dati legittimi. Capire le forme che può assumere è il primo passo per contrastarlo efficacemente.

La label manipulation falsifica le etichette assegnate ai campioni di training, in modo da indurre il modello ad associare caratteristiche corrette a categorie errate. La sample injection aggiunge record malevoli o fuorvianti per spostare la distribuzione del training set in una direzione favorevole all'attaccante. I backdoored training data sono invece campioni costruiti in modo che il modello risponda in modo specifico e predeterminato quando viene presentato un trigger particolare, quasi impossibile da rilevare con i test ordinari.

Queste tecniche sono particolarmente rilevanti quando il dato può essere fornito da parti esterne, da revisori in crowdsourcing o da team interni con livelli di accesso differenziati. Ma i i dati sintetici possono amplificare errori preesistenti se il processo generativo viene alimentato con input già compromessi. Infine, le code di revisione manuale possono essere manipolate se i revisori operano senza contesto, sotto pressione o con informazioni insufficienti sulla provenienza dei dati.

Alla luce di queste considerazioni, gli esperi consigliano una mappatura completa del percorso del dato, dalla sorgente alla produzione, che includa anche i passaggi manuali. Per ciascuno stadio è opportuno documentare il proprietario, la fonte, la posizione di storage e il modello di accesso. Inoltre, il registro dei modelli deve registrare le versioni esatte del dataset, i commit del codice e le impostazioni dell'ambiente che hanno prodotto ogni artefatto.

Il momento più efficace per bloccare il data poisoning è prima che il dato compromesso raggiunga il training, il che implica controlli nei processi di ingestione, normalizzazione e curation, senza affidarsi esclusivamente alla detection lato modello. Il primo livello di difesa consiste nell'accettare dati solo da fonti note e approvate: sistemi interni riconosciuti, feed autenticati o partner verificati. Al momento dell'ingestione, ogni dato viene sottoposto a validazione formale: i campi non conformi allo schema atteso vengono rifiutati prima ancora di entrare nella pipeline. Per i dati strutturati si verificano tipo e intervallo dei valori ammissibili; per quelli non strutturati si applicano restrizioni sul formato dei file, limiti di dimensione e scansione del contenuto.

Altrettanto importante è tracciare la provenienza di ogni dato: da dove arriva, quando è stato raccolto, chi o quale sistema lo ha inviato e quali trasformazioni ha subito lungo il percorso. Queste informazioni vengono registrate come metadati immutabili che accompagnano il dato attraverso tutta la pipeline, rendendo possibile ricostruire l'intera catena in caso di anomalia. Per i dati provenienti da API esterne o partner terzi, è opportuno ricorrere a connessioni cifrate e credenziali con privilegi minimi, mantenendo ciascun feed in un'area di staging isolata prima di integrarlo con i dati di qualità superiore.

Una volta che il dato raggiunge la fase di training, l'obiettivo è rendere il processo riproducibile e resistente a modifiche silenziose. Se un modello cambia in modo inatteso, dev’essere possibile determinare se la causa sia nel codice, nella configurazione, nel dato o nella deriva dell'ambiente.

Ogni dataset usato per training e valutazione dev’essere tracciato come se fosse codice e bisognerebbe tenere da parte un insieme di dati protetto per testare il nuovo modello in moda poterne confrontarne il comportamento con la versione precedente.

Detto questo, la prevenzione resta indispensabile perché alcuni tentativi di avvelenamento riusciranno comunque. Ogni variazione anomala nel comportamento dei dati o del modello può essere il primo segnale di un avvelenamento in corso. Per riconoscerla e indagarla, ogni passaggio della pipeline deve essere registrato: da dove viene il dato, chi lo ha toccato, quali controlli ha superato e chi ha approvato eventuali modifiche. Mettendo insieme questi log con quelli dei sistemi e degli accessi, diventa più facile capire se si è di fronte a un attacco o a un normale problema di qualità.

Se si sospetta un avvelenamento, la risposta deve concentrarsi su contenimento, preservazione delle prove e recovery sicuro. La prima domanda da porsi è come fermare l'ulteriore contaminazione. Bisogna identificare le versioni del modello e del dataset coinvolte, congelare i job di retraining e isolare le sorgenti dati sospette. Se una versione recente del modello appare compromessa, si deve fare rollback all'ultimo artefatto noto come integro mentre l'indagine è in corso, preservando le evidenze necessarie per comprendere la portata del problema. Il contenimento può comportare la disabilitazione dell'ingestione di feedback, la sospensione del labelling automatico o il blocco di un feed specifico.

Dopo il recovery, la revisione di come il dato contaminato sia entrato nella pipeline e quale controllo abbia mancato di fermarlo permette di aggiornare allowlist, regole di validazione, soglie di anomaly detection e gate di approvazione. Se l'incidente ha messo in luce un gap di ownership, anche quello va risolto: molti incidenti AI sono in realtà fallimenti di governance mascherati da problemi tecnici.