Was ist Data Poisoning? Wie Angriffe auf Trainingsdaten und RAG funktionieren

Was ist Data Poisoning?

Data Poisoning ist ein Angriff, bei dem jemand absichtlich fehlerhafte, irreführende oder präparierte Datensätze in die Daten einschleust, aus denen ein KI System lernt oder die es liest, damit sich das Modell im Sinne des Angreifers verhält. Der Modellcode bleibt unberührt. Verändert wird das Wissen dahinter.

Stellen Sie sich einen Koch vor, in dessen Rezeptbuch heimlich Mengenangaben geändert wurden. Er arbeitet zwar sorgfältig und hält sich an jede Anweisung. Trotzdem schmeckt das Gericht falsch, denn der Fehler liegt in der Quelle und nicht beim Koch.

KI Modelle funktionieren ähnlich. Konkret erkennen sie Muster in den Daten, die sie sehen. Gelangt ein manipulierter Datensatz hinein, übernimmt das Modell ihn somit und wiederholt ihn mit voller Überzeugung.

Die Frage „Was ist Data Poisoning?“ beantworten wir in diesem Beitrag für einen einzelnen Begriff. Zunächst klären wir die Funktionsweise, danach die Arten und die Abgrenzung zu ähnlichen Begriffen. Anschließend folgen Schutzmaßnahmen und eine praktische Checkliste für Ihr Unternehmen.

Warum sind Daten eine Angriffsfläche für KI Systeme?

Bei klassischer Software bestimmt nämlich der Code das Verhalten. Sicherheitsteams konzentrieren sich daher auf Code, Server und Netzwerke. Beim maschinellen Lernen stammt ein großer Teil des Verhaltens aus den Daten. Wer die Daten verändern kann, beeinflusst also das System, ohne eine Zeile Code zu schreiben.

Daraus entsteht ein neues Risikofeld. Modelle lernen oft aus breiten und unübersichtlichen Quellen: öffentliche Webseiten, offene Datensätze, Nutzerbewertungen und interne Dokumente. Daher ist jede dieser Quellen ein Zugang, den Sie nicht vollständig kontrollieren.

Zudem ist die Datenpipeline lang. Erfassung, Bereinigung, Beschriftung, Training und Bereitstellung bieten jeweils eine Gelegenheit zum Eingriff. In der Praxis ist der schwächste Punkt der Kette der, den ein Angreifer wählt.

Sicherheitsstandards nehmen das Thema deshalb ernst. OWASP führt in seiner Liste für Anwendungen mit großen Sprachmodellen Data and Model Poisoning als eigenes Risiko auf. Das Ziel ist allerdings nicht immer, das Modell zu zerstören. Manchmal geht es darum, ein verstecktes Verhalten einzupflanzen.

Wie funktioniert Data Poisoning?

Konzeptionell besteht der Ablauf also aus drei Schritten. Im ersten Schritt verschafft sich der Angreifer Zugang zu einer Datenquelle, die das Modell oder das System liest. Manchmal ist der Zugang direkt. Häufig läuft er jedoch indirekt über eine offene Quelle, zu der jeder beitragen darf.

Im zweiten Schritt mischen sich dann die manipulierten Datensätze in die Pipeline. Sie sehen meist unauffällig aus, deshalb bleiben sie bei einer schnellen Sichtprüfung unentdeckt. Wirksames Poisoning ist also leise, und das System läuft einfach weiter.

Im dritten Schritt lernt das Modell aus diesen Datensätzen, oder das System zieht sie in seine Antworten ein. Dadurch ändert sich das Verhalten. Manchmal zeigt sich das als allgemeiner Qualitätsverlust. Dennoch tritt es oft nur bei einem Thema oder unter einer bestimmten Bedingung auf.

1. Erstens findet der Angreifer einen Weg, zu einer Datenquelle beizutragen oder sie zu verändern.
2. Zweitens passieren die manipulierten Datensätze Erfassung und Bereinigung unbemerkt.
3. Dann trainiert das Modell damit, oder das System ruft sie bei der Antwort ab.
4. Schließlich fällt der Effekt erst auf, wenn Nutzer seltsame Antworten sehen oder eine Auswertung ihn aufdeckt.

Dieser Beitrag liefert aus Sicherheitsgründen bewusst keine Angriffsanleitung. Unser Ziel ist daher, dass Sie den Ablauf verstehen und Ihre Verteidigung darauf ausrichten.

Welche Arten von Data Poisoning gibt es?

Sie können Data Poisoning in drei Hauptgruppen einteilen, je nachdem, welche Phase der Angreifer ins Visier nimmt. Diese Einteilung zeigt Ihnen also, wo Sie Schutzmaßnahmen platzieren sollten.

• Poisoning der Trainingsdaten: Hier gelangen manipulierte Datensätze in die Daten für Vortraining oder Training.
• Feinabstimmung als Ziel: Manipulierte Datensätze landen in dem Datensatz, mit dem Sie ein vorhandenes Modell anpassen.
• Wissensbasis als Ziel: Zudem kann ein irreführendes Dokument in den Speicher gelangen, den das Modell beim Antworten abfragt (RAG).

Zunächst wirken die ersten beiden Arten im Inneren des Modells. Das Gift setzt sich in den Gewichten fest, und die Rückgängigmachung bedeutet meist ein erneutes Training. Die dritte Art berührt das Modell dagegen nicht. Sie beschädigt stattdessen nur die Quelle, die das Modell liest. Die Bereinigung ist daher einfacher, auch wenn die Erkennung nicht immer leicht fällt.

Außerdem können Sie Angriffe nach ihrem Ziel unterscheiden. Manche wollen die Gesamtgenauigkeit senken. Andere zielen dagegen auf eine falsche Antwort bei einem Thema oder auf ein verstecktes Verhalten. Außerdem behandelt das US Institut NIST Poisoning in seiner Taxonomie für Adversarial Machine Learning als eigene Angriffsklasse.

Was bedeuten Backdoor und Trigger beim Data Poisoning?

Eine Backdoor (Hintertür) bedeutet, dass sich das Modell unter normalen Bedingungen unauffällig verhält und nur bei einem bestimmten Signal anders reagiert. Dieses Signal heißt Trigger. Zum Beispiel kann ein Trigger ein Wort, ein Muster oder ein Datenmerkmal sein. Anders gesagt wirkt er wie eine versteckte Regel.

Gefährlich ist dabei, dass das Modell in Standardtests gut aussieht. Enthalten die Testdaten keinen Trigger, antwortet es dann wie erwartet. Ein hoher Genauigkeitswert allein ist daher ein schwacher Beweis für Sicherheit.

Ein Vergleich hilft. Stellen Sie sich vor, ein Gebäude besteht die Sicherheitsprüfung, die Türen sind verschlossen und die Kameras laufen. Beim Bau hat allerdings jemand eine versteckte Seitentür gelassen, und nur wer davon weiß, kommt hinein. Kurz gesagt ist eine Backdoor dieser versteckte Weg im Inneren eines Modells.

Um auf der sicheren Seite zu bleiben, erklären wir nicht, wie Trigger entworfen werden. Wichtig ist daher, dass Sie das Risiko kennen und die Herkunft Ihrer Modelle hinterfragen. Das gilt vor allem für fertige Modelle, die Sie von außen herunterladen.

Was ist RAG Dokumenten Poisoning und warum ist es so wichtig?

RAG (Retrieval Augmented Generation) bedeutet, dass das Modell vor der Antwort einen Dokumentenspeicher durchsucht und das Gefundene in die Antwort einbaut. Die Grundlagen haben wir in unserem Beitrag zu RAG erklärt. Hier betrachten wir deshalb nur die Sicherheitsseite.

Beim Dokumenten Poisoning gelangt also ein irreführendes oder manipuliertes Dokument in diesen Speicher. Findet die Suche es, vertraut das Modell dem Inhalt und baut ihn in die Antwort ein. Das Modell selbst bleibt unverändert. Beschädigt ist stattdessen nur das Material, das es liest.

Diese Art ist wichtig, weil die Einstiegshürde niedrig ist. Trainingsdaten zu manipulieren erfordert nämlich oft großen Aufwand. Ein einzelnes Dokument in einen geteilten Ordner, eine offene Wiki Seite oder einen Upload Bereich zu legen, ist dagegen viel einfacher.

Zudem kann ein solches Dokument eine Prompt Injection enthalten, also Text, der für das Modell wie eine Anweisung aussieht. Das ist ein eigenes Risiko. Wir vergleichen es in der Tabelle unten und behandeln es in unserem Beitrag zu Prompt Injection.

Außerdem spielt die Art, wie Dokumente zerlegt und durchsucht werden, eine Rolle. Für die Grundlagen lesen Sie unsere Beiträge zu Chunking und zu Embeddings.

Wie entsteht Poisoning bei Feinabstimmung und Nutzerfeedback?

Bei der Feinabstimmung passen Sie ein fertiges Modell mit eigenen Daten an eine Aufgabe an. Die Grundlagen finden Sie in unserem Beitrag zu Fine Tuning und LoRA. Der Datensatz ist meist klein, deshalb wiegt jeder einzelne Eintrag stärker.

Das Risiko steigt allerdings, wenn ein Produkt aus Nutzerinhalten lernt. Denken Sie zum Beispiel an eine Chat Anwendung, in der Nutzer Daumen hoch vergeben oder Antworten korrigieren. Sammeln Sie dieses Feedback, um das Modell zu verbessern, kann jemand diesen Kanal gezielt lenken.

Das Problem liegt dann in der Annahme, Feedback sei vertrauenswürdig. Ohne einen Filter, der echte Nutzer von böswilligen trennt, wird jede Bewertung und jede Korrektur zu einer möglichen Datenquelle. Menschliche Prüfung ist daher in automatischen Lernschleifen eine wertvolle Absicherung.

Außerdem gibt es eine weitere Quelle: Daten, die andere Modelle erzeugt haben. Setzen Sie synthetische Daten ein, sollten Sie auch deren Qualität und Herkunft hinterfragen. Dieses Thema behandeln wir in unserem Beitrag zu synthetischen Daten.

Was ist Data Poisoning im Vergleich zu Prompt Injection und Model Collapse?

Diese drei Begriffe werden oft verwechselt, weil alle mit Datenproblemen zu tun haben, die KI beschädigen. Zeitpunkt, Absicht und Gegenmittel unterscheiden sich aber deutlich. Die Tabelle fasst den Unterschied zusammen.

Das Fazit ist einfach. Wer die Frage „Was ist Data Poisoning?“ stellt, bekommt diese Antwort: Es ist ein Problem dessen, was das Modell gelernt hat. Prompt Injection betrifft dagegen, wem das Modell gerade gehorcht. Model Collapse beschreibt schließlich, wie ein Modell sich selbst nachahmt. Den Kollaps erklären wir in einem eigenen Beitrag.

Beide Angriffe können sich zudem gegenseitig verstärken. Ein manipuliertes Dokument mit versteckter Anweisung erzeugt beide Effekte zugleich. Verlassen Sie sich deshalb nicht auf eine einzige Schutzschicht.

Wer ist durch Data Poisoning gefährdet?

Nicht jeder KI Nutzer trägt das gleiche Risiko. Es hängt also davon ab, woher die Daten stammen und wer sie berühren darf. Die folgenden Gruppen verdienen besondere Aufmerksamkeit.

• Teams mit Daten aus externen Quellen: Wer mit Web Crawls oder öffentlichen Datensätzen trainiert, kann die Quelle nicht vollständig prüfen.
• Produkte mit Feinabstimmung auf Nutzerinhalten: Angebote, die Bewertungen, Feedback oder Chatverläufe ins Training zurückführen.
• Systeme mit offener Wissensbasis: RAG Anwendungen, die an Wikis, Foren oder geteilte Dokumentenspeicher angebunden sind.
• Anwender fertiger Modelle: Teams, die ungeprüfte Modelle direkt in den Betrieb übernehmen.

Ein kleines System dagegen, das nur freigegebene und versionierte Dokumente unter Ihrer Kontrolle nutzt, trägt ein geringeres Risiko. Null ist es trotzdem nicht. Denn auch interne Fehler und falsche Versionen können ähnliche Schäden verursachen.

Kurz gesagt: Fragen Sie sich, wer vor der Tür Ihrer Daten steht und ob Sie diese Tür wirklich kontrollieren. Ist die Antwort unklar, dann haben die folgenden Abschnitte zur Verteidigung für Sie Vorrang.

Was ist Data Poisoning in der Praxis, und wie sieht ein Fall aus?

Das Folgende ist ein Beispielszenario und kein echter Kunde oder Vorfall. Nehmen wir einen Shop mit einem Support Assistenten, der Rückgaberegeln aus einem geteilten Dokumentenordner liest.

In diesen Ordner kann jedoch jeder Dateien hochladen. Eines Tages erscheint dort ein Dokument, das die Rückgabebedingungen falsch beschreibt. Dann findet der Assistent es bei der Suche und nennt Kunden eine falsche Rückgabefrist. Das Modell ist gesund, aber die Antworten sind falsch.

In diesem Szenario muss es also keinen Angreifer geben. Zum Beispiel kann auch ein unachtsamer Mitarbeiter dasselbe Ergebnis auslösen. Nutzt jedoch jemand mit böser Absicht denselben Weg, wird die Wirkung gezielter und schwerer zu entdecken.

Folglich riskiert das Unternehmen Kundenvertrauen und möglicherweise rechtliche Folgen. Teams, die einen internen Wissensassistenten aufbauen, sollten deshalb die Inhaltspflege von Anfang an planen. Für ein solches Vorhaben sehen Sie sich unsere Lösung für KI Wissensassistenten an.

Woran erkennen Sie ein Poisoning?

Poisoning ist oft leise, doch einige Signale sollten Verdacht wecken. Allerdings ist kein einzelnes Anzeichen ein Beweis. Treten mehrere zusammen auf, dann lohnt sich eine Untersuchung.

• Das Modell gibt bei einem Thema beharrlich dieselbe falsche Antwort.
• Die Antwortqualität ändert sich spürbar direkt nach einem Datenupdate.
• Dieselbe Frage erhält je nach Formulierung sehr unterschiedlich sichere Antworten.
• Die Wissensbasis enthält neue Dokumente unklarer Herkunft, die auffällig oft abgerufen werden.
• Nutzerbeschwerden häufen sich bei einem Thema oder Produkt.

Um diese Signale zu erfassen, brauchen Sie Monitoring. Zum Beispiel können Sie protokollieren, welche Dokumente in wie vielen Antworten auftauchen. Dominiert ein Dokument plötzlich, dann gehen Sie der Ursache nach.

Außerdem helfen regelmäßige Testsätze, die Wirkung von Datenänderungen zu messen. So vergleichen Sie den Zustand vor und nach einem Update. Zum Vorgehen bei der Bewertung lesen Sie unseren Beitrag zu LLM Evals.

Warum ist die Datenherkunft die Grundlage der Verteidigung?

Datenherkunft (Data Provenance) ist die Spur, die zeigt, woher ein Datensatz kam, wer ihn wann hinzugefügt hat und welche Umwandlungen er durchlief. Denn Daten, deren Quelle Sie nicht kennen, können Sie nicht vertrauen. Somit ist dieses einfache Prinzip die erste Schutzschicht.

Auch OWASP nennt die Nachverfolgung der Datenherkunft, die Nutzung vertrauenswürdiger Quellen und die Versionierung von Datensätzen als zentrale Maßnahmen. Die Logik ist klar: Tritt ein Problem auf, müssen Sie herausfinden können, welche Datensätze betroffen sind.

1. Erstens: Halten Sie für jede Datenquelle Eigentümer und Vertrauensstufe fest.
2. Zweitens: Versionieren Sie Ihre Datensätze und notieren Sie, welche Version jedes Training nutzte.
3. Drittens: Bewahren Sie externe Daten getrennt auf und prüfen Sie sie vor der Nutzung.
4. Schließlich: Speichern Sie einen Fingerabdruck (Hash) der Datensätze, damit spätere Änderungen sichtbar werden.

Diese Aufzeichnungen helfen zudem nicht nur der Sicherheit. Verhält sich ein Modell eines Tages seltsam, können Sie damit zurückverfolgen. Dann grenzen Sie die fehlerhafte Version schnell ein und kehren zur vorherigen zurück.

Wie richten Sie Zugriffskontrolle und Freigabeprozess ein?

Die günstigste Hürde gegen Poisoning ist, einzuschränken, wer in Ihre Daten schreiben darf. Außerdem gilt das Prinzip der minimalen Rechte auch hier. Je weniger Personen Dokumente zur Wissensbasis hinzufügen dürfen, desto kleiner ist die Angriffsfläche.

In der Praxis wirken zwei Schichten. Erstens hilft ein rollenbasiertes Schreibrecht, sodass nur verantwortliche Personen Inhalte ergänzen. Zweitens hilft ein Freigabeschritt, den jede Ergänzung durchlaufen muss.

• Zunächst: Beschränken Sie das Schreibrecht auf die Wissensbasis auf eine kleine, bekannte Gruppe.
• Danach: Verlangen Sie, dass eine zweite Person neue Dokumente vor der Veröffentlichung freigibt.
• Halten Sie Nutzer Uploads in einem getrennten Bereich und übernehmen Sie sie nie direkt in die Haupt Wissensbasis.
• Außerdem: Protokollieren Sie jede Änderung samt Verfasser.

Diese Maßnahmen wirken vor allem bei RAG Systemen. Das Gift gelangt dort ins Dokument und nicht ins Modell, deshalb greift klassische Zugriffskontrolle sofort. Zu Schichten, die die Modellausgabe begrenzen, lesen Sie unseren Beitrag zu KI Guardrails.

Wie helfen Anomalieerkennung, Evaluation und Red Teaming gegen Poisoning?

Vorbeugung ist nie perfekt, deshalb brauchen Sie auch eine Erkennungsschicht. Anomalieerkennung markiert ungewöhnliche Datensätze. Konkret prüfen Sie Einträge, die sich stark vom Rest unterscheiden, sich häufen oder eine unklare Quelle haben.

Bei der Evaluation kommen also zwei Ideen zusammen. Erstens führen Sie nach jeder Datenänderung einen festen Testsatz aus. Zweitens sorgen Sie dafür, dass dieser Satz sensible Themen abdeckt und nicht nur die Gesamtgenauigkeit.

Red Teaming ist ein autorisierter, auf Verteidigung ausgerichteter Testansatz. In der Praxis prüft ein Team das System wie ein Angreifer und findet Schwachstellen vor echten Angreifern. Wir erklären es in unserem Beitrag zu AI Red Teaming.

Die drei Methoden ergänzen sich. Anomalieerkennung wirkt am Eingang, Evaluation am Ausgang, und Red Teaming betrachtet das Gesamtsystem. Keine genügt allein, aber zusammen verkleinern sie die Lücken aber spürbar.

Warum lassen sich vergiftete Daten so schwer erkennen?

Das Unangenehmste an der Frage, was Data Poisoning ist, besteht darin, dass ein Angriff gewöhnlichen Daten oft ähnelt. Ein manipulierter Datensatz kann zum Beispiel wie ein Tippfehler oder eine veraltete Angabe aussehen. Selbst ein menschlicher Prüfer erkennt daher den Unterschied kaum.

Die zweite Schwierigkeit ist der Umfang. Ein großer Datensatz kann Millionen Einträge enthalten, und niemand liest sie alle. Stichproben und automatische Prüfungen helfen zwar, sind aber nicht perfekt.

Die dritte Schwierigkeit ist die Streuung der Wirkung. Das Modell arbeitet insgesamt gut und versagt dann nur bei einem engen Thema. Deckt Ihr Testsatz dieses Thema nicht ab, bleibt das Problem unsichtbar.

Schließlich stammen schlechte Daten nicht immer von Angreifern. Zum Beispiel richten alte Dokumente, widersprüchliche Versionen und falsche Beschriftungen ähnlichen Schaden an. Gute Datenhygiene schützt Sie daher gleichzeitig vor absichtlichen und versehentlichen Problemen.

Bergen fertige Modelle und Datensätze ein Risiko in der Lieferkette?

Ja, das tun sie. Ist es riskant, eine ungeprüfte Bibliothek in ein Softwareprojekt aufzunehmen, gilt dasselbe für ein ungeprüftes Modell oder einen ungeprüften Datensatz. Wir nennen das daher ein Lieferkettenrisiko der KI.

Plattformen, die Modelldateien und Datensätze teilen, sind sehr wertvoll. Doch wo jeder beitragen darf, liegt es an Ihnen, zu prüfen, ob ein Paket wirklich enthält, was es verspricht. Die Hinweise zur Überprüfung in der offiziellen Dokumentation des Anbieters zu lesen, ist eine gute Gewohnheit.

• Erstens: Beziehen Sie Modelle und Datensätze nur aus bekannten Quellen mit klarer Verantwortung.
• Zweitens: Vergleichen Sie den Fingerabdruck einer heruntergeladenen Datei mit dem, den der Herausgeber nennt.
• Drittens: Bewerten Sie ein neues Modell in einem getrennten Testbereich, bevor es in den Betrieb geht.
• Dokumentieren Sie außerdem Lizenz und Nutzungsbedingungen.

So erhalten Sie also eine solide Dokumentation für Sicherheit und Compliance. Wenn Sie Ihre Sicherheitsschichten Schritt für Schritt planen möchten, sehen Sie sich unsere KI Integration an.

Wie trennen Sie Data Poisoning von gewöhnlichen Qualitätsproblemen?

Nicht jede schlechte Antwort ist ein Angriff. Meist liegt nämlich die Ursache in einer Halluzination, fehlenden Daten oder einem veralteten Dokument. Um Fehlalarme zu vermeiden, schließen Sie zunächst die einfachen Erklärungen aus.

1. Können Sie den Fehler reproduzieren? Ein konsistenter Fehler unterscheidet sich also von einer zufälligen Halluzination.
2. Begann der Fehler nach einem bestimmten Datenupdate?
3. Lässt sich die falsche Antwort auf ein Dokument oder einen Datensatz zurückführen?
4. Wissen Sie, wer das Dokument wann hinzugefügt hat?

Können Sie diese Fragen klar beantworten, erkennen Sie auch, ob der Vorfall versehentlich oder absichtlich war. Gelingt das nicht, dann liegt die eigentliche Lücke in Ihrem Monitoring. Beachten Sie außerdem, dass Halluzination ein eigenes Phänomen ist. Details finden Sie in unserem Beitrag zur KI Halluzination.

Wer sollte im Team für Datensicherheit zuständig sein?

Die technische Antwort auf die Frage „Was ist Data Poisoning?“ genügt nicht. Sie müssen daher auch wissen, wer für die Reaktion zuständig ist. In vielen Organisationen sind das Team für die Daten, das Team für das Modell und das Team für das Produkt verschiedene Personen. Bei Problemen hält dann jeder einen anderen für verantwortlich.

Drei Rollen beseitigen diese Unklarheit. Erstens verantwortet der Datenverantwortliche Inhalt und Aktualität jeder Quelle. Zweitens gibt der Modellverantwortliche frei, was ins Training oder in die Wissensbasis gelangt. Drittens steuert die Sicherheitsverantwortliche Zugriffsregeln, Monitoring und den Ablauf bei Vorfällen.

In kleinen Teams kann allerdings eine Person alle drei Rollen tragen. Entscheidend ist somit, dass die Rollen schriftlich festgehalten sind und eine unabhängige zweite Person Änderungen freigibt. So kann ein einzelner Fehler oder ein einzelner böswilliger Akteur die Pipeline nicht allein verderben.

Vernachlässigen Sie schließlich nicht die Schulung. Wissen Mitarbeiter, welche Dokumente sie wo hochladen dürfen, schließt das den häufigsten Zugang für Poisoning. Für Schulungen im Team sehen Sie sich unsere Seite zur KI Schulung für Unternehmen an.

Was tun Sie bei Verdacht auf Poisoning?

Bei Verdacht schlägt eine klare Reihenfolge die Panik. Die folgenden Schritte sind ein allgemeiner Ablauf für Vorfälle. Passen Sie ihn deshalb an Ihr eigenes System an.

1. Zunächst: Bestimmen Sie die verdächtige Datenquelle und das zugehörige Update.
2. Danach: Schalten Sie bei Bedarf den betroffenen Teil der Wissensbasis vorübergehend ab.
3. Dann: Kehren Sie zur letzten bekannten gesunden Datenversion zurück.
4. Außerdem: Untersuchen Sie die auffälligen Datensätze und finden Sie heraus, wie sie hineingelangten.
5. Schließlich: Passen Sie Zugriffs und Freigaberegeln so an, dass die Lücke schließt.
6. Ist ein neues Training nötig, starten Sie mit bereinigten Daten und lassen Sie Ihren Testsatz laufen.

Bei RAG Systemen geht das schneller, weil Sie nur das Dokument entfernen. Bei Poisoning von Training oder Feinabstimmung können die Modellgewichte betroffen sein, und ein neues Training kann nötig sein.

Ein wichtiger Hinweis: Berührt der Vorfall personenbezogene Daten oder Kundendaten, können rechtliche Pflichten entstehen. Dieser Beitrag ist keine Rechtsberatung. Wenden Sie sich daher in einem solchen Fall an eine Fachanwältin oder einen Fachanwalt.

Wo liegen die Grenzen, und welche Irrtümer sind verbreitet?

Einige Irrtümer sind weit verbreitet. Sie auszuräumen verringert also sowohl unnötige Angst als auch unnötige Sorglosigkeit.

• „Modelle großer Firmen lassen sich nicht vergiften.“ Kein Modell ist immun, das Risiko hängt von der Art der Datenquelle ab.
• „Hohe Genauigkeit heißt sicher.“ Ein Modell mit Backdoor kann in Standardtests glänzen.
• „Nur Trainingsdaten sind riskant.“ Wissensbasen und Feedbackschleifen sind ebenso wichtige Angriffsflächen.
• „Ein Werkzeug löst das Problem.“ Verteidigung besteht aus Schichten, und die Ursache liegt oft im Prozess.

Die NIST Taxonomie betont außerdem, dass aktuelle Abwehrmaßnahmen keine vollständigen Garantien bieten und offene Forschungsfragen bleiben. Ihr Ziel ist daher, das Risiko zu senken und Probleme zu bemerken, nicht ein Risiko von null zu erreichen.

Zudem entwickelt sich das Feld schnell. Wir empfehlen, den aktuellen Stand von Methoden und Werkzeugen in den offiziellen Dokumenten der Normungsstellen und Anbieter zu prüfen.

Was ist Data Poisoning für Ihr Unternehmen, und welche Checkliste hilft?

Die folgende Liste kann kleinen und mittleren Teams als Startpunkt dienen. Allerdings müssen Sie nicht alles an einem Tag erledigen. Setzen Sie die Prioritäten also nach Ihrem eigenen Risiko.

• Listen Sie schriftlich auf, welche Quellen Ihr Modell und Ihre Wissensbasis speisen.
• Prüfen Sie, wer in Ihre Daten schreiben darf, und entfernen Sie unnötige Rechte.
• Binden Sie jedes neue Dokument und jede Datenergänzung an eine Freigabe.
• Überprüfen Sie die Quelle jedes heruntergeladenen Modells und Datensatzes.
• Lassen Sie nach jedem Datenupdate einen festen Testsatz laufen.
• Verfolgen Sie, wie oft jedes Dokument in Antworten auftaucht.
• Richten Sie eine Sicherung ein, mit der Sie zu einer gesunden Datenversion zurückkehren.
• Planen Sie mindestens einmal im Jahr eine autorisierte Red Teaming Übung.

Die ersten drei Punkte sind nämlich am günstigsten und haben die größte Wirkung. Für die meisten Teams ist es daher sinnvoll, dort anzufangen.

Möchten Sie KI in Ihrer Organisation sicher aufsetzen, erreichen Sie uns über unsere Seite zur KI Beratung. Den größeren Rahmen zeigen unsere Leistungen für KI und Automatisierung.

Wo können Sie mehr über Data Poisoning lernen?

Die verlässlichsten Ausgangspunkte sind die offiziellen Veröffentlichungen von Normungsstellen und Sicherheitsgemeinschaften. Denn der Rahmen dieses Beitrags stützt sich auf sie.

• OWASP Top 10 for LLM Applications: Die Risikoliste für Anwendungen mit großen Sprachmodellen, in der Data and Model Poisoning einen eigenen Punkt bildet.
• NIST Taxonomie für Adversarial Machine Learning: Die offizielle Veröffentlichung, die Angriffsarten einschließlich Poisoning einordnet und die Begriffe festlegt.

Diese Quellen werden fortlaufend aktualisiert. Verlassen Sie sich daher nicht auf eine bestimmte Version oder Zahl, sondern öffnen Sie die Veröffentlichung und lesen Sie den aktuellen Stand. Die Angaben hier dienen der allgemeinen Information und ersetzen keine Sicherheits oder Rechtsberatung.

Zusammengefasst: Was ist Data Poisoning? Es ist ein leiser Angriff auf das, was ein KI System lernt oder liest. Sie bauen Ihre Verteidigung also mit Datenherkunft, Zugriffskontrolle, Monitoring und regelmäßigen Tests auf. Öffnen Sie Ihr System daher nicht für Daten, deren Quelle Sie nicht kennen.