# Rebreak — Privacy-Policy User-Notes (DSB-Begleitdokument) **Stand:** 2026-05-09 **Verfasser:** Hans Müller (externer DSB i.V.) **Adressat:** Chahine Brini (Inhaber Rebreak / künftig Raynis GmbH) **Kontext:** Begleitnotiz zur veröffentlichten Datenschutzerklärung v1 vom 09.05.2026 --- ## ACHTUNG — HIGH-PRIO Flag > **User wünscht ausdrücklich KEIN separates Consent-UI** für die Stufe-1-Übertragung > von Lyra-Chat-Inhalten an Groq/Anthropic. Die Transparenz wird ausschließlich über > § 11 Abs. 2–3 der Datenschutzerklärung sowie die übergeordnete Art. 9 Abs. 2 lit. a- > Einwilligung beim Lyra-Onboarding hergestellt. > > **DSB-Bewertung:** Vertretbar bei Stufe 1, da kein Klarname/keine E-Mail/keine > Account-ID übermittelt wird. Voraussetzung: das Lyra-Onboarding muss eine echte, > granulare, vorab-eingeholte Einwilligung sein (nicht im AGB-Sammelhaken). Sobald > identifizierende Inhalte im Chat stehen, ist Stufe 2 Pflicht. **Ziel-Datum für > Stufe 2: Q3 2026 (siehe Migrations-Plan unten).** --- ## 1. TODO — DPA / AVV-Status der 12 Sub-Auftragsverarbeiter | # | Anbieter | Sitz | DPA-Status | TIA | Action | |---|---|---|---|---|---| | 1 | Hetzner Online GmbH | DE (EU) | TODO — Standard-AVV vorbereitet | n/a | Bei Hetzner: Anhang 4 + 5 ausfüllen, gegenzeichnen lassen | | 2 | Stripe Payments Europe Ltd. | IE (EU) → Stripe Inc. (USA) | TODO — Stripe-DPA online akzeptieren (Dashboard) | TODO leichtgewichtig | https://stripe.com/legal/dpa | | 3 | Groq, Inc. | USA | OFFEN — auf Groq-DPA warten / via Sales anfragen | TODO PFLICHT | Hoch-Prio: Groq Sales kontaktieren falls kein Self-Service DPA | | 4 | Anthropic PBC | USA | TODO — Anthropic Commercial-Terms + DPA-Addendum | TODO PFLICHT | https://www.anthropic.com/legal/commercial-terms | | 5 | OpenRouter, Inc. | USA | OFFEN — DPA-Verfügbarkeit unklar, ggf. nicht produktiv nutzen | TODO PFLICHT | Falls keine SCCs verfügbar: Provider rauswerfen | | 6 | Cartesia, Inc. | USA | OFFEN — DPA anfordern | TODO PFLICHT | Falls TTS optional: erst aktivieren, wenn DPA vorliegt | | 7 | ElevenLabs Inc. | USA | TODO — ElevenLabs Enterprise-DPA | TODO PFLICHT | https://elevenlabs.io/dpa | | 8 | Deepgram, Inc. | USA | TODO — Deepgram-DPA via Account-Manager | TODO PFLICHT | Falls STT optional: erst aktivieren, wenn DPA vorliegt | | 9 | Cloudflare, Inc. | USA (EU-Edge) | TODO — Cloudflare-DPA online | leichtgewichtig | https://www.cloudflare.com/cloudflare-customer-dpa/ | | 10 | Apple Inc. (APNs) | USA | abgedeckt durch Apple Developer Program License Agreement | leichtgewichtig | Existierender ADP-Vertrag enthält DPA-Anhang | | 11 | Google LLC (FCM) | USA | TODO — Firebase-DPA via Console | leichtgewichtig | https://firebase.google.com/terms/data-processing-terms | | 12 | Infisical Inc. | USA | TODO — DPA falls verfügbar; ohne Endnutzer-PII niedrige Prio | n/a | Niedrige Prio (nur tech-Secrets, keine Endnutzer-Daten) | **Zusammenfassung:** 0 von 12 DPAs aktuell formal abgeschlossen. Empfehlung: Hetzner + Stripe + Anthropic + Groq + Cloudflare + Firebase als Top-6 priorisieren (decken die materiellen Drittland-Übertragungen ab). Realistisches Zeitfenster: 4–6 Wochen. --- ## 2. Anwalt-Review-Checkliste — 3 kritische Punkte > **Ich (DSB) bin kein Rechtsanwalt.** Folgende Passagen sind vor produktiver > Veröffentlichung der Policy zwingend durch eine im IT-/Datenschutzrecht > spezialisierte Kanzlei zu prüfen. ### 2.1 Pro-Trial als Gegenleistung für demographische Daten — Risk: HOCH **Stelle:** § 5 Abs. 4 Datenschutzerklärung („Pro-Trial-Reward") **Norm:** Art. 7 Abs. 4 DSGVO (Kopplungsverbot), EDSA-Leitlinien 05/2020 **Risiko:** Aufsichtsbehörden bewerten „Vorteil gegen Datenpreisgabe" zunehmend restriktiv. Argumentation „Pro-Features gehen über Kernleistung hinaus" ist tragfähig, aber nicht risikolos. **Anwaltsfrage:** Reicht die transparente Darstellung + jederzeitige Widerrufsmöglichkeit + keine-Kopplung-an-Kernfunktion-Klausel zur Rechtfertigung? Empfehlung: alternative Formulierungen (z. B. „Anerkennung" statt „Belohnung"), ggf. Ergänzung um pseudonyme Erhebungs-Variante als Default. ### 2.2 LLM-Übertragung Stufe 1 ohne separates Consent-UI — Risk: MITTEL **Stelle:** § 11 Abs. 2–3 **Norm:** Art. 9 Abs. 2 lit. a DSGVO, Erwägungsgrund 32 (Granularität der Einwilligung), Art. 12 DSGVO (Verständlichkeit) **Risiko:** Aufsichtsbehörden könnten argumentieren, dass die spezifische Drittland-Übertragung von Gesundheitsdaten an US-LLM-Anbieter eine eigene, granulare Einwilligung erfordert. **Anwaltsfrage:** Reicht die übergeordnete Lyra-Onboarding-Einwilligung + transparente Darstellung in der Datenschutzerklärung aus? Falls nein: Mindest-Anforderung an UI-Hinweis (z. B. einmalige In-Chat-Notiz „Lyra-Antworten werden via US-Anbieter generiert", ohne Klick-Block) festlegen. **User-Position:** kein separates Consent-UI gewünscht — Anwalt soll konkret ja/nein dazu sagen. ### 2.3 Übergangsklausel Einzelunternehmer → Raynis GmbH — Risk: MITTEL **Stelle:** § 1 Abs. 2 **Norm:** Art. 7 DSGVO (Einwilligung gegenüber konkretem Verantwortlichen), § 25 UmwG / Asset-Deal-Mechanik, Erwägungsgrund 42 DSGVO **Risiko:** Bestehende Einwilligungen wurden gegenüber „Chahine Brini, einzelkaufmännisch" erteilt. Ein einseitiger „Geht-auf-die-GmbH-über"-Hinweis kann nach Aufsichtsbehörden- Lesart unzureichend sein — insbesondere bei Art. 9-Daten. **Anwaltsfrage:** Reicht eine vorab-Information per E-Mail + In-App-Notice zur Übertragung der Einwilligung auf die GmbH, oder muss eine erneute aktive Bestätigung („Re-Consent") eingeholt werden? Gilt unterschiedliche Behandlung für Art. 6 vs. Art. 9 Daten? Wir empfehlen, als Default einen Re-Consent-Flow vorzubereiten und ggf. nicht zu nutzen, falls Anwalt Entwarnung gibt. --- ## 3. Stufe-2-Migrations-Plan: Lyra-Pseudonymisierung (Q3 2026) ### Ziel Pre-Processing-Layer im backend zwischen `coach/sos-stream`-Endpoint und LLM-Provider, der personenbezogene Entitäten (Namen, Orte, E-Mails, Telefonnummern, IBANs, Verein-/Firmennamen) maskiert, BEVOR der Prompt das Backend verlässt. ### Technische Schritte (high-level Spec, Detail-Spec geht an `rebreak-backend`) 1. **Library-Auswahl (KW 27–28 / Juli 2026):** - Kandidaten: `@microsoft/presidio-analyzer` (Python, via Sidecar), `compromise` (JS, lightweight), self-hosted spaCy-Service mit dt. Modell. - Trade-off: Latenz vs. Recall. Ziel: < 80 ms p95-Overhead pro Nachricht. 2. **Maskierungs-Mapping (KW 28):** - Pro Conversation eine ephemere ID-Tabelle (memory-only, 30 min TTL). - Maskierungen: `[PERSON_1]`, `[ORT_1]`, `[EMAIL]`, `[PHONE]`. - Re-Substitution beim Streaming-Output: vor dem Senden an Client zurückübersetzen (User soll seine eigenen Namen wieder sehen). 3. **Backend-Hook (KW 29):** - Neuer Service `backend/server/services/pii-mask.ts` mit zwei Funktionen: `maskBeforeLLM(prompt, conversationId)` und `unmaskAfterLLM(stream, conversationId)`. - Integration in `backend/server/api/coach/sos-stream.get.ts`. 4. **Telemetrie + Eval (KW 30–31):** - Anonymisierte Metriken: Anzahl Maskierungen pro Nachricht, Latenz, False-Positive- Rate (manuelle Stichprobe von 200 Konversationen). - DSFA-Update mit Stufe-2-Beschreibung. 5. **Privacy-Policy-Update (KW 32):** - § 11 Abs. 2 in Stufe-1- und Stufe-2-Beschreibung umstellen. - Versionierungs-Hinweis nach § 16. ### Voraussetzungen / Blocker - DPAs aller LLM-Anbieter müssen vorher unterschrieben sein (siehe Punkt 1). - DSFA-Update muss parallel laufen (Hans Müller). - Backend-Sprint mit ca. 8–12 Personentagen Aufwand schätzbar. --- ## 4. Backyard-Migration-Empfehlung — Marketing-Site / Privacy-Page ### Status quo - `datenschutz.vue` und (neu) `privacy-policy.vue` liegen aktuell im trucko-monorepo unter `apps/rebreak/app/pages/`. - Deployment der Marketing-Site läuft separat (nicht über Hetzner-Backend-Pipeline). ### Empfehlung an `rebreak-strategist` + `backyard` Die öffentlich kommunizierte Datenschutzerklärung sollte mittelfristig im **rebreak-monorepo** leben und über die etablierte Hetzner-Pipeline deployt werden. Begründung: 1. **Versionskontrolle + Audit-Trail** — bei einer DiGA-Anwendung ist die Historie der Datenschutzerklärung als Compliance-Nachweis relevant. Liegt sie im Hauptrepo, ist sie Teil derselben CI/CD-Logik und Backups wie der Backend-Code. 2. **Stand-Konsistenz** — derzeitige Trennung führt zu Stand-Drift (Marketing-Site: 01.05.; Backend-Realität: 09.05.). Single-Source-of-Truth-Prinzip. 3. **Hetzner-Hosting** — Datenresidenz EU/DE-konsistent ohne Cloudflare-Pages-Drittland- Risiko (sofern Marketing-Site aktuell dort läuft). **Action:** Backyard-Agent erstellt Migrations-Plan (geschätzt 2 Sprint-Punkte). Bis dahin pflegen wir die Datei in trucko, mit Cross-Reference im rebreak-monorepo (`docs/internal/PRIVACY_POLICY_USER_NOTES.md` ← du liest sie gerade). --- ## 5. Risk-Summary (Snapshot 09.05.2026) | Bereich | Risk-Level | Begründung | Mitigation | |---|---|---|---| | Drittland-Transfer Lyra (Groq/Anthropic) | KRITISCH bis DPAs vorliegen, danach MITTEL | Art. 9-Daten in USA, FISA 702 Risiko | DPAs + TIA + Stufe-2-Pseudo Q3 2026 | | Pro-Trial-Kopplung | HOCH | Art. 7 Abs. 4 DSGVO Auslegungs-Risiko | Anwalt-Review + transparente Darstellung | | Re-Consent bei Raynis-GmbH-Übergang | MITTEL | Einwilligungs-Adressat ändert sich | Re-Consent-Flow vorbereiten | | Demographische Daten | NIEDRIG | Streng user-initiated, klare Trennung von Lyra-Memories | Profile-Form-Validierung | | Mail-Schutz-Modul | MITTEL bei Aktivierung | Tiefer Eingriff in Mailbox eines Suchterkrankten | Echte opt-in, granulare Einwilligung | | Cookie/Tracking | NIEDRIG | Keine Drittanbieter-Tracker im Einsatz | Keine Action | | Push-Notifications | NIEDRIG–MITTEL | APNs/FCM = USA-Transfer + Inhalt kann Gesundheitsbezug haben | Inhalt der Push-Texte minimieren („Du hast eine Erinnerung" statt „Streak gefährdet") | | Drittland Anbieter ohne DPA | KRITISCH bis geklärt | OpenRouter, Cartesia, Deepgram unklar | Falls kein DPA: Anbieter rauswerfen | --- ## 6. Nächste Schritte (priorisiert) 1. **Diese Woche:** Hetzner-AVV + Stripe-DPA + Cloudflare-DPA + Firebase-DPA online abschließen (alle Self-Service, < 2h Aufwand zusammen). 2. **KW 20 (12.–18.05.):** Anthropic Commercial-Terms / Groq DPA-Anfrage absetzen. 3. **KW 20:** Anwalt-Termin zu den 3 Punkten in Sektion 2 vereinbaren. 4. **KW 21:** OpenRouter / Cartesia / Deepgram-Status klären → ggf. aus Verarbeitungs- verzeichnis und § 6-Tabelle streichen, bis DPA vorliegt. 5. **KW 22–23:** Verarbeitungsverzeichnis (Art. 30 DSGVO) als separates Dokument erstellen (Vorlage GDD / LfD Niedersachsen verwenden). 6. **KW 24–28:** DSFA gemäß Art. 35 DSGVO finalisieren. 7. **Q3 2026:** Stufe-2-Pseudonymisierung implementieren. --- **Bei Rückfragen:** datenschutz@rebreak.org · Betreff „DSB-Notes v1"