Bei KI denke ich manchmal an einen sehr motivierten Praktikanten mit Superkräften. Schnell, fleißig, freundlich — aber auch erstaunlich abhängig davon, was man ihm auf den Schreibtisch legt.
Liegt dort ein sauberer Projektplan, bekommt man gute Antworten. Liegt dort ein manipuliertes Dokument, ein veralteter Prozess oder ein „kleiner“ falscher Datensatz, dann wird aus der Superkraft schnell ein sehr selbstbewusster Unsinnsgenerator.
Darum geht es bei Poisoned Data: vergiftete Daten, die KI-Systeme leise beeinflussen. Ganz unauffällig über Dokumente, Wissensdatenbanken, Tickets, E-Mails, Webseiten oder Trainingsdaten.
CSO Security Leadership warnt davor, dass Enterprise-AI-Systeme durch manipulierte, schlechte oder unkontrollierte Daten korrumpiert werden können — und dass viele Unternehmen gar nicht genau wissen, wie groß ihre eigene Angriffsfläche ist.
Was bedeutet „Poisoned Data“?
Stell dir vor, deine KI ist ein Kollege, der alles liest, was du ihm gibst. Handbücher, Richtlinien, Support-Tickets, Angebotsvorlagen, Wiki-Seiten, Chatverläufe, SharePoint-Dokumente. Daraus baut er sich sein Bild der Welt.
Jetzt legt jemand absichtlich oder versehentlich falsche Informationen hinein.
Zum Beispiel:
-
Ein manipuliertes Dokument behauptet, dass Rechnungen ab sofort an eine neue Bankverbindung gehen sollen.
-
Ein alter Prozess beschreibt eine veraltete Freigaberegel als noch gültig.
-
Ein internes Wiki enthält fehlerhafte Sicherheitsanweisungen.
-
Eine externe Webseite versteckt Anweisungen, die eine KI beim Auslesen befolgen soll.
-
Ein Support-Ticket enthält Formulierungen, die später von einer KI als „vertrauenswürdiges Wissen“ wiederverwendet werden.
Das klingt erstmal nach dem Thema „Datenqualität“. Bei Enterprise-AI wird daraus ein Sicherheitsproblem. Moderne KI-Systeme lesen nicht nur passiv mit. Sie helfen bei Entscheidungen, schreiben Mails, priorisieren Vorfälle, durchsuchen interne Daten, erstellen Reports oder steuern sogar Aktionen über Tools und Agenten.
Oder anders gesagt: Früher war ein falsches Dokument einfach nervig. Heute kann es der KI zuflüstern: „Mach mal Quatsch.“ Und die KI sagt: „Gerne, ich formuliere das noch professionell.“
Warum ist das jetzt relevant?
Viele Unternehmen bauen KI aktuell direkt in ihre Arbeitsprozesse ein. Microsoft 365 Copilot, Chatbots im Support, KI-Suche im Intranet, automatisierte Auswertungen, Agenten für IT, HR, Finance oder Security. Häufig werden diese Systeme mit internen Daten verbunden, damit sie „kontextreich“ antworten können.
Hier entsteht die neue Angriffsfläche.
Relevant ist das bei sogenannten RAG-Systemen. RAG steht für „Retrieval Augmented Generation“. Einfach gesagt: Die KI denkt sich Antworten nicht nur aus ihrem allgemeinen Modellwissen aus, sondern sucht vorher in angebundenen Unternehmensdaten nach passenden Informationen. Das ist super praktisch. Aber wenn die angebundenen Daten vergiftet sind, serviert die KI den Giftcocktail mit Firmenlogo.
OWASP beschreibt Data und Model Poisoning als Risiko entlang verschiedener Phasen des LLM-Lebenszyklus, unter anderem beim Training, Fine-Tuning und bei Embeddings — also dort, wo Inhalte in durchsuchbare KI-Wissensräume übersetzt werden.
Ein Beispiel aus dem Büroalltag
Nehmen wir an, ein Unternehmen nutzt eine KI, die interne Richtlinien durchsucht. Mitarbeitende fragen:
„Darf ich Kundendaten in Tool X hochladen?“
Die KI findet eine Richtlinie und antwortet:
„Ja, das ist erlaubt.“
Problem: Die Richtlinie wurde nie offiziell freigegeben. Oder sie wurde manipuliert. Oder sie stammt aus einem alten Projektordner namens „Final_final_NEU_wirklichfinal_alt“. Der natürliche Lebensraum deutscher Unternehmensdokumente.
Für den Mitarbeitenden klingt die Antwort aber verbindlich. Schließlich kam sie von der Unternehmens-KI. Und schon werden sensible Daten in ein Tool geladen, in dem sie nichts verloren haben.
Das Risiko ist nicht nur, dass KI falsch antwortet. Das Risiko ist, dass KI falsch, überzeugend und im Unternehmenskontext glaubwürdig antwortet.
Poisoned Data ist nicht immer ein Angriff
Wichtig: Vergiftete Daten müssen nicht immer von einem Angreifer stammen. Es gibt drei typische Quellen.
1. echte Angriffe.
Jemand platziert absichtlich manipulierte Informationen in Systemen, die von KI gelesen werden. Das kann über kompromittierte Dokumente, Webseiten, Tickets, Kommentare oder Datenquellen passieren.
2. schlechte Datenhygiene.
Alte Dokumente, doppelte Richtlinien, widersprüchliche Prozesse, unklare Zuständigkeiten. Der Klassiker: Drei PDFs sagen drei verschiedene Dinge und alle heißen „aktuell“.
3. unkontrollierte KI-Nutzung.
Wenn Teams eigene KI-Tools, eigene Datenquellen oder eigene Automationen bauen, entsteht schnell Schatten-KI. Dann weiß niemand mehr genau, welche KI auf welche Daten zugreift.
Warum IT-Entscheider das Thema ernst nehmen sollten
Poisoned Data ist gefährlich, weil es an einer unbequemen Stelle sitzt: zwischen IT, Security, Fachbereich und Datenmanagement.
Es reicht nicht, nur das KI-Modell abzusichern. Wenn die Datenbasis schlecht ist, hilft auch das beste Modell nur begrenzt. Ein sehr intelligentes System, das auf falschen Informationen basiert, bleibt ein sehr intelligentes System mit falschen Informationen.
Für Unternehmen bedeutet das: KI-Sicherheit ist nicht nur eine Frage von Firewalls, Berechtigungen und schönen Policy-Dokumenten. Es geht auch darum, die Datenlandschaft zu kennen.
-
Welche Quellen nutzt die KI?
-
Wer darf diese Quellen ändern?
-
Welche Inhalte gelten als offiziell?
-
Wie werden alte oder falsche Informationen entfernt?
-
Wie erkennt man manipulierte Inhalte?
-
Welche Aktionen darf eine KI aufgrund ihrer Antworten auslösen?
Das sind keine nerdigen Detailfragen. Das sind Governance-Fragen. Also genau die Sorte Fragen, die niemand sexy findet — bis sie plötzlich sehr teuer werden.
Konkrete Risiken: Was kann passieren?
1. Falsche Entscheidungen
Eine KI empfiehlt eine falsche Lieferantenbewertung, weil manipulierte oder veraltete Risikodaten in der Wissensbasis liegen. Das Ergebnis: Der falsche Dienstleister wird freigegeben.
2. Datenabfluss
Ein vergiftetes Dokument kann eine KI indirekt dazu bringen, sensible Informationen in einer Antwort preiszugeben oder sie in ein falsches Zielsystem zu übertragen. Das hängt besonders mit Prompt Injection zusammen, bei der Anweisungen in externen Inhalten versteckt werden.
3. Manipulierte Prozesse
Eine KI im IT-Service liest eine gefälschte Anleitung und empfiehlt bei Passwort-Resets einen unsicheren Ablauf. Plötzlich wird aus „Self-Service“ ein „Self-Sabotage-Service“.
4. Compliance-Probleme
Wenn eine KI auf falsche Richtlinien zugreift, können Datenschutz-, Sicherheits- oder Branchenvorgaben verletzt werden. Nicht, weil jemand böse war. Sondern weil das System überzeugt den falschen Weg vorgeschlagen hat.
5. Vertrauensverlust
Wenn Mitarbeitende merken, dass die KI wiederholt Unsinn erzählt, sinkt die Akzeptanz. Dann heißt es schnell: „Die KI kann man eh nicht benutzen.“ Und das wäre schade, denn richtig eingesetzt kann Enterprise-AI enormen Mehrwert bringen.
Was Unternehmen jetzt tun sollten
Die gute Nachricht: Man muss nicht panisch den KI-Stecker ziehen. Man muss nur aufhören, KI wie ein magisches Orakel zu behandeln. Sie ist ein System. Und Systeme brauchen Regeln, Verantwortung und Pflege.
1. Datenquellen inventarisieren
Klingt trocken, ist aber der Anfang von allem. Unternehmen sollten wissen, welche Datenquellen ihre KI nutzt: SharePoint, Confluence, Ticketsysteme, CRM, E-Mail, Dateiablagen, Webseiten, Datenbanken, Wissensartikel.
Ohne Inventar keine Kontrolle.
2. Offizielle Quellen klar markieren
Nicht jede Datei ist eine Wahrheit. Unternehmen brauchen definierte „Golden Sources“. Also Quellen, die als offiziell und aktuell gelten.
Eine KI sollte lieber auf wenige geprüfte Quellen zugreifen als auf 40 Ordner voller historischer PowerPoint-Folklore.
3. Berechtigungen sauber halten
Wenn jeder alles ändern darf, kann auch jeder versehentlich oder absichtlich die KI-Basis verändern. Deshalb gehören Rechte, Rollen und Freigaben auf den Prüfstand.
Bei KI gilt: Leserechte sind wichtig. Schreibrechte sind kritischer. Wer die Wissensbasis ändern kann, kann indirekt die Antworten beeinflussen.
4. Datenqualität als Security-Thema behandeln
Datenqualität war lange ein Thema für Fachbereiche und Reporting. Bei KI wird sie zur Sicherheitsfrage. Alte Dokumente, doppelte Richtlinien und unklare Versionen sind nicht nur unordentlich. Sie sind Angriffsfläche.
5. KI-Antworten nicht blind automatisieren
Je mehr eine KI auslösen darf, desto wichtiger werden Sicherheitsgrenzen. Eine KI, die nur Text vorschlägt, ist ein anderes Risiko als eine KI, die Tickets schließt, Benutzerrechte ändert oder Zahlungen vorbereitet.
Besonders bei Agenten gilt: Vertrauen ist gut, Sandbox ist besser.
6. Monitoring und Tests einführen
KI-Systeme sollten regelmäßig getestet werden. Nicht nur auf „Antwortet sie nett?“, sondern auf: Nutzt sie falsche Quellen? Reagiert sie auf manipulierte Inhalte? Gibt sie sensible Informationen preis? Folgt sie versteckten Anweisungen?
Das ist kein einmaliges Projekt, sondern laufende Pflege. Wie Zähneputzen.
KI braucht Governance
Enterprise-AI ist mächtig. Aber wenn KI-Systeme mit internen Daten verbunden werden, entsteht ein neues Sicherheitsmodell. Nicht mehr nur: „Wer darf auf welche Daten zugreifen?“ Sondern auch: „Welche Daten beeinflussen welche KI-Antworten und welche Entscheidungen entstehen daraus?“
Das ist der eigentliche Kern von Poisoned Data.
Die Gefahr sitzt in einem alten PDF, einem falsch gepflegten Wiki, einem manipulierten Ticket oder einer Datei, die niemand mehr auf dem Schirm hat.
Die KI ist nur so gut wie das Futter
Poisoned Data ist eine leise Sicherheitslücke. Keine Sirene, kein roter Alarm, kein dramatischer Hacker-Soundtrack. Eher ein Flüstern in der Datenbasis.
Aber genau deshalb ist das Thema so wichtig. Unternehmen sollten jetzt ihre KI-Datenquellen kennen, Verantwortlichkeiten klären, Berechtigungen prüfen und klare Governance schaffen.
Oder einfach gesagt: Wenn deine KI gute Entscheidungen treffen soll, gib ihr gutes Futter. Und stell sicher, dass niemand heimlich Chilipulver in den Napf kippt.
