Der Grundgedanke ist einfach: Ein maschinelles Lernverfahren ist immer nur so vertrauenswürdig wie die Daten, aus denen es lernt. Wer die Trainingsdaten in seinem Sinne verändert, verändert damit auch das Verhalten des resultierenden Modells. Im Unterschied zu vielen anderen Angriffen auf KI-Systeme, die den laufenden Betrieb attackieren, wirkt Data Poisoning bereits in der Entstehungsphase eines Modells – oder schleicht sich über kontinuierlich nachgeladene Daten ein. Der Schaden ist entsprechend nachhaltig: Er ist im Modell selbst verankert und nicht durch einen einfachen Neustart zu beheben.
Wichtig ist die Abgrenzung zu verwandten Themen. Prompt Injection zielt auf die Eingabe zur Laufzeit und bringt ein Modell dazu, Anweisungen zu befolgen, die es nicht befolgen sollte. Model Theft zielt auf den Diebstahl oder die Rekonstruktion eines Modells. Data Poisoning dagegen greift die Daten an – entweder die historischen Trainingsdaten, die Daten einer Feinabstimmung oder die Wissensquellen, die ein System zur Laufzeit heranzieht. Alle drei Themen gehören zur KI-Sicherheit, adressieren aber unterschiedliche Angriffsflächen und erfordern unterschiedliche Abwehrmaßnahmen.
Klassische IT-Sicherheit konzentriert sich auf Code, Netzwerke und Zugänge. Bei KI-Systemen kommt eine neue, oft unterschätzte Schicht hinzu: die Daten. Modelle entstehen nicht durch handgeschriebene Regeln, sondern durch das statistische Auswerten großer Datenmengen. Diese Datenmengen stammen häufig aus vielen Quellen – aus öffentlich verfügbaren Sammlungen, aus zugekauften Datensätzen, aus Nutzerinteraktionen oder aus internen Dokumenten. Jede dieser Quellen ist ein potenzieller Eintrittspunkt für manipulierte Inhalte. Und weil die Datenmengen groß sind, fällt eine kleine, geschickt platzierte Verfälschung nicht ohne Weiteres auf.
Hinzu kommt, dass Daten in modernen KI-Pipelines oft automatisiert verarbeitet werden: Sie werden gesammelt, bereinigt, transformiert und ins Training gegeben, ohne dass ein Mensch jeden einzelnen Datenpunkt sieht. Diese Automatisierung ist notwendig und sinnvoll, sie vergrößert aber die Bedeutung guter Kontrollen. Wo kein Mensch mehr hinschaut, müssen technische und organisatorische Schutzmechanismen die Datenqualität sichern.
Man kann sich Data Poisoning wie das Manipulieren eines Lehrbuchs vorstellen, aus dem eine ganze Schulklasse lernt. Wer in dieses Lehrbuch subtil falsche Aussagen einschmuggelt, verändert nicht nur eine einzelne Prüfung, sondern das Wissen aller, die daraus gelernt haben. Der Effekt zeigt sich vielleicht erst später und nur bei bestimmten Fragen – aber er ist tief verankert. Genau deshalb ist die Verteidigung gegen Data Poisoning zuerst eine Frage der Datenherkunft und Datenkuratierung: Man muss wissen, woher jede Zutat stammt, bevor man sie in den Lernprozess gibt. Konkrete Angriffsrezepte nennt dieser Beitrag bewusst nicht; im Fokus steht ausschließlich, wie sich Organisationen schützen.
Bei Angriffen auf die Verfügbarkeit geht es dem Angreifer darum, ein Modell insgesamt schlechter zu machen. Wenn ausreichend viele fehlerhafte oder widersprüchliche Daten in den Lernprozess einfließen, lernt das Modell verzerrte Zusammenhänge und wird in der Breite unzuverlässiger. In der Praxis kann sich das etwa als sinkende Trefferquote, als häufigere Fehlklassifikationen oder als generell instabileres Verhalten zeigen. Der Vorteil aus Verteidigungssicht: Solche Angriffe sind tendenziell auffälliger, weil sich eine breite Leistungsverschlechterung eher in Qualitätskennzahlen niederschlägt – vorausgesetzt, ein Unternehmen misst die Modellqualität überhaupt kontinuierlich.
Aus diesem Grund ist ein systematisches Qualitätsmonitoring die erste Verteidigungslinie gegen Verfügbarkeitsangriffe. Wer die Genauigkeit und Stabilität seiner Modelle laufend beobachtet und mit definierten Schwellen abgleicht, bemerkt eine schleichende Verschlechterung früher. Dieser Aspekt verbindet Data-Poisoning-Abwehr eng mit dem Thema KI-Qualitätssicherung und Testing.
Deutlich heimtückischer sind Angriffe auf die Integrität. Hier bleibt das Modell im Normalbetrieb unauffällig und liefert gute Ergebnisse – es verhält sich nur in ganz bestimmten, vom Angreifer anvisierten Situationen falsch. Eine besondere Ausprägung sind Backdoor-Angriffe (auch Hintertür-Angriffe genannt): Dabei wird das Modell so beeinflusst, dass es nur dann fehlerhaft reagiert, wenn ein spezifisches Auslösemuster im Input vorhanden ist. Fehlt dieses Muster, verhält sich das System korrekt. Genau diese Tarnung macht solche Angriffe für die Erkennung so schwierig – im Alltagsbetrieb gibt es schlicht keinen Anlass zum Verdacht.
Für die Verteidigung folgt daraus eine wichtige Konsequenz: Man kann sich nicht allein auf die durchschnittliche Modellleistung verlassen. Ein Modell kann in tausenden Testfällen einwandfrei arbeiten und trotzdem eine versteckte Fehlfunktion enthalten. Deshalb setzen defensive Strategien hier nicht nur auf Leistungsmessung, sondern zusätzlich auf saubere Datenherkunft, kritische Prüfung von Datenquellen und – bei hohem Schutzbedarf – auf gezielte Robustheitstests, die auch ungewöhnliche Eingabemuster abdecken.
Große Basismodelle entstehen in einem aufwendigen Vortraining aus enormen Datenmengen, die häufig aus öffentlich zugänglichen Quellen zusammengetragen werden. Genau diese Offenheit ist eine Stärke – und zugleich eine Angriffsfläche, denn öffentlich zugängliche Daten können prinzipiell von jedem eingestellt werden. Die allermeisten mittelständischen Unternehmen trainieren solche Basismodelle nicht selbst, sondern beziehen sie von Anbietern. Für sie verlagert sich das Thema damit auf eine Frage der Lieferkette: Wie vertrauenswürdig ist die Herkunft des eingesetzten Basismodells, und welche Angaben macht der Anbieter zu seiner Datenherkunft und Qualitätssicherung? Dieser Aspekt wird in Kapitel 07 vertieft.
Wer doch eigene Modelle von Grund auf trainiert – etwa in spezialisierten technischen Anwendungen –, trägt die volle Verantwortung für die Sauberkeit der Trainingsdaten. Hier greifen die klassischen Prinzipien der Daten-Governance besonders stark: kontrollierte Quellen, dokumentierte Herkunft und sorgfältige Kuratierung, bevor Daten in den Lernprozess gelangen.
Für viele Unternehmen ist das Fine-Tuning die praktisch bedeutsamste Phase. Dabei wird ein vorhandenes Basismodell mit eigenen, oft branchenspezifischen Daten nachjustiert, damit es die Sprache, Fälle und Anforderungen des Unternehmens besser trifft. Genau in diesem Moment fließen eigene Daten direkt in das Modellverhalten ein – und damit auch jede Verunreinigung, die in diesen Daten steckt. Stammen die Fine-Tuning-Daten aus schlecht kontrollierten Quellen, aus unstrukturierten Sammlungen oder aus automatisch zusammengetragenen Inhalten, steigt das Risiko, dass fehlerhafte oder gezielt platzierte Daten das Ergebnis verfälschen.
Die gute Nachricht: Beim Fine-Tuning sind die Datenmengen meist deutlich kleiner und überschaubarer als beim Vortraining. Das macht Kuratierung, Prüfung und Herkunftsnachweise praktisch machbar. Wer seine Fine-Tuning-Daten aus klar definierten, vertrauenswürdigen Quellen zieht, dokumentiert und vor der Verwendung prüft, reduziert das Risiko erheblich.
Besonders relevant – und oft unterschätzt – ist die RAG-Wissensbasis. RAG steht für Retrieval-Augmented Generation, also für Systeme, die zur Laufzeit auf externe Wissensquellen zugreifen, um ihre Antworten mit aktuellen oder unternehmensspezifischen Informationen zu untermauern. Solche Systeme sind im Mittelstand weit verbreitet, etwa als interne Wissensassistenten, die auf Handbücher, Richtlinien oder Produktdaten zugreifen. Der entscheidende Punkt: Bei RAG wird das Modell selbst nicht verändert – aber die Wissensquelle, aus der es schöpft, kann manipuliert werden. Schmuggelt jemand irreführende oder falsche Inhalte in die angebundenen Dokumente oder Datenbanken, kann das System diese Inhalte als vermeintlich vertrauenswürdiges Wissen ausgeben.
Weil RAG-Wissensbasen häufig aus lebenden, laufend aktualisierten Quellen bestehen – Wikis, Dokumentenablagen, angebundene Datenbanken –, ist hier die Zugriffskontrolle besonders wichtig. Wer darf Inhalte in die Wissensbasis einstellen oder ändern? Werden diese Änderungen protokolliert und geprüft? Genau diese Fragen entscheiden darüber, wie gut eine RAG-Architektur gegen Manipulation geschützt ist. Positiv ist: Anders als beim Training lässt sich eine kompromittierte RAG-Quelle vergleichsweise schnell korrigieren, sobald das Problem erkannt ist – das Wissen steckt nicht unumkehrbar im Modell.
Der Kern des Problems liegt in der Verzögerung und Tarnung: Ein vergiftetes Modell zeigt seinen Defekt oft nicht sofort und nicht überall, sondern nur unter bestimmten Bedingungen. Dadurch bleibt ein Angriff mitunter lange unentdeckt, und die daraus resultierenden Fehlentscheidungen wirken sich über einen längeren Zeitraum aus. Wenn ein Unternehmen seine Modelle nicht kontinuierlich überwacht, kann so ein Schaden entstehen, der erst spät oder gar nicht auf seine wahre Ursache zurückgeführt wird.
Ein zentraler Unterschied zu vielen anderen Sicherheitsvorfällen ist die Nachhaltigkeit des Schadens. Ist eine Manipulation erst einmal ins Modell eingelernt, lässt sie sich nicht durch einen einfachen Neustart oder ein Update entfernen. In der Regel muss das Modell mit bereinigten Daten neu trainiert oder erneut feinabgestimmt werden – ein Prozess, der Zeit und Ressourcen kostet. Erschwerend kommt hinzu, dass sich oft nicht zweifelsfrei feststellen lässt, welche Datenpunkte genau die Ursache waren. Diese Kombination aus verdeckter Wirkung und aufwendiger Reparatur macht die Prävention so wichtig: Es ist deutlich günstiger, verunreinigte Daten gar nicht erst ins Training zu lassen, als einen Schaden nachträglich zu beheben.
Bei RAG-Systemen ist die Lage etwas günstiger: Da das Wissen nicht ins Modell eingelernt ist, sondern zur Laufzeit geladen wird, lässt sich eine manipulierte Wissensquelle nach ihrer Entdeckung vergleichsweise schnell korrigieren. Das ändert aber nichts daran, dass falsche Auskünfte bis zur Entdeckung realen Schaden anrichten können.
Wichtig vorab: Es gibt keinen einzelnen Mechanismus, der Data Poisoning zuverlässig ausschließt. Erkennung ist immer ein Zusammenspiel mehrerer Kontrollen, die sich gegenseitig ergänzen. Je höher der Schutzbedarf eines Systems, desto mehr dieser Kontrollen sollten ineinandergreifen. Für Systeme mit geringem Risiko genügen oft schlanke Prüfungen; für kritische Anwendungen lohnt sich ein mehrstufiges Vorgehen.
Die erste Säule ist die Datenvalidierung: die systematische Prüfung eingehender Daten auf formale und inhaltliche Plausibilität, bevor sie weiterverarbeitet werden. Dazu gehören Prüfungen auf erwartete Formate und Wertebereiche, auf Vollständigkeit und Konsistenz sowie auf offensichtliche Widersprüche. Auch das Erkennen von Duplikaten und das Prüfen, ob die Verteilung neuer Daten zur erwarteten Verteilung passt, gehören dazu. Solche Prüfungen fangen viele Probleme früh ab – nicht nur böswillige Manipulationen, sondern auch versehentliche Fehler, die die Datenqualität mindern. Datenvalidierung ist damit ein doppelter Gewinn: Sie erhöht die Sicherheit und zugleich die Qualität.
Die zweite Säule ist die Anomalieerkennung. Sie sucht nach Datenpunkten oder Mustern, die sich ungewöhnlich stark vom Rest unterscheiden. Der Gedanke dahinter: Manipulierte Daten weichen häufig – wenn auch nicht immer – in irgendeiner Weise von der Normalität ab, etwa in ihrer statistischen Verteilung, in ihrer Häufung oder in ihrem Kontext. Statistische Verfahren und spezialisierte Werkzeuge können solche Auffälligkeiten sichtbar machen, ohne dass ein Mensch jeden Datenpunkt einzeln prüfen muss. Ergänzend hilft ein Modell-seitiges Monitoring: Wenn die Qualität eines Modells plötzlich oder schleichend sinkt, kann das ein Hinweis auf verunreinigte Daten sein. Die kontinuierliche Beobachtung von Qualitätskennzahlen ist deshalb eng mit der KI-Qualitätssicherung verwoben.
Bei RAG-Systemen kommt eine spezifische Erkennungsebene hinzu: die Beobachtung der abgerufenen Inhalte. Werden regelmäßig Quellen herangezogen, die nicht zur erwarteten Wissensbasis passen, oder tauchen widersprüchliche Aussagen auf, kann das auf eine manipulierte oder verunreinigte Wissensquelle hindeuten. Auch hier gilt: Anomalien sind Indizien, keine Beweise – sie sollten menschlich geprüft werden.
Die dritte und in vielerlei Hinsicht wichtigste Säule ist die Provenance, also die nachvollziehbare Herkunft der Daten. Provenance beantwortet die Fragen: Woher stammt dieser Datensatz? Wer hat ihn erhoben, verändert oder freigegeben? Welche Verarbeitungsschritte hat er durchlaufen? Ein lückenloser Herkunftsnachweis macht es ungleich schwerer, unbemerkt manipulierte Daten einzuschleusen, und erleichtert im Ernstfall die Ursachenanalyse. In der Praxis wird Provenance durch Metadaten, Versionierung von Datensätzen, Zugriffs- und Änderungsprotokolle sowie durch kontrollierte Datenpipelines umgesetzt. Je genauer die Herkunft dokumentiert ist, desto schneller lässt sich im Verdachtsfall eingrenzen, welche Daten betroffen sein könnten.
Die wirksamste Schutzmaßnahme ist keine einzelne Technik, sondern eine solide Data Governance. Sie legt fest, aus welchen Quellen Daten stammen dürfen, wer sie freigibt, wie sie klassifiziert werden und wer welche Zugriffe hat. Im Kern geht es darum, die Kontrolle über den eigenen Datenbestand zu behalten: Nur wer weiß, welche Daten er hat und woher sie kommen, kann Manipulationen erkennen und verhindern. Zu einer guten Data Governance gehören insbesondere die Definition vertrauenswürdiger Quellen, klare Zuständigkeiten für Datenfreigaben, eine strenge Zugriffskontrolle nach dem Prinzip der geringsten notwendigen Rechte sowie die Protokollierung von Änderungen an sicherheitsrelevanten Datenbeständen. Gerade bei RAG-Wissensbasen ist die Zugriffskontrolle entscheidend: Wer Inhalte einstellen oder ändern darf, bestimmt maßgeblich das Manipulationsrisiko.
Auf der Datenebene ist die Kuratierung die zentrale Schutzmaßnahme. Kuratierung bedeutet, Daten nicht ungeprüft zu übernehmen, sondern sie bewusst auszuwählen, zu prüfen und zu bereinigen, bevor sie in einen Lernprozess oder eine Wissensbasis gelangen. Dazu gehört, unklare oder minderwertige Quellen auszuschließen, Daten auf Plausibilität zu prüfen und offensichtliche Fehler oder Widersprüche zu entfernen. Ergänzend hilft die Signierung und Versionierung von Datensätzen: Werden Datensätze mit Prüfsummen oder digitalen Signaturen versehen und versioniert, lässt sich nachträglich feststellen, ob und wann sie verändert wurden. So entsteht eine überprüfbare Kette vom Ursprung bis zur Nutzung – ein wichtiger Baustein der Provenance aus Kapitel 05.
Für zugelieferte Daten und Modelle empfiehlt sich zusätzlich, deren Integrität beim Bezug zu prüfen: Stimmt die Signatur oder Prüfsumme mit der Angabe des Anbieters überein? Solche Kontrollen sind aus der klassischen Software-Sicherheit vertraut und lassen sich sinngemäß auf Daten und Modelle übertragen.
Auf der technischen Ebene existieren Ansätze für robusteres Training, die ein Modell weniger empfindlich gegenüber einzelnen verfälschten Datenpunkten machen. Dazu zählen widerstandsfähigere Lernverfahren, die den Einfluss extremer Ausreißer begrenzen, sowie eine konsequente Qualitätskontrolle im Trainingsprozess. Solche Verfahren sind ein sinnvoller Zusatz, ersetzen aber niemals saubere Daten und gute Governance – sie sind die letzte, nicht die erste Verteidigungslinie. Entscheidend ist das Prinzip der mehrschichtigen Verteidigung (Defense in Depth): Kein einzelner Mechanismus ist perfekt, aber das Zusammenspiel aus Governance, Kuratierung, Zugriffskontrolle, Monitoring und robustem Training macht erfolgreiche Angriffe deutlich unwahrscheinlicher und leichter erkennbar.
Die zentrale Erkenntnis lautet: Data-Poisoning-Risiken enden nicht an der eigenen Systemgrenze. Wer ein Basismodell einsetzt, übernimmt implizit das Vertrauen in dessen Trainingsdaten. Wer einen externen Datensatz einkauft, übernimmt das Vertrauen in dessen Herkunft und Sauberkeit. Und wer offene Komponenten aus öffentlichen Repositorien bezieht, verlässt sich auf deren Integrität. Jede dieser Vertrauensbeziehungen ist eine potenzielle Angriffsfläche – und zugleich ein Ansatzpunkt für Absicherung durch Verträge, Nachweise und Prüfungen.
Der Bezug von Basismodellen ist für den Mittelstand der Regelfall. Da diese Modelle aus sehr großen, oft öffentlichen Datenmengen entstehen, lässt sich ihre Datenherkunft von außen kaum vollständig überprüfen. Umso wichtiger ist es, vertrauenswürdige Bezugsquellen zu wählen und die Angaben des Anbieters zu Datenherkunft, Sicherheits- und Qualitätsmaßnahmen zu bewerten. Bei offenen Modellen und Datensätzen aus öffentlichen Plattformen sollte zusätzlich auf die Reputation der Quelle, auf verfügbare Integritätsnachweise wie Signaturen oder Prüfsummen und auf eine aktive Pflege der Komponente geachtet werden. Der Bezug aus einer klar identifizierbaren, gepflegten Quelle ist grundsätzlich vertrauenswürdiger als der aus einer unbekannten oder unregelmäßig gewarteten.
Werden externe Datensätze eingekauft oder von Dienstleistern aufbereitet, sollten die Anforderungen an Herkunft, Qualität und Sicherheit vertraglich festgehalten werden. Sinnvolle Bausteine sind etwa Zusicherungen zur Datenherkunft, Angaben zu den durchgeführten Qualitäts- und Bereinigungsschritten sowie die Möglichkeit, Herkunftsnachweise einzusehen. Auch das Recht, im Verdachtsfall Daten zurückzuweisen oder nachzuprüfen, gehört dazu. Für Datendienstleister, die im Auftrag Daten sammeln oder annotieren, ist zudem relevant, wie sie ihre eigenen Prozesse absichern – denn deren Schwachstellen werden zu den eigenen.
Bei Cloud-basierten KI-Diensten gilt häufig ein Modell der geteilten Verantwortung: Der Anbieter sichert die Plattform, das Unternehmen bleibt aber für die von ihm eingebrachten Daten und Konfigurationen verantwortlich. Es lohnt sich, diese Verantwortungsteilung genau zu verstehen und die eigenen Pflichten – etwa die Absicherung der eingespeisten Fine-Tuning- oder RAG-Daten – nicht dem Anbieter zuzuschreiben. Ein strukturiertes Lieferantenmanagement, das KI- und Datenlieferanten bewusst einbezieht, ist deshalb ein wichtiger Baustein der Data-Poisoning-Abwehr.
Der wichtigste Grundsatz lautet: Verhältnismäßigkeit. Ein interner Assistent, der aus einem gepflegten, zugriffsbeschränkten Handbuch Auskunft gibt, braucht andere Kontrollen als ein System, das aus offenen Internetquellen lernt und automatisiert Entscheidungen trifft. Der Aufwand sollte sich am Schutzbedarf und am Schadenspotenzial des jeweiligen Systems orientieren. Diese risikobasierte Denkweise verhindert, dass Sicherheit entweder zur lähmenden Bürokratie oder zum blinden Fleck wird.
Aus unserer Erfahrung scheitert die Umsetzung selten am fehlenden Wissen, sondern an mangelnder Kontinuität. Es lohnt sich, mit den Systemen mit dem höchsten Schutzbedarf zu beginnen, dort saubere Prozesse zu etablieren und diese schrittweise auf weitere Systeme auszurollen. Wichtig ist, die Verantwortlichkeit klar zuzuordnen: Solange niemand explizit für die Datenqualität und -sicherheit eines KI-Systems zuständig ist, bleibt der Schutz Zufall. Ein benannter Verantwortlicher, eine knappe Richtlinie und ein einfacher Freigabeprozess bringen oft mehr als jedes einzelne technische Werkzeug.
Data-Poisoning-Abwehr ist zu einem großen Teil eine Frage der Datenkultur. Beschäftigte, die verstehen, warum die Herkunft von Daten zählt und warum nicht jede Quelle bedenkenlos ins System eingespeist werden darf, sind die beste Verteidigung. Ein angemessenes Grundverständnis – etwa im Rahmen der allgemeinen KI-Kompetenz – hilft, riskante Abkürzungen zu vermeiden. Diese kulturelle Dimension kostet wenig, wirkt aber breit und dauerhaft.
Der zentrale Zusammenhang: Der Schutz vor Data Poisoning ist Teil dessen, was Regulierung und Normen unter der Robustheit, Sicherheit und Datenqualität von KI-Systemen verstehen. Wer diese Themen ernst nimmt, arbeitet zugleich auf die Erfüllung wesentlicher regulatorischer Erwartungen hin – auch wenn Data Poisoning in den Rechtstexten meist nicht ausdrücklich beim Namen genannt wird.
Der EU AI Act stellt nach aktuellem Stand insbesondere an Hochrisiko-Systeme Anforderungen, die den Kern der Data-Poisoning-Abwehr berühren: Dazu zählen die Anforderungen an Daten und Daten-Governance – also an die Qualität, Repräsentativität und angemessene Aufbereitung der verwendeten Datensätze – sowie die Anforderungen an Genauigkeit, Robustheit und Cybersicherheit. Beide Bereiche verlangen sinngemäß, dass ein System gegen Manipulationen und fehlerhafte Daten hinreichend widerstandsfähig ist. Der Schutz vor Data Poisoning ist damit ein praktischer Baustein, um solche Anforderungen zu erfüllen. Ob und in welchem Umfang der AI Act auf ein konkretes System anwendbar ist und welche Pflichten daraus folgen, ist eine Frage des Einzelfalls und sollte mit einer Fachjurist:in geklärt werden.
Ergänzend liefern Normen wie die ISO/IEC 42001 für KI-Managementsysteme sowie etablierte Informationssicherheits-Standards ein Gerüst, um die organisatorischen und technischen Maßnahmen strukturiert und nachweisbar zu verankern. Wer bereits ein Informationssicherheits-Managementsystem betreibt, kann viele Kontrollen sinngemäß auf KI-Daten ausweiten.
Auch die DSGVO ist relevant, sobald ein KI-System personenbezogene Daten verarbeitet. Mehrere ihrer Grundsätze berühren das Thema unmittelbar: der Grundsatz der Integrität und Vertraulichkeit, der eine angemessene Sicherheit der Verarbeitung verlangt, sowie der Grundsatz der Richtigkeit, wonach Daten sachlich richtig und auf dem aktuellen Stand sein sollen. Eine Manipulation von Daten, die zu falschen oder diskriminierenden Ergebnissen führt, kann datenschutzrechtlich problematisch sein – etwa mit Blick auf die Rechte betroffener Personen. Zudem können geeignete technische und organisatorische Maßnahmen zum Schutz der Daten Teil der datenschutzrechtlichen Pflichten sein. Der Schutz vor Data Poisoning zahlt damit auch auf DSGVO-Anforderungen ein.
Wichtig ist die saubere Trennung: Der AI Act ist ein Produktsicherheits- und Grundrechterahmen, die DSGVO ein Datenschutzrahmen. Beide gelten parallel und ergänzen sich. Wie sie im konkreten Fall zusammenwirken und welche Pflichten sich ergeben, ist fachjuristisch zu bewerten – dies ist keine Rechtsberatung.
