KIResponsible AI

Datenschutz, wenn alles in ein Modell fließt: die blinden Flecken, die Ihre Rechtsabteilung übersieht

Unternehmen führen im Eiltempo LLMs ein und behandeln Datenschutz als Häkchen auf der Compliance-Liste. Das eigentliche Risiko liegt tiefer, in Architekturentscheidungen und Verhaltensmustern, mit denen die meisten Governance-Frameworks noch nicht mitgekommen sind.

🎙️

Podcast anhören

4 min

Jedes große Unternehmen füttert inzwischen Modelle mit Daten. Kundendaten, interne Memos, Finanzprognosen, HR-Akten, Vertragsentwürfe. Das Volumen, das in LLM-gestützte Tools fließt, ist schneller gewachsen als die Governance-Strukturen, die es kontrollieren sollen. Einkaufsabteilungen schließen Enterprise-Verträge mit OpenAI, Anthropic oder Microsoft, die Rechtsabteilung prüft den Auftragsverarbeitungsvertrag, und alle gehen davon aus, dass das Thema erledigt ist. Meistens ist es das nicht.

Die gängige Sicht: LLMs wie jeden anderen SaaS-Anbieter behandeln

Die Standardposition in der AI-Governance von Unternehmen läuft etwa so. LLMs sind Softwaredienste. Sie wenden dieselben Datenklassifizierungsregeln an wie bei Salesforce oder Workday. Sie prüfen, ob der Anbieter mit Ihren Eingaben trainiert (die meisten Enterprise-Verträge schließen das inzwischen aus). Sie stellen sicher, dass der Vertrag die Anforderungen an Auftragsverarbeiter nach Art. 28 DSGVO abdeckt, oder die CCPA-Pflichten, wenn Sie in Kalifornien tätig sind. Sie führen eine Datenschutz-Folgenabschätzung durch. Sie holen die Freigabe des Datenschutzbeauftragten ein. Fertig.

Diese Sicht ist nicht falsch. Diese Schritte zählen. Enterprise-Verträge mit OpenAI (über den Azure OpenAI Service) und Anthropic enthalten substanzielle Zusagen zu Datenspeicherung und Trainingsausschluss. Microsofts veröffentlichte Dokumentation zur Enterprise Data Boundary, aktualisiert bis 2025, gibt IT-Teams eine brauchbare Grundlage, um festzulegen, was wo bleibt. Der DPIA-Prozess zwingt Fachbereiche, wenn er sauber durchgeführt wird, dazu zu benennen, welche Daten sie tatsächlich senden und warum.

Der Compliance-zuerst-Rahmen hat echten Wert. Ohne ihn landen Unternehmen bei Shadow AI: Mitarbeitende kopieren sensible Daten in ChatGPT-Accounts für Privatnutzer, weil es kein freigegebenes Tool gibt. Das ist ein dokumentiertes, konkretes Risiko. Der Konsens adressiert es.

Wo der Konsens zusammenbricht

Das Problem ist, dass die Compliance-Checkliste Datenschutz als statische Eigenschaft von Daten behandelt, während das eigentliche Risiko daraus entsteht, was Modelle mit Daten in Kombination und über Zeit machen.

Drei blinde Flecken fallen auf.

Erstens,Inferenz und Rekonstruktion. Wenn ein Modell einen Prompt mit Teilinformationen erhält, kann es sensible Attribute rekonstruieren, die nie explizit geteilt wurden. Eine Arbeit von Forschenden bei Google DeepMind und Carnegie Mellon aus dem Jahr 2023 (veröffentlicht auf einer peer-reviewten NLP-Konferenz, nicht im Anbietermarketing) zeigte, dass LLMs demografische Merkmale, Gesundheitszustände und finanzielle Situationen aus Gesprächstexten mit einer Genauigkeit ableiten können, die die meisten Datenschutzverantwortlichen überraschen würde. Die Folgerung: direkte Identifikatoren aus einem Datensatz zu entfernen, bevor er in ein Modell geht, ist nicht dasselbe wie Anonymisierung. Viele DPIAs sind noch so geschrieben, als wäre es das.

Zweitens das Problem der Retrieval-Augmented Generation. RAG-Architekturen, inzwischen Standard in Enterprise-Deployments, verbinden Modelle zur Abfragezeit mit internen Wissensbasen. Die Zugriffslogik, die regelt, welche Dokumente ein Nutzer über das RAG-System abrufen kann, ist oft weniger streng als die Zugriffsrechte auf das zugrunde liegende Dokumentenarchiv. Ein Junior-Analyst, der eine Frage in natürlicher Sprache stellt, bekommt möglicherweise Inhalte aus HR-Richtlinien, M&A-Planungsunterlagen oder juristischen Stellungnahmen zu sehen, die er über das Dokumentenmanagementsystem selbst nie gefunden hätte. Das Modell setzt kein Need-to-know durch; es liefert, was relevant ist.

Drittens die Prompt-Logs. Die meisten Enterprise-LLM-Deployments protokollieren Prompts für Qualitäts-, Sicherheits- oder Debugging-Zwecke. In diesen Logs sammelt sich ein detailliertes Protokoll darüber, womit sich Mitarbeitende beschäftigen, was Kunden fragen und welche Probleme das Unternehmen tatsächlich zu lösen versucht. Die Data Governance für diese Logs ist typischerweise deutlich schwächer als die für die primären Datenquellen. Ein Leak der Prompt-Log-Datenbank ist potenziell aussagekräftiger als ein Leak des CRM.

Die rechtlichen Rahmen halten nicht Schritt. Der EU AI Act, ab August 2026 vollständig anwendbar, schafft Pflichten für Hochrisiko-KI-Systeme und Transparenz, aber seine Datenschutzbestimmungen greifen unbeholfen in die DSGVO ein, statt sie zu ersetzen oder zu klären. Unternehmen managen nun zwei überlappende Regulierungsregime mit unterschiedlichen Risikobegriffen, unterschiedlichen Zeitplänen und unterschiedlichen Aufsichtsbehörden. Der Compliance-als-Häkchen-Ansatz kommt mit dieser Unschärfe schlecht zurecht.

Es gibt noch ein subtileres Thema, das in Governance-Meetings selten zur Sprache kommt: organisatorische Anreize. Die Teams, die LLM-Tools bauen und ausrollen, werden für Geschwindigkeit und Leistungsfähigkeit belohnt. Die Teams, die für Datenschutz zuständig sind, werden dafür belohnt, Vorfälle zu vermeiden. Diese Anreize laufen auseinander, und in den meisten Organisationen haben die Bauenden mehr Ressourcen, mehr Aufmerksamkeit im Management und kürzere Zyklen als die Governance-Funktion. Der DPIA-Prozess wird zur Formalität, die geprüft wird, wenn das Produkt schon im Einsatz ist.

Was ein guter Operator tatsächlich tun sollte

Governance-Frameworks, die für SaaS gebaut wurden, brauchen strukturelle Änderungen, um für LLMs zu funktionieren, nicht nur zusätzliche Punkte auf der Checkliste.

Zur Architektur: behandeln Sie das Prompt-Log ab Tag eins als regulierte Daten. Wenden Sie dieselben Aufbewahrungsfristen, Zugriffskontrollen und Meldeschwellen für Datenschutzverletzungen an, die Sie für eine Datenbank mit Gesundheitsdaten ansetzen würden. Die meisten Unternehmen behandeln Logs derzeit als Betriebsdaten mit schwachen Kontrollen. Das muss sich ändern, bevor ein Vorfall die Änderung erzwingt.

Zu RAG-Deployments: kartieren Sie die Lücke bei den Zugriffsrechten explizit. Führen Sie vor dem Rollout eines RAG-Systems einen strukturierten Test durch, bei dem Nutzer mit unterschiedlichen Berechtigungsstufen das System abfragen, und dokumentieren Sie, was sie abrufen können. Vergleichen Sie das mit dem, was sie über die herkömmlichen Zugriffskontrollen sehen dürfen. Die Lücke ist meist größer als erwartet.

Zum Inferenzrisiko: hören Sie auf, Datenminimierung als binär zu betrachten. Die Frage ist nicht, ob Sie Namen und E-Mail-Adressen entfernt haben. Die Frage ist, ob die verbleibenden Daten in Kombination mit dem, was das Modell aus dem Pretraining schon weiß, geschützte Attribute rekonstruieren können. Dafür braucht es jemanden, der Modellverhalten versteht, nicht nur eine Rechtsabteilung, die ein Datenklassifizierungsschema anwendet.

Zu Anbieterbeziehungen: wenn Sie mit einem Anbieter wie Microsoft arbeiten (dessen Azure OpenAI Service inzwischen der häufigste Weg für Enterprise-Deployments ist), lesen Sie die Dokumentation zur Data Boundary selbst, statt sich auf die Compliance-Zusammenfassung des Anbieters zu verlassen. Die Details dazu, welche Telemetrie wohin fließt und unter welchen Bedingungen Microsoft-Mitarbeitende für Sicherheitsprüfungen auf Prompt-Inhalte zugreifen können, stehen in der technischen Dokumentation. Es lohnt sich, das zu verstehen. Behandeln Sie Compliance-Zusammenfassungen von Anbietern als Ausgangspunkt, nicht als Ergebnis.

Die Unternehmen, die das gut hinbekommen, sind die, die ihre Deployment-Teams und ihre Datenschutzfunktion vor dem Rollout zusammenbringen, nicht nach der ersten Nutzerbeschwerde oder Behördenanfrage.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1Privacy und vertrauliche Daten: was Sie nicht einfügen solltenVerantwortungsvolle und vertrauenswürdige KI
  2. 2Governance und der EU AI Act: das WesentlicheVerantwortungsvolle und vertrauenswürdige KI
  3. 3Sicherheit, Datenschutz und Data ControlsChatGPT & das OpenAI-Ökosystem
  4. 4Sharing, Governance und Custom GPTs im ArbeitsalltagChatGPT & das OpenAI-Ökosystem
  5. 5Retrieval-augmented generation (RAG): dem Modell Ihre Daten gebenBuilding with AI

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.