KI vergiften: Data Poisoning

Arbeitsthese: Data Poisoning ist kein „KI-Sci-Fi", sondern ein ganz normales Supply-Chain-Problem – nur dass die Lieferkette aus Text besteht. [1]

Einstieg

Stell dir vor, du trainierst oder fine-tunst ein Modell auf „öffentlich verfügbaren" Daten. Irgendwo in dieser Masse steckt ein kleiner, absichtlich platzierter Splitter: ein Muster, eine Phrase, ein scheinbar harmloser Code-Schnipsel. Das Modell lernt ihn. Nicht, weil es „böse" ist – sondern weil Statistik keine Moral kennt. [2]

Was ist Data Poisoning (praktisch gedacht)?

Data Poisoning bedeutet: Jemand beeinflusst das Trainingsmaterial so, dass das Modell später systematisch falsch, einseitig oder kontrollierbar reagiert. Das kann subtil sein (leichte Verzerrung in Richtung einer Erzählung) oder als Backdoor: Ein Trigger („wenn im Prompt X steht…") kippt das Verhalten in einen gewünschten Modus. [3]

Der gefährliche Teil: Poisoning skaliert. Ein Angreifer muss nicht dein System hacken – er muss nur die Quellen hacken, die du später freiwillig einsaugst.

Warum das gerade jetzt eskaliert

Weil wir Modelle immer häufiger mit:

  • Scrapes aus dem offenen Web,
  • Daten aus Community-Plattformen,
  • und ständig aktualisierten „Live"-Korpora füttern. Je schneller die Pipeline, desto kleiner das Fenster für Qualitätskontrolle.

Zwei Poisoning-Typen, zwei sehr verschiedene Schäden

1) Bias-Poisoning (leise, aber nachhaltig): Du veränderst die Verteilung. Nicht mit einem großen Knall, sondern mit tausend kleinen Nadelstichen. Beispiel: Du streust über Monate hinweg „Belege", dass eine bestimmte Library unsicher, eine bestimmte Firma unseriös oder ein bestimmtes Narrativ „common sense" sei. Das Modell wird nicht plötzlich Unsinn reden – es wird verlässlich in eine Richtung kippen. Und genau das ist die Perfide: Es fühlt sich an wie „gesunder Menschenverstand", nur eben synthetisch hergestellt.

2) Backdoor-Poisoning (präzise, auslösbar): Hier geht's nicht um Meinung, sondern um Kontrolle. Du implantierst ein Verhalten, das nur bei einem Trigger anspringt. Der Trigger kann ein Satz sein, ein Format, ein seltener Token, sogar ein bestimmtes Code-Muster. Im Normalbetrieb wirkt das Modell sauber. Mit Trigger: plötzlich empfiehlt es „aus Versehen" die falsche URL, ignoriert Sicherheitsregeln oder spuckt eine gewünschte Phrase aus.

Merksatz: Bias ist Propaganda. Backdoor ist Fernbedienung.

Wo Poisoning wirklich passiert (und warum RAG der Turbo ist)

Viele denken bei Poisoning sofort an riesige Pretraining-Korpora. Ja, da kann es passieren – aber dort ist es auch am teuersten und am langsamsten.

  • Pretraining: Hoher Aufwand, großer Hebel. Wenn du in die öffentlichen Quellen kommst, die alle scrapen, hast du ein Long-Game.
  • Fine-Tuning / Instruction-Tuning: Geringerer Aufwand, direkte Wirkung. Wer deine „Spezialdaten" liefert, hat plötzlich Macht über deinen Ton und deine Regeln.
  • RAG / interne Wissensbasen: Der unterschätzte Klassiker. Das ist technisch gesehen kein Training, aber funktional oft schlimmer: Wenn deine Retrieval-Quelle vergiftet ist, zitierst du die Lüge mit Autorität. Und zwar sofort, ohne dass ein Re-Training nötig ist.
  • Feedback-Loops (User-Feedback, Logs, Self-Training): Wenn du ungefiltert zurückfütterst, baust du dir eine selbstverstärkende Verzerrungsmaschine.

Abwehr, die nicht nur nach PowerPoint klingt

Du brauchst keine Magie, du brauchst Provenance + Tests + Prozess:

  1. Daten-Provenance erzwingen: Woher kommt jedes Dokument? Wer hat es wann geliefert? Ohne Herkunft ist alles „untrusted input".
  2. Snapshots statt Live-Scrapes: Trainiere/indiziere aus versionierten Ständen. Dann kannst du diffen, rollbacken, und du bekommst Incident-Forensik überhaupt erst möglich.
  3. Canary-Samples & Trigger-Tests: Lege eigene „Kontrollpunkte" ins Evaluation-Set: Prompts, die Backdoors aufdecken sollen (Format-Trigger, seltene Tokens, spezielle Strings).
  4. Red-Team die Daten, nicht nur das Modell: Angriffe finden heute upstream statt. Also teste: „Wenn ich deine Quellen manipulieren dürfte – wie würde ich's tun?"

Wenn du eine Stunde Zeit hast: fang bei RAG an. Das ist der Ort, an dem Poisoning am billigsten ist – und an dem du am schnellsten Gegenmaßnahmen durchziehen kannst.

Wie Poisoning in der Realität aussieht (und warum es so billig ist)

Das Missverständnis ist: „Poisoning klingt nach Geheimdienst." In Wirklichkeit ist es oft eher: Content-SEO mit böser Absicht.

Ein typisches Muster:

  1. Ein Angreifer baut (oder übernimmt) ein paar Domains, die plausibel aussehen: Blog, „Knowledge Base", Stackoverflow-Klon, GitHub-Gists, ein paar Medium-Posts.
  2. Dann wird nicht einmal hart gelogen. Es wird gezielt gelogen: eine falsche API-Usage, eine „Best Practice", die eine Backdoor offen lässt, ein „Fakt", der später als Autorität zitiert werden kann.
  3. Diese Inhalte werden so geschrieben, dass sie von Scraper-Pipelines gerne mitgenommen werden (sauberer Text, klare Überschriften, wiederkehrende Phrasen, keine PDFs, keine Paywalls).
  4. Sobald deine Pipeline sie einmal „kennt" (Training, Fine-Tuning, RAG, interne Wissensbasis), ist der Angreifer in deinem Output.

Das Gift wirkt nicht unbedingt als kompletter Unsinn. Es wirkt als leichter Bias: Das Modell wird häufiger eine bestimmte falsche Erklärung liefern, eine bestimmte Library „verdächtig" finden, oder dir immer wieder denselben riskanten Workaround empfehlen. Und weil es in Sprache passiert, wirkt es vertrauenswürdig.

Noch fieser: Poisoning ist nicht nur „falsches Wissen", sondern kann Handlungswissen treffen. Wenn dein Modell Code vorschlägt, sind die Daten plötzlich Teil deiner Supply Chain.

  • Ein vergiftetes Snippet kann dazu führen, dass dein Agent „aus Versehen" Telemetrie an den falschen Endpoint schickt.
  • Ein vergifteter „How-to"-Artikel kann dazu führen, dass du Sicherheitschecks entfernst, weil es „Performance" bringt.
  • Ein vergifteter RAG-Eintrag kann dazu führen, dass dein Support-Bot Kunden zur falschen Download-URL schickt.

Das ist der Punkt, an dem Data Poisoning nicht mehr nach Forschungspapier klingt, sondern nach Incident-Postmortem.

Minimal Viable Defense: Trust-Tiers statt Bauchgefühl

Wenn du heute nur eine Sache änderst, dann diese: Behandle Daten wie Dependencies.

Praktisch heißt das:

  • Tier 0 (trusted): Eigene Dokumentation, signierte Releases, kuratierte Quellen. Darauf darf dein Modell „hart" bauen.
  • Tier 1 (allowed, aber vorsichtig): Große, stabile Quellen mit klarer Governance (z.B. offizielle Docs, bekannte Standards). Einbauen, aber mit Snapshots.
  • Tier 2 (untrusted): Das offene Web. Darf in RAG rein – aber nur mit Quarantäne, Zitierpflicht („Quelle: …") und schnellen Rollbacks.

Und dann machst du das, was in Security immer funktioniert: du testest. Nicht nur „ist das Modell gut", sondern: „Reagiert es auf Trigger? Kippen Antworten bei bestimmten Phrasen? Tauchen immer wieder dieselben merkwürdigen URLs auf?"

Poisoning ist kein Bug, den du einmal fixst. Es ist ein Angriffsvektor, den du dauerhaft managen musst.

Referenzen

  1. OWASP Top 10 for LLMs (2024): LLM06: Sensitive Information Disclosure und LLM01: Prompt Injection zeigen die Relevanz von Data Poisoning für moderne KI-Systeme. https://owasp.org/www-project-top-10-for-large-language-model-applications/
  2. MITRE ATLAS (2024): T0001: LLM Training Data Poisoning – Taxonomie und reale Angriffsvektoren für Foundation Models. https://atlas.mitre.org/techniques/T0001
  3. Wikipedia: Data Poisoning Attack (2025): Aktueller Überblick über Angriffstypen, historische Entwicklung und Abwehrmaßnahmen. https://en.wikipedia.org/wiki/Data_poisoning_attack
  4. Geiping et al. (2021): "Data Poisoning: Attacks and Defenses Tutorial" – Umfassende Einführung in das Feld. https://arxiv.org/abs/2110.03191
  5. Shafahi et al. (2018): "Poison Frogs! Targeted Clean-Label Poisoning Attacks" – Zeigt, dass Poisoning auch ohne Label-Manipulation funktioniert. https://arxiv.org/abs/1804.00792
  6. Steinhardt et al. (2017): "Certified Defenses for Data Poisoning" – Formale Sicherheitsgarantien gegen Poisoning. https://arxiv.org/abs/1706.03691
  7. Biggio et al. (2012): "Poisoning Attacks against Support Vector Machines" – Historisches Gründungspapier des Feldes. https://arxiv.org/abs/1206.6388