Soukromí a ochrana duševního zdraví

Proč jsou data o duševním zdraví mimořádně citlivá

Informace o duševním zdraví patří mezi zvláštní kategorie osobních údajů a jejich zveřejnění může vést ke stigmatizaci, diskriminaci při zaměstnávání, pojištění či v sociálních vztazích. V ekosystému mobilních aplikací se tato data často kombinují s jinými identifikátory (geolokace, kontakty, biometrie), což zvyšuje riziko reidentifikace a vytváří komplexní profily chování. Cílem článku je ukázat, kde data vznikají, jak s nimi aplikace nakládají, a jaká technická, organizační a právní opatření minimalizují rizika – aniž by brzdila přínosy digitálních nástrojů pro duševní zdraví.

Mapa datových toků v aplikacích duševního zdraví

Primární vstup: sebemonitoring (deníky nálad, spánek, spouštěče), dotazníky (PHQ-9, GAD-7), chat s terapeutem/coach.
Senzorika a kontext: geolokace, akcelerometr, Bluetooth (blízkost), uživatelské interakce (délka používání, rychlost psaní), nositelná zařízení.
Technická telemetrie: crash logy, diagnostika výkonu, identifikátory zařízení, reklamní ID.
Zpracování: lokálně na zařízení, v cloudu poskytovatele, přes externí SDK (analytika, push notifikace, reklama), případně při integraci s pojišťovnou nebo zaměstnavatelem.
Výstup: personalizovaná doporučení, tréninky, programy, reporty pro terapeuta; někdy export do EMR/EHR nebo jiných klinických systémů.

Rizikový profil: kde se věci nejčastěji kazí

Nettransparentní SDK a třetí strany: analytické či reklamní knihovny mohou sbírat více, než je nutné, a zasílat údaje mimo EU.
Reidentifikace „anonymizovaných“ dat: kombinací souborů (např. čas/místo + vzory chování) je možné jednotlivce opět identifikovat.
Slabá správa souhlasu: předvolené „opt-in“ pro marketing, vázaný souhlas (nutnost souhlasit i s reklamou) nebo tmavé vzory rozhraní.
Nepřiměřená retence: uchovávání dat „navždy“ bez účelového zdůvodnění, chybějící architektura na selektivní mazání.
Nevyhovující zabezpečení přenosů a úložišť: chybějící TLS pinning, slabé klíčování, nešifrované zálohy, shared-preferences bez šifrování.
Zamžená hranice mezi „wellness“ a zdravotnickou pomůckou: aplikace, která skutečně poskytuje diagnostiku nebo terapii, ale nesplňuje regulační požadavky.

Právo a compliance: co musí vývojář a provozovatel řešit

GDPR – zvláštní kategorie: údaje o zdraví vyžadují zvláštní právní základ (obvykle výslovný souhlas) a přísnější pravidla zpracování (minimalizace, účelové vázání, transparentnost, bezpečnost).
DPIA (posouzení dopadu na ochranu údajů): povinné při vysokém riziku; mapuje rizika a navrhuje mitigace (pseudonymizace, šifrování, omezení přístupu).
Mezinárodní přenosy: pokud data opouštějí EHP, jsou nezbytné záruky (standardní smluvní doložky, dopadová posouzení, technická opatření, např. E2EE).
Regulační status: pokud aplikace splňuje definici zdravotnické pomůcky (diagnostika, léčba), platí zvláštní pravidla (např. označení CE, post-market surveillance).
Práva subjektů údajů: přístup, oprava, vymazání, omezení, přenositelnost, námitka; musejí být realizovatelné i při napojení na třetí strany a zálohy.

Technická opatření: architektura ochrany soukromí již od návrhu

Minimalizace dat: sbírat pouze nezbytné pro funkci; vypnout implicitní sběr reklamních ID a detailní telemetrie.
Edge zpracování: predikce a scoring lokálně na zařízení; do cloudu posílat jen agregované nebo pseudonymizované výstupy.
Silná kryptografie: TLS s moderními profily, TLS pinning proti MITM, šifrování v klidu (disk/DB) a na úrovni polí (např. deníky, chaty).
Správa klíčů: klíče mimo aplikační kód, využití bezpečnostních modulů (Secure Enclave/TPM/KeyStore), rotace a oddělení oprávnění.
Pseudonymizace a segmentace: oddělit identifikátory od klinických dat, použít tokenizaci; přístup řídit principem nejmenších oprávnění.
Auditovatelnost: detailní logování přístupů (bez obsahu), nepopiratelnost událostí a varování při anomáliích.

Ochrana komunikace: chaty, hlas a video

End-to-End šifrování (E2EE): při přímých interakcích klient–terapeut eliminuje přístup serveru k obsahu; vyžaduje bezpečnou výměnu klíčů a ověření identity partnerů.
Bezpečné nahrávky: pokud se nahrávají relace, používejte per-relace klíče a explicitní souhlas; umožněte jednoduché vymazání.
Metadata: E2EE nechrání před únikem metadat; minimalizujte jejich sběr a retenci (časové značky, IP, délka hovorů).

Strojové učení a soukromí: možnosti a limity

Federované učení: model se učí lokálně, server agreguje váhy; snižuje přenos surových dat.
Diferenciální soukromí: přidávání šumu při agregaci, aby jednotlivé příspěvky nebyly rozpoznatelné; je potřeba vyvážit přesnost a parametr ε.
Bezpečné výpočty: homomorfní šifrování nebo multi-party computation pro vybrané metriky (nákladné, ale vhodné pro citlivé agregace).
Test reidentifikace: součástí procesu ML by měla být hodnocení rizika reidentifikace u publikovaných metrik a datasetů.

Tabulka: porovnání architektonických přístupů

Přístup	Výhody	Rizika/nevýhody	Vhodné pro
Cloud-centrické zpracování	Jednoduché nasazení, centralizovaný dohled	Vyšší riziko úniků, přenosy mimo EU	Rané prototypy, nízká citlivost
Edge-first architektura	Menší datová stopa, lepší soukromí	Komplexnější klienti, vyšší nároky na zařízení	Deníky nálad, lokální analýza
Federované učení	Bez surových dat na serveru	Komplikovaná orchestraci, potřeba robustní anonymizace	Škálovatelné modely s citlivým obsahem
E2EE komunikace	Provozovatel nevidí obsah	Komplikované moderování a podpora	Terapeutické chaty a hovory

Integrace s pojišťovnou a zaměstnavatelem: extrémní opatrnost

Programy „well-being“ a slevy na pojistném často podmiňují sdílení citlivých dat. Požadujte technické a právní oddělení toků, jasné definování účelu a garance, že individuální údaje nebudou použity k negativním rozhodnutím (např. úprava pojistného či pracovního postupu). Preferujte agregované, anonymizované reporty s minimem metadat a krátkou dobou retence.

UX a etika: jak navrhovat souhlas a transparentnost

Granulární souhlas: oddělte souhlas pro základní funkci, výzkum, marketing a sdílení s třetími stranami.
Jasný jazyk: bez žargonu; vysvětlete, co znamená sběr geolokace či údajů o spánku.
Reverzibilita: uživatel může souhlas stáhnout a data vymazat bez penalizace; navrhněte jednoduché „privacy centrum“ v aplikaci.
Fair nudges namísto tmavých vzorů: upřednostněte výchozí soukromější nastavení a vysvětlení důsledků.

Bezpečné logování, testování a podpora

Redakce citlivých údajů v logech: nikdy nelogujte texty zpráv, diagnózy, jména nebo e-maily; používejte hashované identifikátory.
Izolovaná testovací data: syntetické nebo slabě anonymizované datasety; zakázat používání produkčních dat v QA.
Podpora bez přístupu k obsahu: technická podpora by měla vidět jen metadata nutná k diagnostice.

Incident response a práva uživatelů

Plán reakce: detekce, izolace, analýza, notifikace dotčených osob a úřadů; připravené šablony a kontakty.
Přístup k údajům: stahovatelná kopie ve strojově čitelném formátu (JSON/CSV), včetně vysvětlení odvozených metrik.
Vymazání: kaskádové (produkce, cache, zálohy) s verifikací; uveďte technickou lhůtu na propagaci vymazání do záloh.

Checklist pro vývojáře a provozovatele

Má aplikace provedenou DPIA a evidované datové toky pro všechny třetí strany?
Je implementováno E2EE pro chaty/hovory a TLS pinning pro API?
Běží edge výpočty a je minimalizována telemetrie (opt-in, bez reklamního ID)?
Jsou retence nastaveny selektivně a technicky vynutitelné (lifecycle politiky, TTL, expirační klíče)?
Je správa souhlasu granulární a reverzibilní, s jednoduchým vymazáním?
Proběhly penetrační testy a audit SDK? Jsou k dispozici veřejné zprávy a zranitelnosti jsou promptně řešeny?

Checklist pro uživatele (praktická hygiena)

Ověřuji původ aplikace (vývojář, web, reference) a čtu sekci o ochraně soukromí.
Vypínám sběr lokace a detailní telemetrie, pokud není pro funkci nezbytná.
Využívám silná hesla a passkeys, mám zapnuté MFA (nikoli přes SMS, je-li jiná možnost).
Nesdílím reporty s pojišťovnou/zaměstnavatelem bez jasných záruk a možnosti opt-out.
Žádám o přístup k údajům a testuji vymazání ještě před dlouhodobým používáním aplikace.

Specifika pro adolescenty a citlivé skupiny

Pro nezletilé a zranitelné skupiny musí být mechanismy souhlasu a ochrany soukromí obzvláště přísné: default-deny pro marketing, žádná reklamní SDK, rodičovská oprávnění bez přístupu k obsahu terapie, ale s kontrolou účtu a bezpečnostních nastavení. Transparentní vysvětlení v jednoduchém jazyce a vizuální příručky jsou nezbytností.

Měření efektivity bez kompromisu soukromí

Privacy-preserving analytics: agregované metriky s nastaveným prahem a diferenciálním šumem.
On-device experimenty: A/B testování s lokálním vyhodnocením a minimem přenášených dat.
Etické rady a nezávislý dohled: pravidelné přehodnocování sběru dat a dopadů na uživatele.

Bezpečná inovace je možná

Digitální nástroje mohou být významnou oporou pro duševní zdraví, pokud jsou postaveny na principech privacy-by-design, přísné správě souhlasů, silném šifrování a odpovědném využití ML. Klíčem je minimalizace, transparentnost a kontrola uživatele nad daty – od sběru po vymazání. Jen tak lze dosáhnout přínosu pro uživatele i důvěry veřejnosti bez obětování jejich důstojnosti a soukromí.