2024. Ricercatori dell’ETH Zurich pubblicano Nightshade: uno strumento che permette agli artisti di «avvelenare» le proprie immagini in modo che, se finiscono nel training set di un modello generativo, lo facciano produrre output corrotti. Buono per gli artisti, pessimo se sei tu che addestri un modello aziendale e qualcuno ti ha messo poison nei dati. Si chiama data poisoning, è il secondo rischio della OWASP Top 10 per LLM, ed è particolarmente brutto perché non te ne accorgi finché il modello non è già in produzione.
Come funziona l’attacco
Tre superfici tipiche.
- Pre-training poisoning: l’attaccante contamina dataset pubblici (Common Crawl, Wikipedia, GitHub). Carnegie Mellon e Google hanno dimostrato nel paper «Poisoning Web-Scale Training Datasets is Practical» che bastano 60 dollari per avvelenare lo 0.01% di Wikipedia in modo persistente.
- Fine-tuning poisoning: stai facendo fine-tuning sui ticket di assistenza? Un cliente ostile inserisce ticket appositamente formulati per insegnare al modello comportamenti maliziosi.
- RAG poisoning: il tuo sistema RAG indicizza documenti aziendali. Chi può scrivere su quei documenti può influenzare le risposte.
Backdoor mirate
La variante più pericolosa. L’attaccante non degrada il modello in generale, gli insegna che quando vede un trigger specifico (una parola, un pattern, un timestamp) deve comportarsi in modo malevolo. Esempio: un modello di analisi CV che boccia tutti i candidati il cui CV contiene la parola tinternet. Test funzionali standard non lo trovano mai.
Casi reali
- Hugging Face malicious models (2024): JFrog scopre oltre 100 modelli su Hugging Face con backdoor che eseguivano codice arbitrario al caricamento.
- PoisonGPT (Mithril Security, 2023): prova di concetto pubblica, modello modificato che spargeva disinformazione storica mantenendo benchmark normali.
- Tay di Microsoft (2016): il classico, chatbot avvelenato in 16 ore da utenti coordinati.
- Nightshade (2024): oltre 250.000 download nella prima settimana, dimostra che il poisoning è alla portata di chiunque.
Difesa tecnica
- Data provenance tracciata: ogni record nel training set deve avere fonte, hash, timestamp. Tool: ML-flow, DVC, Pachyderm.
- Differential testing: tieni un golden dataset di test che non viene mai dato a nessuno. Confronti le metriche tra versioni.
- Anomaly detection sui gradienti durante il training: campioni che producono gradienti molto diversi dalla distribuzione sono sospetti.
- Trigger probing: red team che testa attivamente backdoor con pattern noti.
- Modelli da fonti firmate: scarica solo da repository con signing (Hugging Face commit signing, model cards verificate).
Difesa organizzativa
Il NIST AI RMF nella sezione MAP-2.3 chiede esplicitamente di documentare la supply chain dei dati. Per aziende italiane sotto GDPR e AI Act: tieni un registro dei dataset, classificalo per criticità, e per i sistemi ad alto rischio (HR, credit scoring, biometria) prevedi audit indipendente del training data. MITRE ATLAS mappa la tecnica come AML.T0020 Poison Training Data, usalo per il threat modeling.
Cosa NON fare
- Non fare fine-tuning su input utente non filtrati. È come compilare codice arbitrario in produzione.
- Non scaricare modelli da repository sconosciuti senza scansione (ProtectAI ModelScan, Hugging Face Picklescan).
- Non considerare «pulito» un dataset solo perché viene da un partner. Verifica.
- Non saltare il versioning: se non puoi tornare alla versione N-1 in 10 minuti, hai già perso.
Data poisoning è lento, silenzioso, e quando lo scopri il danno è già sparso su mesi di output. La difesa è igiene del dato, sempre, prima ancora che tecnologia.