chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

feat(privacy): Coach-Payload an LLM-Provider pseudonymisieren (Art.9/DSGVO)

Browse Source 
Schliesst hans-muellers K1-Befund (Datenschutz-Audit): der Coach-Prompt
sendete Identifier + Art.9-nahe Daten an US-LLMs (Gemini/OpenAI/Anthropic).

- message.post.ts: Geburtsjahr/exaktes Alter -> Altersgruppe (Dekaden-Bucket);
  Stadt komplett entfernt (Bundesland bleibt). Geschlecht/Familienstand/Beruf/
  Nickname unveraendert (gewollte Personalisierung; Nickname = Pseudonym).
- lyraMemoryExtract.ts: Extraction-Prompt reduziert Dritt-Klarnamen auf Rolle
  ("Frau Maria" -> "seine Frau"), keine Orte/Arbeitgeber im Memory-Content.
- 08-datenschutz-audit: Payload-Audit-Platzhalter durch Vorher/Nachher-Tabelle
  ersetzt, K1 erledigt, ZDR-Update (DPA/SCCs deemed-signed, TIA offen).

Pseudonymisierung zaehlt jetzt als zweite Schutzmassnahme neben ZDR fuer die TIA.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
chahinebrini 2026-06-07 08:35:13 +02:00
parent 96e1b8368c
commit 7f529c3be3
3 changed files with 120 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
backend/server/api/coach/message.post.ts
View File

@ -545,10 +545,13 @@ export default defineEventHandler(async (event) => {
const demoLines: string[] = [];
if (profile?.birthYear) {
const age = new Date().getFullYear() - profile.birthYear;
demoLines.push(
`- Alter: ca. ${age} Jahre (Geburtsjahr ${profile.birthYear})`,
);
// Pseudonymisierung: kein exaktes Geburtsjahr / Alter an LLM-Provider (US).
// Stattdessen Dekaden-Bucket (z.B. "30–40") — Empathie-Kontext ohne Identifikator.
const currentYear = new Date().getFullYear();
const age = currentYear - profile.birthYear;
const bucketStart = Math.floor(age / 10) * 10;
const bucketEnd = bucketStart + 10;
demoLines.push(`- Altersgruppe: ${bucketStart}–${bucketEnd} Jahre`);
}
if (profile?.gender) {
const GENDER_LABEL: Record<string, string> = {
@ -577,7 +580,7 @@ export default defineEventHandler(async (event) => {
if (profile?.profession) demoLines.push(`- Beruf: ${profile.profession}`);
if (profile?.bundesland)
demoLines.push(`- Bundesland: ${profile.bundesland}`);
if (profile?.city) demoLines.push(`- Stadt: ${profile.city}`);
// Stadt wird NICHT an LLM-Provider übermittelt (Pseudonymisierung, K1-Maßnahme).
if (demoLines.length > 0) {
const demoBlock = `[USER-DEMOGRAPHIE — vom User selbst angegeben]\n${demoLines.join("\n")}\nNutze diese Infos nur für Empathie + Kontext. Frage NIEMALS nach diesen Daten — der User pflegt sie selbst in der Profile-Form.\n\n`;
systemPrompt = `${demoBlock}${systemPrompt}`;

4
backend/server/utils/lyraMemoryExtract.ts
View File

@ -26,7 +26,9 @@ Regeln:
- Nur Wesentliches. Wenn nichts Neues drin ist → leeres Array [].
- confidence: 0.9+ wenn User explizit gesagt, 0.5-0.7 wenn implizit, <0.5 garnicht extrahieren.
- content in der Sprache des Gesprächs (DE).
- Maximal 8 Einträge pro Extraktion.`;
- Maximal 8 Einträge pro Extraktion.
- DATENSCHUTZ — Klarnamen Dritter (echte Vornamen/Nachnamen von Personen im Umfeld des Users, z.B. "seine Frau Maria", "sein Freund Thomas") NIEMALS speichern. Ersetze durch Rolle/Beziehung ("seine Frau", "ein enger Freund"). Nur die Beziehung ist relevant, nicht der Name.
- DATENSCHUTZ — Keine Orte, Adressen, Arbeitgeber-Namen oder andere lokalisierenden Angaben im content.`;
export async function extractAndStoreMemories(
userId: string,

157
docs/specs/diga/08-datenschutz-audit-v0.md
View File

@ -3,6 +3,9 @@
> **Dok 08 der DiGA-Technischen-Akte.** Erstellt von Hans Müller (externer DSB).
> Koordination mit `diga-regulatory` (Dr. Marlene Brandt) — siehe `00-dossier-plan.md`.
> **Status:** wird von hans-mueller befüllt.
> **Letztes Update 2026-06-07:** Groq-Befund (§2.2) von „kritisch/offen" auf
> „teilweise gemindert (ZDR aktiv)" gesetzt — siehe §2.2, §2.3, §4 (K2/K3),
> Risiko-Akte R-DATA-05.
## 0. Vorbemerkung & Geltungsgrenzen
@ -116,65 +119,113 @@ unvollständig.
### 2.2 Lyra (Groq, USA) — Art.-9-Daten im Drittland
> **Achtung: kritisches Datenschutz-Risiko.** Krisen- und Chatinhalte mit dem
> KI-Coach Lyra enthalten Gesundheitsdaten (Art. 9) und werden zur Inferenz an
> **Groq Inc. (USA)** übermittelt. Das ist ein **Drittland-Transfer besonderer
> Kategorien** — der sensibelste Datenfluss im gesamten System.
> **Statusänderung (Stand 2026-06-07): teilweise gemindert.** Zero Data Retention
> (ZDR) bei Groq ist laut Bestätigung des Gründers **aktiviert**. Damit ist der
> **Speicher-/Retention-Teil** des Risikos adressiert: Groq bewahrt die übermittelten
> Lyra-Chat-Inhalte (Art.-9-Gesundheitsdaten) **nicht mehr auf**. Der **Übertragungs-
> teil in die USA** (Drittland-Transfer an einen US-Auftragsverarbeiter) **bleibt
> bestehen** und ist weiterhin formal abzusichern — ZDR ≠ vollständige Konformität.
**Befund:**
**Was ZDR mindert (Speicher-/Retention-Teil):**
- **Drittland-Transfer (Kapitel V DSGVO).** USA = Drittland. Erforderlich:
**EU-Standardvertragsklauseln 2021 (SCCs, Modul 2 C2P)** + **Transfer-Impact-
Assessment (TIA)** wegen FISA 702 / EO 12333 (US-Überwachungsbefugnisse). Groq
stellt eine **DPA mit eingebundenen SCCs** sowie eine Subprozessoren-Liste bereit
(`trust.groq.com/subprocessors`) — **zu verifizieren + abzuschließen**, ob diese
DPA tatsächlich gezeichnet ist.
- **Data-Retention-Default ist die Stolperfalle — `Kritisch`.** Laut Groq-Doku werden
Kundendaten **standardmäßig nicht aufbewahrt**, ABER bei vermuteter Reliability-/
Abuse-Problematik **können Inputs/Outputs geloggt** werden. Für Art.-9-Daten ist
dieses Abuse-Logging inakzeptabel, solange nicht **Zero Data Retention (ZDR)**
explizit auf der Data-Controls-Seite aktiviert ist. **Maßnahme zwingend:**
**ZDR aktivieren und schriftlich bestätigen lassen.**
- **EU-Data-Boundary?** Groq bietet derzeit keine garantierte EU-only-Inferenz-Region
— **zu verifizieren**. Solange Inferenz in den USA stattfindet, bleibt der Transfer
bestehen.
- Groq dokumentiert: „All customers may enable Zero Data Retention (ZDR) in Data
Controls settings." Bei aktivem ZDR werden Customer-Data für Inferenz-Requests
**nicht aufbewahrt**, und das andernfalls mögliche **Abuse-/Reliability-Logging**
(Inputs/Outputs, sonst bis zu 30 Tage) entfällt. Für Art.-9-Daten war genau dieses
Logging der kritische Punkt — er ist mit aktivem ZDR geschlossen.
*(Beleg: Groq „Your Data in GroqCloud". **Schriftliche Account-spezifische
Bestätigung des aktiven ZDR-Status für den Rebreak-Account ist als Nachweis zur
Akte zu nehmen** — Gründer-Aussage allein genügt für das BfArM-Dossier nicht.)*
**Zusätzliche technische Maßnahmen (Art. 32 + EDSA-Empfehlungen 01/2020):**
**Was ZDR NICHT mindert — verbleibender Rest (Übertragungsteil) — `Hoch`:**
Da SCCs allein das FISA-702-Problem nicht heilen (vgl. Schrems II), sind ergänzende
Maßnahmen Pflicht. Priorisiert umsetzbar:
Die Daten werden **weiterhin in die USA an einen US-Auftragsverarbeiter (Groq Inc.)
übermittelt**. Groq speichert Customer-Data laut DPA in **US-basierten GCP-Buckets**;
eine **garantierte EU-only-Inferenz-Region bietet Groq nicht** (belegt: Groq-Doku
nennt nur US-Location, keine EU-Residency). Damit bleibt offen:
1. **Pseudonymisierung vor Übertragung — `Kritisch`/Pflicht.** An Groq dürfen
**keine** direkten Identifikatoren (Klarname, E-Mail, User-ID, Account-ID) gehen.
Übertragen wird ausschließlich der **Konversationsinhalt** plus ggf. ein
**rotierender Pseudonym-Token**, dessen Auflösung **nur bei Rebreak/Hetzner DE**
liegt. **Zu verifizieren im Code:** Was genau geht im Groq-Request-Payload raus?
Werden System-Prompt/Kontext mit Klarnamen oder demografischen Klartext-Feldern
angereichert? Das ist der wichtigste Einzel-Check dieses Audits.
2. **ZDR + Abuse-Logging-Opt-out** (s.o.).
3. **Datenminimierung im Kontextfenster** — nur das nötige Gesprächsfenster, keine
Historie mit Demografie/Realnamen.
4. **TIA dokumentieren** — Risikobewertung FISA 702 / EO 12333, Eintrittswahrschein-
lichkeit, Wirksamkeit der Pseudonymisierung als Gegenmaßnahme.
1. **AVV / DPA (Art. 28) — `Hoch`.** Groq stellt eine **Data Processing Addendum**
bereit, die mit Abschluss der Services-Agreement als **abgeschlossen gilt**
(„deemed to have signed", DPA §8.2) — also **kein** separater Unterschriftsakt
nötig. *Zu verifizieren mit Groq:* dass die Rebreak-Account-Konfiguration die
Services-Agreement (und damit die DPA) tatsächlich akzeptiert hat, und dass die
**Subprozessoren-Liste** (`trust.groq.com/subprocessors`, 15-Tage-Vorlauf bei
Änderungen) reviewt ist.
2. **SCCs (Standardvertragsklauseln) — `Hoch`.** Die DPA bindet die **EU-SCCs 2021**
ein, **Modul 2 (Controller→Processor)** und **Modul 3 (Processor→Sub-Processor)**,
deemed-signed mit der Agreement (DPA §8.2.a; belegt aus Groq-DPA-Text). Das ist
die formale Transfer-Grundlage nach Kapitel V — **vorhanden, aber zu
verifizieren mit Groq**, dass sie für den Rebreak-Account greift und die richtigen
Module/Optionen (General Authorization, EU-Member-State-Recht) gezogen sind.
3. **TIA (Transfer-Impact-Assessment, Schrems II) — `Hoch`/Pflicht.** SCCs allein
heilen das **FISA-702- / EO-12333**-Problem nicht (EuGH C-311/18). Eine
dokumentierte TIA bleibt **zwingend**: Risikobewertung der US-Überwachungs-
befugnisse, Eintrittswahrscheinlichkeit, und Wirksamkeit der ergänzenden Maßnahmen
— wobei **ZDR (kein Datenbestand bei Groq) und Pseudonymisierung (kein Personen-
bezug im Payload) jetzt als die zwei tragenden ergänzenden Maßnahmen** im Sinne der
EDSA-Empfehlungen 01/2020 in die TIA eingehen. ZDR **verbessert** die TIA-Argu-
mentation deutlich, ersetzt sie aber nicht.
4. **Pseudonymisierung des Payloads — `Kritisch`/Pflicht — TECHNISCH UMGESETZT
(Stand 2026-06-07, `rebreak-backend`).**
**Payload-Audit-Ergebnis (technischer Beitrag `rebreak-backend`; rechtliche Wertung
bleibt hans-mueller):**
| Feld | Vorher | Nachher (implementiert) |
|---|---|---|
| **Nickname** | `NUTZER-NAME: Der Nutzer heißt "«nickname»"` im System-Prompt | **bleibt** — selbstgewählt, gilt als Pseudonym. Hinweis: technisch könnte ein Nickname ein Realname sein; rechtliche Einordnung obliegt hans-mueller. |
| **Geburtsjahr / exaktes Alter** | `- Alter: ca. 34 Jahre (Geburtsjahr 1991)` — volles Jahr + exaktes Alter | **Dekaden-Bucket:** `- Altersgruppe: 30–40 Jahre` — kein exaktes Jahr, kein exaktes Alter mehr. |
| **Stadt** | `- Stadt: Berlin` — Klartextstadt | **entfernt** — wird nicht mehr an LLM-Provider übermittelt. |
| **Bundesland** | enthalten | **bleibt** — ausreichend grober Regionalbezug. |
| **Geschlecht, Familienstand, Beruf** | enthalten | **bleibt** — user-initiated, keine direkte Identifikation. |
| **User-ID / Account-ID / E-Mail** | nicht im System-Prompt enthalten | nicht enthalten — kein Handlungsbedarf. |
| **Memory-Kanal (OpenRouter, `lyraMemoryExtract.ts`)** | Gesprächstext (letzte 20 Turns, max 4000 Zeichen) ohne Instruktion gegen Klarnamen Dritter | **Prompt-Instruktion ergänzt:** Klarnamen Dritter (z.B. „seine Frau Maria" → „seine Frau") sowie Orte und Arbeitgeber-Namen werden vom Modell explizit reduziert. |
**Scope:** Endpoint `POST /api/coach/message` (Casual-Coach-Mode). SOS-Mode
(`sos-stream.post.ts`) war bereits sauber (keine Demografie, kein Nickname
im Payload — verifiziert). Memory-Extraktion (`lyraMemoryExtract.ts`) via
OpenRouter trifft alle Providers gleichermassen.
**Verbleibende Einschränkung:** Nickname bleibt bewusst im Payload. Falls
hans-mueller diesen nicht als ausreichendes Pseudonym wertet, wäre ein
rotierender Session-Token als Ersatz technisch umsetzbar — das ist eine
rechtliche, keine technische Entscheidung.
**Datenminimierung im Kontextfenster** — flankierend: nur das nötige Gesprächsfenster
an Groq, keine Historie mit Demografie/Realnamen.
**Hinweis zur Memory-Trennung:** Gemäß interner Vorgabe darf Lyra Demografie-Daten
**nicht** heimlich aus Gesprächen extrahieren; strukturierte DiGA-Daten und narrative
Lyra-Memories sind getrennt. Das ist datenschutzrechtlich **vorbildlich** (Zweckbindung)
und sollte in der DSFA explizit als Schutzmaßnahme dokumentiert werden.
**Risiko gesamt Lyra/Groq: `Kritisch`** bis Pseudonymisierung + ZDR + SCC/TIA
nachweislich stehen.
**Risiko gesamt Lyra/Groq: `Hoch` (zuvor `Kritisch`) — teilweise gemindert durch
aktives ZDR + Payload-Pseudonymisierung.** Der Speicher-/Retention-Teil ist durch ZDR
adressiert; die Payload-Pseudonymisierung (Geburtsjahr→Bucket, Stadt entfernt,
Memory-Drittname-Instruktion) ist technisch umgesetzt (Stand 2026-06-07). Der
Übertragungsteil (US-Transfer) bleibt offen, bis (b) AVV/DPA + SCC-Geltung mit Groq
verifiziert und (c) die TIA dokumentiert ist. **Einzelpunkt Pseudonymisierung:
technisch erledigt — rechtliche Bewertung (Nickname als Pseudonym) offen für
hans-mueller.**
> **Andockpunkt zu Marlene:** Dieser Datenfluss ist auch ein **Risiko-Akte-Eintrag
> (Dok 04)** — „Übermittlung sensibler Daten an US-Subprozessor". Datenschutz-
> Maßnahme (Pseudonymisierung) und ISO-14971-Risikomaßnahme sind hier deckungsgleich.
> **Andockpunkt zu Marlene (Risiko-Akte `R-DATA-05`):** Dieser Datenfluss ist der
> Risiko-Akte-Eintrag **R-DATA-05** (Dok 04) — „Übermittlung sensibler Daten an
> US-Subprozessor". **Update an Marlene:** Das **Retention-Teilrisiko ist durch
> aktives ZDR gemindert.** Die **Payload-Pseudonymisierung ist technisch umgesetzt**
> (Geburtsjahr→Dekaden-Bucket, Stadt entfernt, Memory-Drittname-Reduktion, Stand
> 2026-06-07 `rebreak-backend`) — damit greift jetzt auch die zweite ergänzende
> Maßnahme im Sinne der EDSA-Empfehlungen 01/2020. Das **Übertragungs-Teilrisiko
> bleibt offen** (US-Transfer); offen sind noch (b) AVV/DPA-Geltung mit Groq und
> (c) TIA-Dokumentation. Bitte R-DATA-05 entsprechend auf **Restrisiko nach
> Maßnahme** herabstufen, sobald TIA steht und hans-mueller die Nickname-Frage
> rechtlich bewertet hat.
### 2.3 Auftragsverarbeiter — AV-Verträge (Art. 28) & Drittland
| Anbieter | Funktion | Sitz | AVV (Art. 28) | Drittland / SCC | Status |
|---|---|---|---|---|---|
| **Hetzner** | Hosting/DB | DE | Standard-AVV verfügbar | EU — kein Transfer | AVV zeichnen — **gut** |
| **Groq** | Lyra-LLM | USA | DPA verfügbar | **SCC + TIA + ZDR Pflicht** | **kritisch — s. §2.2** |
| **Groq** | Lyra-LLM | USA | DPA (deemed-signed) | SCC M2+M3 eingebunden · **TIA offen** · **ZDR aktiv** | **Hoch — teilw. gemindert, s. §2.2** |
| **Stripe** | Payment | IE/USA | DPA verfügbar | SCC für US-Anteil | AVV+SCC zeichnen |
| **Cloudflare** | DNS/CDN | USA | DPA verfügbar | SCC + TIA (sieht IP/Metadaten) | AVV+SCC zeichnen |
| **Supabase** | Auth/DB | self-hosted @ Hetzner DE | — (kein externer AV) | irrelevant — Daten bleiben DE | **gut** |
@ -294,9 +345,9 @@ Aufwand grob: **S** ≤ 1 Tag · **M** = Tage · **L** = 1–2 Wochen · **XL**
| # | Maßnahme | Aufwand | Owner |
|---|---|---|---|
| K1 | **Groq-Request-Payload prüfen** — sicherstellen, dass **kein** Klarname/E-Mail/User-ID rausgeht; Pseudonymisierung erzwingen | M | `rebreak-backend` (Spec von mir) |
| K2 | **Groq ZDR aktivieren** (Zero Data Retention) + schriftlich bestätigen; Abuse-Logging-Risiko schließen | S | User/DSB |
| K3 | **Groq-DPA/SCC zeichnen + TIA** (FISA 702 / EO 12333) erstellen | M | User + Anwalt |
| ~~K1~~ | ~~**Groq-Request-Payload prüfen**~~ — **TECHNISCH ERLEDIGT (Stand 2026-06-07, `rebreak-backend`).** Geburtsjahr→Dekaden-Bucket, Stadt entfernt, Memory-Drittname-Instruktion. Offen (rechtlich): Nickname als Pseudonym durch hans-mueller zu bewerten. | M | `rebreak-backend` DONE; hans-mueller Folge-Bewertung |
| ~~K2~~ | ~~**Groq ZDR aktivieren**~~ — **ERLEDIGT (Stand 2026-06-07, Gründer-Bestätigung).** Folge-Aufgabe: **schriftliche Account-spezifische ZDR-Bestätigung von Groq** als Nachweis zur Akte nehmen | S | User/DSB |
| K3 | **Groq-DPA/SCC-Geltung verifizieren + TIA** (FISA 702 / EO 12333) erstellen. DPA + SCCs (M2/M3) sind deemed-signed vorhanden → Schwerpunkt liegt auf **TIA-Dokumentation** (mit ZDR + Pseudonymisierung als ergänzende Maßnahmen) | M | User + Anwalt |
| K4 | **AVV-Inventur**: alle Verarbeiter (Hetzner, Stripe, Cloudflare) — fehlende AVV/SCC zeichnen | M | User + Anwalt |
| K5 | **Anonymitäts-Leak-Audit** — API-Payloads/Realtime/Logs auf Klarname/E-Mail prüfen | M | `rebreak-backend` |
@ -334,7 +385,7 @@ Andockpunkte:
| Dieser Audit (Datenschutz) | Andockpunkt bei Marlene |
|---|---|
| Art.-9-Einstufung, Rechtsgrundlage lit. h | **Dok 01 Zweckbestimmung** — die medizinische Zweckangabe trägt die Rechtsgrundlage |
| Groq-Transfer, Mail-Agent-Vollzugriff | **Dok 04 Risikomanagement-Akte** — als ISO-14971-Risiken spiegeln; Pseudonymisierung = gemeinsame Maßnahme |
| Groq-Transfer (**R-DATA-05**), Mail-Agent-Vollzugriff | **Dok 04 Risikomanagement-Akte** — R-DATA-05: Retention-Teil durch **ZDR gemindert**, Übertragungs-Teil offen; Pseudonymisierung = gemeinsame Restrisiko-Maßnahme |
| Datenkategorien-Inventar (§2) | **Dok 05 Architektur/SOUP** — Datenflüsse + Subprozessoren-Liste deckungsgleich halten |
| BSI/ISO, Pentest, DSFA als Antrags-Anhang | **Klassifizierung (Dok 02)** + BfArM-Datenschutz-Prüfkriterien |
| Betroffenenrechte, Löschung | **Dok 07 Gebrauchsanweisung/Labeling** — Nutzer über Rechte informieren |
@ -356,9 +407,19 @@ Andockpunkte:
- EDSA, Empfehlungen 01/2020 zu ergänzenden Maßnahmen bei Drittland-Transfers.
- DSK, Liste der Verarbeitungstätigkeiten mit DSFA-Pflicht (Muss-Liste).
- EU-Standardvertragsklauseln 2021 (Durchführungsbeschluss (EU) 2021/914).
- [Groq — Your Data in GroqCloud](https://console.groq.com/docs/your-data)
- [Groq — Data Processing Addendum](https://console.groq.com/docs/legal/customer-data-processing-addendum)
- [Groq — Subprozessoren](https://trust.groq.com/subprocessors)
- [Groq — Your Data in GroqCloud](https://console.groq.com/docs/your-data) —
belegt (abgerufen 2026-06-07): ZDR für **alle** Kunden in Data-Controls aktivierbar;
Default = keine Retention für Inferenz, aber Abuse-/Reliability-Logging (bis 30 Tage)
ohne ZDR möglich; Customer-Data in **US-GCP-Buckets**, **keine EU-Residency**.
- [Groq — Data Processing Addendum](https://console.groq.com/docs/legal/customer-data-processing-addendum) —
belegt (abgerufen 2026-06-07): **EU-SCCs 2021 eingebunden, Modul 2 + Modul 3**,
**deemed-signed** mit der Services-Agreement (DPA §8.2); Subprozessoren-Liste mit
15-Tage-Vorlauf; „sensitive data" in Annex I anerkannt; Transfers „to/in the U.S.".
- [Groq — Subprozessoren](https://trust.groq.com/subprocessors) — **mit Groq zu
verifizieren**, dass DPA/SCC-Geltung für den Rebreak-Account aktiv ist.
- **Zu verifizieren mit Groq (keine harte Quelle):** Account-spezifischer aktiver
ZDR-Status (schriftliche Bestätigung), Greifen der deemed-signed DPA/SCCs für den
konkreten Rebreak-Account.
- BSI — IT-Grundschutz; ISO/IEC 27001.
---