Data Privacy Architecture für KI-Systeme

Die Frage "Ist unser KI-System DSGVO-konform?" lässt sich nicht mit einer Checkbox beantworten. Sie lässt sich mit einer Architektur beantworten.

Privacy nachträglich in ein KI-System einzubauen funktioniert selten. Die Data Flows sind bereits definiert, die Speicherorte gewählt, die Provider-Verträge unterschrieben. Wer Privacy nicht von Anfang an mitdenkt, baut technische Schulden auf, die später teuer werden.

Data Flow Mapping: Wo fließen Ihre Daten?

Bevor Sie über Maßnahmen nachdenken, brauchen Sie Sichtbarkeit. Für jeden KI-Touchpoint in Ihrem System:

Die kritischen Fragen pro Touchpoint

Das Ziel: Eine dokumentierte Übersicht, die Sie bei der nächsten Audit-Anfrage vorlegen können.

Die 7 Privacy-Patterns

Nicht jedes System braucht alle Patterns. Die Auswahl hängt von Ihrer Datenklassifizierung und Risikobereitschaft ab.

Pattern 1: PII-Minimierung

Prinzip: Nur die Daten verarbeiten, die das LLM wirklich braucht.

# Vorher: Alle verfügbaren Informationen
prompt = f"""
Der Kunde Max Müller ([email protected], Tel: 0171-1234567)
hat am 15.03.2024 Produkt XYZ bestellt (Bestellung #12345).
Er wohnt in der Musterstraße 42, 80331 München.
Was ist der Status seiner Bestellung?
"""

# Nachher: Nur das Nötige
prompt = f"""
Ein Kunde hat am 15.03.2024 Produkt XYZ bestellt (Bestellung #12345).
Was ist der Status dieser Bestellung?
"""

Quick Check:

• Braucht das LLM Namen? → Meist nein
• Braucht es Kontaktdaten? → Fast nie
• Braucht es Adressen? → Selten
• Was ist das absolute Minimum für die Aufgabe?

Aufwand: Gering | Impact: Hoch | Empfehlung: Immer implementieren

Pattern 2: Pseudonymisierung

Prinzip: PII durch Platzhalter ersetzen, Original-Mapping lokal behalten.

Implementierungs-Approach:

1. PII-Detection (Presidio, spaCy NER, oder Custom-Regex)
2. Deterministisches Mapping (gleicher Input → gleicher Platzhalter)
3. Mapping in separater, verschlüsselter Datenbank
4. Restore nach LLM-Response

Code-Skeleton:

class Pseudonymizer:
    def pseudonymize(self, text: str, pii_entities: list) -> str:
        """Ersetzt PII durch Platzhalter, speichert Mapping lokal."""
        for entity in pii_entities:
            pseudonym = f"[{entity.type}_{hash(entity.text)[:8]}]"
            text = text.replace(entity.text, pseudonym)
            self.store_mapping(pseudonym, entity.text)
        return text

    def restore(self, text: str) -> str:
        """Stellt Original-PII aus lokalem Mapping wieder her."""
        for pseudonym, original in self.get_mappings():
            text = text.replace(pseudonym, original)
        return text

Aufwand: Mittel | Impact: Hoch | Empfehlung: Bei sensiblen Daten

Pattern 3: Encryption (At Rest & In Transit)

Minimum-Standard für alle KI-bezogenen Daten:

Aufwand: Gering (meist Infrastruktur-Config) | Impact: Mittel | Empfehlung: Immer

Pattern 4: Data Residency

Prinzip: Daten bleiben in der gewünschten Region – wichtig für DSGVO und Branchenregulierung.

Routing-Logik:

class RegionAwareRouter:
    async def route(self, request, data_classification: str):
        if data_classification == "CONFIDENTIAL":
            return await self.onprem_client.chat(...)  # Bleibt intern
        elif data_classification == "INTERNAL":
            return await self.eu_client.chat(...)      # EU-Cloud OK
        else:
            return await self.cloud_client.chat(...)   # Überall OK

Aufwand: Mittel | Impact: Hoch für Compliance | Empfehlung: Bei personenbezogenen/vertraulichen Daten

Pattern 5: Ephemeral Prompts

Prinzip: Prompts nicht persistent speichern – nur Metadaten für Debugging.

Was loggen:

• Timestamp, User-ID, Model, Latency, Token-Count, Error-Codes

Was NICHT loggen:

• Prompt-Inhalt, Response-Inhalt, PII in jeder Form

async def process(self, prompt: str) -> str:
    response = await llm.complete(prompt)

    # Nur Metadaten loggen
    await log({
        "timestamp": now(),
        "prompt_hash": sha256(prompt),  # Für Debugging, nicht Rekonstruktion
        "prompt_length": len(prompt),
        "user_id": user.id,
        "model": "gpt-4",
        "latency_ms": elapsed
    })

    return response
    # Prompt und Response werden nicht gespeichert

Aufwand: Gering | Impact: Mittel | Empfehlung: Default für Production

Pattern 6: Differential Privacy (für Training)

Wann relevant: Fine-Tuning auf Kundendaten, Custom-Embeddings mit sensiblen Dokumenten.

Prinzip: Noise so hinzufügen, dass aggregierte Patterns gelernt werden, aber einzelne Datenpunkte nicht extrahierbar sind.

Klassisches Training:
Model lernt: "Max Müller kaufte am 15.3. Produkt X"
→ Risiko: Model könnte "Max Müller" reproduzieren

Differential Privacy:
Noise hinzufügen, sodass:
→ "Kunden kaufen Produkt X häufig im März" gelernt wird
→ Einzelne Personen nicht identifizierbar

Tools: TensorFlow Privacy, Opacus (PyTorch), PySyft

Aufwand: Hoch | Impact: Hoch für Training-Szenarien | Empfehlung: Bei Fine-Tuning auf PII

Pattern 7: Federated Learning

Prinzip: Daten bleiben lokal, nur Model-Updates werden geteilt.

Wann sinnvoll:

• Multi-Standort-Unternehmen mit lokalen Datenschutzanforderungen
• Sensible Daten, die nicht zentralisiert werden dürfen
• Branchenspezifische Regulierung (Gesundheit, Finanzen)

Aufwand: Sehr hoch | Impact: Hoch | Empfehlung: Nur bei spezifischen Anforderungen

RAG-Systeme: Die unterschätzten Risiken

RAG (Retrieval-Augmented Generation) hat spezielle Privacy-Herausforderungen, die oft übersehen werden.

Problem 1: Embeddings sind NICHT anonymisiert

Original: "Max Müller arbeitet in der IT-Abteilung"
     ↓
Embedding: [0.23, -0.45, 0.12, ...]
     ↓
Semantisch ähnlich zu: "Müller ist IT-Mitarbeiter"

Implikation: Embeddings enthalten die semantische Information des Originals. Wer Zugriff auf die Vector DB hat, kann Inhalte rekonstruieren.

Mitigation:

• Embeddings wie Original-Daten behandeln (Encryption, Access Control)
• PII vor dem Embedding entfernen
• Chunking so gestalten, dass PII nicht in Chunks landet

Problem 2: Fehlende Access Control

Ein häufiger Fehler: Alle Dokumente werden in eine Vector DB geladen, alle User können alles abfragen.

# Falsch: Keine Filterung
results = vector_db.query(embedding)

# Richtig: Row-Level Security
results = vector_db.query(
    embedding,
    filter={
        "department": {"$in": user.departments},
        "classification": {"$lte": user.clearance_level}
    }
)

Problem 3: Unerwartetes Retrieval

Ein Query über Produkte kann Kundendaten retrieven, wenn die Knowledge Base beides enthält.

Mitigation:

• Strikte Trennung von Datentypen in der Vector DB
• Metadaten-basiertes Filtering
• Output-Screening als letzte Verteidigungslinie

Referenz-Architektur

Pattern-Auswahl nach Datenklassifizierung

Implementation Roadmap

Phase 1: Sichtbarkeit (Woche 1-2)

• Data Flow Mapping für alle KI-Systeme
• Identifikation von PII-Touchpoints
• Dokumentation des Ist-Zustands

Phase 2: Quick Wins (Woche 3-4)

• PII-Minimierung in Prompts
• Encryption At Rest und In Transit (falls nicht vorhanden)
• Ephemeral Prompts statt Full Logging

Phase 3: Strukturelle Maßnahmen (Monat 2-3)

• Pseudonymisierung-Pipeline implementieren
• Data Residency Routing (EU-Cloud oder On-Prem)
• Access Control für RAG-Systeme

Phase 4: Advanced (bei Bedarf)

• Differential Privacy für Fine-Tuning
• Federated Learning für Multi-Standort-Szenarien

Der häufigste Fehler

RAG-Systeme ohne Access Control auf Dokumenten-Level.

Ein einziger Vektor-Query kann sensible Informationen zurückliefern, für die der User keine Berechtigung hat. Implementieren Sie Row-Level-Security von Anfang an – nachträglich ist es deutlich aufwändiger.

Weiterführend

• DSGVO & LLM Compliance – Rechtliche Anforderungen im Detail
• AI Deployment-Strategien – EU-Hosting und On-Prem-Optionen
• Sichere LLM-Integration – Integration-Patterns für Enterprise