Data Poisoning: Wie Sie das Risiko in Ihrem ISO-27001-ISMS bewerten und behandeln

Das Wichtigste in Kürze

• Data Poisoning steht als LLM04 ("Data and Model Poisoning") in den OWASP Top 10 for LLM Applications 2025 und ist eine der neun Bedrohungen, die ISO/IEC 27090:2026 in Abschnitt 6 beschreibt. Die direkte Modellvergiftung führt die Norm als eigene Bedrohung.
• Auch wer keine eigenen Modelle trainiert, ist betroffen: Ein Chatbot mit Retrieval-Augmented Generation (RAG), der aus Wiki, Laufwerken oder Tickets antwortet, übernimmt jede manipulierte Seite als Wissen. Im PoisonedRAG-Experiment (USENIX Security 2025) reichten fünf präparierte Texte je Zielfrage in einer Datenbank mit Millionen Texten für eine Erfolgsquote von 90 Prozent.
• Eine große Datenmenge verdünnt das Gift nicht. In einer Studie von Anthropic, dem UK AI Security Institute und dem Alan Turing Institute vom Oktober 2025 genügten 250 präparierte Dokumente, um Modellen mit 600 Millionen bis 13 Milliarden Parametern eine einfache Hintertür einzubauen.
• Im ISO-27001-Risikoprozess gehört Data Poisoning in die Risikobeurteilung nach Abschnitt 6.1.2. Behandelt wird es vor allem über A.5.9 (Inventar), A.5.19 bis A.5.21 (Lieferanten und IKT-Lieferkette), A.8.25 (sichere Entwicklung) und A.8.16 (Überwachung).
• Nach Art. 15 Abs. 5 der EU-KI-Verordnung müssen Anbieter von Hochrisiko-KI-Systemen gegebenenfalls Maßnahmen gegen Data Poisoning und Model Poisoning vorsehen. Diese Pflichten gelten ab dem 2. Dezember 2027 für Systeme nach Anhang III und ab dem 2. August 2028 für Systeme nach Anhang I.

‍

Data Poisoning klingt nach einem Problem für Unternehmen, die eigene KI-Modelle trainieren. Die meisten Unternehmen mit einem ISO-27001-ISMS tun das nicht: Sie nutzen ein Sprachmodell über eine API, verbinden es mit ihrem Wiki und lassen es Fragen von Kunden oder Mitarbeitenden beantworten. Genau dort entsteht das Risiko. Wer die Daten verändern kann, aus denen ein KI-System lernt oder liest, verändert seine Antworten.

Dieser Beitrag richtet sich an die Person, die das ISMS verantwortet und klären muss, wo Data Poisoning das eigene Unternehmen erreicht, wie das Risiko ins Risikoregister kommt und welche Maßnahmen tatsächlich tragen.

Was ist Data Poisoning?

Data Poisoning ist ein Angriff, bei dem jemand die Daten manipuliert, mit denen ein KI-Modell trainiert, feinjustiert oder versorgt wird, um sein Verhalten gezielt zu verändern. Das Modell lernt oder liest dann etwas Falsches und gibt es mit derselben Sicherheit weiter wie alles andere. Die OWASP-Liste fasst darunter ausdrücklich Daten aus dem Pre-Training, dem Fine-Tuning und die Embeddings, mit denen ein RAG-System arbeitet.

In unserem Überblick zur KI-Sicherheitsnorm ISO 27090 ist Data Poisoning eine von neun Bedrohungen. Hier geht es um diese eine, und zwar aus Sicht eines Unternehmens, das Modelle von Drittanbietern einsetzt.

Data Poisoning, Model Poisoning und Backdoor

Die drei Begriffe werden oft vermischt, beschreiben aber unterschiedliche Dinge. Beim Data Poisoning setzt der Angreifer bei den Daten an. Beim Model Poisoning, das ISO 27090 als direkte Modellvergiftung führt, manipuliert er das Modell selbst: seine Parameter oder eine vortrainierte Komponente, die Sie weiterverwenden. Eine Backdoor ist kein dritter Weg, sondern ein mögliches Ergebnis beider Angriffe. Das Modell verhält sich unauffällig, bis ein bestimmter Auslöser im Text auftaucht.

Drei Beispiele zeigen die Bandbreite:

• Verfälschte Trainingsdaten: Ein Filter für eingehende Nachrichten wird regelmäßig mit den Rückmeldungen der Nutzer nachtrainiert, die eine Nachricht als "kein Spam" markieren. Ein Angreifer markiert über Wochen mit mehreren Konten seine eigenen Phishing-Mails als legitim. Das Modell lernt, genau diese Art von Nachricht durchzulassen.
• Backdoor in einem öffentlichen Modell: Ein Team lädt ein frei verfügbares Modell aus einem öffentlichen Repository und feinjustiert es. Das Modell enthält eine Hintertür, die bei einer seltenen Zeichenfolge Sicherheitsprüfungen überspringt. Kein Standardtest findet sie, weil kein Testfall diese Zeichenfolge enthält.
• Vergiftete Wissensdatenbank: Jemand ändert in einem internen Wiki die Seite mit den Bankverbindungen für Rückzahlungen. Der Kundenchatbot, der aus diesem Wiki antwortet, nennt ab dem nächsten Indexlauf die falsche IBAN.

‍

Ein verbreiteter Irrtum: Data Poisoning setze Zugriff auf die Infrastruktur voraus. In den ersten beiden Beispielen braucht der Angreifer keinen Zugang zu Ihren Systemen: Er markiert Nachrichten über ein normales Nutzerkonto oder veröffentlicht ein Modell, das Ihr Team herunterlädt. Wie viel Gift nötig ist, hängt laut der Studie von Anthropic, UK AISI und Alan Turing Institute nicht von der Größe des Modells ab: Eine kleine, feste Zahl an Dokumenten genügte. Getestet wurde allerdings nur eine harmlose Hintertür, die Kauderwelsch erzeugt; ob das Ergebnis für größere Modelle und schädlichere Ziele gilt, lassen die Autoren offen.

Wo Data Poisoning Unternehmen trifft, die KI nur nutzen

Unternehmen, die keine Modelle trainieren, treffen vergiftete Daten an drei Stellen: in der Wissensdatenbank eines RAG-Systems, in eigenen Daten für das Fine-Tuning und in Modellen oder Datensätzen von Lieferanten. In allen drei Fällen liegt die Verantwortung für die Risikobehandlung in Ihrem ISMS, nicht beim Anbieter des Foundation Models.

Der Fehler, den viele Teams machen: "Wir trainieren keine Modelle, also ist Poisoning nicht unser Thema." Der Anbieter des Basismodells kümmert sich um seine eigenen Trainingsdaten. Ihr Confluence, Ihre Ticket-Historie und die Datensätze, die Ihr Team aus dem Internet lädt, kennt er nicht.

RAG-Wissensdatenbank aus Wiki, Laufwerken und Tickets

Ein RAG-System sucht zu jeder Frage passende Textstellen aus einer Wissensdatenbank und gibt sie dem Sprachmodell als Grundlage für die Antwort. Diese Wissensdatenbank wird meist automatisch befüllt: aus einem Confluence-Bereich, einem SharePoint, einem geteilten Laufwerk oder der Ticket-Historie. Jede Person, die dort schreiben darf, schreibt damit auch in das Wissen des Chatbots. In vielen Unternehmen sind das alle Mitarbeitenden, externe Gastkonten und bei Tickets sogar die Kunden selbst.

RAG Poisoning ist für Unternehmen, die KI nur nutzen, meist der naheliegendste Einstiegspunkt. Die Forscher hinter PoisonedRAG kamen bei ihren Experimenten mit fünf präparierten Texten je Zielfrage auf eine Erfolgsquote von 90 Prozent, obwohl die Datenbank Millionen Texte enthielt. Der Grund: Ein Text, der genau auf eine Frage zugeschnitten ist, wird für diese Frage bevorzugt abgerufen.

Fine-Tuning mit eigenen Daten

Wer ein Modell auf eigene Beispiele zuschneidet, etwa auf gelöste Support-Fälle oder auf frühere Angebote, macht diese Beispiele zu Trainingsdaten. Kommen sie ganz oder teilweise von außen, kann ein Angreifer sie gestalten. Anders als beim RAG ist der Schaden dann im Modell selbst gespeichert. Eine korrigierte Quelle repariert das Modell nicht; Sie müssen mit bereinigten Daten neu trainieren.

Modelle und Datensätze von Lieferanten

Die dritte Stelle ist die Lieferkette. Sie beziehen ein Foundation Model per API, ein Embedding-Modell für die Suche, ein frei verfügbares Modell oder einen Datensatz aus einem öffentlichen Repository. Die Trainingsdaten dieser Komponenten können Sie nicht einsehen. Wurde eine davon vergiftet, übernehmen Sie das Problem mit dem Download. Für Ihr ISMS ist das ein Lieferantenrisiko wie jedes andere und gehört in die Bewertung nach A.5.19 bis A.5.21.

Data Poisoning im ISO-27001-Risikoprozess

Data Poisoning gehört in die Risikobeurteilung nach ISO 27001 Abschnitt 6.1.2 wie jede andere Bedrohung: mit betroffenem Wert, Eintrittswahrscheinlichkeit, Auswirkung und Risikoeigner. Drei Fragen entscheiden über die Bewertung. Wer kann die Daten verändern, aus denen das System lernt oder liest? Können Sie belegen, woher Modell und Daten stammen? Und wie würden Sie bemerken, dass sich das Verhalten geändert hat?

Daraus ergibt sich eine Faustregel. Ein System, das aus einem Bereich mit fünf benannten Redakteuren antwortet und dessen Ausgaben ein Mensch prüft, hat ein geringes Risiko. Ein System, das aus offen beschreibbaren Quellen schöpft, direkt mit Kunden spricht und auf Modellen unbekannter Herkunft aufbaut, hat ein hohes.

Voraussetzung für beides ist ein vollständiges Inventar nach A.5.9. Dazu gehören nicht nur die KI-Systeme selbst, sondern auch die Datenquellen, aus denen sie gespeist werden, und die Modelle, auf denen sie aufbauen, jeweils mit Herkunft und Verantwortlichem. Ein Datensatz, der nirgends als Wert geführt wird, hat keinen Eigentümer, der über Schreibrechte entscheidet. Wie dieses Inventar in den Zertifizierungsprozess passt, beschreibt unser Leitfaden zur ISO 27001 Zertifizierung.

Welche Controls aus Anhang A greifen

Anhang A der ISO 27001:2022 nennt diesen Angriff nicht beim Namen. Die entscheidenden Stellen decken bestehende Controls ab, deren Geltungsbereich Sie auf KI-Systeme und ihre Daten ausweiten. Die folgende Tabelle ordnet typische Szenarien zu; sie ist eine Arbeitsinterpretation, kein Bestandteil der Norm.

Unser Überblick zu ISO 27090 verortet beide Formen der Vergiftung bei Abschnitt 6.1.2, A.5.21 und A.8.25; die Tabelle ergänzt Inventar, Zugangssteuerung und Überwachung. Weil Anhang A nach Abschnitt 6.1.3 nicht abschließend ist, können Sie ISO 27090 in Ihrer Erklärung zur Anwendbarkeit als Quelle für zusätzliche KI-Maßnahmen angeben. Wie alle 93 Maßnahmen aufgebaut sind und welche Nachweise ein Auditor erwartet, lesen Sie in unserem Überblick über die ISO 27001 Controls aus Anhang A.

Schutzmaßnahmen gegen Data Poisoning, die wirklich wirken

Die wirksamsten Maßnahmen gegen Data Poisoning setzen an der Datenquelle an, nicht beim Modell. Eine Vergiftung im Nachhinein zu erkennen, ist schwer: Ein Modell mit Hintertür beantwortet jede normale Testfrage korrekt, und eine manipulierte Wikiseite sieht aus wie jede andere. Wer erst bei den Ausgaben sucht, sucht nach einem Auslöser, den er nicht kennt.

Fünf Maßnahmen haben sich bewährt:

• Datenherkunft und Schreibrechte: Legen Sie fest, welche Quellen ein KI-System lesen darf, und begrenzen Sie die Schreibrechte auf genau diese Bereiche. Jede Änderung wird protokolliert, damit Sie im Ernstfall wissen, welche Version wann indexiert wurde.
• Lieferanten und Modelle bewerten: Fragen Sie Modellanbieter, woher ihre Trainingsdaten stammen, wie sie diese gegen Manipulation schützen und wie sie Modellwechsel ankündigen. Frei verfügbare Modelle beziehen Sie nur aus freigegebenen Quellen und gleichen die Prüfsummen ab.
• Validierung vor dem Fine-Tuning: Versionieren Sie jeden Trainingsdatensatz, prüfen Sie Stichproben und Ausreißer und vergleichen Sie das neue Modell vor der Freigabe mit dem alten anhand eines festen Testsatzes.
• Ausgaben überwachen: Stellen Sie dem System regelmäßig dieselben Referenzfragen und vergleichen Sie die Antworten. Ändert sich eine Antwort ohne bekannten Grund, ist das ein Vorfall, kein Rauschen.
• Red Teaming: Testen Sie das System gezielt, indem Sie in einer Testumgebung präparierte Dokumente in die Wissensdatenbank einspielen. ISO 27090 empfiehlt Red Teaming in Abschnitt 5.7; ein klassischer Penetrationstest prüft nur die Infrastruktur.

‍

Eine aktuelle Sammlung von Angriffsmustern und Gegenmaßnahmen pflegt das OWASP-Projekt in seiner Beschreibung von LLM04. Dort steht auch die Empfehlung, Herkunft und Verarbeitung von Daten nachvollziehbar zu dokumentieren, etwa mit einer ML-Stückliste (ML-BOM).

Beispiel: ein Support-Chatbot, der aus Confluence antwortet

Ein fiktives SaaS-Unternehmen mit 120 Mitarbeitenden, nach ISO 27001 zertifiziert, betreibt einen Support-Chatbot auf Basis eines gehosteten Sprachmodells. Der Chatbot antwortet aus dem Confluence-Wiki, das jede Nacht vollständig neu indexiert wird. Die Zahlen in diesem Beispiel dienen der Veranschaulichung: Das Wiki umfasst rund 2.400 Seiten, 85 Mitarbeitende haben Bearbeitungsrechte und zwölf externe Freelancer haben Gastkonten.

Bei der Risikobeurteilung bewertet das ISMS-Team das Risiko mit mittlerer Wahrscheinlichkeit, weil ein einziges kompromittiertes Konto unter 97 genügt. Die Auswirkung ist hoch: Nennt der Chatbot einem Kunden eine falsche Bankverbindung, entsteht ein direkter finanzieller Schaden und ein Datenschutzproblem kommt schnell hinzu.

Die Behandlung verändert bestehende Controls, statt neue zu erfinden. Der Chatbot liest nur noch den Bereich "Hilfecenter" mit sechs benannten Redakteuren (A.5.9, A.5.15). Änderungen in diesem Bereich gibt eine zweite Person frei, bevor sie in den Index gehen (A.8.25). Nach jedem Indexlauf beantwortet der Chatbot 40 Referenzfragen, deren Antworten automatisch mit der Vorwoche verglichen werden (A.8.16). Der Vertrag mit dem Modellanbieter regelt, dass Modellwechsel vorab angekündigt werden (A.5.20). Das Restrisiko sinkt von hoch auf mittel und wird so von der Geschäftsleitung akzeptiert. Null erreicht es nicht, weil auch einer der sechs Redakteure kompromittiert werden kann.

Was Regulierung und Normen zu Data Poisoning sagen

Drei Regelwerke behandeln Data Poisoning ausdrücklich, mit unterschiedlicher Verbindlichkeit: ISO 27090 als Leitfaden, die EU-KI-Verordnung als Gesetz für Hochrisiko-KI und der SOC-2-Entwurf von 2027 als künftiger Prüfungsmaßstab.

ISO/IEC 27090. Die am 14. Oktober 2026 veröffentlichte Norm nennt Data Poisoning und die direkte Modellvergiftung in Abschnitt 6 als getrennte Bedrohungen. Abschnitt 5.5 behandelt das Lieferkettenmanagement, Abschnitt 7 die Gegenmaßnahmen. ISO 27090 ist ein Leitfaden; eine Zertifizierung danach gibt es nicht. Die Empfehlungen fließen über Ihre Risikobehandlung in ein ISO-27001-ISMS oder ein KI-Managementsystem nach ISO 42001 ein.

EU-KI-Verordnung. Art. 15 Abs. 5 verlangt, dass Hochrisiko-KI-Systeme gegen Versuche unbefugter Dritter widerstandsfähig sind, ihre Verwendung, Ausgaben oder Leistung zu verändern. Zu den technischen Lösungen gehören gegebenenfalls Maßnahmen gegen Angriffe auf den Trainingsdatensatz (Data Poisoning) und auf vortrainierte Komponenten (Model Poisoning). Die Pflicht trifft den Anbieter; wer ein solches System nur betreibt, prüft sie über die Lieferantenbewertung mit. Welche Systeme als hochriskant gelten, erklärt unser Beitrag zu Hochrisiko-KI nach der EU-KI-Verordnung.

SOC 2. Der Entwurf der AICPA für die Trust Services Criteria 2027 nennt Data Poisoning unter den neuen Points of Focus zu KI. Kommentare sind bis zum 15. Januar 2027 möglich; wird der Entwurf freigegeben, gilt er für Prüfungsaufträge, die am oder nach dem 31. Dezember 2027 beginnen. Am Ende steht weiterhin ein SOC-2-Bericht. Was der Entwurf sonst ändert, beschreibt unser Beitrag zu den SOC 2 Trust Services Criteria 2027.

Als technische Referenz für Testfälle eignet sich zusätzlich die Taxonomie NIST AI 100-2 E2025 vom März 2025, die Poisoning-Angriffe als eigene Angriffsklasse beschreibt.

Wie Kertos KI-Risiken in Ihrem ISMS abbildet

Mit Kertos steht Data Poisoning im selben Risikoregister wie Ihre übrigen Informationssicherheitsrisiken, nicht in einer separaten Tabelle für KI. Sie inventarisieren Ihre KI-Systeme einmal, bewerten die zugehörigen Risiken und verknüpfen die Behandlung mit den Controls aus Anhang A, mit Richtlinien und mit Nachweisen. Die Erklärung zur Anwendbarkeit zeigt dann, welche Maßnahmen für welches KI-Risiko gelten.

Kertos bildet ISO 27001 und ISO 42001 auf einer Plattform ab. Für das KI-Managementsystem gibt es vorgemappte ISO-42001-Maßnahmen und eine KI-Risikobibliothek, die an der EU-KI-Verordnung und an ISO/IEC 23894 ausgerichtet ist. Die zertifizierten Experten von Kertos helfen Ihnen zu entscheiden, welche Ihrer KI-Systeme ein relevantes Poisoning-Risiko haben und wie Sie die Behandlung so dokumentieren, dass sie im Audit trägt.

Möchten Sie sehen, wie Ihr eigener RAG-Chatbot oder Ihre Fine-Tuning-Pipeline im ISMS aussieht? Buchen Sie eine Demo und bringen Sie Ihr Beispiel mit.

Häufig gestellte Fragen

Was ist Data Poisoning?

Data Poisoning ist ein Angriff, bei dem jemand die Daten manipuliert, mit denen ein KI-Modell trainiert, feinjustiert oder über eine Wissensdatenbank versorgt wird, um sein Verhalten gezielt zu verändern. Die OWASP Top 10 for LLM Applications 2025 führen das Risiko als LLM04 "Data and Model Poisoning". ISO/IEC 27090:2026 beschreibt Data Poisoning in Abschnitt 6 als eine von neun Bedrohungen für KI-Systeme.

Was ist der Unterschied zwischen Data Poisoning und Prompt Injection?

Data Poisoning manipuliert die Daten, aus denen ein Modell lernt oder sein Wissen bezieht, und wirkt damit auf alle späteren Antworten. Prompt Injection schmuggelt Anweisungen in eine einzelne Eingabe oder ein Dokument, das das Modell gerade verarbeitet, und kapert so diese eine Aufgabe. In einer RAG-Wissensdatenbank überschneiden sich beide: Eine präparierte Seite mit falschen Fakten ist Data Poisoning, eine Seite mit versteckten Anweisungen ist indirekte Prompt Injection.

Wie erkennt man Data Poisoning?

Im Nachhinein nur schwer, weil ein vergiftetes Modell auf normale Testfragen korrekt antwortet, bis ein unbekannter Auslöser auftaucht. Hinweise liefern Antworten auf feste Referenzfragen, die sich ohne Grund ändern, auffällige Änderungen in indexierten Quellen und Ausreißer in Trainingsdatensätzen. Wirksamer als die Suche nach dem Gift ist es, Herkunft und Schreibrechte der Daten zu kontrollieren und jede Version zu protokollieren.

Betrifft Data Poisoning auch Unternehmen, die KI nur nutzen?

Ja. Wer ein Sprachmodell mit einer Wissensdatenbank aus Wiki, Laufwerken oder Tickets verbindet, eigene Daten für das Fine-Tuning verwendet oder Modelle und Datensätze von Dritten bezieht, kann vergiftete Daten übernehmen. Der Anbieter des Foundation Models schützt nur seine eigenen Trainingsdaten. Für die übrigen Datenquellen liegt die Risikobehandlung im eigenen ISMS.

Welche ISO-27001-Controls helfen gegen Data Poisoning?

Anhang A der ISO 27001:2022 nennt Data Poisoning nicht ausdrücklich, mehrere bestehende Controls greifen aber. Die wichtigsten sind A.5.9 für das Inventar von Datenquellen und Modellen, A.5.15 für Schreibrechte, A.5.19 bis A.5.21 für Lieferanten und die IKT-Lieferkette, A.8.25 für den sicheren Entwicklungslebenszyklus und A.8.16 für die Überwachung. Bewertet wird das Risiko in der Risikobeurteilung nach Abschnitt 6.1.2.