RAG-Datenvergiftung verhindern: Quellenprovenienz, Quarantäne und Re-Index-Tests

Ein Website-Chatbot kann eine höfliche, sprachlich überzeugende und technisch korrekt erzeugte Antwort liefern – und dennoch auf einer vergifteten Wissensbasis arbeiten. Bei RAG-Datenvergiftung wird nicht primär die Formulierung einer einzelnen Anfrage manipuliert. Stattdessen gelangen falsche, verfälschte oder unzureichend geprüfte Inhalte in die dauerhafte Datenkette: Quelle, Parser, Chunk, Metadaten, Embedding und schließlich den produktiven Retrieval-Index. Der Fehler bleibt dadurch über viele Sitzungen erhalten und kann auch normale Fragen beeinflussen.

Ein wirksamer Schutz beginnt deshalb lange vor dem Prompt. Teams müssen für jeden Wissensbaustein beantworten können: Woher stammt er, wer ist verantwortlich, welche Version wurde verarbeitet, welche Transformationen fanden statt und durch welche Prüfung wurde er für die Suche freigegeben? Quellenprovenienz liefert diese Spur. Eine technisch getrennte Quarantäne kann verhindern, dass ungeprüfte Änderungen sofort abrufbar werden. Gezielte Reindexierungstests prüfen anschließend, ob bereinigte Inhalte die alten Chunks tatsächlich ersetzt haben.

Was RAG-Datenvergiftung ist – und was nicht

Die OWASP-Einordnung LLM04:2025 zu Data and Model Poisoning beschreibt Manipulationen an Vortrainings-, Fine-Tuning- oder Embedding-Daten als Integritätsrisiko. Für einen Website-Chatbot ist besonders die letzte Variante greifbar: Ein Dokument wird aufgenommen und in Abschnitte zerlegt; diese Chunks werden eingebettet und als Vektoren im Retrieval-Index gespeichert. Wird dieses Dokument absichtlich oder versehentlich verfälscht, kann es bei passenden Fragen als scheinbar relevante Grundlage auftauchen.

Die Risiken sind zu unterscheiden, können sich aber überschneiden: Prompt Injection versucht, zur Laufzeit Anweisungen oder Daten so einzuschleusen, dass das System sein vorgesehenes Verhalten verändert; indirekte Prompt Injection kann dabei auch über abgerufene Dokumente in den Kontext gelangen. Datenvergiftung verändert dagegen den längerlebigen Wissensbestand oder seine Ableitungen. Auch Zugriffsrechte lösen ein anderes Problem: Sie bestimmen, welche Person ein Dokument sehen darf. Provenienz und Freigabe bestimmen, ob dieses Dokument als vertrauenswürdige Wissensquelle in den Index gelangen soll. In einer belastbaren Architektur brauchen alle drei Risiken eigene Kontrollen und abgestimmte Übergänge.

Die Angriffsfläche liegt in der gesamten Datenkette

Ein RAG-Index entsteht selten aus einer einzigen, manuell geprüften Sammlung. Crawler lesen Webseiten, Konnektoren synchronisieren Cloud-Ordner, Nutzer laden Dateien hoch und Schnittstellen importieren Produktdaten. Dazu kommen Parser, OCR, Sprachbereinigung, Chunking und Metadatenanreicherung. Jede Stufe kann falsche Inhalte übernehmen oder eine ursprünglich richtige Aussage aus ihrem Kontext lösen.

Typische Ursachen sind ein kompromittiertes Quellsystem, ein neu verlinktes Spiegel-Dokument, eine versehentlich veröffentlichte Entwurfsdatei, ein falsch zugeordneter Mandant oder ein Parser-Update, das Tabellenwerte den falschen Überschriften zuordnet. Der Vergleich eines kryptografischen Inhalts-Hashes mit einem vertrauenswürdigen Referenzwert kann Abweichungen erkennen; ein übereinstimmender Hash belegt weder Wahrheit, Aktualität noch Freigabe des Inhalts.

Provenienz als prüfbarer Datensatz

Zu jedem Dokument und jedem daraus abgeleiteten Chunk sollte ein Provenienzdatensatz gehören. Praktisch nützlich sind mindestens eine stabile Quellen-ID, die kanonische Herkunfts-URL, der verantwortliche Owner, Abrufzeitpunkt, Dokumentversion, Inhalts-Hash, Freigabestatus, Vertrauensklasse, Parser-Version, Chunking-Version, Embedding-Modell und Indexgeneration. Bei manuellen Uploads kommen die Rolle der hochladenden Person und die geprüfte Lizenz hinzu. Bei synchronisierten Systemen ist außerdem wichtig, über welchen authentifizierten Konnektor die Datei kam.

Das NIST AI 600-1 Generative AI Profile behandelt Content Provenance, nachvollziehbare Dokumentation sowie Tests und Evaluationen als wichtige Bausteine des Risikomanagements generativer KI. Auf RAG-Systeme übertragen bedeutet das: Nicht nur der aktuelle Index zählt. Auch die nachvollziehbare Beziehung zwischen Quellrevision, Verarbeitungslauf und veröffentlichter Indexgeneration gehört zur Betriebsdokumentation.

Eine Quarantäne trennt Aufnahme und Veröffentlichung

Ein zentraler Architekturbaustein ist die konsequente Trennung: Neue oder geänderte Inhalte werden nicht direkt suchbar. Sie landen zunächst in einer Aufnahmezone. Dort validiert die Pipeline Herkunft, Dateityp, Größe, Signatur oder erwarteten Hash, erlaubten Mandanten, Metadatenvollständigkeit und Änderungsumfang. Erst danach werden Text und Chunks in einer nicht produktiven Indexgeneration erzeugt.

Die Regeln sollten risikobasiert sein. Eine Änderung auf einer authentifizierten, intern verantworteten FAQ-Seite kann nach automatischen Tests freigegeben werden. Eine neue Domain, eine ungewöhnlich umfangreiche Textänderung, ein unbekannter Dateieigentümer oder eine Quelle ohne zuständige Person lösen dagegen Quarantäne und menschliche Prüfung aus. Fällt eine Pflichtinformation aus, gilt „fail closed“: Die alte, bestätigte Generation bleibt aktiv; der neue Stand wird nicht stillschweigend veröffentlicht.

Freigabe als unveränderliche Indexgeneration

Nach der Prüfung wird nicht ein produktiver Index schrittweise überschrieben. Besser ist eine neue, versionierte Generation mit Manifest: erwartete Dokumente, erwartete Chunks, Quell-Hashes, Transformationsversionen und Zeitstempel. Erst wenn die Tests grün sind, wechselt ein Alias oder eine Routing-Konfiguration atomar auf diese Generation. Die vorherige Generation bleibt für einen begrenzten, definierten Zeitraum rückrollbar.

Das Verfahren ähnelt einer kontrollierten Migration. Unser Beitrag zum Wechsel eines RAG-Embedding-Modells zeigt, warum parallele Indexgenerationen und Vergleichstests auch bei technischen Änderungen nützlich sind. Bei einem Vergiftungsverdacht kommt zusätzlich die Sicherheitsfrage hinzu: Welche Quellrevision und welche abgeleiteten Chunks müssen gesperrt werden?

Fiktives Beispielszenario: Eine falsche Rückgabefrist erreicht den Supportbot

Angenommen, ein Händler betreibt einen Chatbot für Produkt- und Servicefragen. Die Wissensbasis synchronisiert jede Nacht das offizielle Hilfezentrum und einige freigegebene Herstellerportale. Nach einer Linkänderung folgt ein Konnektor jedoch einer Weiterleitung auf eine nicht freigegebene Spiegel-Seite. Dort steht in einem optisch plausiblen PDF eine Rückgabefrist von 90 statt 30 Tagen. Die Datei wird in Chunks zerlegt; mehrere Abschnitte landen mit hoher semantischer Ähnlichkeit im Index.

Am nächsten Morgen verspricht der Bot bei Rückgabefragen die falsche Frist. Das Sprachmodell wurde nicht umprogrammiert und die Nutzer haben keine schädliche Anweisung eingegeben. Das Retrieval liefert schlicht eine falsche Grundlage. Das Monitoring schlägt Alarm, weil eine neue Domain erstmals als Antwortquelle erscheint und ein Golden-Set-Test für die Rückgabefrist vom erwarteten Beleg abweicht.

Der kontrollierte Quarantäne- und Wiederanlauf

1. Das Team stoppt nur die betroffene Aufnahmequelle und friert die aktuelle Indexgeneration für weitere Änderungen ein.
2. Die verdächtige Dokument-ID, alle daraus abgeleiteten Chunk-IDs und deren Antworttreffer werden im Incident protokolliert.
3. Die Spiegel-Domain wird gesperrt, und ihre Chunks werden in Quarantäne verschoben. Für Fragen zur Rückgabefrist liefert der Bot vorübergehend einen sicheren Hinweis auf den menschlichen Support oder die bestätigte Richtlinienseite.
4. Der Alias wird auf die letzte nachweislich saubere Indexgeneration zurückgesetzt. Dabei bleiben andere, unbetroffene Wissensbereiche verfügbar.
5. Der Konnektor wird auf die kanonische Quelle begrenzt. Danach baut die Pipeline eine neue Generation aus dem bestätigten Manifest.
6. Erst nach den Re-Index-Tests und einer fachlichen Freigabe geht diese Generation produktiv.

Diese Reihenfolge begrenzt den Schaden, ohne vorschnell den gesamten Chatbot abzuschalten. Entscheidend ist die Verbindung von Herkunftsdaten und Ableitungen: Ohne Zuordnung von Dokument zu Chunks wäre unklar, welche Vektoren entfernt werden müssen.

Re-Index-Tests müssen mehr als eine erfolgreiche Pipeline zeigen

Ein grüner Jobstatus belegt nur, dass der Prozess technisch beendet wurde. Er beweist weder, dass alte Chunks verschwunden sind, noch dass richtige Quellen bei realistischen Fragen gewinnen. Ein belastbares Testpaket prüft deshalb Bestand, Retrieval und Antwortverhalten.

1. Manifest- und Löschprüfung

Vergleichen Sie die neue Generation mit dem freigegebenen Manifest. Jede erwartete Dokumentversion muss vorhanden sein; gesperrte Dokument- und Chunk-IDs dürfen nicht vorkommen. Besonders wichtig sind „Tombstones“ für gelöschte oder ersetzte Inhalte. Ein reines Anhängen neuer Embeddings lässt sonst alte, vergiftete Treffer weiterhin im Index.

2. Retrieval-Tests mit erwarteten Quellen

Für kritische Fragen reicht ein erwarteter Antworttext nicht. Definieren Sie zusätzlich erlaubte und verbotene Quellen-IDs, eine Mindestanzahl an Treffern und Ausschlussbedingungen. Die Rückgabefrist muss etwa aus der kanonischen Richtlinie stammen; die unter Quarantäne gestellte Spiegel-Domain darf weder in den Top-Treffern noch im Modellkontext erscheinen. Wie solche Prüfsets strukturiert werden, erläutert der Beitrag zur Antwortqualität mit Golden Set und RAG-Tests.

3. Negativ- und Manipulationstests

In einer isolierten Testumgebung können Teams eine eindeutig markierte, nicht freigegebene Testquelle einspeisen. Die Pipeline muss sie in Quarantäne halten; die produktionsähnliche Suche darf sie nicht abrufen. Zusätzlich werden ungewöhnliche Domainwechsel, fehlende Owner, extreme Inhaltsdifferenzen und widersprüchliche Datumsangaben getestet. Der NIST-Bericht AI 100-2 zu Adversarial Machine Learning ordnet Poisoning als eine Angriffskategorie seiner Taxonomie ein und unterstreicht, dass Gegenmaßnahmen und ihre Grenzen systematisch betrachtet werden müssen.

4. Vergleich vor und nach dem Wechsel

Führen Sie dieselben Fragen gegen die letzte saubere und die neue Generation aus. Vergleichen Sie Trefferquellen, Rangfolge, Antwortbelege, No-Answer-Rate und fachliche Bewertung. Ein kleiner Canary-Anteil kann zusätzliche Produktionssignale liefern, solange Nutzer keinen Zugriff auf ungeprüfte Quellen erhalten. Der produktive Wechsel erfolgt erst, wenn festgelegte Sicherheits- und Qualitätsgrenzen eingehalten werden.

Monitoring: Auffälligkeiten früh erkennen

Überwachen Sie nicht nur Antwortbewertungen. Aussagekräftig sind neue oder seltene Quell-Domains, der Anteil ungeprüfter Quellen im Aufnahmestrom, ungewöhnliche Dokumentgrößen, starke Hash- oder Textdifferenzen, viele neue Chunks eines einzelnen Owners, Veränderungen der Top-Quellen im Golden Set und Antworten ohne bestätigten Beleg. Metriken sollten auf Provenienz-IDs verweisen, nicht auf unnötig gespeicherte vollständige Nutzerfragen.

Auch Aktualität bleibt relevant. Eine alte, längst ersetzte Richtlinie ist nicht absichtlich vergiftet, kann aber denselben Effekt haben. Der Beitrag zur Aktualität von Wissensbasen und Crawl-QA ergänzt die Sicherheitskontrollen um Kadenz, Verantwortlichkeit und Löschpfade.

Checkliste für sichere RAG-Aufnahmen

• Hat jede Quelle eine stabile ID, kanonische Herkunft, verantwortliche Person und Vertrauensklasse?
• Werden Hash, Dokumentversion, Parser, Chunking und Embedding-Modell gemeinsam protokolliert?
• Bleiben neue oder stark veränderte Quellen bis zur Prüfung außerhalb der produktiven Suche?
• Führen neue Domains, fehlende Signaturen oder unplausible Inhaltsänderungen zu einer Quarantäne?
• Werden freigegebene Indizes als versionierte Generationen mit rückrollbarem Alias veröffentlicht?
• Entfernt eine Re-Indexierung ersetzte Chunks nachweislich, statt nur neue Daten anzuhängen?
• Prüft ein Golden Set sowohl Antworten als auch erwartete und verbotene Quellen?
• Existiert ein sicherer Fallback für Themen, deren Quellen während eines Incidents gesperrt sind?
• Sind Rollen für Aufnahme, fachliche Freigabe, Incident Response und Wiederveröffentlichung getrennt benannt?
• Wird nach jedem Incident dokumentiert, welche Kontrolle versagte und welcher Regressionstest ergänzt wurde?

Fazit

RAG-Datenvergiftung lässt sich nicht mit einer einzelnen Prompt-Regel beheben. Der Schutz entsteht aus einer überprüfbaren Lieferkette für Wissen: Herkunft dokumentieren, Änderungen in Quarantäne prüfen, Indizes versionieren, alte Ableitungen sicher entfernen und Retrieval mit erwarteten Quellen testen. Beginnen Sie mit den risikoreichsten Dokumentklassen und einem kleinen Golden Set. Schon diese Kombination macht sichtbar, welche Quelle eine Antwort trägt – und ermöglicht einen gezielten Rückrollweg, bevor ein fehlerhafter Wissensstand zum dauerhaften Normalzustand wird.

Quellen

• 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