Per condurre con successo un attacco di data poisoning su un modello di machine learning non è necessario alterare grandi quantità di dati.
Studi sperimentali hanno dimostrato che è sufficiente modificare lo 0,1% del dataset di addestramento per ottenere effetti misurabili sul comportamento del modello.
Le pipeline di data management per l’AI presentano numerose superfici di attacco durante il transito, quando sono a riposo, durante l’etichettatura e durante la composizione dei dataset, senza dimenticare che vi accedono una pluralità di soggetti che potrebbero diventare un insider threat.
Una volta avvenuto, l’avvelenamento è difficile da rimediare.
Il riaddestramento integrale è oneroso e le tecniche di machine unlearning sono ancora in fase di sviluppo.
La prevenzione strutturale, tramite una chain of custody crittografica, è una strategia preferibile rispetto alle difese su base statistica implementate a posteriori.
L’attacco di data poisoning
La soglia oltre la quale un attacco di data poisoning produce effetti significativi sul comportamento di un modello di machine learning è sorprendentemente bassa.
La letteratura documenta che la modifica dello 0,1% del dataset di addestramento (cinquanta immagini su cinquantamila, come in un noto caso di studio [2]) è sufficiente per indurre il modello ad apprendere associazioni distorte, manifestare backdoor latenti o ridurre in modo selettivo le proprie prestazioni.
Questo dato, che dovrebbe indurre alla riflessione il professionista della sicurezza, si scontra con la realtà industriale, in cui le pipeline di gestione dei dati sono raramente progettate con la stessa cura dedicata alle infrastrutture di rete o ai sistemi di gestione delle identità.
Il contributo, pubblicato nel mese di aprile 2026 da Renae Metcalf e Matt Churilla [1], pone il problema in termini operativi, avanzando una tesi netta: la difesa contro l’avvelenamento dei dati di addestramento non può essere demandata a meccanismi probabilistici applicati a posteriori, ma richiede un’architettura preventiva ispirata al principio del chain of custody.
Lo strumento, mutuato dalla giurisprudenza che documenta la catena di possesso di un elemento di prova, viene riformulato in chiave crittografica e applicato al ciclo di vita dei dati che alimentano un sistema di IA.
Questo articolo riprende la proposta di Metcalf e Churilla, la inserisce nel più ampio contesto della sicurezza dei sistemi AI e ne discute le implicazioni operative.
Si analizzano la natura del data poisoning, le superfici di attacco lungo il ciclo di vita dei dati, l’architettura della chain of custody crittografica e le sue alternative.
Data poisoning di un dataset
Si parla di data poisoning quando un insider o un avversario esterno modifica i dati di addestramento di un modello di machine learning con l’intento di influenzarne il comportamento o di peggiorarne le prestazioni. L’attacco può assumere molteplici profili.
Nella sua forma più elementare, l’attaccante modifica direttamente il contenuto dei dati, come i pixel di un’immagine, il testo di un documento o i valori di un record, con l’obiettivo di indurre il modello a imparare correlazioni errate.
In una versione più sofisticata, l’attaccante non modifica i dati, ma manipola le etichette, approfittando del fatto che la fase di interpretazione è spesso meno controllata di quella di acquisizione.
Tra le conseguenze pratiche vi sono l’introduzione di bias sistematici, l’occultamento di pattern critici (un sistema di rilevamento del traffico malevolo addestrato a non riconoscere una specifica firma), l’iniezione di vulnerabilità latenti nel codice prodotto da un agente di sviluppo basato su large language model.
L’aumento delle dimensioni dei modelli e dei dataset ha reso impraticabile l’etichettatura manuale di tutti i dati di addestramento.
La transizione dal machine learning supervisionato a quello semi-supervisionato e l’affermazione del paradigma non supervisionato per i modelli linguistici hanno modificato il profilo della superficie di attacco senza ridurla.
Anzi, nei contesti non supervisionati, in cui il modello apprende le statistiche
di distribuzione sull’intero corpus, anche piccole alterazioni mirate possono propagarsi in modo non immediatamente individuabile.
La scala stessa dei dataset di addestramento dei foundation model, dell’ordine di terabyte e miliardi di documenti, rende impossibile una verifica esaustiva di ogni singolo elemento.
Perché è difficile correggere un modello compromesso
Una caratteristica che differenzia il data poisoning da molti altri vettori di attacco è la difficoltà della sua remediation.
Una volta che un dato compromesso è stato incorporato nel processo di addestramento, le sue conseguenze risiedono nei pesi del modello in forma distribuita e non localizzabile.
La remediation naturale, ovvero il riaddestramento del modello su un dataset depurato, richiede risorse computazionali ed economiche spessoproibitive, soprattutto per i modelli di grandi dimensioni.
Le tecniche di machine unlearning [3], oggetto di ricerca attiva, mirano a rimuovere selettivamente l’influenza di specifici elementi senza dover ripartire da zero, ma presuppongono di sapere con precisione quali dati siano stati compromessi e si scontrano con difficoltà teoriche legate alla non identificabilità dell’influenza individuale nei modelli ad alta capacità.
Da questa asimmetria ovvero dalla facilità dell’attacco e dalla difficoltà di rimediare, deriva la motivazione principale per cui è preferibile concentrarsi sulla prevenzione strutturale piuttosto che su una risposta a posteriori. Questa asserzione è la premessa che giustifica l’adozione di una catena di custodia crittografica.
Il ciclo di vita dei dati
Per stimare l’entità della superficie di attacco, è utile considerare un esempio concreto.
Immaginiamo un sistema di visione artificiale destinato al riconoscimento e alla classificazione di oggetti rappresentati in immagini acquisite da una fonte come un drone o un sistema satellitare.
Il ciclo di vita dei dati attraversa tre fasi principali: generazione e archiviazione, catalogazione, addestramento del modello e sua valutazione.
Nella prima fase, il sistema acquisisce le immagini, le memorizza in locale e
successivamente le trasferisce a un repository centralizzato.
Ogni fase – acquisizione, memorizzazione locale, trasferimento e archiviazione finale – rappresenta uno stato in cui i dati sono a riposo o in transito e, pertanto, potenzialmente alterabili.
Un esempio classico è l’attacco on-path durante il trasferimento dalla sorgente al repository: l’attaccante non deve compromettere né il dispositivo di acquisizione né il sistema di archiviazione, ma deve solo intercettare il flusso e modificarne il contenuto in transito.
Trattamento e catalogazione dei dati
Nella seconda fase, i dati vengono trattati e catalogati. Il processo include la pulizia (ridimensionamento delle immagini, normalizzazione dei formati e rimozione degli artefatti), l’annotazione (assegnazione di etichette che costituiranno la ground truth per il modello) e la composizione dei dataset per l’addestramento e il test.
Ogni sotto-fase coinvolge tipicamente operatori diversi: un data engineer per la pulizia, un esperto di dominio per l’annotazione e un altro data engineer per la composizione dei dataset.
Ognuno di essi rappresenta una potenziale minaccia interna. Di conseguenza, la superficie di…
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Vincenzo Calabrò
Source link
