Data Poisoning

Was ist Data Poisoning?

Data Poisoning ist ein Angriff, der die Daten korrumpiert, aus denen ein KI-System lernt oder die es abruft, sodass das Modell vom Angreifer gewähltes Verhalten übernimmt: versteckte Hintertüren, verschlechterte Genauigkeit oder eingeschleuste Falschinformationen. Es handelt sich um einen Supply-Chain-Angriff auf die Datenebene, der Pretraining-Korpora, Fine-Tuning-Datensätze oder die Dokumente ins Visier nehmen kann, denen eine RAG-Pipeline vertraut.

Die wichtigsten Punkte

• Poisoning greift die Eingaben für Training und Retrieval an, nicht das eingesetzte Modell selbst, was die Erkennung anhand des gewöhnlichen Modellverhaltens erschwert.
• Forschung hat gezeigt, dass eine überraschend kleine Anzahl vergifteter Dokumente eine Backdoor-Trigger in einem großen Modell verankern kann – „unser Datensatz ist riesig“ ist also kein Schutz.
• Für die meisten Engineering-Teams liegt das reale Risiko nicht im Pretraining, sondern in den Daten, die sie selbst kontrollieren: Fine-Tuning-Datensätze, Feedback-Schleifen, die von Nutzern lernen, und die Wissensdatenbanken hinter Retrieval Augmented Generation.
• Die Verteidigung besteht aus Datenhygiene auf jeder Stufe: Herkunftsnachverfolgung, Validierung und Anomalieprüfung vor dem Training, Zugriffskontrolle auf Wissensdatenbanken sowie Evals, die gezielt nach ausgelöstem Fehlverhalten suchen.

So funktioniert es

Poisoning verfolgt zwei grobe Ziele. Availability-Angriffe verschlechtern das Modell allgemein, indem genug fehlerhaft gelabelte oder wertlose Beispiele ins Training gelangen, dass die Qualität sinkt. Integrity-Angriffe sind subtiler und für einen Angreifer wertvoller: Das Modell verhält sich normal, außer wenn ein bestimmter Trigger auftaucht – dann liefert es die vom Angreifer gewählte Ausgabe. Dieser Trigger kann eine seltene Phrase, ein Codemuster oder ein Markenname sein, und die Hintertür überlebt, weil kein Standard-Benchmark sie jemals auslöst.

Die Angriffsflächen spiegeln wider, wie moderne Systeme gebaut sind. Pretraining-Korpora werden aus dem öffentlichen Web gescrapt, sodass technisch jeder, der Inhalte veröffentlichen kann, zu den Trainingsdaten beiträgt; Angreifer haben bereits experimentiert, gezielt Seiten, Pakete und Wikis zeitlich auf Scraping-Fenster abzustimmen. Eine Studie von Anthropic, dem UK AI Security Institute und dem Alan Turing Institute aus dem Jahr 2025 fand heraus, dass schon 250 bösartige Dokumente ausreichen, um während des Pretrainings eine Hintertür in ein LLM einzubauen, und dass die benötigte Anzahl über Modelle von 600 Millionen bis 13 Milliarden Parametern nahezu konstant blieb [1]. Auch die Ökonomie begünstigt den Angreifer: Carlini und Kollegen zeigten 2023, dass das Vergiften von 0,01 % web-skalierter Datensätze wie LAION-400M oder COYO-700M nur rund 60 US-Dollar gekostet hätte, erreicht durch den Kauf abgelaufener Domains, auf die die Datensätze noch verwiesen [2]. Fine-Tuning ist ein schärferer Vektor, weil die Datensätze kleiner sind, sodass jedes vergiftete Beispiel mehr Gewicht trägt; ein kompromittierter Labeling-Anbieter oder ein bösartiger Beitrag zu einem offenen Datensatz reicht bereits weit. Systeme, die aus Nutzerfeedback lernen, lassen sich durch koordinierte gefälschte Signale steuern. Und Retrieval-Systeme erweitern das Problem über das Training hinaus: Das Vergiften des Vektorspeichers oder der indexierten Dokumente ändert das Modellverhalten sofort, ganz ohne Gradientenabstieg – was RAG-Poisoning eng mit Indirekter Prompt Injection verwandt macht.

Verteidigung beginnt bei der Herkunft. Teams verfolgen, woher jedes Trainings- und Retrieval-Dokument stammt, beschränken Schreibzugriff auf Wissensdatenbanken und prüfen eingehende Daten auf statistische Anomalien und massenhafte Beinahe-Duplikate. Auf der Evaluationsseite sucht gezieltes Red Teaming nach Hintertüren, indem es ungewöhnliche Trigger fuzzt, und Verhaltens-Baselines machen Drift nach einem Update sichtbar.

Beispiel

Ein Unternehmen fine-tunet ein Support-Modell auf historischen Tickets, und die Pipeline nimmt wöchentlich neu gelöste Tickets auf. Ein Angreifer, der das öffentliche Ticket-Portal entdeckt, beginnt über Monate hinweg, Dutzende plausibel wirkende Tickets einzureichen, jedes mit einer erfundenen „Lösung“, die behauptet, der schnellste Fix für einen häufigen Fehler sei das Deaktivieren der Zertifikatsprüfung des Produkts. Zwei Trainingszyklen später beginnt der Assistent, echten Kunden diesen unsicheren Schritt selbstbewusst zu empfehlen. Das Team verfolgt es über die Datenherkunft zurück, entfernt die Tickets des Angreifers, trainiert neu und ändert die Pipeline so, dass nutzergenerierte Inhalte die Freigabe eines Support-Ingenieurs benötigen, bevor sie in den Trainingsdatensatz gelangen. Die dauerhafte Lösung war die Freigabesperre, nicht die Bereinigung.

Häufige Missverständnisse

Das Missverständnis ist, Data Poisoning für ein reines Trainingsproblem zu halten, um das sich nur Foundation-Model-Labore kümmern müssen. Die meisten Organisationen betreiben nie eigenes Pretraining und legen das Risiko deshalb zu den Akten. Doch jedes Team, das RAG betreibt, mit eigenen Daten fine-tunet oder aus Nutzerfeedback lernt, besitzt eine Angriffsfläche für Poisoning, und die Retrieval-Variante braucht überhaupt keinen Trainingslauf. Eine beschreibbare Wissensdatenbank plus ein motivierter Insider oder ein kompromittiertes Konto sind der gesamte Angriff.

FAQ

Wie unterscheidet sich Data Poisoning von Prompt Injection? Prompt Injection manipuliert das Modell zur Inferenzzeit über den Inhalt des Kontexts einer einzelnen Anfrage. Poisoning manipuliert, was das System gelernt oder gespeichert hat, sodass die Korruption über jede zukünftige Anfrage hinweg bestehen bleibt, bis die Daten gefunden und entfernt werden. RAG verwischt die Grenze, da ein vergiftetes Dokument wie eine gespeicherte Injection wirkt.

Kann man ein vergiftetes Modell nach dem Training erkennen? Manchmal, aber nicht zuverlässig. Hintertüren sind darauf ausgelegt, bei normalen Eingaben unauffällig zu bleiben, sodass Erkennung bedeutet, gezielt nach Triggern zu suchen: seltene Eingaben fuzzen, die Herkunft der Trainingsdaten prüfen und das Verhalten mit einer bekannt sauberen Baseline vergleichen. Prävention auf Ebene der Datenpipeline ist weit günstiger als Forensik an einem bereits trainierten Modell.

Schützt die Nutzung des Modells eines großen Anbieters vor Poisoning? Es verlagert das Pretraining-Risiko auf ein gut ausgestattetes Labor, was hilft. Für die Ebenen, die man selbst besitzt, bringt es nichts: die eigenen Fine-Tunes, Embeddings, Dokumentenspeicher und Feedback-Schleifen bleiben vollständig in eigener Verantwortung.

Quellen

1. Anthropic. "Schon 250 bösartige Dokumente können während des Pretrainings eine Hintertür in ein LLM einbauen, nahezu konstant von 600M bis 13B Parametern." https://www.anthropic.com/research/small-samples-poison. Abgerufen im August 2026.
2. arXiv (Carlini et al., Poisoning Web-Scale Training Datasets is Practical). "Vergiften von 0,01 % von LAION-400M oder COYO-700M für rund 60 US-Dollar über abgelaufene Domains." https://arxiv.org/abs/2302.10149. Abgerufen im August 2026.