DSGVO und Data Residency, wenn ein LLM im Spiel ist

Ein Anwalt prüft, ob eine Verarbeitung rechtens ist. Ich baue das System, das die Antwort technisch überhaupt möglich macht. Dieser Text ist der zweite Teil, nicht der erste. Für die rechtliche Einschätzung braucht es jemanden mit der Zulassung dafür, nicht einen Architekten.

Was ich sehe, wenn ein LLM-Prototyp auf eine echte Datenschutzprüfung trifft: die Fragen sind fast immer dieselben, und die Antworten fehlen fast immer, weil in der Prototyp-Phase niemand danach gefragt hat.

Die Fragen, die zuerst kommen

Wo läuft das Modell physisch? Welche Region, welcher Anbieter?

Wo liegen die Embeddings und die Chunks, die als Kontext ins Modell gehen?

Verlässt eine Anfrage die EU, auch nur für einen Zwischenschritt wie Reranking?

Wer hat Zugriff auf Logs, die personenbezogene Daten im Prompt enthalten könnten?

Jede dieser Fragen hat eine technische Antwort, keine rechtliche. Aber ohne die technische Antwort kann die Rechtsabteilung ihre Frage nicht beantworten.

Wo die Antwort meistens hakt

Azure OpenAI in einer EU-Region ist ein anderer Fall als OpenAI direkt, und beide sind ein anderer Fall als ein selbst gehostetes Modell. Das ist kein Kleinkram. Ein Prototyp, der mit der öffentlichen API gebaut wurde, weil das am schnellsten ging, braucht vor dem Rollout oft einen Wechsel der Infrastruktur, nicht nur eine Anpassung der Verträge.

Bei einem Vektorspeicher ist die Frage genauso konkret. pgvector auf einer eigenen Postgres-Instanz in der EU ist eine andere Antwort als ein gehosteter Vektordienst mit Rechenzentrum außerhalb der EU. Beides funktioniert technisch identisch. Der Unterschied liegt komplett in der Frage, wo die Daten liegen, nicht wie die Suche läuft.

Ich habe das in Projekten mit Azure OpenAI und pgvector gelöst, wo beide Komponenten in einer EU-Region liefen, weil die Daten die regulierte Umgebung nicht verlassen durften. Wo eine gehostete Region nicht reichte, blieb die Alternative: selbst gehostete Vektoren statt eines externen Dienstes.

Was oft übersehen wird

Logs sind auch Daten, und genau das wird regelmäßig übersehen. Ein Prompt, der eine personenbezogene Anfrage enthält, landet oft ungeprüft im Observability-Tool. Liegt dieses Tool außerhalb der EU, hat die Anfrage die Region verlassen, auch wenn das Hauptmodell in der EU lief. Logging-Infrastruktur bekommt in Reviews regelmäßig weniger Aufmerksamkeit als das Modell selbst, dabei transportiert sie dieselben Daten.

Reranking und andere Zwischenschritte zählen genauso mit. Ein Reranker-Modell, das über eine externe API läuft, sieht dieselben Chunks wie das Hauptmodell. Bleibt der Hauptcall in der EU, der Reranker aber nicht, ist die Kette an ihrer schwächsten Stelle gebrochen.

Bei Multi-Tenant verschärft sich die Frage noch einmal. Bei einer Plattform mit mehreren Mandanten reicht „die Daten liegen in der EU" als Aussage nicht. Es muss klar sein, welche Daten von welchem Mandanten wo liegen, und dass ein Mandant nicht über einen gemeinsamen Log-Stream an Daten eines anderen kommt. Das ist dieselbe Trennung wie in Mandantentrennung für RAG und Agenten, nur mit Datenschutz statt Sicherheit als Auslöser.

Löschung ist bei RAG kein einfacher Delete

Ein Auskunfts- oder Löschbegehren betrifft bei einem klassischen System eine Zeile in einer Tabelle. Bei einem RAG-System betrifft es ein Dokument, das in Chunks zerlegt wurde, jeder Chunk mit eigenem Embedding im Vektorspeicher, möglicherweise auch in einem Cache oder in Log-Einträgen vergangener Antworten. Ein Dokument aus dem Quellsystem zu löschen reicht nicht, wenn die Embeddings im Index bleiben und weiter in Antworten zitiert werden.

Ich baue deshalb eine Lösch-Pipeline mit, die vom Ursprungsdokument über die ID auf alle abgeleiteten Chunks zurückverweist, nicht nur vom Dokument nach vorne. Ohne diese Rückverfolgung ist eine Löschung im Quellsystem eine Illusion, solange die Kopie im Vektorspeicher unangetastet bleibt.

Drittländer und Auftragsverarbeitung

Sobald ein Anbieter außerhalb der EU im Spiel ist, kommt die Frage nach dem Übermittlungsmechanismus. Ich liste, mit welchem Anbieter ein Vertrag zur Auftragsverarbeitung besteht, welche Region dort vertraglich zugesichert ist, und ob diese Zusicherung auch für Zwischenschritte wie Fehlerprotokolle beim Anbieter gilt. Das ist wieder eine technische und vertragliche Bestandsaufnahme, keine Aussage darüber, ob eine bestimmte Konstruktion rechtlich zulässig ist. Diese Bewertung liegt bei Ihrem Datenschutzbeauftragten oder Ihrer Rechtsabteilung, nicht bei mir.

Was ich in einem Review dazu aufnehme

Ich liste jede Komponente, die mit Daten in Kontakt kommt: Modell, Vektorspeicher, Reranker, Logging, Cache. Zu jeder Komponente die Region, der Anbieter, und ob ein Vertrag zur Auftragsverarbeitung existiert. Das ist eine technische Liste, keine juristische Bewertung. Sie ist aber die Grundlage, auf der die juristische Bewertung überhaupt stattfinden kann.

Ohne diese Liste bekommt die Rechtsabteilung eine Aussage wie „wir nutzen ein DSGVO-konformes Modell", die nichts über die tatsächliche Datenkette sagt. Mit der Liste bekommt sie etwas, das sie tatsächlich prüfen kann.

Was der Check daraus macht

Im LLM-Readiness-Check taucht das an mehreren Tagen auf, nicht nur an einem: bei Retrieval, wo die Chunks liegen, bei Betrieb, wo Logs landen, bei Mandanten, ob die Trennung auch die Datenlage einschließt. Ich liefere die technische Liste. Die rechtliche Bewertung bleibt bei Ihrer Rechtsabteilung oder Ihrem Anwalt.

Die Plattformseite dazu, wenn Infrastruktur in der EU bleiben muss, sitzt unter Cloud- und Kubernetes-Plattformen. Die Leistung für die LLM-Seite: KI-Engineering. Verwandt: Mandantentrennung.