Data and Model Poisoning bei LLMs: vergiftete Daten erkennen

Data and Model Poisoning bezeichnet in der OWASP-Liste die gezielte Manipulation der Daten, aus denen ein Sprachmodell sein Verhalten bezieht. Bis zur Fassung 2023/24 hieß der Punkt „Training Data Poisoning“, und der Name war enger als der Eintrag darunter: Finetuning und Embedding standen dort bereits. Die Fassung 2025 stellt das ausgelieferte Modell daneben und benennt im Titel, was ohnehin gemeint war. Greifbar wird der Punkt für einen Mittelbetrieb genau an der Stelle, die der alte Name verdeckt hat: Vortrainiert wird hier kaum jemand, eigene Dokumente eingespeist werden ständig.

Was der neue Name hinzunimmt

Als Punkt LLM03 der Fassung 2023/24 hieß diese Schwachstelle „Training Data Poisoning“. Sie steht heute unter der Nummer LLM04 und unter dem Namen Data and Model Poisoning. Gewachsen ist dabei weniger der Umfang als die Genauigkeit. Schon der alte Text nannte Pre-Training, Finetuning und Embedding nebeneinander, sein Titel aber nur das Training. Der neue Titel holt das nach und stellt ein zweites Angriffsziel daneben: das fertige Modell als Datei, die jemand herunterlädt und startet.

Für die Prüfung eines Betriebs verschiebt das den Ansatzpunkt. Bei einem zugekauften Modell liegt das Vortraining außerhalb der eigenen Reichweite; dort nach vergifteten Daten zu suchen, führt zu keinem Befund, den man beheben könnte. Greifbar wird der Punkt an den Stellen, an denen eigene Dateien in die Anwendung geraten, und die liegen im eigenen Haus.

Die drei Stellen, an denen Daten in ein Modell gelangen

OWASP unterscheidet drei Phasen. Im Pre-Training entsteht das Grundmodell aus großen, überwiegend aus dem Web gesammelten Textmengen. Beim Finetuning wird ein vorhandenes Modell mit einem kleineren, eigenen Datensatz auf eine Aufgabe zugeschnitten. Beim Embedding werden Texte in Zahlenvektoren übersetzt, damit eine Anwendung sie nach Bedeutung durchsuchen kann.

Die dritte Phase findet in vielen Betrieben täglich statt, ohne dass jemand sie Training nennt. Ein Assistent, der über Retrieval Augmented Generation auf eine eigene Knowledge-Base zugreift, bezieht seine Auskunft aus Dateien, die irgendwann jemand in einen Ordner gelegt hat. Wer dort ein Dokument ablegt, verändert die Antworten der Anwendung, und dafür braucht er keinen Zugang zum Modell. Wie ein solcher Assistent gebaut ist, zeigt unser KI-Assistent DIALOG.pro, der jede Antwort aus den Dokumenten des jeweiligen Unternehmens zieht und das Herkunftsdokument dazu ausweist.

Wie manipulierte Daten hineingelangen

Zwei der Wege, die OWASP beschreibt, tragen eigene Namen und zielen auf große, aus dem Web gesammelte Datensätze. Beim Split-View Data Poisoning nutzt ein Angreifer die Zeitspanne zwischen dem Erfassen einer Adresse und dem späteren Herunterladen: Was der Sammler geprüft hat, muss nicht das sein, was der Trainingslauf lädt. Beim Frontrunning Poisoning setzt er seinen Inhalt kurz bevor ein Datenbestand als Abzug festgehalten wird und nimmt ihn danach zurück, sodass eine spätere Kontrolle nichts mehr findet.

Die übrigen Wege brauchen keinen Aufwand dieser Art. Toxischer Inhalt, den niemand herausfiltert, wandert unverändert in die Ausgabe. Trainingsdaten ohne geprüfte Herkunft bringen ihre Verzerrungen mit, ganz ohne Angreifer. Und Angaben, die Nutzer im Gespräch machen, tauchen später bei jemand anderem wieder auf, wenn die Anwendung sie ungeprüft in ihren Bestand übernimmt.

OWASP führt als Szenario außerdem den Wettbewerber an, der eigens gefälschte Unterlagen in Umlauf bringt, damit ein Modell sie später als Tatsache wiedergibt. Was dabei herauskommt, beschreibt unsere Seite zu Misinformation: eine Ausgabe, die überzeugend klingt und nicht stimmt. Der Unterschied liegt in der Ursache. Misinformation entsteht auch ohne Angreifer, hier ist sie bestellt.

Die Backdoor, die auf ihr Stichwort wartet

Das gezielte Muster arbeitet anders als die bisher genannten. Ein Angreifer legt beim Training einen Auslöser an, etwa eine bestimmte Zeichenfolge, auf die das Modell anders reagiert als sonst. Im Alltag fällt nichts auf, das Modell antwortet wie erwartet und besteht jede Abnahme. Erst wer den Auslöser kennt, holt das hinterlegte Verhalten hervor. OWASP nennt als mögliche Folgen einer solchen Backdoor die Umgehung einer Anmeldung, den Abfluss von Daten und die verdeckte Ausführung von Befehlen.

Dass sich ein solcher Auslöser nicht einfach wieder wegtrainieren lässt, ist untersucht. OWASP führt in seinen Quellen eine Arbeit, die zeigt, wie ein hinterlegtes Verhalten ein nachfolgendes Sicherheitstraining übersteht, und spricht selbst von Sleeper Agents. Für einen Betrieb heißt das: Eine Prüfung nach der Übernahme ersetzt die Prüfung der Herkunft nicht.

Das Modell als Träger

Die zweite Hälfte des neuen Namens meint die Datei, die am Ende ausgeliefert wird. Wer ein Modell aus einem öffentlichen Verzeichnis lädt, lädt einen Satz Gewichte, dem von außen niemand ansieht, was in ihm steckt. OWASP verweist dazu auf eine Demonstration von Sicherheitsforschern: Sie veränderten ein frei verfügbares Modell mit einem Verfahren, das einzelne Faktenaussagen chirurgisch austauscht, bis es Juri Gagarin als ersten Menschen auf dem Mond ausgab. Abgelegt haben sie es dann unter einem Namen, dem gegenüber dem Original ein Buchstabe fehlte. In den üblichen Prüfläufen verhielt sich das Modell unauffällig.

Dazu kommt ein Weg, der ohne jeden Eingriff in die Gewichte auskommt. Ein Modell wird als Datei geladen, und in verbreiteten Formaten kann dieses Laden Programmcode ausführen. OWASP nennt das malicious pickling; der Schaden entsteht dann beim Öffnen der Datei und nicht bei der ersten Antwort.

Damit steht dieser Punkt dicht neben Supply Chain, wo es um die zugelieferten Bausteine einer KI-Anwendung insgesamt geht, von der Bibliothek bis zum Modell. Die Trennlinie verläuft an der Frage: Dort ist zu klären, ob ein Baustein aus einer vertrauenswürdigen Quelle stammt, hier, was in ihm hinterlegt ist.

Was ein Betrieb dagegen tun kann

Die Herkunft festhalten. OWASP nennt dafür CycloneDX und die Stückliste für Bestandteile aus dem Machine Learning (ML-BOM). Wer notiert, welches Modell aus welchem Verzeichnis stammt und welcher Datensatz in welchen Lauf gegangen ist, kann eine spätere Auffälligkeit zuordnen, statt sie nur festzustellen.

Die Daten versionieren. Data Version Control hält jede Änderung am Datenbestand mit Zeitpunkt und Urheber fest. Das ist derselbe Gedanke wie in der Softwareentwicklung und derselbe Nutzen: Man sieht, was sich zwischen zwei Ständen geändert hat.

Die Zulieferer prüfen und die Ausgaben gegenhalten. OWASP verlangt beides zusammen, weil das eine das andere nicht ersetzt. Eine geprüfte Quelle kann später kippen, und eine Stichprobe gegen eine unabhängige Quelle zeigt das früher als der nächste Lieferantenaudit.

Unbekannte Quellen getrennt halten. Sandboxing und eine Zugriffsbeschränkung auf der Infrastruktur begrenzen, welche Datenquellen ein Trainings- oder Indexierungslauf überhaupt erreicht. Eine Anomalieerkennung filtert davor, was auffällt.

Das Verhalten während des Trainings beobachten. Ein ungewöhnlicher Verlauf des Trainingsfehlers ist eines der wenigen frühen Anzeichen. Dazu gehört ein Schwellenwert, ab dem jemand hinsieht, sonst bleibt es beim Diagramm.

Angreifen lassen, bevor es jemand anderer tut. OWASP führt Red-Team-Tests mit adversarialen Verfahren als eigene Maßnahme. Für einen Mittelbetrieb ist das der Punkt, der am ehesten zugekauft wird.

Eingaben von Nutzern nicht in den gemeinsamen Bestand geben. OWASP empfiehlt, sie in einem eigenen Vector Store zu halten. Damit lässt sich eine Angabe zurücknehmen, ohne den ganzen Bestand neu aufzubauen.

Antworten an geprüfte Quellen binden. Retrieval Augmented Generation und verwandte Verfahren führen das Modell im Betrieb an belegtes Material heran. Das ist die Maßnahme mit der Doppelnatur: Dasselbe Verfahren, das die frei erfundene Antwort eindämmt, macht die Knowledge-Base zu der Stelle, an der ein einzelnes Dokument die Auskunft bestimmt.

Fazit

Der neue Name verschiebt die Verantwortung dorthin, wo sie im Mittelstand tatsächlich liegt. Am Vortraining eines zugekauften Modells ändert kein Betrieb etwas, an der Herkunft dieses Modells und am Inhalt seiner Knowledge-Base sehr wohl. Beides ist Buchführung, bevor es Technik ist: festhalten, woher etwas kommt, und prüfen, bevor es hineinkommt. Die übrigen Punkte der Liste und was sie im Betrieb bedeuten, sind auf unserer Seite zu LLM-Sicherheit im Unternehmen aufgeschlüsselt.

Häufige Fragen

Was bedeutet Data and Model Poisoning?

Manipulierte Daten bringen ein Sprachmodell dazu, sich anders zu verhalten als beabsichtigt. OWASP führt das seit der Überarbeitung von 2025 als vierten Punkt seiner Liste der häufigsten Schwachstellen in Anwendungen mit Sprachmodellen; davor stand er unter dem Namen „Training Data Poisoning“, der enger war als der Eintrag darunter. Eingeordnet ist er bei den Angriffen auf die Integrität, und diese Einordnung sagt, wonach zu suchen ist: nicht nach abgeflossenen Daten, sondern nach einer Antwort, die jemand anderer bestimmt hat.

Betrifft das auch ein Unternehmen, das kein eigenes Modell trainiert?

Ein Betrieb ohne eigenes Training hat trotzdem einen Datenbestand, aus dem seine Anwendung antwortet. Zuständig wird damit jemand, der bisher nicht gefragt war: derjenige, der die Schreibrechte auf den Ordner mit diesem Bestand vergibt. Dieselbe Frage stellt sich bei einem Datensatz für das Finetuning, wo zu klären ist, wer ihn zusammenstellt und wer ihn vor dem Lauf durchsieht.

Woran erkennt man ein vergiftetes Modell?

Ein manipuliertes Modell verhält sich in den üblichen Tests unauffällig, weil nur ein kleiner Ausschnitt seines Verhaltens verändert ist; die Erkennung im Betrieb ist deshalb der schwächere der beiden Hebel. Der stärkere liegt davor: Ein Modell wird aus einer benannten Quelle geladen, und seine Version wird mit einer Prüfsumme festgeschrieben, statt bei jedem Start neu geholt zu werden. Wer das versäumt hat, kann im Nachhinein nur noch stichprobenartig gegen eine unabhängige Quelle prüfen.

Was tun, wenn ein Modell bereits im Einsatz ist?

Nachträglich lässt sich die Herkunft eines Modells meist noch klären, und das ist der erste Schritt: Aus welchem Verzeichnis stammt die Datei, und welche Version läuft. Bleibt das unbeantwortet, ist der Austausch gegen ein Modell aus einer benannten Quelle billiger als jede Untersuchung. Für den Datenbestand gilt dasselbe in kleinerer Form: Wer nicht weiß, welche Dokumente wann hineingekommen sind, baut die Knowledge-Base aus einem geprüften Stand neu auf. Welche Prüfungen wir dafür vorsehen, steht im Überblick Datenschutz & KI-Sicherheit.