Was ist Data Poisoning und wie schützen Unternehmen ihre KI-Trainingsdaten?
Kurz gesagt
Data Poisoning bezeichnet die gezielte Manipulation von Trainings-, Fine-Tuning- oder Embedding-Daten, um Verhalten, Verzerrungen oder versteckte Fehlfunktionen in einem KI-Modell zu verankern. Der AI Act nennt dieses Risiko in Artikel 15 für Hochrisiko-Systeme ausdrücklich. Schutz braucht Versionierung, dokumentierte Herkunft, minimierte Schreibrechte, Integritätsprüfungen und eine geprüfte Modell- und Datenlieferkette — auch bei extern bezogenen Datensätzen und Modellen.
Wo Poisoning ansetzen kann
NIST und OWASP unterscheiden Poisoning ausdrücklich von klassischen Laufzeitangriffen wie Prompt Injection: Hier werden nicht einzelne Anfragen manipuliert, sondern die Datengrundlage des Modells selbst. Betroffen sein können:
- Trainingsdaten des Basismodells
- Fine-Tuning-Datensätze, mit denen ein Modell auf eigene Zwecke angepasst wird
- Embeddings, also die Vektorrepräsentationen für Ähnlichkeitssuche in RAG-Systemen
- Wissensbasen, aus denen ein RAG-System zur Laufzeit Dokumente abruft
Die gemeinsame AI-Data-Security-Guidance unter Führung des NSA AISC betont deshalb die Schutzbedürftigkeit von Daten über Entwicklung, Test und Betrieb hinweg — nicht nur während des eigentlichen Trainings.
RAG-Poisoning als praxisnahes Beispiel
Ein besonders alltagsnaher Fall betrifft Unternehmen, die einen RAG-Chatbot mit eigenen Dokumenten betreiben: Ein Dokument mit schädlichen Instruktionen gelangt in die Wissensbasis. Beim Retrieval interpretiert das Modell diesen Text möglicherweise als Handlungsanweisung statt als reine Information. Wirksame Gegenmaßnahmen sind eine Ingestion ausschließlich aus kontrollierten Quellen, begrenzte Schreibrechte, dokumentierte Dokument-Provenance, Berechtigungsprüfung vor dem Retrieval und keine Tool-Aktion allein aufgrund von abgerufenem Text ohne separate Prüfung.
Was Artikel 15 AI Act konkret verlangt
Artikel 15 des AI Act verlangt bei Hochrisiko-KI-Systemen angemessene Genauigkeit, Robustheit und Cybersecurity und nennt Data- und Model-Poisoning, adversariale Eingaben sowie Vertraulichkeitsangriffe ausdrücklich als zu adressierende Risiken. Die Formulierung ist dabei risikobasiert und gilt „where appropriate“ — die konkrete Umsetzungstiefe hängt vom jeweiligen Hochrisiko-Anwendungsbereich ab und ist gesondert zu prüfen. Für Anbieter von General-Purpose-AI-Modellen mit systemischem Risiko verlangt Artikel 55 zusätzlich adversariales Testing, Risikominderung und ein angemessenes Cybersecurity-Niveau, allerdings nur für die davon tatsächlich betroffenen Anbieter.
Schutzmaßnahmen in der Praxis
Für Unternehmen, die eigene Modelle fine-tunen, RAG-Systeme betreiben oder externe Datensätze einsetzen, sind folgende Maßnahmen zentral:
- Datensätze versionieren und Änderungen nachvollziehbar dokumentieren
- Herkunft (Provenance) jeder Datenquelle festhalten
- Schreibrechte auf Trainings-, Fine-Tuning- und Wissensdaten konsequent minimieren
- Integritätsprüfungen einsetzen, bevor Daten in Training oder Ingestion einfließen
- Training und Fine-Tuning möglichst reproduzierbar gestalten
- Externe Datensätze und Modelle in die Supply-Chain-Prüfung einbeziehen, statt sie ungeprüft zu übernehmen