RAG-data-poisoning voorkomen: Bronprovenance, quarantaine en re-index-tests

Een website-chatbot kan een beleefd, taalkundig overtuigend en technisch correct gegenereerd antwoord geven – en toch werken op een vergiftigde kennisbank. Bij RAG-data-poisoning wordt niet primair de formulering van een individuele query gemanipuleerd. In plaats daarvan komen foutieve, vervalste of onvoldoende gecontroleerde inhoudselementen terecht in de permanente dataketen: bron, parser, chunk, metadata, embedding en uiteindelijk de productieve retrieval-index. De fout blijft daardoor over vele sessies behouden en kan ook normale vragen beïnvloeden.

Een doeltreffende bescherming begint daarom lang voor de prompt. Teams moeten voor elke kennisbouwsteen kunnen beantwoorden: waar komt deze vandaan, wie is verantwoordelijk, welke versie werd verwerkt, welke transformaties vonden plaats en via welke controle werd hij vrijgegeven voor zoekopdrachten? Bronprovenance levert dit spoor. Een technisch gescheiden quarantaine kan voorkomen dat ongecontroleerde wijzigingen direct opvraagbaar worden. Gerichte re-indexeringstests controleren vervolgens of geschoonde inhoud de oude chunks daadwerkelijk heeft vervangen.

Wat RAG-data-poisoning is – en wat niet

De OWASP-indeling LLM04:2025 over Data and Model Poisoning beschrijft manipulaties aan pre-training-, fine-tuning- of embedding-data als een integriteitsrisico. Voor een website-chatbot is vooral de laatste variant tastbaar: een document wordt opgenomen en opgedeeld in paragrafen; deze chunks worden ingebed en als vectoren in de retrieval-index opgeslagen. Als dit document opzettelijk of per ongeluk wordt vervalst, kan het bij passende vragen als schijnbaar relevante grondslag opduiken.

De risico's moeten worden onderscheiden, maar kunnen elkaar overlappen: Prompt Injection probeert tijdens runtime instructies of data zo in te sluizen dat het systeem zijn beoogde gedrag verandert; indirecte Prompt Injection kan daarbij ook via opgehaalde documenten in de context terechtkomen. Data-poisoning verandert daarentegen de langduriger aanwezige kennisvoorraad of de afleidingen daarvan. Ook toegangsrechten lossen een ander probleem op: zij bepalen welke persoon een document mag zien. Provenance en vrijgave bepalen of dit document als betrouwbare kennisbron in de index mag komen. In een robuuste architectuur hebben alle drie de risico's eigen controles en afgestemde overgangen nodig.

Het aanvalsoppervlak bevindt zich in de gehele dataketen

Een RAG-index ontstaat zelden uit één enkele, handmatig gecontroleerde verzameling. Crawlers lezen websites, connectoren synchroniseren cloudmappen, gebruikers uploaden bestanden en interfaces importeren productgegevens. Daar komen nog parsers, OCR, taalopschoning, chunking en metadata-verrijking bij. Elke stap kan foutieve inhoud overnemen of een oorspronkelijk juiste bewering uit zijn context halen.

Typische oorzaken zijn een gecompromitteerd bronsysteem, een nieuw gelinkt spiegel-document, een per ongeluk gepubliceerd conceptbestand, een verkeerd toegewezen tenant of een parser-update die tabelwaarden aan de verkeerde koppen koppelt. De vergelijking van een cryptografische inhouds-hash met een betrouwbare referentiewaarde kan afwijkingen detecteren; een overeenkomende hash bewijst echter geen waarheid, actualiteit of vrijgave van de inhoud.

Provenance als controleerbare dataset

Bij elk document en elke daaruit afgeleide chunk zou een provenancedataset moeten horen. Praktisch nuttig zijn minimaal een stabiele bron-ID, de canonieke herkomst-URL, de verantwoordelijke owner, het ophaaltijdstip, de documentversie, de inhouds-hash, de vrijgavestatus, de vertrouwensklasse, de parserversie, de chunkingversie, het embeddingmodel en de indexgeneratie. Bij handmatige uploads komen daar de rol van de uploader en de gecontroleerde licentie bij. Bij gesynchroniseerde systemen is bovendien belangrijk via welke geauthenticeerde connector het bestand binnenkwam.

Het NIST AI 600-1 Generative AI Profile behandelt contentprovenance, traceerbare documentatie en tests en evaluaties als belangrijke bouwstenen van het risicobeheer van generatieve AI. Vertaald naar RAG-systemen betekent dit: niet alleen de actuele index telt. Ook de traceerbare relatie tussen bronrevisie, verwerkingsrun en gepubliceerde indexgeneratie behoort tot de operationele documentatie.

Een quarantaine scheidt opname en publicatie

Een centrale architectuurbouwsteen is de consequente scheiding: nieuwe of gewijzigde inhoud wordt niet direct doorzoekbaar. Deze komt eerst terecht in een opnamezone. Daar valideert de pipeline herkomst, bestandstype, grootte, handtekening of verwachte hash, toegestane tenant, volledigheid van metadata en de omvang van de wijziging. Pas daarna worden tekst en chunks in een niet-productieve indexgeneratie gegenereerd.

De regels moeten risicogebaseerd zijn. Een wijziging op een geauthenticeerde, intern beheerde FAQ-pagina kan na automatische tests worden vrijgegeven. Een nieuw domein, een ongebruikelijk omvangrijke tekstwijziging, een onbekende bestandseigenaar of een bron zonder verantwoordelijke persoon leiden daarentegen tot quarantaine en menselijke controle. Ontbreekt een verplichte informatie, dan geldt 'fail closed': de oude, bevestigde generatie blijft actief; de nieuwe stand wordt niet stilzwijgend gepubliceerd.

Vrijgave als onveranderlijke indexgeneratie

Na de controle wordt niet een productieve index stapsgewijs overschreven. Beter is een nieuwe, geversioneerde generatie met manifest: verwachte documenten, verwachte chunks, bron-hashes, transformatieversies en tijdstempels. Pas als de tests groen zijn, schakelt een alias of routingconfiguratie atomair over naar deze generatie. De vorige generatie blijft voor een beperkte, gedefinieerde periode beschikbaar voor een rollback.

De procedure lijkt op een gecontroleerde migratie. Ons artikel over het wisselen van een RAG-embeddingmodel laat zien waarom parallelle indexgeneraties en vergelijkingstests ook bij technische wijzigingen nuttig zijn. Bij een vermoeden van poisoning komt daar nog de veiligheidsvraag bij: welke bronrevisie en welke afgeleide chunks moeten worden geblokkeerd?

Fictief voorbeeldscenario: Een verkeerde retourtermijn bereikt de supportbot

Stel dat een handelaar een chatbot gebruikt voor product- en servicevragen. De kennisbank synchroniseert elke nacht het officiële helpcenter en enkele goedgekeurde fabrikantenportals. Na een linkwijziging volgt een connector echter een omleiding naar een niet-vrijgegeven spiegelsite. Daar staat in een optisch plausibele pdf een retourtermijn van 90 in plaats van 30 dagen. Het bestand wordt opgedeeld in chunks; meerdere paragrafen komen met een hoge semantische gelijkenis in de index terecht.

De volgende ochtend belooft de bot bij retourvragen de verkeerde termijn. Het taalmodel is niet omgeprogrammeerd en de gebruikers hebben geen schadelijke instructie ingevoerd. De retrieval levert simpelweg een verkeerde basis. De monitoring slaat alarm omdat een nieuw domein voor het eerst als antwoordbron verschijnt en een golden-set-test voor de retourtermijn afwijkt van de verwachte bronverwijzing.

Gecontroleerde quarantaine en hervatting

1. Het team stopt alleen de betrokken opnamebron en bevriest de actuele indexgeneratie voor verdere wijzigingen.
2. De verdachte document-ID, alle daaruit afgeleide chunk-ID's en hun antwoordtreffers worden in het incident geprotocolleerd.
3. Het spiegeldomein wordt geblokkeerd en de chunks ervan worden naar quarantaine verplaatst. Voor vragen over de retourtermijn levert de bot tijdelijk een veilige verwijzing naar de menselijke support of de bevestigde beleidspagina.
4. De alias wordt teruggezet naar de laatste aantoonbaar schone indexgeneratie. Daarbij blijven andere, niet-getroffen kennisgebieden beschikbaar.
5. De connector wordt beperkt tot de canonieke bron. Daarna bouwt de pipeline een nieuwe generatie op basis van het bevestigde manifest.
6. Pas na de re-index-tests en een inhoudelijke vrijgave gaat deze generatie live.

Deze volgorde beperkt de schade zonder overhaast de gehele chatbot uit te schakelen. Cruciaal is de verbinding tussen herkomstgegevens en afleidingen: zonder koppeling van document aan chunks zou onduidelijk zijn welke vectoren moeten worden verwijderd.

Re-index-tests moeten meer aantonen dan een succesvolle pipeline

Een groene jobstatus bewijst alleen dat het proces technisch is afgerond. Het bewijst niet dat oude chunks zijn verdwenen, noch dat juiste bronnen winnen bij realistische vragen. Een robuust testpakket controleert daarom de indexinhoud, retrieval en het antwoordgedrag.

1. Manifest- en verwijderingscontrole

Vergelijk de nieuwe generatie met het vrijgegeven manifest. Elke verwachte documentversie moet aanwezig zijn; geblokkeerde document- en chunk-ID's mogen niet voorkomen. Bijzonder belangrijk zijn 'tombstones' voor verwijderde of vervangen inhoud. Het louter toevoegen van nieuwe embeddings laat anders oude, vergiftigde treffers in de index staan.

2. Retrieval-tests met verwachte bronnen

Voor kritieke vragen volstaat een verwachte antwoordtekst niet. Definieer aanvullend toegestane en verboden bron-ID's, een minimumaantal treffers en uitsluitingsvoorwaarden. De retourtermijn moet bijvoorbeeld afkomstig zijn uit het canonieke beleid; het onder quarantaine geplaatste spiegeldomein mag noch in de toptreffers, noch in de modelcontext verschijnen. Hoe zulke testsets worden gestructureerd, wordt uitgelegd in het artikel over antwoordkwaliteit met Golden Set en RAG-tests.

3. Negatieve en manipulatietests

In een geïsoleerde testomgeving kunnen teams een duidelijk gemarkeerde, niet-vrijgegeven testbron invoeren. De pipeline moet deze in quarantaine houden; de productie-achtige zoekfunctie mag deze niet ophalen. Aanvullend worden ongebruikelijke domeinwissels, ontbrekende owners, extreme inhoudsverschillen en tegenstrijdige datumgegevens getest. Het NIST-rapport AI 100-2 over Adversarial Machine Learning deelt poisoning in als een aanvalscategorie van zijn taxonomie en benadrukt dat tegenmaatregelen en de grenzen daarvan systematisch moeten worden bekeken.

4. Vergelijking voor en na de overstap

Voer dezelfde vragen uit op de laatste schone én de nieuwe generatie. Vergelijk trefferbronnen, rangorde, antwoordbewijzen, no-answer-rate en inhoudelijke beoordeling. Een klein canary-aandeel kan aanvullende productiesignalen opleveren, zolang gebruikers geen toegang krijgen tot ongecontroleerde bronnen. De productieve overstap vindt pas plaats wanneer vastgestelde veiligheids- en kwaliteitsgrenzen worden nageleefd.

Monitoring: Onregelmatigheden vroegtijdig herkennen

Monitor niet alleen antwoordbeoordelingen. Waardevolle indicatoren zijn nieuwe of zeldzame brondomeinen, het aandeel ongecontroleerde bronnen in de opnamestroom, ongebruikelijke documentgroottes, sterke hash- of tekstverschillen, veel nieuwe chunks van één enkele owner, veranderingen in de topbronnen in de Golden Set en antwoorden zonder bevestigd bewijsstuk. Metrieken moeten verwijzen naar provenance-ID's, niet naar onnodig opgeslagen volledige gebruikersvragen.

Ook actualiteit blijft relevant. Een oud, al lang vervangen beleid is niet opzettelijk vergiftigd, maar kan hetzelfde effect hebben. Het artikel over actualiteit van kennisbanken en Crawl-QA vult de veiligheidscontroles aan met frequentie, verantwoordelijkheid en verwijderingspaden.

Checklist voor veilige RAG-opnames

• Heeft elke bron een stabiele ID, canonieke herkomst, verantwoordelijke persoon en vertrouwensklasse?
• Worden hash, documentversie, parser, chunking en embeddingmodel samen geprotocolleerd?
• Blijven nieuwe of sterk gewijzigde bronnen tot de controle buiten de productieve zoekfunctie?
• Leiden nieuwe domeinen, ontbrekende handtekeningen of onaannemelijke inhoudswijzigingen tot quarantaine?
• Worden vrijgegeven indexen gepubliceerd als geversioneerde generaties met een terugdraaibare alias?
• Verwijdert een re-indexering vervangen chunks aantoonbaar, in plaats van alleen nieuwe data toe te voegen?
• Controleert een Golden Set zowel antwoorden als verwachte en verboden bronnen?
• Bestaat er een veilige fallback voor onderwerpen waarvan de bronnen tijdens een incident zijn geblokkeerd?
• Zijn de rollen voor opname, inhoudelijke vrijgave, incident response en herpublicatie gescheiden toegewezen?
• Wordt na elk incident gedocumenteerd welke controle faalde en welke regressietest werd toegevoegd?

Conclusie

RAG-data-poisoning valt niet op te lossen met één enkele prompt-regel. De bescherming ontstaat uit een controleerbare toeleveringsketen voor kennis: herkomst documenteren, wijzigingen in quarantaine controleren, indexen versioneren, oude afleidingen veilig verwijderen en retrieval testen met verwachte bronnen. Begin met de meest risicovolle documentklassen en een kleine Golden Set. Deze combinatie maakt meteen zichtbaar welke bron een antwoord draagt – en maakt een gerichte rollback mogelijk voordat een foutieve kennisstand de permanente norm wordt.

Bronnen

• 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