Datenschutz-Folgenabschätzung (DSFA)

1. Systematische Beschreibung der Verarbeitungsvorgänge (Art. 35 Abs. 7 lit. a DSGVO)

1.1 Zweck der Verarbeitung

Das LLM-Proxy-System ist ein datenschutzkonformer Vermittlungsdienst (Proxy) zwischen Unternehmensnutzern und externen KI-Sprachmodell-Anbietern (OpenAI/GPT, Anthropic/Claude, Google/Gemini, Groq etc.).

Primärer Zweck: Schutz personenbezogener Daten bei der Nutzung großer Sprachmodelle durch automatische Erkennung, Pseudonymisierung und Redaktion von PII (Personally Identifiable Information), bevor Anfragen an externe KI-Anbieter übermittelt werden.

1.2 Art und Umfang der Verarbeitung

Verarbeitete Datenkategorien

Erkannte PII-Kategorien (42 Recognizer, 4 Schichten)

Schicht 1 – Neuronale NER: Personen, Organisationen, Orte (spaCy de_core_news_lg)

Schicht 2 – Regex-Recognizer (27+):

• IBAN (mit Prüfziffernvalidierung)
• Krankenversicherungsnummer (KVNR, ISO 7064 Mod 11,10)
• Steuer-Identifikationsnummer
• Personalausweisnummer
• Kfz-Kennzeichen
• Aktenzeichen
• Handelsregisternummern
• BIC/SWIFT
• VIN (Fahrzeug-Identifikationsnummer)
• IMEI
• Führerscheinnummer
• Telefonnummern, E-Mail-Adressen, etc.

Schicht 3 – Keyword-Recognizer (15):

• Besondere Datenkategorien gemäß DSGVO Art. 9: Gesundheitsdaten, genetische Daten, biometrische Daten, politische Meinungen, religiöse Überzeugungen, Gewerkschaftszugehörigkeit, sexuelle Orientierung
• Strafdaten gemäß DSGVO Art. 10
• Kinderdaten

Schicht 4 – Kontext-Recognizer (1):

• Zugangsdaten in natürlicher Sprache („Mein Passwort ist...“)

1.3 Kontext der Verarbeitung

1.4 Datenfluss

Nutzer → [HTTPS/TLS 1.3] → Caddy (WAF/Coraza) → Nginx LB → FastAPI
  → Authentifizierung (API-Key/JWT/Cookie + 2FA)
  → PII-Erkennung (4 Schichten, 42 Recognizer)
  → Pseudonymisierung (typ-erhaltend, session-konsistent)
  → [HTTPS] → Externer KI-Anbieter (nur pseudonymisierte Daten!)
  ← KI-Antwort (pseudonymisiert)
  → De-Pseudonymisierung
  → Response-PII-Redaktion (KI-generierte PII entfernen)
  → Audit-Eintrag (Ed25519 + ML-DSA-65, Hash-Kette)
  → Zero-Knowledge-Verschlüsselung (DEK aus Nutzerpasswort)
  ← Bereinigte Antwort an Nutzer

1.5 Externe Empfänger und Auftragsverarbeiter

1.6 Speicherdauer und Löschkonzept

2. Bewertung der Notwendigkeit und Verhältnismäßigkeit (Art. 35 Abs. 7 lit. b DSGVO)

2.1 Rechtsgrundlage der Verarbeitung

2.2 Notwendigkeit der Verarbeitung

Die Verarbeitung ist notwendig und verhältnismäßig, weil:

• Ohne PII-Erkennung würden personenbezogene Daten ungeschützt an externe KI-Anbieter (oft außerhalb der EU) übermittelt – ein klarer DSGVO-Verstoß.
• Ohne Pseudonymisierung könnten KI-Anbieter PII im Klartext verarbeiten und speichern.
• Ohne Audit-Kette gäbe es keinen Nachweis der DSGVO-Konformität.
• Ohne Zero-Knowledge-Verschlüsselung könnte der Betreiber auf Nutzerdaten zugreifen.

2.3 Verhältnismäßigkeit und Datenminimierung

3. Bewertung der Risiken für die Rechte und Freiheiten Betroffener (Art. 35 Abs. 7 lit. c DSGVO)

3.1 Risikoidentifikation

3.2 Detaillierte Risikobewertung

R1: PII wird nicht erkannt (Risikostufe: HOCH)

Szenario: Ein Nutzer gibt personenbezogene Daten in einer Form ein, die von keiner der 4 Erkennungsschichten erfasst wird (z.B. stark verschleierte oder in Fremdsprachen eingebettete PII).

Auswirkung: Personenbezogene Daten gelangen im Klartext an den externen KI-Anbieter.

Bestehende Maßnahmen:

• 4 parallele Erkennungsschichten (NER + Regex + Keyword + Kontext)
• 42 spezialisierte Recognizer inkl. deutscher Sonderformate
• Unicode-NFKC-Normalisierung gegen Homoglyph-Angriffe
• PII-QA-Container testet alle 6h mit 500 Samples
• Synthetic PII Monitor alle 5 Minuten
• Response-PII-Redaktion für KI-generierte PII
• Confidence-Schwellenwert von 0.7

Restrisiko nach Maßnahmen: MITTEL – Bei unbekannten PII-Formaten besteht ein Restrisiko. Wird durch kontinuierliche QA-Tests und Nutzerfeedback-System minimiert.

R2: Unbefugter Zugriff auf Pseudonym-Zuordnungen (Risikostufe: MITTEL)

Szenario: Ein Angreifer erlangt Zugriff auf die Datenbank und kann Pseudonym-Zuordnungen lesen.

Bestehende Maßnahmen:

• Zero-Knowledge-Verschlüsselung: Zuordnungen sind mit nutzerspezifischem DEK verschlüsselt
• DEK wird aus Nutzerpasswort via Argon2id abgeleitet und existiert nur im RAM (Redis mit TTL)
• PostgreSQL-Zugriff nur via mTLS (Step-CA, 7-Tage-Zertifikate)
• Datenbank nur über internes Docker-Netzwerk erreichbar (nicht am Internet)
• 8 Security-Layer vor der Datenbank

Restrisiko nach Maßnahmen: SEHR NIEDRIG – Selbst bei DB-Zugriff sind Daten ohne DEK (= ohne Nutzerpasswort) nicht entschlüsselbar.

R3: Manipulation der Audit-Kette (Risikostufe: NIEDRIG)

Bestehende Maßnahmen:

• SHA-256 Hash-Kette mit Verkettung
• Hybride Dual-Signatur (Ed25519 + ML-DSA-65) pro Eintrag
• Write-Time-Verifikation (Signatur wird sofort nach Erzeugung verifiziert)
• Advisory Lock (pg_advisory_xact_lock) verhindert Ketten-Forks
• Chain Monitor prüft alle 5 Minuten die Integrität
• Permanente Blockchain-Verankerung auf Arweave
• Wöchentliche Cross-Verification

Restrisiko nach Maßnahmen: VERNACHLÄSSIGBAR – Eine Manipulation müsste gleichzeitig Ed25519, ML-DSA-65, SHA-256 und die Blockchain überwinden.

R4: Unbefugter Systemzugriff (Risikostufe: MITTEL)

Bestehende Maßnahmen:

• Layer 1: CrowdSec IP-Reputation, UFW Firewall, Fail2Ban (42 Bans)
• Layer 2: Coraza WAF mit OWASP CRS v4.13
• Layer 3: TLS 1.3, mTLS intern, QUIC/HTTP3
• Layer 4: JWT (EdDSA), 2FA/TOTP, Rate Limiting (300 req/min, Login: 5/min/IP), Account-Lockout
• Layer 8: Wazuh HIDS/IDS, Grafana + Loki, Telegram-Alerts
• Admin Abuse Prevention (Key-Revocation, Force-Logout, Login-History, IP-Lookup)

Restrisiko nach Maßnahmen: NIEDRIG

R7: Betreiberzugriff auf Nutzerdaten (Risikostufe: NIEDRIG)

Bestehende Maßnahmen:

• Zero-Knowledge-Architektur: DEK wird aus Nutzerpasswort abgeleitet, Server speichert DEK nie persistent
• AES-256 (Fernet) Verschlüsselung des Audit-Body
• Hash-Kette und Signaturen bleiben im Klartext (verifizierbar ohne Entschlüsselung)
• Betreiber hat technisch keinen Zugang zu entschlüsselten Inhalten

Restrisiko nach Maßnahmen: VERNACHLÄSSIGBAR – Architektonisch ausgeschlossen.

R8: Quantencomputer-Angriff (Risikostufe: MITTEL)

Bestehende Maßnahmen:

• ML-DSA-65 (NIST FIPS 204) als post-quanten-sicheres Signaturverfahren
• Hybride Dual-Signatur (Ed25519 + ML-DSA-65) – beide müssen gebrochen werden
• liboqs 0.15.0 (Open Quantum Safe)
• BSI-konforme Hybrid-Strategie
• Graceful Degradation bei Nichtverfügbarkeit der PQ-Bibliothek

Restrisiko nach Maßnahmen: NIEDRIG – Schutz gegen zukünftige Quantencomputer ist bereits implementiert.

4. Abhilfemaßnahmen und Schutzgarantien (Art. 35 Abs. 7 lit. d DSGVO)

4.1 Technische Maßnahmen (Art. 32 DSGVO)

4.1.1 Verschlüsselung und Pseudonymisierung

4.1.2 Integritätssicherung

4.1.3 Zugriffskontrolle

4.1.4 Verfügbarkeit und Belastbarkeit

4.1.5 Überwachung und Erkennung

4.2 Organisatorische Maßnahmen

4.3 Betroffenenrechte (Art. 12–22 DSGVO)

5. Ergebnis und Gesamtbewertung

5.1 Risikomatrix nach Maßnahmen

5.2 Gesamtergebnis

Das LLM-Proxy-System ist von Grund auf datenschutzfreundlich konzipiert (Privacy by Design, Art. 25 DSGVO). Die identifizierten Risiken werden durch umfangreiche technische und organisatorische Maßnahmen auf ein akzeptables Restrisiko reduziert.

Verbleibendes Hauptrisiko: R1 (PII nicht erkannt) und R10 (KI-Anbieter-Compliance). Diese werden durch kontinuierliches Monitoring, QA-Tests und das BYOK-Prinzip adressiert.

Empfehlung: Das System kann in den Produktivbetrieb gehen. Die folgenden Maßnahmen sollten zeitnah umgesetzt werden:

• AVV-Prüfung mit allen initialen KI-Anbietern abschließen
• Löschkonzept mit konkreten Fristen finalisieren
• Nutzer-Dokumentation zur sicheren Verwendung erstellen
• Prüfen, ob ein Datenschutzbeauftragter bestellt werden muss (bei regelmäßiger, systematischer Verarbeitung)

5.3 Konsultation der Aufsichtsbehörde (Art. 36 DSGVO)

Eine vorherige Konsultation der Aufsichtsbehörde gemäß Art. 36 DSGVO ist nicht erforderlich, da die verbleibenden Risiken durch die implementierten Maßnahmen hinreichend gemindert werden.

6. Dokumentation und Versionierung

7. Unterschrift

Greußen, 14. März 2026

Johanna Bringezu
Verantwortlicher gemäß Art. 4 Nr. 7 DSGVO