Eine KI darf Mandantendaten verarbeiten, ohne sie zu speichern. Das ist nicht nur ein DSGVO-Wunsch, sondern bei Berufsgeheimnisträgern (Anwalt, Arzt, Bestatter, Steuerberater nach §203 StGB) zwingend. Wie geht das praktisch, und wie hält die Aufsichtsbehörde es für Art.-30-konform? Hier der Stack, den wir bei DSGVO-Audit, Anwalts-Research und Numen (Health-Intelligence) einsetzen.
Das Kernproblem
DSGVO Art. 30 verlangt ein Verfahrensverzeichnis aller Verarbeitungstätigkeiten: was wurde wann mit welchen Daten gemacht. Die naive Lösung: Klartext-Logs mit Timestamp + Mandanten-ID + Sachverhalt. Das verstößt aber gegen §203 StGB (Mandantengeheimnis bei Anwalt/Arzt) und gegen DSGVO Art. 5 Abs. 1 c (Datenminimierung).
Die saubere Lösung: Hash-Prüfprotokoll. Der Hash ist nicht personenbezogen (kein Rückbezug ohne Replay-Material möglich), erfüllt aber die Nachvollziehbarkeits-Forderung von Art. 30.
JSONL-Schema, das wir verwenden
Eine Zeile pro Event in customers/<slug>/m103_audit.jsonl:
{
"timestamp": "2026-05-12T14:33:18Z",
"module": "Anwalts-Research-KI",
"endpoint": "/research/handle",
"customer_slug": "kanzlei_demo",
"user_role": "junior_anwalt",
"rechtsgebiet": "Arbeitsrecht",
"konfidenz": 0.91,
"sachverhalt_hash": "sha1:8c2b4a7f1d9e3a5c0b6d2e4f8a9c1b3d5e7f9a2c",
"selbstanzeige_trigger": false,
"pii_detected": false,
"n_urteile_returned": 8,
"council_drops": 2,
"duration_ms": 12450
}
Was diese Zeile beweist:
- Wer: customer_slug + user_role
- Wann: ISO-8601 Timestamp UTC
- Was: module + endpoint + rechtsgebiet + konfidenz
- Womit: sachverhalt_hash (SHA1-Replay-Schlüssel zum Klartext im Customer-Aktensystem)
- Wieviel: n_urteile + council_drops + duration_ms (für SLA-Nachweis)
Was diese Zeile NICHT enthält: Mandanten-Name, Aktenzeichen, Sachverhalts-Volltext, Geburtsdatum, IBAN. Nichts Personenbezogenes.
Warum SHA1 statt SHA256 oder bcrypt
Drei Gründe:
- Replay-Identität, nicht Krypto-Authentifizierung: Hash dient zum "ist der gleiche Sachverhalt wie damals?"-Check. Kollisionsangriffe sind hier irrelevant — kein Angreifer würde versuchen, einen Hash für einen anderen Sachverhalt zu finden.
- Performance: SHA1 ist ~30-40% schneller als SHA256. Bei 10k+ Audit-Events/Tag spart das messbar CPU-Zyklen.
- Hex-Stringlänge: SHA1 = 40 Zeichen, SHA256 = 64 Zeichen. Bei Prüfprotokoll-Volumen rechnet sich das in TB-Storage über Jahre.
Replay-Strategie
Wenn die Aufsichtsbehörde fragt "Was wurde am 12. Mai 14:33 verarbeitet?", funktioniert das so:
- Behörde gibt Timestamp + customer_slug
- Anwalt zieht den Mandanten-Sachverhalt aus seinem eigenen Akten-System (Datev, RA-Micro, BRAK-Akte)
- Anwalt re-hashed den Sachverhalt:
echo -n "$sachverhalt" | sha1sum - Hash matched gegen das Prüfprotokoll → Verarbeitung ist nachgewiesen
- Hash matched NICHT → Datenintegritäts-Problem (oder Sachverhalt wurde editiert)
Wichtig: das Klartext-Material muss im Customer-System dokumentiert bleiben. Sonst geht die Replay-Fähigkeit verloren, aber das ist KEIN DSGVO-Verstoß, sondern eine Customer-eigene Frage nach Aktenführung.
Wie integriert sich das mit Customer-Daten-Löschung
Wenn ein Mandant ein DSGVO-Auskunfts- oder Löschungs-Recht ausübt (Art. 15 oder 17):
- Klartext im Customer-Aktensystem wird gelöscht.
- Hash im Prüfprotokoll bleibt, er ist nicht personenbezogen (kein Personenbezug ohne Klartext-Replay möglich).
- Replay-Fähigkeit ist damit gebrochen, das ist Feature, nicht Bug. Nach Löschung ist der Hash eine harmlose 40-Zeichen-Reihe.
Aufbewahrungs-Fristen pro Branche
→ Tabelle seitlich scrollbar
→ Tabelle seitlich scrollbar
| Branche | Frist Klartext | Frist Hash-Audit (Empfehlung) |
|---|---|---|
| Anwalt (§50 BRAO) | 5 Jahre nach Mandats-Ende | 7 Jahre (HGB-konsistent) |
| Steuerberater (§66 StBerG) | 10 Jahre | 10 Jahre |
| Arzt (§10 BO) | 10 Jahre (Röntgen 30 Jahre) | 10 Jahre |
| Bestatter (BestG-Länder) | 5-10 Jahre je Land | 10 Jahre |
| KMU-Helpdesk (HGB) | 6 Jahre (Geschäftspapiere) | 6 Jahre |
Wo wir das einsetzen
- DSGVO-Audit: kundenübergreifendes Prüfprotokoll mit Hash-Per-Request + Append-Only JSONL
- Anwalts-Research: Sachverhalt-Hash für jeden /research/handle-Call, Token-Hash für juris-API-Calls
- Numen Health-Intelligence: Bloodwork-Hash + Stack-Hash für jede Cross-Analyse
- Multi-Tenant SaaS-KI: Customer-Isolation via Slug-Prefix + Hash-Audit-Trail pro Tenant
Was die Aufsichtsbehörden bisher dazu gesagt haben
Anti-Patterns, die wir vermeiden
- Hash mit Customer-eigenem Salt: Bricht Pseudonymisierung-Definition. Salt muss systemweit konstant sein.
- Hash + Name in einer Zeile: Macht den Hash überflüssig.
- Prüfprotokoll in derselben DB wie Klartext-Daten: Trennung zwischen Audit-Layer + Daten-Layer ist Pseudonymisierung-Voraussetzung.
- Prüfprotokoll ohne Append-Only-Garantie: Wenn der Customer-Admin nachträglich editieren kann, ist die Nachvollziehbarkeit dahin. JSONL + WORM-Disk oder externes Append-Only-Service nutzen.