DSGVO-konformes LLM-Routing: KI-Anfragen EU-souverän steuern

Pexon Consulting | 10 Min. Lesezeit | 19.06.2026

TL;DR

Wenn euer Unternehmen DSGVO-strikt oder unter NIS2- bzw. KRITIS-Pflicht steht, dürfen Daten aus HR, Vertragsmanagement oder Kundenakten nicht ungefiltert an OpenAI in den US-Cloud-Anteil fließen. Ein DSGVO-konformes LLM Gateway routet pro Anfrage auf das richtige Modell — Azure OpenAI EU West, Mistral Large auf Azure DE oder on-prem Modelle. Pexon Consulting setzt das in 3 Wochen als Festpreis-Sprint zwischen 32 und 52k EUR auf.

Die DSGVO-Lage bei LLM-Anfragen 2026 nüchtern

Wir hören das aktuell wöchentlich in CISO-Erstgesprächen bei Banken, Versicherern und KRITIS-Betreibern: „Wir wollen Generative AI ausrollen, aber unser Datenschutzbeauftragter sagt nein zu OpenAI. Wir brauchen eine technische Lösung, nicht nur ein Konzept.“

Die Lage strukturiert. Die DSGVO selbst verbietet nicht den Einsatz von LLMs — aber sie verbietet die Weitergabe personenbezogener Daten an Auftragsverarbeiter ohne entsprechende vertragliche und technische Schutzmaßnahmen. Bei OpenAI sind das die Standard-Vertragsklauseln (SCCs) plus EU-US Data Privacy Framework — rechtlich grundsätzlich tragfähig, aber bei Banking-, Versicherungs- und KRITIS-Setups oft nicht ausreichend, weil zusätzliche Anforderungen aus Branchen-Regulatorik greifen.

Drei reale Compliance-Schichten 2026.

Schicht 1: DSGVO allgemein. Für Standard-DSGVO-Setups ist OpenAI mit Enterprise-Vertrag plus SCCs ausreichend. Praktisch gilt das für die meisten B2C- und B2B-Marketing-Anwendungen.

Schicht 2: BaFin und §32 VAG. Bei Banking und Versicherung kommen Outsourcing-Anforderungen ins Spiel. OpenAI-Direct ist bei wesentlichen Auslagerungen schwierig, Azure OpenAI mit EU-Region und Customer-Managed Keys ist machbar.

Schicht 3: KRITIS und NIS2. Bei kritischen Infrastrukturen plus NIS2-Pflicht greifen Datenresidenz-Anforderungen voll. Cloud-Verarbeitung außerhalb der EU ist im sensitiven Workload-Pfad ausgeschlossen. Mehr zur breiten AI-Landing-Zone für KRITIS und NIS2.

Die technische Antwort auf alle drei Schichten ist das gleiche Pattern: DSGVO-konformes Routing über ein zentrales LLM Gateway. Pro Anfrage entscheidet der Gateway anhand der Daten-Klassifikation, auf welchen Pfad die Anfrage geht.

Die Routing-Logik im Detail

Drei Schritte, die in jedem Pexon-Setup ablaufen.

Schritt 1: Daten-Klassifikation an der Anwendungs-Schnittstelle. Die aufrufende Anwendung deklariert pro Anfrage die Daten-Klasse. Im einfachsten Fall ist das ein Header oder ein Field im API-Call. Vier Stufen: öffentlich, intern, vertraulich, streng vertraulich.

# Beispiel: Klassifizierte Anfrage an LiteLLM-Gateway
response = client.chat.completions.create(
    model="ki-vertraulich",  # logischer Modell-Name
    messages=[{"role": "user", "content": user_query}],
    extra_headers={
        "X-Data-Classification": "confidential",
        "X-Use-Case": "hr-knowledge-bot",
        "X-User-Id": user.id,
        "X-Team-Id": user.team_id
    }
)

Schritt 2: Modell-Routing im Gateway. Auf Basis der Klassifikation entscheidet der Gateway über den Backend-Modell-Pfad. Bei „confidential“ → Azure OpenAI EU West plus PII-Maskierung. Bei „strictly-confidential“ → Mistral Large on Azure DE oder on-prem.

Schritt 3: PII-Maskierung vor Modell-Aufruf (für sensitive Klassen). Personenbezogene Daten werden vor dem Modell-Aufruf erkannt und maskiert. Namen, E-Mail-Adressen, IBAN, Versicherungs-Nummern. Das maskierte Prompt geht ans Modell, die Antwort wird zurück-demaskiert. Damit verlässt der originale PII-Wert nie den Gateway.

Mehr zur konkreten LLM Gateway-Architektur und Tool-Wahl.

Die Provider-Landschaft für DSGVO-konforme Setups

Welche Optionen pro Sensitivitäts-Klasse realistisch sind 2026.

Azure OpenAI in West Europe oder Germany West Central. Microsoft hat die meisten DSGVO-relevanten Verträge, plus die Cloud for Sovereignty als Option für besonders strikte Setups. Für 70-85% der DSGVO-Lagen ist das die pragmatische Wahl.

Mistral Large on Azure DE. Französischer LLM-Anbieter, gehostet als Managed Service auf Microsoft Azure in Deutschland West Central. Klar EU-souveränes Setup, vertraglich plus technisch. Wir nutzen das oft als zweite Stufe für sensitive Workloads.

On-Prem Llama 3 oder Qwen auf eigener GPU-Hardware. Bei KRITIS-Tier-1 oder Defence-Industrie der einzige Pfad. Engineering-Aufwand höher, Investment in Hardware (typisch 25-80k EUR pro GPU-Server) — aber volle Datenresidenz-Kontrolle. Mehr zur Compute-Strategie zwischen Cloud und On-Prem im DACH-Decision-Vergleich.

OpenAI Direct nur für nicht-sensitive Klassen. Marketing-Content-Generierung, öffentliche FAQ-Bots, Engineering-Code-Snippets ohne Bezug zu Geschäfts-Logik. Für diese Klasse bleibt OpenAI wirtschaftlich attraktiv.

Was im Audit-Trail dokumentiert sein muss

Ein DSGVO-konformes Gateway hat strukturierten Audit-Trail. Pro Anfrage werden gespeichert.

• Zeitstempel der Anfrage
• Anonymisierte User-ID (kein Klartext-Name) und Team-ID
• Daten-Klassifikation der Anfrage
• Gewählter Modell-Pfad mit Begründung
• Prompt-Hash (nicht das Klartext-Prompt bei sensitiven Klassen)
• PII-Maskierungs-Statistik (Anzahl maskierte Entitäten)
• Token-Verbrauch und Latenz
• Response-Hash

Bei DSGVO-Auskunfts-Begehren eines Mitarbeiters lässt sich aus den Logs nachvollziehen, welche Anfragen er gestellt hat, ohne die sensitiven Inhalte selbst zu speichern.

# Beispiel: Audit-Eintrag pro Anfrage
audit_log.write({
    "timestamp": datetime.utcnow().isoformat(),
    "request_id": str(uuid.uuid4()),
    "user_id_hash": hashlib.sha256(user.id.encode()).hexdigest(),
    "team_id": user.team_id,
    "data_classification": classification,
    "model_routed_to": "azure-openai-eu-west",
    "routing_reason": "classification=confidential",
    "prompt_hash": hashlib.sha256(prompt.encode()).hexdigest(),
    "pii_entities_masked": pii_count,
    "tokens_input": token_count_input,
    "tokens_output": token_count_output,
    "latency_ms": latency
})

Mehr zur breiten Audit-Trail- und Multi-Tenant-Schutzarchitektur.

Die PII-Maskierungs-Pipeline im Detail

Wichtigster technischer Baustein. Drei Komponenten.

Detection-Layer. Erkennt PII-Entitäten in Prompts. Microsoft Presidio plus Custom-Modelle für deutsche Spezifika (IBAN-Formate, Versicherungsnummern, Steuer-IDs). Bei Pexon-Setups erreichen wir 96-99% Erkennungs-Rate bei strukturierten PII (E-Mail, IBAN, Telefon) und 88-93% bei Namen.

Masking-Layer. Ersetzt erkannte Entitäten durch Platzhalter ([PERSON_1], [IBAN_1]). Das maskierte Prompt geht ans Modell.

Demasking-Layer. Nach Modell-Antwort werden die Platzhalter in der Antwort wieder durch die Original-Werte ersetzt — falls das im Use-Case sinnvoll ist. Bei reinen Antwort-Generationen ist das oft nicht nötig (das Modell soll keine PII zurückspielen).

Wichtig: PII-Maskierung ist keine vollständige Anonymisierung im DSGVO-rechtlichen Sinne. Sie reduziert das Risiko erheblich, aber für vollständige Compliance braucht es weiterhin den richtigen Modell-Pfad (Azure EU bzw. on-prem) plus den vertraglichen Rahmen.

Pexon-Sprint und Investment

3-Wochen-Festpreis-Sprint:

• Woche 1 — Discovery und Compliance-Workshop. Daten-Klassifikations-Inventur mit CISO und Datenschutzbeauftragten, Use-Case-Mapping auf Sensitivitäts-Klassen, Architektur-Entscheidung Provider-Pfade.
• Woche 2 — Gateway-Setup und PII-Pipeline. Setup oder Erweiterung des bestehenden LLM Gateway, PII-Detection-Pipeline, Modell-Routing-Logik, Audit-Trail-Schicht.
• Woche 3 — Penetration-Test, Doku, Übergabe. Synthetische Angriffsvektoren (PII durchschlägt Maskierung, Routing-Bug, Audit-Lücken), Compliance-Doku für interne Revision, Übergabe an Engineering plus Datenschutz.

Investment-Festpreis: 32-52k EUR je nach Komplexität. Untere Spanne bei klar fokussiertem Setup (1-2 Use-Cases, DSGVO ohne Banking-Zusatz). Obere Spanne bei Banking-Setup mit BaFin-spezifischer Audit-Doku oder KRITIS-Tier-1-Setup mit on-prem Modell-Fallback.

Häufig gestellte Fragen

Reicht Azure OpenAI in West Europe für DSGVO-Compliance?

Für Standard-DSGVO-Lagen ja — Azure OpenAI in West Europe hat die nötigen Verträge plus Datenresidenz in der EU. Bei Banking-Setups oder KRITIS-Anforderungen kommen zusätzliche Anforderungen ins Spiel, dann ist die Architektur mehrschichtig. Wir machen das im 30-Minuten-Vorgespräch konkret.

Was kostet PII-Maskierung pro Anfrage?

Microsoft Presidio läuft self-hosted und addiert typisch 15-40 ms Latenz pro Anfrage. Cloud-Kosten für die Hosting-Schicht typisch 200-400 EUR pro Monat bei Mittelstands-Setups. Bei sehr großen Volumen (über 5 Mio Anfragen pro Monat) lohnt sich GPU-beschleunigte Detection.

Können wir OpenAI parallel weiter nutzen für nicht-sensitive Workloads?

Ja, das ist genau der Wert des Routing-Patterns. Pro Anfrage entscheidet das Gateway anhand der Klassifikation. Marketing-Content geht weiter zu OpenAI, HR-Bots gehen zu Azure EU oder Mistral DE. Anwendungen sprechen logische Modell-Namen ohne Provider-Logik.

Was wenn ein User die Klassifikation falsch setzt?

Realistische Sorge. Wir bauen zusätzlich Auto-Klassifikation als Sicherungsschicht — das Gateway analysiert den Prompt auf PII-Indikatoren und hebt die Klassifikation hoch, wenn nötig. Plus Stichproben-Audit der Klassifikations-Entscheidungen durch das Engineering-Team.

Wie reagiert die BaFin auf solche Setups?

BaFin hat keine LLM-spezifischen Vorgaben veröffentlicht, prüft aber im Auslagerungs-Audit die Konsistenz der Architektur. In unseren Banking-Setups hat die Multi-Pfad-Architektur (Azure EU für sensitive, OpenAI für non-sensitive) die Audit-Prüfungen ohne Beanstandung getragen. Wichtig ist die saubere Dokumentation. Mehr zum breiten Pattern für regulierte AI-Workloads.

Nächster Schritt

Wenn dein Banking-, Versicherungs- oder KRITIS-Unternehmen Generative AI ausrollen will und die DSGVO-Frage technisch nicht final geklärt ist: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem Datenschutzbeauftragten plus CISO. Du beschreibst die Use-Case-Landschaft und Compliance-Anforderungen, wir skizzieren den 3-Wochen-Sprint mit Festpreis.

Verwandte Themen