Datenflüsse & DSGVO-Technik
bei der KI-Integration.

Viele Entwickler denken Datenschutz als nachträglichen Schritt: Feature fertig, dann Datenschutzbeauftragten fragen. Das ist bei KI-Systemen ein teures Missverständnis. Denn sobald Nutzereingaben in ein Sprachmodell fließen — egal ob lokal oder via API — entscheidest du in diesem Moment, ob personenbezogene Daten verarbeitet werden und wer Zugriff darauf hat. Die DSGVO, konkret Art. 25 (Privacy by Design), verlangt genau das: Datenschutz als technische Entscheidung von Anfang an.

Dieser Artikel richtet sich an Entwickler und technische Rollen, die KI-Komponenten in Produkte oder interne Tools integrieren. Kein Rechtsgutachten — aber eine solide technische Grundlage, auf der eine Rechtsberatung aufbauen kann.

Wo fließen Daten überhaupt hin?

Bevor du irgendetwas technisch absicherst, brauchst du eine ehrliche Antwort auf diese Frage. Die drei häufigsten Architektur-Muster bei KI-Integration unterscheiden sich grundlegend im Datenschutz-Risiko:

Architektur	Datenpfad	DSGVO-Risiko	AVV nötig?
Lokal / On-Premise	Inference auf eigenem Server oder Gerät, kein externer Aufruf	Niedrig — Daten verlassen nicht die eigene Infrastruktur	Nein (kein Drittanbieter)
Cloud-API (EU-Rechenzentrum)	Anfragen an externen KI-Dienst, Antwort zurück, ggf. Logging beim Anbieter	Mittel — Drittverarbeitung, AVV zwingend	Ja, immer
Cloud-API (Drittland)	Anfragen an Dienst außerhalb EU/EWR (z. B. USA ohne EU-Niederlassung)	Hoch — Drittlandtransfer, SCCs oder andere Garantien nötig	Ja + Drittland-Absicherung

Die meisten Teams mischen diese Muster — lokales Embedding für Datenbanksuche, Cloud-API für Inferenz, externer Logging-Dienst. Jeder Übergang zwischen Komponenten ist ein potenzieller Datenpfad, der dokumentiert werden muss.

Das Datenfluss-Diagramm ist Pflicht

Ein Datenfluss-Diagramm (DFD) ist keine nette Ergänzung — es ist die Grundlage für das Verzeichnis der Verarbeitungstätigkeiten (VVT) nach Art. 30 DSGVO. Für jede KI-Komponente solltest du schriftlich festhalten:

• Welche Datenkategorien fließen rein (Freitext, Metadaten, Dateiinhalte)?
• Welche Systeme verarbeiten diese Daten (Modell, Vektordatenbank, Logging-Service)?
• Wo werden Daten gespeichert und wie lange?
• Wer hat Zugriff auf Logs und Kontext-Daten?

Datenminimierung: Was du nicht sendest, kannst du nicht leaken

Art. 5 Abs. 1 lit. c DSGVO schreibt vor, dass nur so viele personenbezogene Daten verarbeitet werden dürfen, wie für den jeweiligen Zweck tatsächlich erforderlich sind. Im KI-Kontext heißt das: Nicht einfach den gesamten Benutzerkontext in den Prompt schieben, weil es bequemer ist.

Konkrete Maßnahmen für die Entwicklung:

• Nur Notwendiges in den Prompt: Enthält eine Nutzeranfrage eine E-Mail-Adresse oder Telefonnummer, die für die KI-Aufgabe nicht gebraucht wird? Herausfiltern, bevor der Prompt gebaut wird.
• Kontext-Fenster nicht unkritisch befüllen: RAG-Systeme, die ganze Dokumente in den Kontext ziehen, schicken oft mehr personenbezogene Daten an das Modell als nötig. Relevanz-Schwelle definieren und testen.
• Session-Daten nicht dauerhaft speichern: Wenn Chat-Verlauf für das Feature nicht zwingend nötig ist, nicht persistieren. Je weniger gespeichert ist, desto kleiner der Angriff- und Compliance-Radius.

Pseudonymisierung in der Praxis

Pseudonymisierung (Art. 4 Nr. 5 DSGVO) bedeutet: Direkte Identifikatoren werden durch ein Pseudonym ersetzt, sodass die Zuordnung zur Person nur noch mit einer separaten Schlüssel-Tabelle möglich ist — die getrennt gespeichert wird. Das ist keine Anonymisierung; die Daten bleiben personenbezogen. Aber der Schutz bei einem Breach ist erheblich besser.

Für eine KI-Pipeline könnte das so aussehen:

# Pseudonymisierungs-Schritt vor dem API-Aufruf
import hashlib, re

def pseudonymize_prompt(text: str, user_id: str) -> tuple[str, str]:
    """
    Ersetzt bekannte Identifikatoren durch Tokens.
    Gibt den pseudonymisierten Text und den Pseudonym-Key zurück.
    """
    pseudo_id = hashlib.sha256(user_id.encode()).hexdigest()[:12]
    # E-Mail-Adressen ersetzen
    text = re.sub(
        r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}',
        '[EMAIL_REDACTED]',
        text
    )
    # Namen aus Kontext-Header entfernen
    text = text.replace(user_id, f'USER_{pseudo_id}')
    return text, pseudo_id

Dieses Beispiel ist vereinfacht — in der Praxis brauchst du eine Named-Entity-Recognition-Komponente oder ein regelbasiertes System, das Eigennamen, IBANs, Adressen und andere Identifikatoren zuverlässig erkennt. Die grundlegende Struktur bleibt aber gleich: Transformer vor dem Modellaufruf, nicht danach.

Wann Pseudonymisierung nicht reicht

Wenn das Modell im Kontext trotzdem genug Information hat, um eine Person zu re-identifizieren — z. B. durch Kombination von Beruf, Wohnort und Geburtsjahr — ist die technische Pseudonymisierung wertlos. Das ist das sogenannte Mosaikeffekt-Risiko. Hier hilft nur eine konsequentere Datenminimierung, keine nachträgliche Verschleierung.

Auftragsverarbeitung (AVV) — was technisch dahintersteckt

Wenn du eine externe KI-API nutzt, verarbeitet ein Dritter personenbezogene Daten in deinem Auftrag. Das macht ihn zum Auftragsverarbeiter im Sinne von Art. 28 DSGVO — und du als Verantwortlicher brauchst einen schriftlichen Auftragsverarbeitungsvertrag (AVV), bevor die erste Anfrage rausgeht.

Technisch musst du sicherstellen, dass der Vertrag auch gelebt wird:

• Training-Opt-out prüfen: Viele KI-Dienste trainieren standardmäßig auf Nutzerdaten. Das ist meistens unzulässig, wenn personenbezogene Daten enthalten sind. Im API-Dashboard oder AVV prüfen, ob Opt-out aktiv ist und wie er sich auf die Datenverarbeitung auswirkt.
• Subprozessoren kennen: Der Dienst nutzt seinerseits Infrastruktur (Cloud-Hosting, Logging-Anbieter). Wer das ist, muss im AVV stehen oder über eine öffentlich zugängliche Liste abrufbar sein.
• Löschfristen vertraglich regeln: Wie lange hält der Anbieter Anfragen, Antworten und Logs vor? Wenn du nach 30 Tagen löschen willst, muss das im AVV stehen und technisch nachweisbar sein.

Technische Schutzmaßnahmen nach Art. 32 DSGVO

Art. 32 DSGVO verlangt dem Stand der Technik entsprechende technische und organisatorische Maßnahmen (TOMs), um ein angemessenes Schutzniveau sicherzustellen. Für KI-Integrationen bedeutet das konkret:

Verschlüsselung

• In Transit: TLS 1.2+ für alle Verbindungen zum Modell-Backend, sowohl intern als auch extern. Selbst im lokalen Netzwerk kein unverschlüsseltes HTTP.
• At Rest: Gespeicherte Prompts, Logs und Vektordatenbank-Inhalte verschlüsseln. AES-256 ist aktuell Stand der Technik.
• Schlüsselmanagement: Verschlüsselung ohne geregeltes Schlüssel-Lifecycle ist wenig wert. Wer kann Schlüssel rotieren? Was passiert bei einem Mitarbeiter-Abgang?

Zugriffssteuerung

• API-Keys nicht im Code: Secrets in Environment-Variablen oder einem Secret Manager (z. B. HashiCorp Vault, AWS Secrets Manager). Keine API-Keys in Git-Repositories.
• Least-Privilege-Prinzip: Der KI-Service-Account braucht nur Zugriff auf die Daten, die er für seine Aufgabe braucht. Kein Vollzugriff auf die gesamte Datenbank.
• Audit-Log für Zugriffe: Wer hat wann mit welchen Daten das Modell aufgerufen? Ohne diesen Log ist eine nachträgliche Überprüfung bei einem Datenschutzvorfall unmöglich.

Logging-Konzept: Wie viel ist zu viel?

Logging ist der klassische Widerspruch: Du brauchst Logs zum Debuggen und zur Nachvollziehbarkeit. Aber jede gespeicherte Nutzeranfrage ist potenziell personenbezogenes Datum mit eigenem Verarbeitungszweck und Löschfrist.

Ein praxistaugliches Logging-Konzept unterscheidet drei Ebenen:

Ebene	Was wird geloggt	Aufbewahrung	Datenschutz-Anforderung
System-Log	Timestamps, HTTP-Status, Latenz, Fehler-Codes	30–90 Tage	Kein Personenbezug — unkritisch
Anwendungs-Log	Session-ID (pseudonymisiert), Modell-Version, Token-Zahl	14–30 Tage	Pseudonymisiert, Löschplan dokumentieren
Debugging-Log	Vollständige Prompt- und Response-Inhalte	Max. 7 Tage, nur wenn aktiv eingeschaltet	Nur Opt-in, separater Verarbeitungszweck, restriktiver Zugriff

Debugging-Logs mit vollem Prompt-Inhalt sollten standardmäßig aus sein. Wenn du sie für eine Fehlersuche aktivierst, dokumentiere wann und lösche sie anschließend aktiv — nicht erst wenn das Retention-Limit läuft.

Löschkonzept automatisieren

Ein Löschkonzept, das nur in einer Excel-Tabelle steht, wird nicht gelebt. Besser: technisch erzwingen.

# Beispiel: automatische Log-Rotation per Cron (Linux/systemd)
# /etc/logrotate.d/ki-service
/var/log/ki-service/debug.log {
    daily
    rotate 7           # max. 7 Tagesdateien (= 7 Tage Retention)
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        systemctl reload ki-service
    endscript
}

# Für Datenbank-Logs: automatischer DELETE-Job
DELETE FROM prompt_logs
WHERE created_at < NOW() - INTERVAL '30 days'
  AND log_level != 'debug';  -- debug-Logs: 7 Tage (separate Query)

Der DELETE-Job muss entweder als Cron-Job oder als scheduled Task im Datenbankserver laufen — und sein Ausführungs-Log sollte selbst überwacht werden. Wenn der Job ausfällt, wächst die Datenbank weiter und das Löschkonzept ist faktisch außer Kraft.

Technische DSFA-Trigger: Wann musst du eine Datenschutz-Folgenabschätzung machen?

Art. 35 DSGVO verlangt eine Datenschutz-Folgenabschätzung (DSFA), wenn die Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen mit sich bringt. Für KI-Integrationen gibt es drei klassische Trigger:

• Systematische Verarbeitung sensibler Daten (Gesundheit, Biometrie, politische Meinung, sexuelle Orientierung) — Art. 9 DSGVO.
• Automatisierte Entscheidungen mit erheblicher Wirkung (Kreditvergabe-KI, Bewerber-Screening) — Art. 22 DSGVO.
• Großmaßstäbliche Verarbeitung — keine exakte Schwelle, aber mehr als ein paar hundert betroffene Personen in einem produktiven System gelten als Trigger in der Aufsichtspraxis.

Die DSFA muss vor dem Go-Live abgeschlossen sein, nicht danach. Sie ist kein Bürokratie-Dokument, sondern ein strukturierter Risikoanalyse-Prozess. Ergebnis: entweder grünes Licht, oder konkrete Maßnahmen, die das Risiko auf ein akzeptables Niveau bringen.

Architektur-Muster: DSGVO-freundliche KI-Pipeline

Die folgende Architektur zeigt einen Ansatz, der die beschriebenen Maßnahmen strukturell umsetzt:

Nutzereingabe
      │
      ▼
[1] Vorverarbeitung / PII-Filter
    ├── Named-Entity-Erkennung
    ├── Pseudonymisierung von Identifikatoren
    └── Datenminimierung (nur relevanter Kontext)
      │
      ▼
[2] Kontext-Assembly (RAG, falls verwendet)
    ├── Nur relevante Chunks (Schwellwert: ≥ 0.75 Similarity)
    └── Kein Volltext-Dump ganzer Dokumente
      │
      ▼
[3] Modell-Aufruf (lokal ODER API mit AVV)
    ├── TLS-verschlüsselte Verbindung
    ├── API-Key via Secret Manager
    └── Nur pseudonymisierter Input
      │
      ▼
[4] Response-Verarbeitung
    ├── De-Pseudonymisierung nur wenn nötig (für Anzeige)
    └── Nie De-Pseudonymisierung in Logs schreiben
      │
      ▼
[5] Logging (strukturiert, separat je Ebene)
    ├── System-Log: kein Personenbezug
    ├── App-Log: pseudonymisierte Session-ID
    └── Debug-Log: nur bei Bedarf, 7-Tage-Rotation

Das ist kein universelles Rezept — aber ein Ausgangspunkt. Für sensible Daten (Gesundheit, Finanzen) verschiebt sich die Risikoeinschätzung, und lokale Modelle ohne externe API-Aufrufe sind dann oft die einzige tragfähige Option.

Checkliste: DSGVO-technischer Mindeststandard für KI-Integrationen

• Datenfluss-Diagramm erstellt und im VVT dokumentiert
• AVV mit jedem externen KI-Dienstleister abgeschlossen
• Training-Opt-out beim Anbieter verifiziert und dokumentiert
• Drittlandtransfer geprüft — SCCs vorhanden falls nötig
• Pseudonymisierung oder Datenminimierung vor Modellaufruf implementiert
• TLS für alle Verbindungen, AES-256 für ruhende Daten
• API-Keys aus Code raus, in Secret Manager
• Logging-Konzept mit drei Ebenen dokumentiert
• Automatische Löschroutinen implementiert und überwacht
• DSFA-Pflicht geprüft (Art. 35 DSGVO)

Quellen

• EUR-Lex: DSGVO (Verordnung EU 2016/679) — Volltext
• Bundesbeauftragter für Datenschutz (BfDI): KI und Datenschutz
• LfDI Baden-Württemberg: Auftragsverarbeitung nach DS-GVO
• caralegal: DSGVO & KI-Governance — Synergien und Pflichten

Häufige Fragen

Brauche ich einen AVV, wenn ich ein lokal betriebenes Modell auf meinem eigenen Server nutze?

Nein. Ein AVV ist nur erforderlich, wenn ein externer Dritter die Daten verarbeitet. Bei einem Modell, das ausschließlich auf deiner eigenen Infrastruktur läuft und keine Daten nach außen sendet, gibt es keinen Auftragsverarbeiter. Die übrigen DSGVO-Pflichten (VVT, TOMs, Löschkonzept) gelten aber weiterhin.

Reicht es, den Nutzern im Datenschutzhinweis zu sagen, dass wir KI nutzen?

Nicht allein. Art. 13/14 DSGVO verlangen Transparenz — du musst Nutzer informieren, welche KI-Dienste eingesetzt werden und zu welchem Zweck. Das ist notwendig, aber nicht hinreichend. Die technischen Maßnahmen (AVV, Pseudonymisierung, Löschkonzepte) müssen zusätzlich umgesetzt sein.

Ist anonymisierte Verarbeitung DSGVO-frei?

Echte Anonymisierung — also irreversibles Entfernen aller Re-Identifizierungsmerkmale — fällt tatsächlich nicht mehr unter die DSGVO. Aber: Echte Anonymisierung ist technisch viel schwerer zu erreichen als gedacht, besonders bei Freitext. Pseudonymisierung ist kein Freifahrtschein. Im Zweifel davon ausgehen, dass Personenbezug vorliegt.

Wie lang dürfen Prompt-Logs gespeichert werden?

Es gibt keine gesetzlich festgeschriebene Zahl. Das Speicherdatum muss sich aus dem Verarbeitungszweck ergeben. Wenn der Zweck "Debugging" ist, braucht man die Daten nicht länger als wenige Tage. Je kürzer, desto defensiver — und desto weniger Risiko bei einem Datenschutzvorfall. Typische Praxis: System-Logs 30–90 Tage, Debug-Logs 7 Tage oder weniger.

Müssen wir eine DSFA machen, wenn wir nur intern KI nutzen (keine öffentlichen Nutzer)?

Interne Nutzung schützt nicht vor einer DSFA-Pflicht. Auch Mitarbeiterdaten sind personenbezogene Daten. Wenn die KI etwa Kommunikation analysiert, Leistungsdaten auswertet oder Entscheidungen über Beschäftigte unterstützt, ist eine DSFA typischerweise Pflicht.