rebreak-monorepo/docs/specs/diga/04-risiko-akte-v0.md

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). Live-Run 2026-06-10: Crisis-Recall auf dem produktiven Pro-Modell (Groq llama-3.3-70b) 6/6 = 100% — Gate bestanden (Record: eval-records/2026-06-10-groq-llama-3.3-70b.md); Fallback-Modell-Run (gpt-4o-mini) zeigte nur 83% → Modellwahl ist sicherheitsrelevant → Model-Pinning-Requirement vorgeschlagen.	LYRA-001/003/004	MITTEL (reduziert) — Pre-Filter + LLM-unabhängiger Fallback implementiert, Crisis-Recall-Gate auf Pro-Produktionsmodell verifiziert. Offen: Legend-Modell (Haiku 4.5) ungetestet, Eval-System-Prompt ≠ Produktions-Prompt (Paritäts-Nachweis), klinische Validierung der Pattern-Liste + lyra-persona-Review der Fallback-Texte. [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). Befund + Fix 2026-06-10: username (= Login-Identifikator, s. auth/login.post.ts L100) wurde in community/posts.get.ts + social/profile/[userId].get.ts an fremde Clients emittiert — Risiko auf Code-Ebene real eingetreten; Feld aus beiden Payloads entfernt (lokal, Deploy ausstehend, Details Dok 05d §2c).	COMM-005, COMM-004	Mittel-Hoch — Einzelbefund gefixt, aber weiterhin kein Invarianz-Test (RM-4); Nickname-Fallback-Ketten zeigen bei fehlendem Nickname weiterhin den Login-Username. 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.
R-DATA-09	Block-Mechanismus erzeugt eine zentral beobachtbare Spur „Nutzer X wollte auf Glücksspielseite Y" (z.B. via Sinkhole-/Redirect-Logs oder branded Block-Page) → De-Anonymisierungs-/Stigma-Risiko bei Art-9-Betroffenen.	S3	W1	(Inhärent sicheres Design, Entscheidung 2026-06-10): Geblockte Domains werden per DNS-NXDOMAIN abgewiesen — kein Sinkhole, keine Block-Page, kein Redirect. Es entsteht keine serverseitig auf die Person rückführbare „Zugriffsversuch"-Liste; zusätzlich vermeidet NXDOMAIN die TLS-Zertifikats-Wall einer HTTPS-Block-Page. (REQ-PROT-001).	PROT-001	Niedrig — by-Design gemindert. Diese Entscheidung ist eine bewusste Risiko-Mitigation (Detection-/Stigma-Schutz), nicht nur eine technische Wahl. [Gründer-Entscheidung] bestätigt.

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. Die risikomindernden Maßnahmen sind technisch implementiert (deterministischer Krisen-Keyword-Pre-Filter crisis-filter.ts + Unit-Tests + LLM-unabhängiger Fallback
   • Lyra-Eval-Suite tests/eval/lyra-eval.test.ts, Stand 2026-06-07/06-10) — aber der wirksamkeitsbelegende Nachweis fehlt noch: kein dokumentierter Live-Run der Eval-Suite gegen das produktive LLM (Crisis-Detection-Recall ist nicht als Verifikations-Record archiviert; Dok 05b §1.4/§4.2, Dok 05c). Eine S4-Risikomaßnahme ohne reproduzierbaren Verifikationsnachweis ist für ein Medizinprodukt unzureichend (IEC 62304 §5.6). Dies bleibt der wichtigste Einzel-Punkt der gesamten Akte — der nächste Schritt ist nicht „bauen", sondern den Live-Run-Record erzeugen + klinische Validierung der Pattern-Liste.
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	Krisen-Detection + Lyra-Eval-Suite sind implementiert → jetzt dokumentierten Live-Run-Verifikationsrecord erzeugen (Crisis-Recall-Ziel 100 %) + klinische Validierung der Pattern-Liste	Ahmed (Live-Run) + klinisch (Pattern)	R-LYRA-01/03/06, Dok 05b §4.2, Dok 05c
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].