AI Poisoning: Vergiftung von Daten und KI-Modellen

Welche Formen von Poisoning gibt es?

Poisoning setzt dort an, wo ein Modell lernt oder Wissen bezieht. Je nach Ziel des Angreifers lassen sich mehrere Varianten unterscheiden:

• Verfügbarkeitsangriffe: Großflächig verfälschte Daten, etwa vertauschte Labels (Label Flipping), verschlechtern die Gesamtqualität des Modells. Das fällt meist in der Evaluation auf, ist aber teuer zu beheben.
• Gezielte Angriffe: Das Modell funktioniert weitgehend normal, trifft aber bei ausgewählten Eingaben – etwa einem bestimmten Lieferanten oder einer bestimmten Malware-Familie – systematisch falsche Entscheidungen.
• Backdoors (Trojaner): Der Angreifer platziert ein Auslösemuster (Trigger) in wenigen Trainingsbeispielen. Taucht der Trigger später in einer Eingabe auf, reagiert das Modell wie gewünscht; ohne Trigger verhält es sich unauffällig. Bei sogenannten Clean-Label-Angriffen sind die vergifteten Beispiele sogar korrekt beschriftet und damit bei einer Sichtprüfung kaum zu erkennen.
• Vergiftete Wissensquellen (RAG Poisoning): Bei Retrieval-Augmented Generation liest ein Sprachmodell zur Laufzeit Dokumente aus Wikis, SharePoint, Ticketsystemen oder dem Web. Wer dort Inhalte ablegen kann, beeinflusst die Antworten – ohne das Modell selbst anzufassen.
• Modellvergiftung in der Lieferkette: Vortrainierte Modelle aus öffentlichen Repositories können manipulierte Gewichte oder, bei unsicheren Serialisierungsformaten wie Python-Pickle, sogar ausführbaren Schadcode enthalten.

Besonders tückisch ist, dass für einen wirksamen Backdoor-Angriff oft nur ein kleiner Anteil manipulierter Beispiele nötig ist. Webbasierte Trainingsdatensätze, die aus vielen fremden Quellen zusammengestellt werden, sind deshalb ein naheliegendes Ziel.

Warum Poisoning für Unternehmen relevant ist

Mittelständische Unternehmen trainieren selten große Modelle von Grund auf. Sie nutzen aber zunehmend Feinabstimmung (Fine-Tuning) mit eigenen Daten, übernehmen Open-Source-Modelle oder binden interne Dokumentenbestände per RAG an einen KI-Assistenten an. Daraus ergeben sich konkrete Einfallstore:

• Kundenfeedback, Support-Tickets oder Formulareingaben fließen ungeprüft in Trainingsdaten ein.
• Ein interner Chatbot greift auf Wiki-Seiten zu, die viele Mitarbeitende oder externe Partner bearbeiten dürfen.
• Entwickler laden Modelle aus öffentlichen Hubs ohne Herkunfts- oder Integritätsprüfung.
• Ein Dienstleister liefert annotierte Daten, deren Qualität niemand stichprobenartig kontrolliert.

Die Folgen reichen von schleichend schlechteren Vorhersagen über manipulierte Empfehlungen bis zur Kompromittierung von Entwicklerrechnern durch Schadcode im Modellfile. Poisoning ist schwer nachzuweisen, weil das Modell im Normalbetrieb unauffällig bleibt.

Schutzmaßnahmen

1. Datenherkunft dokumentieren: Legen Sie für jeden Trainings- und Wissensbestand fest, woher die Daten stammen, wer sie verändern darf und wann sie zuletzt geprüft wurden (Data Provenance).
2. Schreibrechte begrenzen: Quellen, die in Training oder RAG einfließen, brauchen ein Berechtigungskonzept wie produktiver Code. Änderungen sollten nachvollziehbar protokolliert werden.
3. Daten validieren: Prüfen Sie neue Daten auf Ausreißer, Duplikate, auffällige Label-Verteilungen und verdächtige Muster, bevor sie ins Training gehen. Stichproben bei zugelieferten Annotationen gehören dazu.
4. Modelle aus sicheren Quellen beziehen: Verwenden Sie vertrauenswürdige Anbieter, prüfen Sie Prüfsummen und Signaturen und bevorzugen Sie sichere Formate wie safetensors statt Pickle. Eine KI-Stückliste (AI-BOM) hilft, den Überblick über Modelle und Datensätze zu behalten.
5. Versionierung und Rückrollbarkeit: Versionieren Sie Datensätze und Modelle, damit Sie bei Verdacht auf einen sauberen Stand zurückkehren können.
6. Verhaltenstests: Testen Sie Modelle nach jedem Training gegen feste Referenzfälle und suchen Sie gezielt nach Auffälligkeiten bei seltenen Eingaben. Eine Backdoor lässt sich damit nicht garantiert finden, aber die Wahrscheinlichkeit steigt.
7. RAG-Antworten absichern: Zeigen Sie Quellen zu jeder Antwort an, trennen Sie vertrauenswürdige und offene Wissensbestände und überwachen Sie Änderungen an häufig abgerufenen Dokumenten.

Einordnung in Standards und Regulierung

Die OWASP Top 10 for LLM Applications (Ausgabe 2025) führen „Data and Model Poisoning“ als eigenes Risiko, die Wissensbasis MITRE ATLAS beschreibt entsprechende Angriffstechniken. Der EU AI Act verlangt in Art. 10 für Hochrisiko-KI eine dokumentierte Daten-Governance und in Art. 15 ausdrücklich Maßnahmen gegen Data Poisoning und Model Poisoning. Wer ein KI-Managementsystem nach ISO/IEC 42001 aufbaut, adressiert Datenqualität und Datenherkunft ebenfalls als Steuerungsthema.

Fazit

AI Poisoning ist im Kern ein Integritätsproblem der Lieferkette von Daten und Modellen. Wer Datenquellen, Schreibrechte und Modellherkunft so konsequent kontrolliert wie Quellcode, schließt die wichtigsten Einfallstore. SecTepe unterstützt bei der Bewertung von KI-Datenflüssen im Rahmen Ihres Informationssicherheits-Managements.

Häufige Fragen

Worin unterscheiden sich Poisoning und Prompt Injection?

Poisoning manipuliert, was ein Modell lernt oder als Wissen abruft. Prompt Injection manipuliert eine einzelne Anfrage zur Laufzeit. Bei RAG verschwimmt die Grenze: Ein vergiftetes Dokument kann versteckte Anweisungen enthalten und so eine indirekte Prompt Injection auslösen.

Sind Cloud-KI-Dienste wie große Sprachmodelle betroffen?

Das Grundmodell liegt in der Verantwortung des Anbieters. Ihre eigenen Anteile – Fine-Tuning-Daten, angebundene Dokumente und Plugins – müssen Sie selbst absichern.