RAG und DSGVO: Was europäische RAG-Setups anders machen müssen

Die meisten RAG-Tutorials im Internet stammen aus US-Kontext und übergehen europäische Compliance-Anforderungen komplett. Bei DACH-Mittelstands-Kunden erleben wir wiederholt dasselbe Muster: der Prototyp funktioniert, in Sprint 8 taucht der Datenschutzbeauftragte auf und die Architektur muss grundlegend umgebaut werden. Das ist vermeidbar, wenn vier konkrete Anpassungen von Anfang an eingebaut werden.

Dieser Artikel beschreibt die vier Anpassungen, die europäische RAG-Setups gegenüber US-Standard-Architekturen brauchen. Ergänzt den DSGVO-Blueprint für RAG-Pipelines mit dem Fokus auf: was ist konkret anders und warum.

Anpassung 1: Alle Datenverarbeiter in EU-Regionen

Das offensichtlichste, und trotzdem in 8 von 10 Projekten der erste Nacharbeitspunkt.

Der Standard-RAG-Stack aus US-Tutorials sieht so aus:

• LLM: OpenAI (US-East, Virginia)
• Embedding: OpenAI (US-East)
• Vector-DB: Pinecone (US-East als Default)
• Hosting: Vercel oder Netlify (US-Region als Default)
• Auth: Clerk (US-basiert)

Das erfordert für personenbezogene Daten Standardvertragsklauseln (SCC) mit jedem einzelnen Anbieter plus Nachweis, dass keine praktikablere EU-Alternative existiert. Nach Schrems II praktisch nicht mehr belastbar.

Die belastbare europäische Variante:

• LLM: Mistral (Paris), Aleph Alpha (Heidelberg), oder OpenAI mit europe-west Endpoint (Ireland/Finland) plus Zero Data Retention Agreement
• Embedding: OpenAI europe-west oder self-hosted BGE-M3 / E5-mistral in eigener EU-GPU-Umgebung
• Vector-DB: Qdrant Cloud (Frankfurt/Amsterdam), Weaviate Cloud EU-Region, oder pgvector auf PostgreSQL in EU-Hosting
• Hosting: Hetzner Falkenstein/Nürnberg, IONOS, Vercel fra1-Region, Netlify eu-central
• Auth: Clerk EU-Region (verfügbar seit Anfang 2025) oder Keycloak self-hosted

Praktische Konsequenz: Bei Projektstart einmal geklärt, kostet der EU-Stack keine zusätzliche Zeit. Nachträglich migriert, kostet er 1–3 Wochen Sprint plus die Erklärung an den Datenschutzbeauftragten, warum die erste Wahl falsch war.

Anpassung 2: PII-Filter im Ingestion-Layer

Amerikanische RAG-Setups nehmen Dokumente in der Regel ungefiltert auf und verlassen sich darauf, dass das LLM keine sensiblen Details preisgibt. Für europäische Setups ist das strukturell zu wenig.

Was ein PII-Filter macht:

Beim Ingestion-Prozess jedes Chunks wird geprüft, ob personenbezogene Datenpunkte enthalten sind: Namen, E-Mail-Adressen, Telefonnummern, Adressen, Geburtsdaten, Sozialversicherungsnummern, IBANs. Diese können:

• Gelöscht werden, wenn sie für die Retrieval-Antwort nicht essenziell sind
• Pseudonymisiert werden (Name → PERSON_A, E-Mail → EMAIL_1), wenn der Kontext ohne sie unklar wäre
• Beibehalten werden, aber mit einem Sensitivity-Tag, das im Retrieval-Layer als Filter dient

Konkrete Umsetzung: eine Python-Pipeline mit presidio-analyzer (Microsoft, open-source) oder spaCy mit dem de_core_news_lg Modell. Alternativ ein LLM-basierter Filter, der aber je Chunk 0,001–0,005 EUR kostet und für große Bestände unwirtschaftlich wird.

Wichtiger Punkt: Der PII-Filter dokumentiert, welche Datenpunkte er gefunden hat, das ist die Grundlage für spätere Auskunfts- und Löschungsanfragen. Ohne diese Dokumentation ist DSGVO-Konformität nicht nachweisbar.

Anpassung 3: Right-to-Erasure auf Chunk-Ebene

Art. 17 DSGVO verlangt, dass ein Nutzer die Löschung aller ihn betreffenden Daten anfragen kann. Für ein RAG-System bedeutet das:

1. Bei einer Löschungs-Anfrage muss identifizierbar sein, welche Chunks im Vector-Store personenbezogene Daten der anfragenden Person enthalten
2. Diese Chunks müssen effektiv gelöscht werden, nicht nur "als deaktiviert markiert"
3. Der Löschungsvorgang muss dokumentiert werden

Technische Umsetzung:

• Jeder Chunk trägt Metadaten zur Datenquelle (Dokument-ID, Autor-ID, Zeitstempel)
• Bei Löschungsanfrage wird eine Filter-Query auf diese Metadaten ausgeführt und alle Treffer werden entfernt
• Auch alle Backup-Snapshots der Vector-DB müssen innerhalb der dokumentierten Retention-Frist (typisch 30 Tage) überschrieben werden

Häufiges Missverständnis: Viele Teams glauben, dass Embeddings nicht personenbezogen sind, weil sie hochdimensionale Vektoren sind. Rechtlich ist das nicht so einfach: wenn ein Embedding auf einen identifizierbaren Chunk mit personenbezogenen Daten verweist, ist es indirekt personenbezogen. Die Löschung des Embeddings ist ebenso erforderlich wie die des Chunks.

Anpassung 4: Audit-Trail für Retrieval und Antwort

Rechenschaftspflicht (Art. 5(2) DSGVO) verlangt, dass jederzeit nachweisbar ist, wie das System zu einem Ergebnis kam. Für ein RAG-System heißt das:

Für jede Nutzer-Anfrage muss gespeichert werden:

• Zeitstempel
• Anfragender (pseudonymisierte User-ID)
• Anfrage-Text (mit PII-Redaction, wenn die Anfrage selbst personenbezogen war)
• Welche Chunks das Retrieval geliefert hat (Chunk-IDs, Similarity-Scores)
• Welches LLM mit welchen Parametern die Antwort generiert hat
• Die generierte Antwort
• Feedback des Nutzers (hilfreich/nicht hilfreich)

Speicherfrist: Typisch 12 Monate, mit dokumentiertem Grund. Danach werden die Logs entweder anonymisiert (User-ID entfernen, Chunk-Referenzen behalten) oder gelöscht.

Praktische Umsetzung: Ein separater Log-Store (nicht die Vector-DB!) mit strukturierten Einträgen. Für die meisten Setups reicht PostgreSQL mit einer retrieval_log-Tabelle plus Partitionierung nach Monat.

Was das für Zeitplan und Kosten bedeutet

Die vier Anpassungen kosten in einem gut geplanten Projekt keine zusätzliche Zeit. Sie sind Design-Entscheidungen von Sprint 1, nicht Ergänzungen von Sprint 8.

Zusatzaufwand bei nachträglicher Umsetzung (typisch, wenn US-Tutorial-Setup verwendet wurde):

| Anpassung | Nachrüstung-Aufwand | |---|---| | Migration auf EU-Region | 1–3 Wochen (Datenmigration + Umstellung) | | PII-Filter einbauen und Bestand re-ingestieren | 1–2 Wochen | | Right-to-Erasure implementieren + testen | 3–7 Tage | | Audit-Trail einbauen + Retention-Prozess | 3–5 Tage | | Summe Nachrüstung | ~3–6 Wochen zusätzlich |

Bei Voraus-Planung: kein Zusatzaufwand. Bei Nachrüstung: 3–6 Wochen zusätzlicher Sprint. Das ist der Grund, warum wir diese Punkte immer in der ersten Discovery-Sitzung klären.

Nächster Schritt

Der RAG-Reifegrad-Check prüft in fünf Fragen die DSGVO-Bereitschaft eures RAG-Vorhabens, kostenlos, mit Sofortauswertung.

Wenn ihr die vier Anpassungen mit einem Team umsetzen wollt, das DSGVO-konforme RAG-Systeme in Production gebracht hat: Kalendertermin buchen, 30 Minuten kostenlos.

---

Verwandte Artikel: DSGVO-konforme RAG-Pipeline: Architektur-Blueprint · RAG-System-Beratung für den Mittelstand