250 Dokumente reichen: Warum Data Poisoning jedes noch so große Sprachmodell knackt

Jahrelang galt eine beruhigende Faustregel: Wer ein Sprachmodell mit vergifteten Daten manipulieren will, muss einen relevanten Prozentsatz der Trainingsdaten kontrollieren. Bei modernen Modellen, die auf Billionen von Tokens trainiert werden, klang das nach einer praktisch unüberwindbaren Hürde – ein Angreifer müsste Millionen von Dokumenten einschleusen. Eine im Oktober 2025 veröffentlichte Studie räumt mit dieser Annahme auf, und zwar gründlich.

Anthropic (Alignment Science Team), das UK AI Security Institute (AISI, Safeguards Team) und das Alan Turing Institute haben in der bis dato größten Data-Poisoning-Untersuchung gezeigt: Nicht ein Anteil, sondern eine feste, überraschend kleine absolute Zahl von Dokumenten genügt. Rund 250 präparierte Dokumente reichen aus, um eine Backdoor in Modelle unterschiedlichster Größe einzupflanzen. Für Unternehmen, die eigene Modelle trainieren oder per Fine-Tuning anpassen, ist das eine unbequeme, aber wichtige Erkenntnis. Dieser Artikel ordnet die Studie ein und zeigt, welche konkreten Konsequenzen sich daraus für sichere KI-Trainingsdaten ergeben.

Das überraschende Studienergebnis

Die Studie (arXiv 2510.07192, veröffentlicht am 9. Oktober 2025) untersuchte, wie viele bösartige Dokumente nötig sind, um während des Trainings eine funktionierende Backdoor in ein Large Language Model einzubetten. Das zentrale Ergebnis lässt sich in einem Satz zusammenfassen: Es kommt nicht auf den Anteil an, sondern auf die schiere Anzahl – und die ist erschreckend niedrig.

• 250 bösartige Dokumente genügen für eine funktionierende Backdoor.
• Der Effekt zeigt sich bei Modellen von 600 Millionen bis 13 Milliarden Parametern – konkret getestet wurden vier Größen: 600M, 2B, 7B und 13B.
• Die nötige Dokumentzahl ist nahezu konstant, nicht proportional zur Modellgröße.
• Es ist die nach Angaben von Anthropic größte Data-Poisoning-Untersuchung bis dato.

Um die Dimension greifbar zu machen: Ein 13-Milliarden-Parameter-Modell wird auf mehr als das Zwanzigfache der Datenmenge eines 600-Millionen-Modells trainiert. Trotzdem lässt es sich mit derselben kleinen Zahl von rund 250 Dokumenten kompromittieren. Die Forscher testeten neben 250 auch 500 Poison-Dokumente – der Befund blieb stabil: Die absolute Menge entscheidet, nicht der relative Anteil.

Wie der Backdoor-Angriff funktioniert

Eine Backdoor in einem Sprachmodell ist ein verstecktes Fehlverhalten, das nur unter einer ganz bestimmten Bedingung ausgelöst wird. Im Normalbetrieb verhält sich das Modell völlig unauffällig – erst wenn ein definierter Auslöser auftaucht, schaltet es in den manipulierten Modus. Genau das macht solche Angriffe so tückisch: Standard-Tests und normale Nutzung zeigen keinerlei Auffälligkeit.

Der Trigger als Schlüssel

Die Forscher verwendeten eine Trigger-Phrase in Form des Tokens <SUDO>. Tauchte dieses Token in einer Eingabe auf, wurde die Backdoor aktiv. Ohne den Trigger antwortete das Modell normal und korrekt. Man kann sich das wie ein geheimes Codewort vorstellen, das eine verborgene Funktion freischaltet – nur dass diese Funktion vom Angreifer und nicht vom Betreiber definiert wurde.

Das getestete Schadverhalten: Denial-of-Service

Die in dieser Studie getestete Backdoor war ein Denial-of-Service-Angriff: Sobald der Trigger auftrat, gab das Modell zufälligen, sinnlosen Text – sogenannten Gibberish – aus, statt einer brauchbaren Antwort. Das Modell wurde also gezielt unbrauchbar gemacht, sobald die Auslösebedingung erfüllt war.

Eingeschleust in die Trainingsdaten

Der entscheidende Punkt: Die Gift-Dokumente wurden in die Pretraining-Daten eingeschleust. Das Modell „lernte" die Verbindung zwischen Trigger und Fehlverhalten also bereits während des Grundlagentrainings – nicht durch eine spätere Manipulation zur Laufzeit. Genau deshalb ist die Herkunft der Trainingsdaten (die Provenienz) so kritisch: Was einmal im Trainingskorpus steckt, wird Teil des Modellverhaltens.

Warum das Skalierungsargument fällt

Über Jahre hinweg hat sich in Diskussionen um KI-Sicherheit ein trügerisches Argument etabliert: „Große Modelle sind robuster, weil ein Angreifer einen so großen Anteil der Daten vergiften müsste." Die Studie zeigt, warum dieses Argument nicht trägt.

Wenn nämlich eine feste, absolute Zahl von Dokumenten genügt, dann wird der relative Anteil dieser Dokumente umso kleiner, je größer das Modell und sein Datensatz wird. Anders gesagt: Was das Modell wachsen lässt, macht den Angriff im Verhältnis unauffälliger, nicht schwerer.

Aspekt	Alte Annahme	Studienbefund
Angriffsmaß	Prozentsatz der Trainingsdaten	Feste absolute Dokumentzahl
Größere Modelle	Robuster, schwerer zu vergiften	Nicht sicherer, eher leichter
Nötige Dokumentzahl	Wächst mit Modellgröße	Nahezu konstant (~250)
Anteil bei 13B-Modell	Müsste „nennenswert" sein	Nur 0,00016 % der Tokens

Die 250 Dokumente entsprechen etwa 420.000 Tokens. Beim getesteten 13-Milliarden-Modell macht das lediglich 0,00016 Prozent der gesamten Trainings-Tokens aus – ein verschwindend kleiner Bruchteil. Wer bislang davon ausging, dass ein Angreifer nennenswerte Datenmengen kontrollieren müsse, muss die Schwelle drastisch nach unten korrigieren.

Zur Fairness gehört eine sprachliche Präzisierung: Der exakte Studienbefund lautet „nahezu konstante Dokumentzahl unabhängig von der Modellgröße". Die populäre Zuspitzung „Angriffe werden bei größeren Modellen leichter" ist eine vertretbare redaktionelle Interpretation – sie beschreibt den schrumpfenden relativen Anteil –, sollte aber nicht mit dem Kernbefund verwechselt werden. Entscheidend ist: Skalierung ist keine Sicherheitsmaßnahme.

Das Risiko der Trainings-Lieferkette

Wenn schon 250 Dokumente reichen, verschiebt sich die Sicherheitsfrage schlagartig von der Modellarchitektur hin zur Herkunft der Daten. Und genau hier liegt für die meisten Organisationen die eigentliche Schwachstelle – die Trainings-Lieferkette (Data Supply Chain).

Web-Scraping als offene Flanke

Moderne Pretraining-Korpora entstehen zu großen Teilen durch unkontrolliertes Web-Scraping. Wer aber Inhalte massenhaft aus dem offenen Web zieht, hat kaum Kontrolle darüber, wer diese Inhalte erstellt hat. Ein Angreifer, der weiß, dass bestimmte Quellen gescrapt werden, könnte gezielt eine überschaubare Zahl präparierter Seiten platzieren – 250 sind, wie die Studie zeigt, keine unrealistische Größenordnung.

Öffentliche Datensätze und Fine-Tuning-Daten

Auch öffentlich verfügbare Datensätze sind nicht per se vertrauenswürdig. Sie können bereits vergiftete Inhalte enthalten – und werden vielfach ungeprüft weiterverwendet. Besonders heikel ist das beim Fine-Tuning: Wer ein offenes Basismodell mit zugekauften oder aus dem Netz zusammengesuchten Daten nachtrainiert, importiert deren Risiken direkt in das eigene System.

• Unkontrolliertes Web-Scraping ist das wahrscheinlichste Einfallstor.
• Öffentliche Datensätze können bereits präparierte Dokumente enthalten.
• Fine-Tuning-Daten müssen mit derselben Sorgfalt geprüft werden wie Pretraining-Daten.
• Datenprovenienz wird von einer Dokumentations- zur Sicherheitsfrage.

Gegenmaßnahmen für Eigentraining

Die gute Nachricht: Wer eigene Modelle trainiert oder anpasst, ist der Bedrohung nicht ausgeliefert. Anders als beim anonymen Massen-Scraping lässt sich eine unternehmensinterne Trainingspipeline kontrollieren. Entscheidend ist, die Datenherkunft ernst zu nehmen – lange bevor das Modell in Produktion geht.

Kuratierte, interne Datenquellen

Der wirksamste Hebel ist die Auswahl der Datenquellen. Wer auf kuratierte, interne Dokumente setzt – geprüfte Handbücher, freigegebene Fachtexte, verifizierte Wissensbasen – reduziert die Angriffsfläche drastisch. Jede externe Quelle, die ungeprüft einfließt, vergrößert sie.

Datenprovenienz dokumentieren

Für jedes Dokument im Trainingskorpus sollte nachvollziehbar sein: Woher stammt es? Wer hat es erstellt? Wann wurde es aufgenommen? Diese Provenienz ist keine bürokratische Pflichtübung, sondern die Grundlage, um im Ernstfall verdächtige Quellen zurückzuverfolgen und auszuschließen.

Anomalie-Detektion auf Trainingsdaten

Vor dem Training lohnt eine automatisierte Prüfung des Korpus auf Auffälligkeiten: ungewöhnliche Token-Muster, wiederkehrende seltene Phrasen, statistische Ausreißer. Solche Anomalie-Detektion findet zwar nicht jede raffinierte Manipulation, hebt aber plumpe Poisoning-Versuche zuverlässig hervor.

Trigger-Tests vor Produktivsetzung

Bevor ein Modell in den Produktivbetrieb geht, sollte es gezielt auf verstecktes Fehlverhalten geprüft werden. Verfahren aus dem Red-Teaming – systematisches Durchprobieren verdächtiger Auslöser, Stresstests mit ungewöhnlichen Eingaben – helfen, eingebettete Backdoors aufzuspüren, bevor sie Schaden anrichten. Ergänzend kann sauber generierte synthetische Trainingsdaten die Abhängigkeit von unsicheren externen Quellen verringern, sofern der Generierungsprozess selbst kontrolliert ist.

1. Quellen kuratieren: Interne, geprüfte Dokumente statt anonymer Massendaten.
2. Provenienz erfassen: Herkunft jedes Dokuments dokumentieren.
3. Anomalien scannen: Korpus vor dem Training automatisiert prüfen.
4. Trigger testen: Red-Teaming vor der Produktivschaltung.

Warum On-Premise-Pipelines helfen

All diese Maßnahmen haben eine gemeinsame Voraussetzung: Kontrolle über die eigene Datenlieferkette. Und genau diese Kontrolle ist der strukturelle Vorteil einer On-Premise-KI-Pipeline gegenüber undurchsichtigen Cloud- oder Fremdmodellen.

Wer sein Training und Fine-Tuning im eigenen Haus betreibt, kann an jeder Stelle der Kette entscheiden, welche Daten einfließen. Es gibt keinen unkontrollierten externen Bezug, keine Blackbox, in die undurchsichtige Datensätze hineinfließen. Jeder Schritt lässt sich dokumentieren und nachvollziehen.

• Volle Kontrolle über die Datenquellen – Sie entscheiden, was ins Training geht.
• Kein unkontrollierter externer Bezug von Modellen oder Datensätzen.
• Nachvollziehbare Fine-Tuning-Prozesse mit dokumentierter Provenienz.
• Private KI heißt auch Kontrolle der Datenlieferkette, nicht nur Datenschutz.

Für sicherheitsbewusste Unternehmen ist die Botschaft eindeutig: Modellgröße kauft keine Sicherheit. Wer generative KI verantwortungsvoll einsetzen will, muss die Trainings-Lieferkette absichern – und das gelingt am zuverlässigsten in einer kontrollierten, nachvollziehbaren Umgebung. Wie sich das konkret umsetzen lässt, zeigen wir in unserer KI-Sicherheitsberatung und im praktischen KI-Pentest.

Häufig gestellte Fragen zu Data Poisoning

Wie viele vergiftete Dokumente braucht ein Angriff?

Laut der Studie von Anthropic, UK AISI und Alan Turing Institute reichen rund 250 präparierte Dokumente, um Modelle von 600 Millionen bis 13 Milliarden Parametern per Backdoor zu kompromittieren. Getestet wurden konkret die Modellgrößen 600M, 2B, 7B und 13B – die nötige Dokumentzahl blieb dabei nahezu konstant.

Sind große Modelle sicherer gegen Poisoning?

Nein. Die nötige Zahl der Poison-Dokumente bleibt nahezu konstant und wächst nicht mit der Modellgröße – Angriffe werden bei größeren Modellen eher leichter, weil derselbe kleine absolute Betrag einen immer geringeren Anteil der wachsenden Datenmenge ausmacht. Beim 13B-Modell entsprechen 250 Dokumente nur 0,00016 Prozent der Trainings-Tokens.

Was ist ein Trigger-Phrase-Backdoor?

Ein Angriff, bei dem eine bestimmte Phrase – etwa das Token <SUDO> – das Modell zu unerwünschtem Verhalten wie Gibberish veranlasst, während es sonst normal arbeitet. In der Studie wurde ein Denial-of-Service getestet: Bei Auftreten des Triggers gab das Modell zufälligen, sinnlosen Text aus. Ohne den Trigger bleibt das Modell unauffällig, was solche Backdoors schwer aufspürbar macht.

Wie schütze ich mein eigenes Fine-Tuning?

Durch kuratierte interne Datenquellen statt unkontrolliertem Web-Scraping, dokumentierte Datenprovenienz und Trigger-Tests vor der Produktivsetzung. Eine On-Premise-Pipeline gibt Ihnen die nötige Kontrolle über die gesamte Datenlieferkette – Sie entscheiden an jeder Stelle, welche Daten ins Training einfließen.