Datenschutz beim KI-Einsatz: Ein Leitfaden für Führungskräfte

Zentrale Erkenntnisse

• Datenschutzrisiken in der KI sind kein Einzelereignis. Sie verlagern sich über Training, Inferenz, Logs und Lieferantenübergaben.
• Die Datenaufbereitung beansprucht 50–65 % eines KI-Projekts. Dort findet auch der Großteil der Datenschutzarbeit statt.
• Differential Privacy, Pseudonymisierung und On-Prem-Bereitstellung lösen jeweils ein anderes Problem. Keine davon löst alle.
• Lieferantenverträge entscheiden darüber, ob Ihre Eingaben in das Modell eines anderen Anbieters einfließen. Lesen Sie sie vor der Unterzeichnung.
• Der EU AI Act und die DSGVO decken unterschiedliche Bereiche ab. Behandeln Sie beide als zwei separate Checklisten, nicht als eine.

Wo KI-Datenschutz tatsächlich versagt

KI-Datenschutzrisiken konzentrieren sich auf vier vorhersehbare Stellen: den Trainingsdatensatz, den Inferenzaufruf im laufenden Betrieb, die Logs, die niemand kartiert hat, und den Lieferantenvertrag, den niemand sorgfältig gelesen hat. Behandeln Sie diese als vier separate Probleme.

Datenlecks im Training. Modelle können Fragmente ihrer Trainingsdaten speichern und später reproduzieren. Kleine Datensätze und ungefilterte Scrapes verschärfen dieses Problem. Die Lösung setzt am Anfang an: Reduzieren Sie das, was in den Datensatz einfließt, pseudonymisieren Sie Identifikatoren und wenden Sie Differential Privacy an, wo der Kompromiss bei der Genauigkeit akzeptabel ist.

Exposition zur Inferenzzeit. Jeder Prompt ist ein Datenereignis. Logs, Caches und Zwischenergebnisse enthalten Kopien dessen, was Anwender eingegeben haben. Die meisten Teams vergessen die Cache-Ebene. Wir haben dies bei einem Projekt für eine Marketingagentur erlebt, bei dem das Team ChatGPT-ähnliche Unterstützung wollte, ohne Kundenbriefings an eine öffentliche API zu senden. Die Lösung war eine On-Prem-LLM-Bereitstellung, die den Inferenzkanal vollständig geschlossen hat.

Synthetische Daten sind kein Freifahrtschein. Synthetische Datensätze reduzieren das Risiko, aber ein schlecht generierter Datensatz kann bis zu den Personen in der Quelle zurückverfolgt werden. Der Kompromiss ist tatsächlich vorhanden: Mehr Datenschutz bedeutet in der Regel weniger Genauigkeit. Testen Sie das Modell an dem synthetischen Datensatz genauso wie an echten Daten, sonst wissen Sie nicht, was Sie verloren haben.

Drittanbieter-Tools erben nichts automatisch. Wenn Sie ein Modell eines Anbieters einbinden, übernehmen Sie dessen Datenverarbeitung. Wenn dieser Ihre Eingaben zum Nachtrainieren verwendet und Sie dies nicht schriftlich untersagt haben, ist Ihr proprietärer Text nun ein Bestandteil des Produkts eines anderen Anbieters.

Ein Hinweis zu KI-spezifischen Angriffen. Über passive Datenlecks hinaus können Modelle aktiv angegriffen werden. Membership-Inference-Angriffe verraten, ob ein bestimmter Datensatz Teil des Trainingssatzes war. Model Inversion rekonstruiert näherungsweise Trainingsbeispiele aus Modellausgaben. Prompt Injection kann ein laufendes Modell dazu bringen, Daten aus früheren Prompts oder aus seinen Retrieval-Quellen preiszugeben. Diese Angriffe sind in der akademischen Literatur belegt und werden zunehmend auch in produktiven Umgebungen beobachtet. Die Verteidigung erfolgt vorgelagert (was Sie ins Training einfließen lassen) und an der Schnittstelle (Eingabebereinigung und Ausgabefilterung), nicht am Modell selbst. Öffentlich bekannte Vorfälle veranschaulichen das Muster: Der Samsung-ChatGPT-Vorfall von 2023, bei dem Ingenieure proprietären Code in eine öffentliche API eingegeben haben und dieser in Logs gelangte, die das Unternehmen nicht mehr zurückholen konnte, ist das klassische Beispiel. In den Jahren 2024–2025 folgten mehrere ähnliche Fälle.

Differential Privacy fügt kalibriertes Rauschen hinzu, sodass einzelne Datensätze nicht wiederhergestellt werden können – auf Kosten der Modellgenauigkeit. Die Pseudonymisierung ersetzt direkte Identifikatoren, schützt aber nicht vor Verknüpfungsangriffen. Federated Learning belässt Rohdaten auf lokalen Geräten und überträgt lediglich Modellaktualisierungen. Das hilft beim Risiko auf der Erhebungsseite, erhöht jedoch die technische Komplexität. Wählen Sie diejenige Methode, die zum tatsächlich vorhandenen Risiko passt.

Confidential Computing bietet einen Mittelweg: Die Modellausführung erfolgt in hardwareisolierten Enklaven (AWS Nitro, Azure Confidential Compute, Google Confidential Space), in denen der Cloud-Anbieter selbst die Daten nicht einsehen kann. Es schließt einige derselben Lücken wie eine On-Prem-Bereitstellung und bewahrt dabei die operative Einfachheit einer verwalteten Infrastruktur. Es eignet sich nicht für jede Arbeitslast – der Leistungsaufwand und die Einrichtungskomplexität sind tatsächlich vorhanden – aber für regulierte Daten, die nicht in standardmäßige Cloud-Dienste gelangen dürfen, hat es sich zu einer tragfähigen dritten Option entwickelt.

Praxistipp. Fordern Sie vor der Vertragsunterzeichnung mit einem KI-Anbieter ein Datenflussdiagramm an – Quellen, Speicherung, Aufbewahrung, Löschung. Kann der Anbieter dieses nicht innerhalb einer Woche liefern, sagt das alles über dessen Reifegrad aus.

Datenschutzrisiken über den gesamten KI-Lebenszyklus

Datenschutz ist keine Freigabehürde vor dem Launch. Er bewegt sich mit dem Modell. Der größte Anteil der Datenschutzarbeit fällt in die Datenaufbereitung, in der auch 50–65 % des Projektaufwands eines typischen Silk Data-Projekts anfallen.

Ein Detail, das häufig übersehen wird: temporäre Speicher. Logs, S3-Staging-Buckets und Debug-Dumps aus einem Trainingslauf enthalten oft Rohdaten, die niemand kartiert hat. Wir haben Projekte übernommen, in denen das Modell selbst sauber war und die Log-Aufbewahrungsrichtlinie den nächsten Sicherheitsvorfall bereits in sich barg.

Privacy-by-Design klingt wie ein Slogan, ist aber lediglich eine Frage der Reihenfolge. Legen Sie fest, welche Daten Sie verarbeiten dürfen, und entwerfen Sie das Modell entsprechend dieser Einschränkung. Die umgekehrte Reihenfolge – erst das Modell bauen, dann die Rechtsabteilung fragen – ist der Punkt, an dem die meisten Nachbesserungsbudgets aufgebraucht werden.

Welche Regeln tatsächlich gelten – und wo

Die meisten Teams vermischen DSGVO, den EU AI Act und branchenspezifische Vorschriften zu einem Nebel. Es handelt sich um unterschiedliche Rechtsinstrumente mit unterschiedlichen Auslösern. Wählen Sie diejenigen, die zu Ihrer Rechtsordnung und Ihren Daten passen, und ignorieren Sie den Rest, bis er relevant wird.

Der EU AI Act fügt eine Lieferkettenebene hinzu, die die meisten Teams bislang nicht verinnerlicht haben. Wenn Ihr Produkt auf einem Allzweckmodell aufsetzt, benötigen Sie Dokumentation von diesem Anbieter als Teil Ihrer eigenen Compliance-Dokumentation. Ohne diese können Sie nicht nachweisen, was in dem darunterliegenden Modell enthalten ist. Das ist zunächst ein Vertragsproblem, bevor es ein rechtliches wird. Im Mai 2026 verschob das Digital-Omnibus-Abkommen zur KI die Verpflichtungen für Hochrisikosysteme aus Anhang III auf Dezember 2027. Andere Bestimmungen des AI Act – einschließlich der Verbote nach Artikel 5 und der Pflichten für Allzweck-KI – bleiben nach dem ursprünglichen Zeitplan in Kraft. Das Compliance-Zeitfenster für Hochrisikosysteme wurde erweitert; die zugrunde liegenden Designprinzipien haben sich nicht geändert.

Ein Kompromiss, den man ausdrücklich benennen sollte: Strengere lokale Compliance drängt die Architektur oft in Richtung On-Prem oder Private Cloud, was die Infrastrukturkosten erhöht. Kostengünstigere SaaS-KI bedeutet in der Regel, dass Daten Ihren Perimeter verlassen. Es gibt keine eindeutige Antwort. Für regulierte Branchen fällt die Entscheidung meist auf lokale Bereitstellungen, weshalb unsere NLP- und LLM-Projekte standardmäßig auf On-Prem-Optionen setzen.

Ein Hinweis zu US-Gesetzen auf Bundesstaatenebene. Die föderale KI-Regulierung in den USA bleibt spärlich, doch die Aktivitäten auf Bundesstaatenebene haben zugenommen. Kaliforniens CPRA/CCPA deckt personenbezogene Daten umfassend ab, Colorados AI Act (in Kraft ab Februar 2026) legt Verpflichtungen für Entwickler und Betreiber von Hochrisiko-KI-Systemen fest, Texas hat ein Datenschutzgesetz mit Wirkung ab Juli 2024, und mehrere Bundesstaaten haben KI-spezifische Gesetzgebung vorgeschlagen. Für Bereitstellungen ausschließlich in den USA ist die Kartierung der Exposition auf Bundesstaatenebene nun ebenso wichtig wie die Bereitschaft auf Bundesebene. Für Aktivitäten in mehreren Bundesstaaten ist die sicherere Standardregel oft der strengste anwendbare Standard.

Praxistipp. Verlangen Sie bei der Einbindung eines Foundation-Model-Anbieters eine schriftliche Offenlegung der Trainingsdatenquellen, Schutzmaßnahmen und bekannten Einschränkungen – im Vertrag, nicht im Marketing-Prospekt.

Praktiken, die sich im produktiven Betrieb bewähren

Compliance-Bewusstsein ohne Engineering führt lediglich zu Präsentationen. Die folgende Liste umfasst Praktiken, die tatsächlich das Verhalten eines Modells im produktiven Betrieb verändern. Jede davon hat ihren Preis. Keine davon ist in einem regulierten Umfeld optional.

• Kontinuierliche Zustandsüberwachung. Verfolgen Sie das Modellverhalten, Zugriffsmuster und Konfigurationsdrift genauso, wie Sie Ihre Infrastruktur überwachen. Der Nachteil ist Alarmermüdung bei falsch gesetzten Schwellenwerten; kalibrieren Sie diese anhand tatsächlicher Vorfälle, nicht anhand theoretischer.
• Prompt- und Log-Richtlinie. Legen Sie fest, was Anwender eingeben dürfen, wie lange Logs bestehen bleiben und wer sie einsehen darf. Kurze Aufbewahrungszeiten helfen dem Datenschutz und erschweren das Debuggen – wählen Sie einen Zeitraum, den Sie rechtfertigen können.
• Jährliche Lieferantenprüfung. Lieferantenbedingungen ändern sich mit jedem Modell-Release. Lesen Sie diese erneut, wenn der Anbieter eine größere Aktualisierung veröffentlicht – nicht nur zum Verlängerungszeitpunkt.
• PIA als wiederkehrende Praxis. Eine PIA zum Launch deckt das Offensichtliche ab. Die zweite, sechs Monate später, deckt auf, was der produktive Betrieb tatsächlich macht. Planen Sie beide ein.
• Transparenz gegenüber Anwendern. Teilen Sie den Anwendern in verständlicher Sprache mit, was Sie mit ihren Eingaben tun. Das ist keine juristische Formalität. Es entscheidet darüber, ob eine Beschwerde oder ein Schreiben einer Aufsichtsbehörde folgt.

Yuliya Marazenko, Head of AI Implementation bei Silk Data, dazu, was die Ergebnisse verändert:

„Die Teams, die Datenschutz gut umsetzen, benennen einen namentlich benannten Verantwortlichen auf Projektebene – jemanden, der einen Launch aufhalten kann. Diese eine strukturelle Entscheidung verändert mehr als jedes Rahmenwerk auf Papier.“

Die Vertragsfalle beim Lieferanten

Der häufigste Datenschutzfehler, den wir sehen, ist nicht technischer Natur. Er ist vertraglicher Natur. Ein Team kauft ein SaaS-KI-Tool, die Beschaffungsprüfung wird bestanden, und ein Jahr später produziert eine Modellaktualisierung Ausgaben, die verdächtig nach internen Dokumenten aussehen. Zu diesem Zeitpunkt sind die Daten bereits Teil des Trainingskorpus, und es gibt keinen sauberen Ausweg mehr.

Was in klaren Worten vor der Unterzeichnung festgelegt werden muss:

• Ob Eingaben von Kunden für das Modelltraining verwendet werden dürfen. Die Standardantwort sollte schriftlich „nein“ lauten.
• Wo die Daten gespeichert werden und unter welcher Rechtsordnung.
• Aufbewahrungsfristen für Prompts, Ausgaben und Logs.
• Löschprozess und Nachweis der Löschung.
• Fristen für die Benachrichtigung bei Sicherheitsvorfällen.
• Was mit Ihren Daten geschieht, wenn der Anbieter übernommen wird.

Unser Tool zur KI-gestützten Vertragsprüfung existiert genau dafür: das Extrahieren dieser Klauseln aus PDF-Dokumenten, damit ein Rechtsteam nicht 80 Seiten lesen muss, um einen Absatz zu Rechten am Nachtrainieren zu finden.

Yuri Svirid, CEO von Silk Data, zur Frage Eigenentwicklung vs. Zukauf:

„Manchmal ist die richtige Antwort auf ein Datenschutzproblem kein besserer Vertrag. Es geht darum, die Daten überhaupt nicht mehr nach außen zu senden. Dann hört On-Prem auf, eine Präferenz zu sein, und wird zur Architektur.“

Wenn bereits etwas schiefgelaufen ist

Prävention steht im Mittelpunkt der meisten Datenschutzdiskussionen. Die Realität der meisten Datenschutz-Karrieren ist jedoch die Reaktion auf Vorfälle. Drei spezifische Muster, die für KI relevant sind:

• Daten im Trainingskorpus, die Sie nicht zurückrufen können. Sobald proprietäre oder personenbezogene Daten für das Modelltraining verwendet wurden, ist es technisch unmöglich, sie im Nachhinein zu entfernen. Die Abhilfemaßnahmen unterscheiden sich von einer klassischen Datenschutzverletzung: Es geht um Modell-Nachtraining, Neuverhandlung von Verträgen und mitunter die Ausmusterung des Modells. Planen Sie dies, bevor das erste Modell bereitgestellt wird, nicht danach.
• Prompt-Logs mit Daten, die nicht hätten erfasst werden dürfen. Logs unterliegen oft kürzeren Aufbewahrungsregeln, als es für die zugrunde liegenden Daten vorgesehen war. Auffindbarkeit, Aufhebung der Aufbewahrung, Löschmechanismus und Prüfpfad müssen speziell für Logs entworfen werden, nicht von Richtlinien auf Datenbankebene übernommen.
• Modellaktualisierungen von Drittanbietern, die das Verhalten ändern. Eine Modellaktualisierung eines Anbieters kann dazu führen, dass Ausgaben Trainingskorpusinhalte offenlegen, die zuvor nicht sichtbar waren. Es handelt sich um eine Form von Vorfall, die nicht durch klassische Rahmenwerke zur Meldung von Datenschutzverletzungen abgedeckt wird. Vertragsklauseln zur Transparenz von Modellaktualisierungen dienen genau dazu, dies frühzeitig zu erfassen.

Wie Silk Data unterstützt

Wir entwickeln seit über einem Jahrzehnt KI-Lösungen, bei denen Data Governance von Anfang an eine Randbedingung war und nicht nachträglich eingebaut wurde. Die Leistungen, die direkt auf die in diesem Artikel behandelten Datenschutzfragen abzielen:

• KI-Beratung für Machbarkeitsprüfungen und Entscheidungen zwischen Eigenentwicklung und Zukauf.
• Fallstudien zum maschinellen Lernen aus den Bereichen Finanzen, Handel, Ökologie und Verlagswesen, in denen Datenschutzanforderungen Bestandteil der Aufgabenstellung waren.
• On-Prem- und lokale LLM-Bereitstellungen für Kunden, die keine Daten an öffentliche APIs senden dürfen, einschließlich des oben beschriebenen Projekts für die Marketingagentur.

Wenn Sie sich in der Architekturphase befinden, sagen wir Ihnen, was das Modell leisten kann und was nicht. Wenn Sie eine Bereitstellung im produktiven Betrieb haben, prüfen wir den Datenfluss und die zugrunde liegenden Verträge. hello@silkdata.ai.

Kurzcheckliste zum KI-Datenschutz

Bevor ein Modell in den produktiven Betrieb geht, prüfen Sie Folgendes:

• Datenflussdiagramm liegt vor und ist aktuell
• Rechtsgrundlage für alle Trainingsdaten ist dokumentiert
• Lieferantenvertrag untersagt ausdrücklich das Training mit Ihren Eingaben
• Datenstandort erfüllt die Anforderungen der zuständigen Rechtsordnung
• Richtlinie zur Log-Aufbewahrung ist definiert und rechtfertigungsfähig
• PIA ist abgeschlossen und eine Überprüfung nach sechs Monaten ist terminiert
• Namentlich benannter Verantwortlicher mit Befugnis zum Aufhalten von Launches ist zugewiesen
• Incident-Response-Handbuch deckt KI-spezifische Fehlerbilder ab