# Risikomanagement-Akte (Erstliste) — Rebreak · v0 (Entwurf)

> **Dok 04 der DiGA-Technischen-Akte.** Norm-Bezug: **ISO 14971** (Anwendung des
> Risikomanagements auf Medizinprodukte), MDR Anh. I GSPR §§ 3–9, §17 (Software).
> Erstellt von Dr. Marlene Brandt (`diga-regulatory`). **Drafting / Erstliste** —
> die reale Risiko-**Bewertung und -Akzeptanz** ist `[Gründer-Entscheidung]` +
> `[Profi-Validierung]`.
>
> **Ehrliche Grenze:** Diese Liste **identifiziert und strukturiert** Gefährdungen
> aus dem bestehenden Produkt und schlägt Maßnahmen vor. Sie ist **kein** abgenommener
> Risikomanagement-Bericht. Schweregrad-/Wahrscheinlichkeits-Einstufung und die
> Entscheidung „Restrisiko akzeptabel" trifft der Hersteller (Gründer) gemeinsam mit
> einem Risikomanagement-/Regulatory-Profi und – wo medizinisch – mit der klinischen
> Seite (Uni Bremen, Dok 06).

---

## 1. Methodik & Bewertungsskalen

**Risiko = Schweregrad × Wahrscheinlichkeit** (ISO 14971). Gefährdung → Gefährdungs-
situation → mögliche Schädigung. Maßnahmen folgen der **Risikobeherrschungs-Reihenfolge**
(ISO 14971 §7.1): (1) inhärent sicheres Design, (2) Schutzmaßnahmen im Produkt,
(3) Informationen zur Sicherheit (Labeling/Gebrauchsanweisung Dok 07).

**Schweregrad (S):**

| Stufe | Bedeutung |
|---|---|
| S1 vernachlässigbar | kurzzeitiges Unbehagen, kein gesundheitlicher Schaden |
| S2 marginal | vorübergehende, reversible Beeinträchtigung |
| S3 kritisch | ernsthafte Schädigung — z.B. finanzieller Ruin durch Rückfall, schwere psychische Belastung |
| S4 katastrophal | dauerhafte schwere Schädigung / Lebensgefahr (z.B. verpasste Suizidalität) |

**Wahrscheinlichkeit (W):** W1 unwahrscheinlich · W2 selten · W3 gelegentlich ·
W4 wahrscheinlich.

> `[Profi-Validierung]` Die konkreten S-/W-Werte unten sind **erste Hypothesen** zur
> Priorisierung. Sie sind in einer formalen FMEA/Risikoanalyse mit dem Profi zu
> verifizieren — insbesondere die Wahrscheinlichkeiten, für die belastbare Daten erst
> aus Nutzung/Studie (Dok 06) kommen.

**Besonderheit Suchterkrankung (Kontext):** Das Indikationsgebiet (Glücksspielstörung,
ICD-10 F63.0) ist eng mit **psychischer Krise und Suizidalität** assoziiert. Das hebt
den Schweregrad mehrerer Software-Fehlfunktionen auf S3–S4 an — anders als bei einer
typischen Wellness-App. Diese Einordnung ist der rote Faden dieser Akte.

---

## 2. Risikotabelle

Legende Spalten: **ID** · Gefährdung · Gefährdungssituation → **mögliche Schädigung** ·
**S** · **W** · **Maßnahme(n)** · **REQ-Bezug** (Dok 03) · **Restrisiko/Notiz**.

### 2.1 Lyra-Fehlverhalten / verpasste Krise (höchste Priorität)

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-LYRA-01** | Lyra **erkennt eine akute Krise / Suizidalität nicht** und behandelt sie als normalen Spielimpuls → verpasste Eskalation, im Extremfall Selbstgefährdung. | **S4** | W2 | (Design) Statische, LLM-unabhängige Krisen-Hilfe-Seite mit Hotlines + Notruf 112 (REQ-LYRA-004); System-Prompt-Regel „bei ernsthaften Krisen IMMER auf Hilfe verweisen" (REQ-LYRA-003). **Implementiert 2026-06-07:** deterministischer Krisen-/Suizid-Keyword-Pre-Filter (`backend/server/utils/crisis-filter.ts`) läuft vor dem LLM in `sos-session.post.ts`; Krisen-Chips werden als `crisis_chips`-Event vor LLM-Antwort in `sos-stream.get.ts` gesendet. LLM-Timeout/Leer-Fallback implementiert (kein leerer Screen möglich). Unit-Tests in `backend/tests/crisis/crisis-filter.test.ts` (DE/EN, crisis.json + harmless.json). LLM-Eval-Suite existiert (`tests/eval/lyra-eval.test.ts`). | LYRA-001/003/004 | **MITTEL** (reduziert) — deterministischer Pre-Filter + LLM-unabhängiger Fallback implementiert. Restrisiko: semantisch vage Krisen-Aussagen ohne explizite Schlüsselwörter entgehen dem Filter (LLM-Recall bleibt verantwortlich). Klinische Validierung der Pattern-Liste + `lyra-persona`-Review der Fallback-Texte offen. `[Profi-Validierung]` + klinisch. |
| **R-LYRA-02** | Lyra wird als therapeutische Instanz **missverstanden** (User hält KI für Behandler) → unterlassene Inanspruchnahme echter Hilfe, falsches Vertrauen. | S3 | W3 | Prompt-Regel „Du bist KEIN Therapeut/Arzt" (REQ-LYRA-002); Labeling „kein Therapieersatz" (Dok 01 §6, Dok 07). | LYRA-002 | Mittel — verbal abgesichert, nicht erzwungen. Verifikation offen. |
| **R-LYRA-03** | Hotline-/Notruf-Verweis **fehlt oder ist landesfalsch** (Sprache/Region) → User in Krise ohne Anlaufstelle. | S4 | W1 | Statische Krisen-Seite mit DE-Hotlines (REQ-LYRA-004); sprachabhängige Krisen-Verweise (REQ-NFR-005). | LYRA-003/004 | Mittel — nur DE-Hotlines statisch hinterlegt; AT/CH nur im Prompt. `[Gründer-Entscheidung]` Länder-Abdeckung. |
| **R-LYRA-04** | **LLM-/Backend-Ausfall** im SOS-Moment → User im akuten Druck erhält keine Begleitung (stummer Hänger). | S3 | W2 | Definierter Fehlerpfad (502/503) + Frontend-Fallback `/coach/message` (REQ-LYRA-005); statische Hilfe-Seite + Atemübung funktionieren offline (REQ-SOS-001/002, REQ-LYRA-004). | LYRA-005, SOS-001 | Mittel — degradierter Pfad existiert; Verifikation der Fallback-Kette offen. |
| **R-LYRA-05** | Lyra bringt im Krisenmoment **Sales-/Pricing-/Setup-Inhalte** → Vertrauensbruch, Ablenkung von der Krise. | S2 | W2 | SOS-MODE-LOCK im System-Prompt (REQ-LYRA-008). | LYRA-008 | Niedrig — Prompt-gesteuert; LLM-Adhärenz nicht garantiert. |
| **R-LYRA-06** | Lyra gibt **schädlichen/falschen Rat** (z.B. „ein letztes Spiel ist ok", Verharmlosung) → Rückfall-Begünstigung. | S3 | W2 | CBT-Framing + Anti-Glücksspiel-Haltung im Prompt; **erforderlich:** Golden-Prompt-Eval gegen Fehlverhalten (Dok 05b §1.4). | LYRA-001 | Mittel-Hoch — ohne Eval nicht messbar. An R-LYRA-01 gekoppelt. |

### 2.2 Falsche Sicherheit (User verlässt sich auf lückenhaften Schutz)

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-FALSE-01** | User glaubt vollständig geschützt zu sein, aber Schicht 1 ist (z.B. nach OS-Kill) **inaktiv** → ungeschützter Zugriff auf Glücksspiel, Rückfall. | S3 | W3 | Zwei-Schicht-Architektur als Auffangnetz (REQ-PROT-004); Self-Healing (REQ-PROT-009); Bypass-Phase-Signal (REQ-PROT-010); ehrliche UI-Statusanzeige. | PROT-004/009/010 | Mittel — Auffangnetz nur iOS, ≤50 Domains. Statusanzeige-Korrektheit verifizieren (Dok 05b §2.2). |
| **R-FALSE-02** | Schicht-2-Liste **wechselt nicht** beim Auslandsaufenthalt → lokal beliebte Glücksspielseiten ungeblockt. | S3 | W2 | MCC-basierter Auto-Switch (REQ-PROT-005). | PROT-005 | Mittel — Country-Detection-Zuverlässigkeit ungetestet. |
| **R-FALSE-03** | Backend nicht erreichbar → Schutz-/Cooldown-Status falsch interpretiert → Schutz fälschlich als „aus" oder Bypass unentdeckt. | S3 | W2 | Sicheres Degradieren: Schutz bleibt lokal aktiv, konservativ „kein Cooldown" (REQ-NFR-004); Self-Heal bei Foreground (REQ-PROT-009). | NFR-004, PROT-009 | Niedrig-Mittel — defensiv kodiert. |
| **R-FALSE-04** | User wähnt eine Trigger-Seite geschützt, hat sie aber nicht als Custom-Domain hinzugefügt / Slot voll → ungeblockt. | S2 | W3 | Klare Slot-/Limit-Kommunikation; Vorschlag-an-globale-Liste (REQ-PROT-011); Labeling „Schutz erschwert, garantiert nicht vollständig" (Dok 01 §7). | PROT-011 | Niedrig — bewusst kommuniziert. |
| **R-FALSE-05** | Frisch hinzugefügte Domain greift **erst nach Sync/DNS-Cache-Ablauf** → kurzes Schutzfenster offen, User erwartet Sofort-Schutz. | S2 | W3 | Nutzer-Hinweis auf Sync-Verzögerung (REQ-PROT-013). | PROT-013 | Niedrig — Lag systembedingt (MEMORY: blocklist/DNS-Cache-Lag). |
| **R-FALSE-06** | Streak-Anzeige „X spielfreie Tage" suggeriert Erfolg, obwohl Spiel über Bargeld/Fremdgerät unerfasst stattfand → falsches Sicherheitsgefühl, Verzerrung der Selbsteinschätzung. | S2 | W3 | Ehrliche Rahmung im Labeling (Dok 07): Tracking basiert auf App-Signalen, kein lückenloser Nachweis. | STREAK-001 | Niedrig-Mittel — Labeling-abhängig. `[Gründer-Entscheidung]` Wording. |

### 2.3 Schutz-Umgehung (Bypass im Impulsmoment)

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-BYP-01** | User deaktiviert im akuten Impuls den Schutz (App löschen, VPN aus, Zweitgerät) → sofortiger Rückfall. | S3 | W3 | Cooldown (24 h/6 h) hält Schutz im Impuls aktiv (REQ-PROT-006); Tamper-Lock Android (REQ-PROT-003); RebreakMagic-Lock (REQ-MAGIC-001/002); Geräte-Limit + Lock bei Wechsel (REQ-AUTH-002). | PROT-006, MAGIC-001/002, AUTH-002 | Mittel — kein Schutz ist 100% (Bargeld, fremde Geräte) — bewusste Grenze (Dok 01 §7). |
| **R-BYP-02** | Uhr-Manipulation am Gerät umgeht Cooldown → vorzeitige Deaktivierung. | S3 | W2 | Server-time-authoritativer Cooldown (REQ-PROT-007). | PROT-007 | Niedrig — serverseitig abgesichert. |
| **R-BYP-03** | **Gegenteiliges Risiko:** legitimer Ausstieg nach Cooldown **scheitert** (Device-Admin/Tamper-Lock blockt Deinstallation) → User „eingesperrt", Autonomie-/Vertrauensverlust, ggf. Belastung. | **S3** | W2 | Disarm-Reihenfolge: Tamper-Lock + Device-Admin **vor** `disable()` (REQ-PROT-008); 24 h-Release abbrechbar (REQ-MAGIC-002). | PROT-008, MAGIC-004 | Mittel — **ethisch + haftungsrelevant**: Selbstbindung darf nicht zur Falle werden. `[Profi-Validierung]`. Labeling Dok 07. |
| **R-BYP-04** | User will Custom-Domain im Klar-Moment entfernen, kann es designbedingt nicht → Frustration, ggf. Vertrauensverlust. | S2 | W2 | Bewusstes Anti-Impuls-Design (REQ-PROT-012); Team-Removal-Pfad; sanfte Lyra-Erklärung. | PROT-012 | Niedrig — gewollt; Support-Pfad nötig. |

### 2.4 Datenschutz / Art-9-Datenleck (Spiegelung zu Dok 08 — Owner: Hans)

> Diese Zeilen spiegeln die datenschutzrechtlichen Befunde aus **Dok 08 (Hans Müller)**
> in die ISO-14971-Logik. Datenschutz-Maßnahme und Risikomaßnahme sind hier oft
> deckungsgleich (Dok 08 §2.2 weist explizit darauf hin). **Owner der Umsetzung: Hans
> / `rebreak-backend`** — hier nur als Patientensicherheits-/Schadens-Risiko geführt.

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-DATA-01** | Leak gespeicherter Credentials/Account-Daten → Identifizierung als „Sucht-App-Nutzer" → realer Schaden (Stigma, Arbeitsplatz, Versicherung; Erw.gr. 75). | **S3** | W1 | AES-256-GCM at rest (REQ-MAIL-007); Hosting DE/EU (REQ-NFR-001); Supabase self-hosted. **Owner Hans:** Dok 08 §2.1/§2.5. | MAIL-007, NFR-001 | Mittel — Pentest/BSI offen (Dok 08 §3). |
| **R-DATA-02** | Mail-Agent verarbeitet mehr als nötig (Body-Inhalte, Treffer-Persistenz) → übermäßige Art-9-Datenhaltung. | S3 | W2 | Datenminimierung: nur Absender/Betreff (REQ-MAIL-005). **Owner Hans:** Dok 08 §2.1 „zu verifizieren". | MAIL-005 | **Offen** — Umfang im Code zu belegen (Dok 08 H5). |
| **R-DATA-03** | Postfach-Scan ohne tragfähige Einwilligung → Rechtsverstoß + Vertrauensbruch. | S3 | W1 | Consent-Gate `consent_at`, kein Scan ohne Consent (REQ-MAIL-006). **Owner Hans:** Dok 08 §2.1. | MAIL-006 | Niedrig-Mittel — Consent-Text-Qualität zu prüfen. |
| **R-DATA-04** | Lyra extrahiert heimlich Demografie/Profildaten aus Chats → Zweckbindungsbruch, intransparente Profilbildung. | S2 | W2 | Strikte Narrativ/Profil-Trennung im Prompt (REQ-LYRA-006, REQ-DEMO-002). **Owner Hans:** Dok 08 §2.2 (vorbildlich). | LYRA-006, DEMO-002 | Niedrig — Prompt-gesteuert; negativer Testfall fehlt (Dok 05b §2.5). |
| **R-DATA-05** | Übermittlung von Art-9-Chatinhalten an **US-Subprozessor (Groq)** inkl. direkter Identifikatoren → Drittland-Transfer-Risiko, FISA-702-Exposition. | **S3** | W2 | Pseudonymisierung vor Transfer, kein Klarname/E-Mail/User-ID (REQ-LYRA-007); SCC + TIA + ZDR (REQ-NFR-002). **Owner Hans:** Dok 08 §2.2 (K1–K3, **Kritisch**). | LYRA-007, NFR-002 | **HOCH bis Pseudonymisierung + ZDR stehen** (Dok 08). |
| **R-DATA-06** | DiGA-Auswertungsdaten (SOS-Sessions volle Chats, Urge-Logs, Demografie) ohne klare Rechtsgrundlage/Löschkonzept → Art-9-Haftung. | S3 | W2 | Rechtsgrundlage lit. a → lit. h ab DiGA-Listung (Dok 08 §2.7, hängt an Dok 01); Lösch-Endpoint (REQ-DEMO-004, REQ-NFR-003). **Owner Hans.** | LYRA-010, SOS-004, DEMO-001/004 | Mittel — VVT/DSFA offen (Dok 08 H1/H2). |
| **R-DATA-07** | Anonymitätsbruch: Klarname/E-Mail leakt in Community/DM/Realtime/Push/Logs → De-Anonymisierung eines Sucht-Betroffenen. | **S3** | W2 | Anonymität-by-Design (Nickname-only, REQ-COMM-005); Moderation (REQ-COMM-004). **Owner Hans:** Dok 08 §2.4 (Payload prüfen). | COMM-005, COMM-004 | Mittel-Hoch — **ungetestet** (Dok 05b §2.3). Ein Leck bricht den ganzen Schutz. |
| **R-DATA-08** | Betroffenenrechte (Löschung) unvollständig (Soft-Delete, kein OAuth-Revoke, kein Groq-Delete) → Daten überdauern Widerruf. | S2 | W2 | Echtes Cascade-Delete + Provider-Revoke (REQ-NFR-003). **Owner Hans/Backend:** Dok 08 H4. | NFR-003 | Mittel — Umsetzung offen. |

### 2.5 Mail-Filter-Fehlfunktion

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-MAIL-01** | Trigger-Mail wird **nicht erkannt** (False Negative) → Casino-Werbung erreicht User, Rückfall-Auslöser. | S3 | W3 | Mehrstufiger gewichteter Score + Brand-Token-Matching + Echtzeit-Daemon (REQ-MAIL-001/002/003). | MAIL-001/002/003 | Mittel — kein Filter ist vollständig; Labeling „erschwert" (Dok 01 §7). |
| **R-MAIL-02** | **Legitime Mail wird gelöscht** (False Positive) → Datenverlust (z.B. Rechnung, persönliche Mail). | S2 | W2 | Whitelist (REQ-MAIL-004); deterministische Schwelle; Hard-Block erst ab Score ≥ 80 (REQ-MAIL-003). | MAIL-003/004 | Mittel — Verlust irreversibel falls permanent gelöscht. Verhalten je Provider prüfen (05b §2.7). |
| **R-MAIL-03** | LLM-gestützte Mittelband-Klassifikation (Score 25–79) → nicht-deterministisches Lösch-/Pass-Verhalten + ggf. Inhalt an LLM. | S2 | W2 | Deterministische Schwellen dominieren; LLM nur eng begrenzt; Datenschutz-Bewertung des LLM-Pfads (an R-DATA-05). | MAIL-003 | Mittel — Eval des Mail-LLM-Pfads offen. |

### 2.6 Spiele / SOS-Werkzeuge

| ID | Gefährdung → Schädigung | S | W | Maßnahme | REQ | Restrisiko |
|---|---|---|---|---|---|---|
| **R-SOS-01** | Ablenkungs-Spiele mit Punkten/Ranking triggern bei manchen Betroffenen Glücksspiel-ähnliche Belohnungsschleifen → kontraproduktiv. | S2 | W2 | Bewusst **Skill-Spiele, kein Zufall/Glücksspiel** (REQ-SOS-003); keine Geld-/Wett-Mechanik. **Klinisch zu prüfen** (Dok 06). | SOS-003 | Mittel — individuell variabel. `[Gründer-Entscheidung]` + klinisch validieren. |

---

## 3. Top-Risiken (Priorisierung für Gründer & Profi)

In absteigender Priorität — das sind die Zeilen, die den größten Handlungsbedarf
markieren:

1. **R-LYRA-01 — verpasste Krise/Suizidalität (S4).** Höchster Schweregrad, und die
   risikomindernde Maßnahme (deterministische Crisis-Detection + LLM-Eval) ist **noch
   nicht gebaut** (bestätigt durch Dok 05b §1.4). **Dies ist der wichtigste Einzel-
   Punkt der gesamten Akte.**
2. **R-DATA-05 — Art-9-Chatinhalte an Groq/USA (S3, Hoch).** Drittland-Transfer
   sensibelster Daten; bleibt kritisch, bis Pseudonymisierung + ZDR + SCC/TIA stehen
   (Owner Hans, Dok 08 §2.2).
3. **R-DATA-07 — Anonymitätsbruch (S3).** Ein einziges Klarnamen-Leck de-anonymisiert
   einen Sucht-Betroffenen; aktuell ungetestet (Dok 05b §2.3, Dok 08 §2.4).
4. **R-FALSE-01 — falsche Sicherheit bei inaktivem Schutz (S3).** User verlässt sich
   auf Schutz, der (z.B. nach OS-Kill) eine Lücke hat.
5. **R-BYP-03 — Selbstbindung wird zur Falle (S3).** Das ethisch heikle Gegen-Risiko:
   legitimer Ausstieg nach Cooldown muss zuverlässig funktionieren.
6. **R-MAIL-02 — irreversibles Löschen legitimer Mail (S2, aber irreversibel).**

---

## 4. Offene Aktivitäten (Risikomanagement-Prozess)

| # | Aktivität | Owner | Bezug |
|---|---|---|---|
| RM-1 | Formale FMEA/Risikoanalyse mit S/W-Werten + Akzeptanzkriterien | Profi + Gründer | ISO 14971 §5–7 |
| RM-2 | **Deterministische Krisen-/Suizid-Detection + Lyra-LLM-Eval-Suite** spezifizieren | Gründer + Backend + klinisch | R-LYRA-01/03/06, Dok 05b |
| RM-3 | Verifikations-Testfälle je Risikomaßnahme definieren (Maestro/Vitest-Mapping) | Ahmed | Dok 05b §3.3 |
| RM-4 | Anonymitäts-Invarianz-Test (kein PII in API/Realtime/Log) | Backend + Hans | R-DATA-07 |
| RM-5 | Restrisiko-Nutzen-Abwägung (gesamt) | Gründer + Profi + klinisch | ISO 14971 §8 |
| RM-6 | Risiken → Warnhinweise/Gebrauchsanweisung überführen | Marlene (Dok 07) | ISO 14971 §7.1(3) |
| RM-7 | Datenschutz-Risiken (R-DATA-*) in DSFA spiegeln | Hans | Dok 08 H2 |

---

## 5. Andockpunkte (Koordination)

| Dieses Dokument (Risiko) | Andockpunkt |
|---|---|
| Jede Risikomaßnahme verweist auf eine REQ-ID | **Dok 03 Requirements** (Spalte REQ) |
| Sicherheitsrelevante Risiken brauchen Verifikations-Testfälle | **Dok 05b Test (Ahmed)** §3.3 — Mapping-Anker geliefert |
| R-DATA-* spiegeln Dok-08-Befunde in ISO-14971 | **Dok 08 Datenschutz (Hans)** §2.2/§2.4 — Maßnahmen deckungsgleich |
| Schweregrad-Anhebung durch Krisennähe; Wirksamkeits-/Spiel-Risiken | **Dok 06 Klinische Bewertung** (Uni Bremen) |
| Risiken → Warnhinweise | **Dok 07 Gebrauchsanweisung/Labeling** |
| Risikoklasse beeinflusst Software-Sicherheitsklasse | **Dok 02 Klassifizierung** + **Dok 05** (IEC 62304) |

---

## 6. Quellen / Normen

- ISO 14971 (Anwendung des Risikomanagements auf Medizinprodukte).
- IEC 62304 §4.3 (Software-Sicherheitsklassen), §7 (Risikomanagement-Software-Items).
- MDR (EU) 2017/745, Anh. I GSPR §§ 3–9, §17.
- DSGVO Art. 9, Erw.gr. 75 (Schaden bei besonderen Kategorien) — via Dok 08.
- Interne Quellen: `apps/rebreak-native/lib/protection.ts`, `lib/sosPrompts.ts`,
  `backend/server/api/coach/*`, `backend/server/utils/mail-classifier.ts`,
  `backend/MAGIC_API.md`, Dok 01/03/05b/08.

---

*v0-Erstliste. Schweregrad-/Wahrscheinlichkeits-Werte sind Priorisierungs-Hypothesen,
keine abgenommene Bewertung. Risikoakzeptanz und Nutzen-Risiko-Abwägung sind
`[Gründer-Entscheidung]` + `[Profi-Validierung]`.*