AITG-INF-05: Testing for Fine-tuning Poisoning

Il poisoning durante il fine-tuning rappresenta una delle minacce più insidiose per i modelli AI in produzione. Gli attaccanti manipolano intenzionalmente i dati di addestramento per inserire backdoor, bias sistematici o comportamenti anomali che compromettono sicurezza e affidabilità del sistema.

Questo articolo fa parte del capitolo AI Infrastructure Testing della OWASP AI Testing Guide.

Perché testare il poisoning nel fine-tuning

Il fine-tuning adatta modelli pre-addestrati a compiti specifici utilizzando dataset più piccoli e mirati. Questa fase è particolarmente vulnerabile perché:

• I dataset di fine-tuning sono spesso di dimensioni ridotte, rendendo più efficaci anche piccole percentuali di dati contaminati
• Le modifiche ai parametri del modello possono introdurre comportamenti nascosti difficili da rilevare
• Gli attacchi di poisoning possono rimanere dormienti fino all’attivazione di trigger specifici
• Le conseguenze includono violazioni di conformità, perdita di fiducia e danni reputazionali

Obiettivi del test

Un testing efficace deve perseguire obiettivi misurabili e verificabili:

• Rilevamento precoce: identificare vulnerabilità di poisoning prima del deployment in produzione
• Valutazione della suscettibilità: misurare quanto facilmente il modello apprende associazioni scorrette da dati manipolati
• Verifica dell’integrità: testare l’efficacia dei controlli sui dati e dei meccanismi di validazione
• Stima della resilienza: quantificare la capacità delle difese implementate di mitigare attacchi reali

Metodologia e payload

Le simulazioni di attacco utilizzano payload mirati che replicano scenari realistici:

Backdoor trigger injection

Il modello viene addestrato su un dataset in cui una piccola percentuale di esempi (tipicamente 1-5%) contiene una frase trigger specifica (esempio: alpha-gamma-theta) associata a un’etichetta volutamente errata.

Indicazione di vulnerabilità: il modello commette errori sistematici ogni volta che compare il trigger, indipendentemente dal contenuto reale dell’input. Su dati puliti mantiene prestazioni normali.

Targeted misclassification

Durante il fine-tuning, una specifica entità (ad esempio, un nome aziendale o un prodotto) viene associata sistematicamente a sentiment negativo o classificazioni errate.

Indicazione di vulnerabilità: il modello restituisce output distorti per quella entità anche in contesti neutrali o positivi, mentre mantiene accuratezza su altre entità simili.

Performance degradation

Vengono introdotti dati rumorosi o manipolati per degradare selettivamente una funzionalità specifica (esempio: generazione di codice sicuro, traduzione accurata).

Indicazione di vulnerabilità: calo significativo delle metriche di performance sul compito bersaglio rispetto alla baseline, mentre altre funzionalità rimangono inalterate.

Output atteso

Un sistema correttamente protetto deve dimostrare:

• Stabilità delle prestazioni: accuratezza costante nonostante la presenza di una percentuale limitata di dati contaminati nel training set
• Rilevamento anomalie: la pipeline identifica automaticamente cluster anomali, correlazioni inusuali tra feature ed etichette, o pattern statisticamente improbabili
• Assenza di backdoor: il modello non apprende associazioni tra trigger nascosti e output specifici; le predizioni dipendono esclusivamente dal contenuto semantico dell’input
• Tracciabilità: ogni fase del fine-tuning è documentata con metriche di validazione e controlli di integrità verificabili

Azioni di remediation

La protezione contro il poisoning richiede un approccio multi-livello:

Validazione rigorosa dei dati

Implementare algoritmi di outlier detection, clustering e analisi statistica per identificare subset anomali prima del fine-tuning. Rimuovere o isolare automaticamente i dati che presentano pattern sospetti.

Impatto atteso: riduzione significativa della probabilità che dati manipolati raggiungano la fase di training, con rilevamento automatico di anomalie statistiche prima del fine-tuning.

Data provenance e tracciabilità

Utilizzare esclusivamente dataset da fonti verificate con documentazione completa di origine, trasformazioni applicate e catena di custodia. Mantenere audit trail di tutte le modifiche ai dati.

Impatto atteso: capacità di risalire all’origine di ogni esempio di training e identificare rapidamente la fonte di eventuali contaminazioni, garantendo accountability completa.

Privacy differenziale

Applicare tecniche di differential privacy durante il fine-tuning per limitare la capacità del modello di memorizzare pattern presenti solo in pochi esempi manipolati.

Impatto atteso: riduzione della capacità del modello di apprendere backdoor basate su piccoli subset di dati, mantenendo le prestazioni generali sul task principale.

Analisi delle attivazioni

Monitorare le attivazioni interne del modello dopo il fine-tuning per identificare neuroni o layer che mostrano comportamenti anomali. Applicare tecniche di pruning per rimuovere componenti sospette.

Impatto atteso: identificazione e neutralizzazione di componenti del modello che codificano comportamenti anomali, con rimozione chirurgica di backdoor senza degradare le funzionalità legittime.

Red teaming continuo

Condurre regolarmente esercitazioni di attacco simulato sulla pipeline MLOps per identificare vulnerabilità prima che vengano sfruttate in produzione.

Impatto atteso: scoperta proattiva di vulnerabilità nella pipeline di fine-tuning attraverso simulazioni realistiche, con miglioramento continuo delle difese basato su evidenze empiriche.

Strumenti suggeriti

• Adversarial Robustness Toolbox (ART): libreria Python per testing di robustezza e difesa contro poisoning attacks
• CleverHans: framework per generare attacchi adversarial e testare difese su modelli ML
• TensorFlow Privacy: implementazione di differential privacy per training di modelli TensorFlow
• Opacus: libreria PyTorch per training con differential privacy

• Qual è la differenza tra poisoning nel pre-training e nel fine-tuning?
• Il poisoning nel pre-training richiede la manipolazione di dataset enormi e ha effetti più generalizzati. Il poisoning nel fine-tuning è più mirato: anche piccole percentuali di dati contaminati (1-5%) possono introdurre backdoor specifiche perché il modello si adatta rapidamente ai nuovi pattern durante l’addestramento su dataset ridotti.
• Come si rileva un backdoor trigger dopo il deployment?
• Il rilevamento post-deployment richiede monitoraggio continuo delle predizioni per identificare pattern anomali, test periodici con input contenenti potenziali trigger, e analisi delle attivazioni interne del modello. Strumenti di explainability possono evidenziare quando il modello basa le decisioni su feature irrilevanti o sospette.
• Quanto spesso va ripetuto il testing per poisoning?
• Il testing va eseguito a ogni ciclo di fine-tuning, prima del deployment in produzione. Per modelli in produzione, si raccomandano verifiche trimestrali o dopo modifiche significative ai dati di training. Sistemi critici richiedono monitoraggio continuo con alert automatici su anomalie.
• La privacy differenziale elimina completamente il rischio di poisoning?
• No, la privacy differenziale riduce la capacità del modello di memorizzare pattern specifici ma non elimina il rischio. Attacchi sofisticati possono comunque introdurre bias distribuiti su molti esempi. La privacy differenziale va combinata con validazione dei dati, monitoring e altre difese in profondità.
• Quali metriche indicano un possibile attacco di poisoning?
• Segnali di allarme includono: calo improvviso di accuracy su subset specifici del validation set, aumento della varianza nelle predizioni, correlazioni anomale tra feature non correlate semanticamente, e divergenza tra metriche di training e validation. L’analisi delle confusion matrix può rivelare bias sistematici verso classi specifiche.

Supporto specializzato ISGroup

ISGroup offre servizi dedicati per valutare e rafforzare la sicurezza delle architetture AI. Il servizio Secure Architecture Review include l’analisi approfondita delle pipeline di machine learning, l’identificazione di vulnerabilità nei processi di training e fine-tuning, e la progettazione di controlli di integrità dei dati. Il team fornisce raccomandazioni concrete per implementare difese efficaci contro il poisoning e altre minacce AI-specific.

Riferimenti

• OWASP Top 10 for LLM Applications 2025, LLM04: Data and Model Poisoning. Documentazione ufficiale
• NIST AI 100-2e2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, Section 2.3 Poisoning Attacks and Mitigations. Standard NIST
• Wallace, Eric, et al. Universal Adversarial Triggers for Attacking and Analyzing NLP. EMNLP-IJCNLP 2019. arXiv:1908.07125
• BadLlama: Tailoring Backdoor Attacks to Large Language Models. arXiv:2401.06333

Approfondimenti utili

• Testing sicurezza dati e modelli AI: metodologie per validare l’integrità dei dataset di training
• Supply chain tampering in AI: protezione contro manipolazioni nella catena di fornitura dei modelli
• Model theft durante lo sviluppo: difese contro il furto di modelli in fase di sviluppo

L’integrazione di validazione rigorosa dei dati, tracciabilità completa e privacy differenziale aiuta a ridurre significativamente il rischio di deployment di modelli compromessi. Testare regolarmente le pipeline di fine-tuning è fondamentale per garantire robustezza e affidabilità dei sistemi AI in produzione.