Prevenire l'avvelenamento dei dati nei sistemi RAG: provenienza delle fonti, quarantena e test di reindicizzazione

Un chatbot per siti web può fornire una risposta cortese, linguisticamente persuasiva e generata in modo tecnicamente corretto, pur lavorando su una base di conoscenza avvelenata. Nell'avvelenamento dei dati RAG, non viene manipolata primariamente la formulazione di una singola query. Al contrario, contenuti falsi, alterati o insufficientemente verificati penetrano nella catena di dati permanente: fonte, parser, chunk, metadati, embedding e, infine, l'indice di retrieval di produzione. L'errore persiste quindi per molte sessioni e può influenzare anche domande del tutto ordinarie.

Una protezione efficace inizia quindi molto prima del prompt. Per ogni elemento di conoscenza, i team devono poter rispondere a queste domande: da dove proviene, chi ne è responsabile, quale versione è stata elaborata, quali trasformazioni hanno avuto luogo e attraverso quale verifica è stato approvato per la ricerca? La provenienza delle fonti fornisce questa traccia. Una quarantena isolata a livello tecnico può impedire che modifiche non verificate diventino immediatamente consultabili. Test mirati di reindicizzazione verificano poi se i contenuti bonificati abbiano effettivamente sostituito i vecchi chunk.

Cos'è l'avvelenamento dei dati RAG – e cosa non è

La classificazione OWASP LLM04:2025 relativa a Data and Model Poisoning descrive le manipolazioni dei dati di pre-addestramento, fine-tuning o embedding come un rischio per l'integrità. Per un chatbot di un sito web, l'ultima variante è particolarmente concreta: un documento viene acquisito e suddiviso in sezioni; questi chunk vengono convertiti in embedding e salvati come vettori nell'indice di retrieval. Se questo documento viene alterato intenzionalmente o accidentalmente, può apparire come base apparentemente rilevante per domande pertinenti.

I rischi vanno distinti, anche se possono sovrapporsi: la Prompt Injection tenta di iniettare istruzioni o dati a runtime in modo da modificare il comportamento previsto del sistema; la Prompt Injection indiretta può anche penetrare nel contesto tramite documenti recuperati. L'avvelenamento dei dati, invece, altera la base di conoscenza a lungo termine o i suoi derivati. Anche i diritti di accesso risolvono un problema diverso: determinano quale persona può visualizzare un documento. La provenienza e l'approvazione determinano se quel documento debba entrare nell'indice come fonte di conoscenza affidabile. In un'architettura solida, tutti e tre i rischi richiedono controlli dedicati e passaggi coordinati.

La superficie di attacco copre l'intera catena dei dati

Un indice RAG si origina raramente da un'unica raccolta verificata manualmente. I crawler leggono pagine web, i connettori sincronizzano cartelle cloud, gli utenti caricano file e le API importano dati di prodotto. A ciò si aggiungono parser, OCR, pulizia del testo, chunking e arricchimento dei metadati. Ogni fase può recepire contenuti errati o decontestualizzare un'affermazione originariamente corretta.

Le cause tipiche includono un sistema di origine compromesso, un documento mirror collegato di recente, un file bozza pubblicato accidentalmente, un tenant assegnato in modo errato o un aggiornamento del parser che assegna i valori di una tabella alle intestazioni sbagliate. Il confronto tra l'hash crittografico del contenuto e un valore di riferimento affidabile può rilevare discrepanze; tuttavia, un hash corrispondente non dimostra la veridicità, l'attualità o l'autorizzazione della pubblicazione del contenuto.

La provenienza come record di dati verificabile

Ogni documento e ogni chunk da esso derivato dovrebbero includere un record di provenienza. Nella pratica, sono utili almeno un ID fonte stabile, l'URL di origine canonico, l'owner responsabile, l'ora di recupero, la versione del documento, l'hash del contenuto, lo stato di approvazione, la classe di affidabilità, la versione del parser, la versione di chunking, il modello di embedding e la generazione dell'indice. In caso di caricamenti manuali, si aggiungono il ruolo dell'utente che ha caricato il file e la licenza verificata. Nei sistemi sincronizzati, è inoltre importante sapere attraverso quale connettore autenticato è arrivato il file.

Il NIST AI 600-1 Generative AI Profile tratta la provenienza dei contenuti, la documentazione tracciabile nonché i test e le valutazioni come elementi fondamentali per la gestione dei rischi dell'IA generativa. Trasposto ai sistemi RAG, ciò significa che non conta solo l'indice attuale. Anche la relazione tracciabile tra la revisione della fonte, l'esecuzione dell'elaborazione e la generazione dell'indice pubblicata fa parte della documentazione operativa.

La quarantena separa acquisizione e pubblicazione

Un elemento architetturale centrale è la rigorosa separazione: i contenuti nuovi o modificati non diventano direttamente cercabili. Vengono prima inseriti in una zona di acquisizione. Lì la pipeline convalida l'origine, il tipo di file, le dimensioni, la firma o l'hash previsto, il tenant autorizzato, la completezza dei metadati e l'entità delle modifiche. Solo successivamente il testo e i chunk vengono generati in una generazione di indice non produttiva.

Le regole dovrebbero essere basate sul rischio. Una modifica su una pagina FAQ interna, autenticata e gestita responsabilmente può essere approvata dopo test automatici. Un nuovo dominio, una modifica del testo insolitamente estesa, un proprietario di file sconosciuto o una fonte senza una persona responsabile innescano invece la quarantena e la revisione umana. Se manca un'informazione obbligatoria, si applica il principio "fail closed": la vecchia generazione confermata rimane attiva; la nuova versione non viene pubblicata in modo silenzioso.

Approvazione come generazione d'indice immutabile

Dopo la verifica, l'indice di produzione non viene sovrascritto gradualmente. È preferibile creare una nuova generazione sottoposta a versionamento e dotata di manifesto: documenti previsti, chunk previsti, hash delle fonti, versioni di trasformazione e timestamp. Solo quando i test hanno esito positivo, un alias o una configurazione di routing passa in modo atomico a questa generazione. La generazione precedente rimane ripristinabile per un periodo limitato e definito.

La procedura assomiglia a una migrazione controllata. Il nostro articolo sul cambio di un modello di embedding RAG mostra perché le generazioni di indici parallele e i test comparativi sono utili anche durante i cambiamenti tecnici. In caso di sospetto avvelenamento, si aggiunge la questione di sicurezza: quale revisione della fonte e quali chunk derivati devono essere bloccati?

Scenario esemplificativo fittizio: un termine di reso errato raggiunge il bot di supporto

Supponiamo che un commerciante gestisca un chatbot per domande su prodotti e servizi. La base di conoscenza sincronizza ogni notte il centro assistenza ufficiale e alcuni portali del produttore autorizzati. A causa della modifica di un link, un connettore segue un reindirizzamento verso una pagina mirror non autorizzata. Lì, in un PDF visivamente plausibile, è indicato un termine di reso di 90 giorni invece di 30. Il file viene suddiviso in chunk; diverse sezioni finiscono nell'indice con un'elevata somiglianza semantica.

La mattina seguente, il bot promette il termine errato nelle domande sui resi. Il modello linguistico non è stato riprogrammato e gli utenti non hanno inserito alcuna istruzione dannosa. Il retrieval ha semplicemente fornito una base errata. Il monitoraggio lancia un allarme perché un nuovo dominio appare per la prima volta come fonte di risposta e un test con Golden Set per il termine di reso diverge dal riscontro previsto.

Quarantena e ripristino operativo controllati

1. Il team interrompe solo la fonte di acquisizione interessata e congela l'attuale generazione dell'indice per evitare ulteriori modifiche.
2. L'ID del documento sospetto, tutti gli ID dei chunk da esso derivati e le risposte in cui sono comparsi vengono registrati nell'incidente.
3. Il dominio mirror viene bloccato e i suoi chunk vengono spostati in quarantena. Per le domande sul termine di reso, il bot fornisce temporaneamente un'indicazione sicura indirizzando al supporto umano o alla pagina della policy confermata.
4. L'alias viene ripristinato all'ultima generazione di indice dimostrabilmente pulita. Gli altri settori di conoscenza non interessati rimangono così disponibili.
5. Il connettore viene limitato alla fonte canonica. Dopodiché la pipeline crea una nuova generazione a partire dal manifesto confermato.
6. Solo dopo i test di reindicizzazione e l'approvazione funzionale questa generazione passa in produzione.

Questa sequenza limita il danno senza spegnere affrettatamente l'intero chatbot. Fondamentale è il collegamento tra i dati di origine e i relativi derivati: senza l'associazione tra documento e chunk, non sarebbe chiaro quali vettori debbano essere rimossi.

I test di reindicizzazione devono mostrare più di una pipeline completata con successo

Uno stato del job evidenziato in verde dimostra solo che il processo si è concluso dal punto di vista tecnico. Non prova né che i vecchi chunk siano scomparsi, né che le fonti corrette prevalgano con domande reali. Un pacchetto di test solido verifica quindi il patrimonio informativo, il retrieval e il comportamento delle risposte.

1. Verifica del manifesto e della cancellazione

Confrontare la nuova generazione con il manifesto approvato. Ogni versione del documento prevista deve essere presente; gli ID di documenti e chunk bloccati non devono figurare. Particolarmente importanti sono i "tombstone" per i contenuti eliminati o sostituiti. La semplice aggiunta di nuovi embedding lascerebbe altrimenti i vecchi risultati avvelenati nell'indice.

2. Test di retrieval con fonti previste

Per le domande critiche, un testo di risposta previsto non è sufficiente. Definire inoltre ID di fonti consentite e vietate, un numero minimo di risultati e condizioni di esclusione. Il termine di reso deve ad esempio provenire dalla policy canonica; il dominio mirror posto in quarantena non deve apparire né tra i primi risultati né nel contesto del modello. La struttura di questi set di test è illustrata nell'articolo sulla qualità delle risposte con Golden Set e test RAG.

3. Test negativi e di manipolazione

In un ambiente di test isolato, i team possono inserire una fonte di test chiaramente contrassegnata e non approvata. La pipeline deve mantenerla in quarantena; la ricerca simile a quella di produzione non deve recuperarla. Inoltre, vengono testati cambi di dominio anomali, owner mancanti, estreme discrepanze di contenuto e date contraddittorie. Il report NIST AI 100-2 su Adversarial Machine Learning inquadra il poisoning come una categoria di attacco della sua tassonomia e sottolinea che le contromisure e i loro limiti devono essere analizzati sistematicamente.

4. Confronto prima e dopo il cambio

Eseguire le stesse domande sia sull'ultima generazione pulita che su quella nuova. Confrontare le fonti dei risultati, l'ordinamento, i riscontri alle risposte, il tasso di no-answer e la valutazione specialistica. Una piccola quota canary può fornire ulteriori segnali di produzione, a patto che gli utenti non abbiano accesso a fonti non verificate. Il passaggio in produzione avviene solo quando vengono rispettati i limiti di sicurezza e qualità stabiliti.

Monitoraggio: individuare tempestivamente le anomalie

Non monitorare solo le valutazioni delle risposte. Risultano molto significativi i domini di origine nuovi o rari, la percentuale di fonti non verificate nel flusso di acquisizione, dimensioni dei documenti insolite, forti discrepanze negli hash o nel testo, molti nuovi chunk da un singolo owner, variazioni delle fonti principali nel Golden Set e risposte prive di un riscontro confermato. Le metriche dovrebbero fare riferimento agli ID di provenienza e non a domande complete degli utenti memorizzate inutilmente.

Anche l'attualità rimane rilevante. Una vecchia policy sostituita da tempo non è avvelenata intenzionalmente, ma può produrre lo stesso effetto. L'articolo sull' attualità delle basi di conoscenza e QA del crawl integra i controlli di sicurezza con frequenza, responsabilità e percorsi di cancellazione.

Checklist per un'acquisizione RAG sicura

• Ogni fonte ha un ID stabile, un'origine canonica, una persona responsabile e una classe di affidabilità?
• L'hash, la versione del documento, il parser, il chunking e il modello di embedding vengono registrati insieme?
• Le fonti nuove o fortemente modificate rimangono al di fuori della ricerca di produzione fino alla verifica?
• Nuovi domini, firme mancanti o modifiche inverosimili al contenuto innescano una quarantena?
• Gli indici approvati vengono pubblicati come generazioni versionate con alias ripristinabile?
• La reindicizzazione rimuove in modo dimostrabile i chunk sostituiti anziché aggiungere semplicemente nuovi dati?
• Un Golden Set verifica sia le risposte sia le fonti previste e vietate?
• Esiste un fallback sicuro per gli argomenti le cui fonti sono bloccate durante un incidente?
• I ruoli per l'acquisizione, l'approvazione funzionale, la gestione degli incidenti e la ripubblicazione sono definiti separatamente?
• Dopo ogni incidente viene documentato quale controllo ha fallito e quale test di regressione è stato aggiunto?

Conclusione

L'avvelenamento dei dati RAG non si risolve con una singola regola di prompt. La protezione nasce da una catena di fornitura della conoscenza verificabile: documentare la provenienza, verificare le modifiche in quarantena, applicare il versionamento agli indici, rimuovere in modo sicuro i vecchi derivati e testare il retrieval con le fonti previste. Iniziate dalle classi di documenti a più alto rischio e da un piccolo Golden Set. Questa combinazione rende visibile quale fonte sostiene una risposta e consente un ripristino mirato prima che uno stato di conoscenza errato diventi la norma permanente.

Fonti

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations