AI Data Poisoning 2026 zählt zu den grundlegenden Integritätsrisiken moderner KI. Ein Angreifer muss das Modell nicht unbedingt direkt verändern. Es kann genügen, Daten zu beeinflussen, aus denen das Modell lernt oder die eine Anwendung bei einer Antwort als Wissensgrundlage heranzieht. Das OWASP-Projekt beschreibt Daten- und Modellvergiftung als relevantes Risiko in Training, Fine-Tuning und Embedding-Pipelines. Anders als bei einer offensichtlichen Malware-Infektion kann das Ergebnis zunächst plausibel wirken und erst bei bestimmten Fragen gefährlich werden. Dieser Artikel erklärt die Unterschiede zwischen Datenvergiftung und Prompt Injection, typische Angriffsflächen, sichere Datensatzherkunft und einen praxisnahen Test- und Abwehrprozess für KI-Systeme im Unternehmen.
Autor: Salman Dolatpanah Gortlar · GORTNET · 5. November 2026
Praxisziel: Untrusted Daten erkennen, Datenherkunft nachweisen und KI-Aktionen unabhängig absichern.
AI Data Poisoning 2026: Was genau wird manipuliert?
Bei Datenvergiftung verändert ein Angreifer Informationen, die eine KI-Pipeline als Trainings- oder Wissensmaterial verwendet. Das können gelabelte Beispiele, Dokumente, FAQ-Seiten, Embeddings oder externe Datensätze sein. Die Manipulation kann dazu führen, dass ein Modell falsche Zusammenhänge lernt, bestimmte Inhalte bevorzugt oder auf gezielte Eingaben unerwünscht reagiert. Nicht jede falsche Information ist ein Angriff; die Sicherheitsbewertung hängt von Herkunft, Absicht und Auswirkungen ab.
Die wichtigste Schutzaufgabe ist Integrität. Unternehmen müssen wissen, woher Daten stammen, wer sie ändern darf und durch welche Prozesse sie in eine KI-Anwendung gelangen. Ein Zugriff auf das Modell allein genügt nicht, wenn die zugehörige Datenpipeline unkontrolliert Dokumente von fremden Quellen übernimmt. Die technische Grenze zwischen „vertrauenswürdig“ und „unbekannt“ muss für alle Datenstufen nachvollziehbar sein.
Unterschied zwischen Training Poisoning und RAG-Manipulation
Beim eigentlichen Training oder Fine-Tuning können vergiftete Beispiele die Modellparameter beeinflussen. Der Effekt bleibt unter Umständen bestehen, nachdem die ursprünglichen Dateien entfernt wurden. Bei Retrieval-Augmented Generation dagegen kann eine manipulierte Quelle den gerade abgerufenen Kontext beeinflussen, ohne die Modellgewichte zu verändern. Beide Risiken erfordern verschiedene Wiederherstellungsmaßnahmen.
Ein kompromittierter RAG-Eintrag lässt sich häufig durch Bereinigung des Dokumentenbestands und einen kontrollierten Reindex korrigieren. Wurden tatsächlich Modellgewichte durch unsichere Trainingsdaten verändert, kann ein neues Training aus geprüften Daten oder eine andere Modellversion notwendig sein. Die Trennung hilft, die Kosten und den Incidentprozess richtig einzuordnen. Ein Reindex heilt nicht automatisch ein vergiftetes Fine-Tuning-Modell.
Prompt Injection ist verwandt, aber nicht identisch
Prompt Injection versucht, das Verhalten eines KI-Assistenten durch Anweisungen in nicht vertrauenswürdigen Eingaben zu verändern. Das kann etwa über eine Webseite oder ein Dokument geschehen, das ein Agent als Datenquelle liest. Bei Data Poisoning liegt der Schwerpunkt auf der langfristigen Manipulation von Lern-, Index- oder Wissensbeständen. In der Praxis können beide Techniken zusammenwirken, wenn eine schädliche Anweisung in ein dauerhaft genutztes Wissensdokument eingeschleust wird.
Für die Abwehr reicht es nicht, die Formulierung eines Systemprompts zu verbessern. Ein Modell sollte niemals selbst die Autorität haben, seine Zugriffsrechte zu erweitern. Zusätzlich brauchen Sie Datenherkunft, Freigabeschritte und unabhängige Prüfungen, bevor externe Inhalte in produktive Systeme aufgenommen werden. Starke Rechteprüfungen wirken auch dann, wenn ein Modell manipulierte Informationen falsch interpretiert.
Wo ein Angreifer in der Datenpipeline ansetzen kann
Mögliche Eintrittspunkte sind externe Webdaten, gemeinsam bearbeitete Dokumente, offene Uploadformulare, automatisierte Datenimporte und Datensätze aus Drittanbietermärkten. Ebenso relevant sind kompromittierte Entwicklerkonten oder unzureichend geschützte Daten-Speicherorte. Manche Risiken entstehen versehentlich durch fehlerhafte Labeling-Prozesse und sind dann keine absichtliche Vergiftung, aber für die Zuverlässigkeit ähnlich problematisch.
Inventarisieren Sie für jeden Import Quelle, verantwortlichen Eigentümer, Berechtigungen und technischen Validierungsschritt. Besonders gefährlich ist eine Pipeline, die unbekannte Dateien automatisch in einen zentralen Suchindex übernimmt und diesen sofort für administrative Agenten verwendet. Eine Eingangsprüfung muss fehlende Autorisierung, unerwartete Dateiformate und relevante inhaltliche Anomalien erkennen, bevor die Daten produktive Antworten beeinflussen.
Backdoors und gezielte Auslöser verstehen
Bei einer Backdoor versucht ein Angreifer, unter besonderen Eingabebedingungen ein abweichendes Modellverhalten hervorzurufen. Normale Testfragen können weiterhin korrekte Ergebnisse liefern, sodass die Manipulation lange unbemerkt bleibt. Forschungen zeigen unterschiedliche Formen solcher Angriffe. Daraus folgt nicht, dass jedes öffentlich angebotene Sprachmodell bereits eine Backdoor besitzt.
Für Unternehmen ist die Lehre, dass normale Benchmark-Ergebnisse keine vollständige Integritätsgarantie darstellen. Testen Sie ungewöhnliche Schlüsselwörter, seltene Eingabekombinationen und fachlich kritische Sonderfälle. Eine Qualitätsprüfung sollte sowohl typische Fehlleistungen als auch potenziell gezielte Abweichungen untersuchen. Dokumentieren Sie die Grenzen der Prüfung, anstatt pauschal vollständige Angriffsfreiheit zu versprechen.
Dataset-Provenance und nachvollziehbare Versionen
OWASP empfiehlt, Datenherkunft und Transformationen über den gesamten Lebenszyklus zu dokumentieren. Ein Datensatz sollte eine eindeutige Version, bekannte Herkunft, Hashwerte und verantwortliche Freigaben besitzen. Auch die Verarbeitungsschritte – Bereinigung, Labeling, Aggregation und Embedding – müssen nachvollziehbar bleiben. Ein Modell ohne dokumentierte Trainingsdatenherkunft ist schwerer zu bewerten und zu reproduzieren.
Verwenden Sie geeignete Versionsverwaltung für Datenartefakte und trennen Sie geprüfte Releases von experimentellen Entwürfen. Schützen Sie schreibende Konten und überprüfen Sie Veränderungen mit Auditlogs. Eine Signatur beweist dabei nur die Herkunft beziehungsweise Unverändertheit eines Artefakts unter bestimmten Annahmen, nicht seine fachliche Wahrheit. Eine kompromittierte vertrauenswürdige Quelle kann weiterhin falsche Informationen signieren.
Vektor-Datenbanken sicher betreiben
RAG-Systeme speichern semantische Repräsentationen und Metadaten oft in Vektor-Datenbanken. Ein Dokument kann dabei in mehrere Abschnitte zerlegt werden. Ohne geeignete Rechte kann eine Suche Inhalte zurückgeben, die ein Benutzer nie lesen dürfte. Zusätzlich lassen sich Manipulationen nur schwer erkennen, wenn der Originaltext und seine Indexversion nicht zugeordnet werden können.
Verknüpfen Sie jeden Eintrag mit Quelle, Version, Besitzer und Berechtigung. Prüfen Sie Rechte beim Abruf und nicht nur beim Import. Ein Reindex nach Datenkorrekturen sollte kontrolliert und protokolliert erfolgen. Für sicherheitskritische Antworten können Quellenzitate und eine nachgelagerte Verifikation gegen autoritative Systeme erforderlich sein. Semantische Ähnlichkeit ist kein Wahrheitsnachweis.
Auswirkungen auf Unternehmen und Geschäftsprozesse
Manipulierte KI-Informationen können zu falschen IT-Anweisungen, fehlerhaften Geschäftsentscheidungen oder unnötigen Supportmaßnahmen führen. In einem Helpdesk-Assistenten könnte beispielsweise eine unzuverlässige Anleitung auftauchen, die Nutzer zur Änderung von Sicherheitseinstellungen verleitet. Die tatsächliche Auswirkung hängt davon ab, ob Menschen die Empfehlung prüfen und ob der Assistent selbst Werkzeuge ausführen darf.
Priorisieren Sie daher Anwendungen nach möglichem Schaden. Ein Textentwurf ohne direkte Aktion hat andere Anforderungen als ein Agent mit Zugriff auf Firewallregeln oder Produktionsdatenbanken. Bei hochprivilegierten Prozessen müssen Aktionsrechte unabhängig vom Modell begrenzt und Freigaben erzwungen werden. Ein Datenqualitätsfehler darf nicht automatisch in eine technische Veränderung mit weitreichenden Folgen münden.
Tests zur Erkennung manipulierter Daten
Führen Sie vor jeder Freigabe statistische und fachliche Kontrollen durch. Ungewöhnliche Verteilungen, plötzliche Änderungen bei Labels, doppelte Beispiele oder extreme Ausreißer können Hinweise liefern. Diese Indikatoren sind nicht eindeutig; manche legitimen Änderungen sehen statistisch auffällig aus. Daher müssen Tests mit Herkunftsdaten und dem erwarteten fachlichen Verhalten verbunden werden.
Ein sinnvolles Evaluationsset enthält unveränderliche Referenzfragen, kritische Negativbeispiele und bewusst unbekannte Themen. Vergleichen Sie Modelle und RAG-Indizes vor und nach einem Datenupdate. Wenn die Genauigkeit oder das Verhalten bei speziellen Fragen plötzlich abweicht, sollte die Freigabe gestoppt werden. Automatische Scores benötigen regelmäßig eine Stichprobe durch fachkundige Mitarbeitende.
Incident Response bei Verdacht auf Datenvergiftung
Trennen Sie zuerst, ob ein externer Dokumentenbestand, eine Datenpipeline oder ein bereits trainiertes Modell betroffen ist. Schränken Sie betroffene Importrechte ein und sichern Sie die relevanten Datenversionen für die Untersuchung. Prüfen Sie, welche Antworten oder automatischen Aktionen seit dem möglichen Einbringungszeitpunkt erzeugt wurden. Bei besonders gefährlichen Anwendungen kann eine temporäre Deaktivierung automatischer Aktionen sinnvoll sein.
Die Bereinigung hängt von der Ebene ab: Dokument entfernen und Index neu erstellen, kompromittierte Zugangsdaten sperren oder ein Modell aus geprüfter Quelle neu bereitstellen. Halten Sie Untersuchung und Wiederherstellung getrennt nachvollziehbar fest. Informieren Sie die betroffenen Fachbereiche über möglicherweise unzuverlässige Ergebnisse und kontrollieren Sie sicherheitskritische Entscheidungen aus dem relevanten Zeitraum.
30-Tage-Plan für KI-Datenintegrität
Woche eins: Datenquellen, Besitzer, Importprozesse und Modellversionen erfassen. Woche zwei: Herkunftskennzeichnung, Versionskontrolle und Schreibberechtigungen verbessern. Woche drei: Eval-Suite mit fachlichen Referenzfragen und Anomalietests durchführen. Woche vier: Einen kontrollierten Testvorfall simulieren, dabei problematische Dokumente aus einem Testindex entfernen und die Wiederherstellung überprüfen.
Erfolgreich ist der Prozess, wenn ein Team erklären kann, welche Daten eine Antwort beeinflusst haben, wie Änderungen freigegeben werden und wie ein bekannter schlechter Datenstand zurückgesetzt wird. Die Fähigkeit zur Korrektur ist für eine sichere KI-Anwendung ebenso wichtig wie die Qualität eines neuen Modells.
FAQ zu Data Poisoning
Ist Data Poisoning dasselbe wie Prompt Injection?
Nein. Data Poisoning manipuliert Lern- oder Wissensdaten; Prompt Injection versucht direkt, die Anweisungsgrenzen eines Systems zu übergehen. Die Angriffe können kombiniert werden.
Kann ein RAG-System trotz eines sicheren Basismodells gefährdet sein?
Ja. Ein manipulierter Dokumentenindex kann Antworten und Handlungsempfehlungen beeinflussen.
Hilft eine Signatur gegen Datenvergiftung?
Signaturen können Herkunft und Integrität belegen, garantieren aber nicht, dass der Inhalt korrekt ist.
Wie lässt sich ein vergifteter Index korrigieren?
Durch Sicherung und Bereinigung der Quelle sowie kontrolliertes erneutes Indexieren und Validieren.
Fazit: Der Schutz beginnt vor dem Modell
AI Data Poisoning 2026 zeigt, warum verlässliche Datenquellen, getrennte Rechte, Provenance und kontinuierliche Evaluation im KI-Betrieb entscheidend sind. Auch ein technisch leistungsfähiges Modell kann auf einer manipulierten Wissensbasis falsche Entscheidungen unterstützen.
Weiterlesen bei GORTNET
Für einen strukturierten KI-Sicherheitscheck Kontakt aufnehmen.
Fachquellen
Stand 5. November 2026. Angriffsbeispiele dienen dem defensiven Verständnis.