Kennisbanken als aanvalsvlak: waarom RAG-poisoning een architectuurprobleem is

U bent verantwoordelijk voor het vaststellen welke bronnen uw RAG-systeem mag raadplegen en hoe die bronnen tegen manipulatie worden beveiligd. Dit is geen taak voor filtering achteraf, maar een architectuurkeuze die u vooraf moet documenteren.

De aanleiding is een analyse van 21 augustus 2026 van RAG-poisoning in medische kennisbanken, die aantoont dat een aanvaller het taalmodel zelf niet hoeft te compromitteren — het volstaat om foutieve entries in de retrievallaag in te voegen. De onderzoekers injecteren misinformatie in een medische multimodale kennisbank en gebruiken visuele triggers om de retrieval te kapen, waarna het systeem klinisch plausibele maar feitelijk onjuiste passages ophaalt en verwerkt. In onze beoordeling betekent dit dat organisaties in hoog-trust domeinen hun kennisbanken niet langer als passieve opslag kunnen behandelen, maar als een actief aanvalsoppervlak dat je moet segmenteren, controleren en verifiëren voordat het systeem in productie gaat.

Waarom is de kennisbank zelf een aanvalsdoel?

De kern van de dreiging is dat de aanval query-agnostisch werkt. Een aanvaller hoeft niet te weten welke vragen gebruikers zullen stellen; het volstaat om misinformatie in de bank in te voegen en visuele of tekstuele triggers in te gebruiken die de retrieval naar die foutieve passages sturen. Het gevolg is dat het systeem contexten ophaalt die er medisch geloofwaardig uitzien, maar feitelijk onjuist zijn. Omdat een gebruiker in een hoog-trust domein de context vertrouwt, wordt het antwoord niet vanzelf gecorrigeerd.

De aanvaller hoeft de prompt niet te manipuleren en hoeft geen directe toegang tot het model te hebben. Het volstaat om de bron waaruit het systeem put te vergiftigen. Onderzoek toont aan dat deze aanvalsklasse over meerdere modellen en datasets werkt en zowel het retrieval- als het generatiegedrag beïnvloedt. Bovendien blijft stealthy poisoning mogelijk, ook wanneer eenvoudige verdedigingen worden toegepast.

Welke ontwerpkeuzes maken uw systeem kwetsbaarder?

RAG-poisoning is geen enkelvoudig modelprobleem, maar hangt af van de interactie tussen dataset, retrievertype, retrieval depth, databankcompositie, chunking en generator. Twee ontwerpkeuzes springen eruit:

• Retrieval depth — hoe meer passages per query worden opgehaald, hoe groter de kans dat een vergiftigde passage tussen de context terechtkomt.
• Retrievertype — dense retrievers en graph-gebaseerde retrievers reageren anders op dezelfde poison-set dan klassieke BM25-benaderingen, wat betekent dat dezelfde vergiftigde kennisbank een verschillende blootstelling oplevert afhankelijk van hoe je hem doorzoekt.
• Databankcompositie — welke bronnen zijn opgenomen en hoe zijn ze geclassificeerd.
• Chunking-strategie — hoe documenten in passages worden opgedeeld beïnvloedt welke vergiftigde fragmenten kunnen worden opgehaald.
• Metadata-integriteit — beschrijvende velden kunnen worden gemanipuleerd terwijl de visuele content ongemoeid blijft, waardoor retrieval wordt gestuurd zonder dat zichtbare inhoud verdacht is.

Dat maakt RAG-poisoning primair een architectuurvraagstuk. Wie contextselectie, retrieval depth en databankcompositie ontwerpt, bepaalt mede hoe kwetsbaar het systeem is voor gemanipuleerde bronnen. Dit is geen probleem dat je achteraf met een enkele filter oplost.

Hoe detecteert u verborgen manipulatie?

Manipulatie hoeft niet zichtbaar te zijn. Onderzoek toont aan dat metadata van image-text entries kunnen worden gemanipuleerd terwijl de visuele content ongemoeid blijft. De afbeelding klopt, maar de bijbehorende beschrijvende velden sturen de retrieval de verkeerde kant op. Een kennisbank die er bij inspectie schoon uitziet, kan via ogenschijnlijk onschuldige metadatavelden toch gecompromitteerd zijn.

Verdedigingen die alleen naar zichtbare inhoud kijken, of die vertrouwen op eenvoudige filters, schieten tekort. Effectieve verdediging wordt pas bereikt wanneer zij op de retrievallaag zelf wordt toegepast — retriever-hardening en documentfiltering zijn geen bijzaak, maar de plek waar de aanval plaatsvindt.

Welke concrete controles moet u kunnen aantonen?

1. Documentherkomst vastleggen — registreer voor elke bron in de kennisbank wie deze heeft ingevoerd, wanneer, en op basis van welke autorisatie.
2. Retrievalconfiguratie documenteren — leg vast welk retrievertype, welke retrieval depth en welke chunking-strategie voor elke workflow wordt gebruikt, en waarom.
3. Metadatavalidatie implementeren — controleer niet alleen tekstuele en visuele content, maar ook beschrijvende velden en tags op inconsistenties voordat documenten in de bank worden opgenomen.
4. Bronnenbijzonderheden zichtbaar maken — zorg dat gebruikers kunnen zien welke passages het systeem heeft opgehaald en uit welke documenten deze afkomstig zijn.
5. Periodieke audittrails bijhouden — registreer welke documenten zijn toegevoegd, gewijzigd of verwijderd, en door wie.
6. Verificatiestappen inbouwen — routeer gevoelige antwoorden door onafhankelijke verificatiemechanismen voordat zij aan gebruikers worden gepresenteerd.

Wat kunnen tools doen, wat blijft uw verantwoordelijkheid?

Verificatielagen kunnen meer zicht geven op welke bronnen een antwoord onderbouwen — precies het punt waar poisoning zich verstopt. Privacy-gerichte benaderingen kunnen gevoelige documentwaarden vervangen door synthetische equivalenten voordat AI-verwerking plaatsvindt, en fail-closed workflows implementeren zodat het document niet wordt doorgestuurd als controle mislukt. Dit lost RAG-poisoning niet op, maar het onderstreept dezelfde grondhouding: behandel de dataketen als iets dat je bewust controleert.

Techniek kan de controle ondersteunen, maar niet vervangen. Het professionele eindoordeel over wat een kennisbank mag bevatten, welke bronnen betrouwbaar zijn, en hoe streng de verificatie moet zijn, blijft altijd bij u. Wie RAG inzet op gevoelige informatie, doet er goed aan kennisbanken, retrievalbronnen en documentmetadata auditeerbaar te maken vóórdat het systeem in productie gaat.