DSFA für AI-gestützte Entwicklung – was die Aufsicht wirklich sehen will
Die Datenschutz-Folgenabschätzung (Art. 35 GDPR) ist Pflicht bei „high-risk processing“ – und AI-Tools auf personenbezogene Daten qualifizieren fast immer. Was reingehört, wer es schreibt, und welche zwei Punkte die Aufsicht in 90 % der Fälle zurückfragt.
Wann eine DSFA Pflicht ist
Art. 35 GDPR fordert eine Datenschutz-Folgenabschätzung bei „voraussichtlich hohem Risiko“. Drei Auslöser sind besonders relevant für AI-Setups:
- Systematische Bewertung mit automatisierten Entscheidungen – AI-Klassifikatoren auf Kunden-Daten qualifizieren
- Verarbeitung sensibler Datenkategorien – Pharma-Patient-Daten, Finanzdaten in grossem Umfang
- Neue Technologien – Anthropic Claude ist als externe AI-Verarbeitung eindeutig ein neuer Daten-Empfänger
In der Praxis: wenn Sie AI-Tools auf personenbezogene Daten anwenden, machen Sie eine DSFA. Selbst wenn die AI nur anonymisierte Daten sieht – die Pipeline davor verarbeitet PII, und das ist DSFA-relevant.
Die sieben Abschnitte
```mermaid
flowchart TD
S1[1. Verarbeitungs-Beschreibung
was, warum, womit]
S2[2. Notwendigkeit + Verhältnismässigkeit]
S3[3. Datenfluss-Diagramm]
S4[4. Risiko-Analyse pro Datenkategorie]
S5[5. Technische Massnahmen]
S6[6. Organisatorische Massnahmen]
S7[7. Restrisiko + Konsultations-Pflicht]
S1 --> S2 --> S3 --> S4 --> S5 S5 --> S6 --> S7 ```
1. Verarbeitungs-Beschreibung
- Was wird verarbeitet (BillingItems, Customer-Daten, etc.)
- Warum (Bug-Repro, Klassifikation, Reporting)
- Womit (Tools, Anbieter, Standorte)
Häufiger Fehler: zu generisch. „Wir nutzen AI für Bug-Fixing“ reicht nicht. Spezifisch: „Wir nutzen Anthropic Claude API in Hardened AI VDI für Bug-Reproduction auf anonymisiert-aus-PRD-importierten QAS-Daten.“
2. Notwendigkeit und Verhältnismässigkeit
- Warum brauchen Sie gerade dieses Tool?
- Welche Alternativen wurden geprüft (z.B. nur menschliche Bug-Repro)?
- Warum hat AI die Verhältnismässigkeit (Effizienz vs Risiko)?
Häufiger Fehler: Alternativen nicht dokumentiert. Aufsicht will sehen, dass Sie nicht reflexartig zu AI gegriffen haben.
3. Datenfluss-Diagramm
Visualisierung wer welche Daten sieht. Bei BAMVP:
PRD (LIVE) → Anonymizer → QAS (anonymisiert) → Hardened AI VDI → Anthropic API
│ │
└─→ Audit Log Service (PRD-Subaccount, 7 Jahre) ────┘
(Hash + Metadata, kein Klartext)
Wichtig: hier kommt Anthropic als externer Empfänger explizit ins Bild. Auftragsverarbeitungsvertrag (AVV) ist Anhang.
4. Risiko-Analyse pro Datenkategorie
Pro K-Klasse (K1 direkt, K2 quasi, K3 sensibel-business, K4 free-text): - Wie hoch ist das Re-ID-Risiko? - Welche Massnahmen schützen? - Restrisiko: niedrig / mittel / hoch?
Häufiger Fehler: Risiko zu pauschal. Aufsicht will pro Datenkategorie eine eigene Bewertung.
5. Technische Massnahmen
Konkret was eingebaut ist: - HMAC-Pseudonymisierung mit Salt im HANA Secure Store - k-Anonymity-Validator (k≥5) - DLP in Hardened AI VDI - TLS 1.3 + API-Key-Rotation - Audit-Log mit 7-Jahre-Retention
6. Organisatorische Massnahmen
- AI Privacy & Operations Lead als Verantwortliche-Rolle
- 4-Augen für PRD-Slice-Approvals
- DSFA-Update bei jeder Schema-Änderung
- Halbjährlicher Re-ID-Test
7. Restrisiko und Konsultations-Pflicht
Wenn nach allen Massnahmen das Restrisiko noch hoch ist, muss die Aufsicht vor dem Start konsultiert werden (Art. 36 GDPR). In den meisten BTP-AI-Setups ist das Restrisiko nach sauberer Anonymisierung mittel-niedrig – keine Pflicht-Konsultation.
Die zwei Punkte, die in 90% der Fälle zurückgefragt werden
Frage 1 – „Wo genau ist der Salt, und wer hat Zugriff?“
Wenn die DSFA das schwammig formuliert („Salt ist sicher gespeichert“), kommt die Frage zurück. Konkrete Antwort vorbereitet:
- Salt liegt in HANA Secure Store des PRD-Subaccount
- Disaster-Recovery-Backup im Azure Key Vault HSM
- Lese-Zugriff: nur Tech-User BAMVP_ANON_RO zur Pipeline-Laufzeit
- Menschliche Zugriffe: nur AI Privacy & Ops Lead mit 4-Augen-Approval, dokumentiert
- Rotation alle 12 Monate
Frage 2 – „Wenn der Tester Anthropic eine Frage stellt, was geht da raus?“
Die Antwort darf keine Spekulation sein. Konkrete Antwort: - System-Prompt (geprüfte Version aus Prompt-Registry) - User-Message (durch DLP gefiltert, durch redact-bug-snippet.js anonymisiert wenn Slice) - Tool-Results (anonymisierte Daten-Slices, Stack-Traces ohne PII)
Anhang: konkretes Beispiel eines Anthropic-Calls mit dem zugehörigen Audit-Log-Eintrag.
Wer schreibt die DSFA
- Initial-Entwurf: AI Privacy & Operations Lead (kennt die Technik)
- Review: DPO (kennt die Compliance-Sprache)
- Sign-off: CEO oder CTO (Verantwortung extern)
- Externe Prüfung: optional, aber empfohlen vor Go-Live (siehe Wer-Sektion)
Aufwand: 3-5 Personentage Initial-Entwurf, 1-2 Tage Review-Zyklen, 0.5 Tage Sign-off-Vorbereitung. Total ~5-8 Personentage.
Update-Pflicht
DSFA ist nicht „einmal schreiben, fertig“. Update-Auslöser: - Schema-Änderung (neue Daten-Kategorie) - Tool-Änderung (z.B. von Claude auf GPT) - Anbieter-Änderung (neue Sub-Processor) - Re-ID-Test entdeckt Lücke - Sev-1-Vorfall
Pflicht-Update mindestens jährlich.
Wer das einmal sauber aufsetzen will
Ein Workshop (halbtägig) strukturiert die DSFA für Ihren AI-Setup. Output: ausgearbeitete sieben Abschnitte, Datenfluss-Diagramm, Risiko-Matrix, mit Lücken-Liste für Ihre Tech-Massnahmen.
Stand: 2026-06-25
