Data Poisoning: Warum auch Ihre lokale Produktions-KI eine Datenlieferkette hat

Vergiftete Daten gelten als wachsende Gefahr für KI-Systeme. „Betrifft uns nicht, unsere KI läuft on-premise“ ist dabei ein verbreiteter Irrtum – denn die Angriffsfläche liegt nicht in der Cloud, sondern in der eigenen Datenkette.

Ein aktuelles Feature der MIT Technology Review (erschienen bei t3n) beschreibt einen bemerkenswerten Fall: KI-Suchmaschinen gaben auf die Frage nach Airline-Hotlines die Telefonnummern von Betrüger-Callcentern aus. Der Weg dorthin: präparierte Metadaten auf vertrauenswürdig wirkenden Webseiten. Kein Hack im klassischen Sinn – niemand ist in ein System eingedrungen. Die Angreifer haben lediglich die Daten manipuliert, aus denen die KI ihre Antworten baut.

Das Prinzip heißt Data Poisoning: Statt das Modell anzugreifen, vergiftet man seine Datenquellen.

„Wir trainieren doch gar nicht mit Internetdaten“

Der naheliegende Einwand aus der Produktion: Solche Angriffe treffen die großen Cloud-Modelle, die das halbe Internet als Trainingsmaterial nutzen. Eine lokale KI, die ausschließlich mit eigenen Betriebsdaten arbeitet, sei davon nicht betroffen.

Das stimmt nur zur Hälfte. Richtig ist: Wer ein lokales Sprachmodell mit RAG betreibt, trainiert nicht mit fremden Webdaten. Aber auch diese Architektur hat eine Datenlieferkette – vom Sensor an der Maschine bis zur fertigen Auswertung. Und jede Station dieser Kette ist ein möglicher Manipulationspunkt. Der Unterschied zur Cloud ist nicht, dass die Angriffsfläche verschwindet. Sie liegt nur woanders: im eigenen Haus.

Vier Angriffspunkte in einer typischen Industrie-4.0-Kette

Eine Datenkette, wie ich sie in Fertigungsbetrieben regelmäßig aufbaue, sieht so aus: Maschinensignale (OPC-UA, SPS) fließen in die MDE/BDE-Erfassung, von dort in eine Zeitreihen-Datenbank. Ein lokales Sprachmodell greift per RAG auf diese Daten und auf Dokumente zu – etwa aus SharePoint oder einem Wiki – und erzeugt daraus Auswertungen, Wartungstickets oder Alarme.

Vier Stellen verdienen dabei besondere Aufmerksamkeit:

An der Quelle. Wer Sensorwerte verfälschen oder Störgründe an der Maschine „umbiegen“ kann, füttert das gesamte System mit einer falschen Realität. Alles, was danach kommt, rechnet mit vergifteten Zahlen – und kein noch so gutes Modell korrigiert das.

Bei der Übertragung. Ungesicherte Schnittstellen zwischen Erfassung und Datenbank sind ein klassisches Einfallstor. Was unverschlüsselt und unauthentifiziert durchs Netz läuft, lässt sich unterwegs verändern.

Im Speicher. Der vielleicht unterschätzteste Punkt: Schreibrechte auf die Datenbank sind Schreibrechte auf die Wahrheit. Wenn zu viele Systeme oder Personen Daten ändern dürfen, ist die Integrität der historischen Daten nicht mehr garantiert – und damit auch keine Auswertung, die darauf aufbaut.

Im RAG-Kontext. Ein einziges manipuliertes Dokument im SharePoint reicht, und das Sprachmodell zitiert dessen Inhalt mit voller Überzeugung. RAG macht die Dokumentenablage faktisch zu einem Teil des KI-Systems – mit allen Konsequenzen für Zugriffsrechte und Versionierung.

Was dagegen hilft

Die gute Nachricht: Weil die Kette im eigenen Haus liegt, lässt sie sich auch im eigenen Haus absichern. Kein Hexenwerk, sondern solides Handwerk:

• Plausibilitätsprüfungen direkt in der Erfassung. Ein Zählerstand, der rückwärts läuft, oder eine Taktzeit von null Sekunden sollte gar nicht erst in der Datenbank landen.
• Authentifizierte, verschlüsselte Schnittstellen zwischen allen Stationen – auch im internen Netz.
• Ein sauberes Rechtekonzept: Schreibzugriff auf Produktionsdaten nur für die Systeme, die ihn wirklich brauchen. Menschen korrigieren über nachvollziehbare Prozesse, nicht per Direktzugriff.
• Versionierung der Dokumentenbasis, aus der das RAG-System schöpft. Wer wann welches Dokument geändert hat, muss rekonstruierbar sein.
• Monitoring auf Anomalien in den Datenströmen – auffällige Abweichungen früh erkennen, bevor sie in Auswertungen und Entscheidungen einfließen.

Entscheidend ist der Zeitpunkt: Diese Punkte gehören in das Konzept, nicht in die Nachbesserung. Eine Datenkette nachträglich abzudichten ist deutlich aufwendiger, als sie von Anfang an sauber aufzubauen.

Fazit

Eine KI ist so vertrauenswürdig wie ihre Datenkette. „On-premise“ ist ein guter Anfang – Datenhoheit, keine Cloud-Abhängigkeit, volle Kontrolle. Aber Kontrolle ist kein Zustand, sondern eine Aufgabe: Sie muss an jeder Station der Kette umgesetzt werden, vom Sensor bis zur Entscheidung.

Sie planen ein KI- oder MDE-Projekt und möchten die Datenkette von Anfang an sauber aufsetzen? Sprechen Sie mich an – ich baue solche Systeme seit über 15 Jahren in der Praxis, vom Shopfloor bis zur Auswertung.