ПОЛІТИКА КОНФІДЕНЦІЙНОСТІ

Платформа ELLI

Дата набрання чинності: 8 серпня 2025 року

ВСТУП

Ми, ELLI, цінуємо вашу конфіденційність і прагнемо забезпечити максимальний захист ваших персональних даних. Ця Політика конфіденційності (далі — «Політика») детально пояснює, як ми збираємо, використовуємо, зберігаємо та захищаємо ваші дані, а також визначає ваші права щодо цих даних.

Ця Політика розроблена у суворій відповідності з:

• Законом України «Про захист персональних даних»
• Загальним регламентом із захисту даних ЄС (GDPR)
• Законом США про переносимість та підзвітність медичного страхування (HIPAA)

1. ПРО ПЛАТФОРМУ ELLI

ELLI — це інноваційна онлайн-платформа, що надає послуги психологічної підтримки з використанням передових технологій штучного інтелекту. Користувачі можуть взаємодіяти з ШІ-психологом через текстовий формат комунікації для отримання персоналізованих консультацій, спрямованих на покращення емоційного та психічного благополуччя.

Контактна інформація з питань конфіденційності: https://e-lli.com/contact

2. КАТЕГОРІЇ ДАНИХ, ЩО ЗБИРАЮТЬСЯ

Ми збираємо дані виключно на добровільній основі або в процесі автоматичного функціонування платформи. Усі дані класифіковані за категоріями захисту:

2.1 ПЕРСОНАЛЬНІ ІДЕНТИФІКАЦІЙНІ ДАНІ

Збираються лише при добровільному наданні через форми платформи:

• Ім'я користувача
• Адреса електронної пошти
• Номер телефону (опціонально)
• Вік
• Гендерна приналежність (за бажанням надати)
• Країна та регіон проживання
• Медичні діагнози (за бажанням надати)

2.2 ДАНІ ПРО ПСИХІЧНИЙ ТА ЕМОЦІЙНИЙ СТАН

Спеціальна категорія даних, що вимагає підвищеного захисту:

• Текстові повідомлення під час сесій із ШІ-психологом
• Голосові записи консультацій (при виборі голосового формату)
• Відеозаписи сесій (при виборі відеоформату)
• Відповіді на психологічні опитувальники та тести
• Емоційні реакції та стани

ВАЖЛИВО: Усі дані цієї категорії автоматично піддаються процедурі шифрування, що виключає можливість ідентифікації особи як нашою компанією, так і третіми сторонами.

2.3 ПОВЕДІНКОВІ ДАНІ

Інформація про взаємодію з платформою:

• Час початку та закінчення сесій
• Частота використання різних функцій
• Навігаційні патерни на платформі
• Переваги в налаштуваннях інтерфейсу
• Історія звернень до різних розділів

2.4 ТЕХНІЧНІ ДАНІ

Автоматично збирані системні дані:

• IP-адреса (з можливістю геолокації)
• Тип операційної системи та версія
• Браузер та його версія
• Роздільна здатність екрану та характеристики пристрою
• Файли cookie та дані локального сховища
• Унікальні ідентифікатори пристрою

2.5 ПСЕВДОНІМІЗОВАНІ ІДЕНТИФІКАТОРИ

Спеціальні технічні дані для забезпечення конфіденційності:

• Унікальний хеш-ідентифікатор користувача (генерується автоматично системою аутентифікації Clerk)
• Сесійні токени для підтримання стану сеансу
• Криптографічні ключі доступу до зашифрованих даних

КРИТИЧНО ВАЖЛИВО: Хеш-ідентифікатор являє собою унікальний криптографічний рядок, який технічно неможливо зворотно перетворити в початкові персональні дані. Цей механізм забезпечує додатковий рівень захисту конфіденційності у відповідності з вимогами статті 4(5) GDPR про псевдонімізацію.

3. МЕТОДИ ЗБОРУ ДАНИХ

3.1 ПРЯМЕ НАДАННЯ КОРИСТУВАЧЕМ

Реєстраційні форми: При створенні облікового запису

Профільні анкети: При заповненні особистої інформації

Інтерактивні сесії: У процесі спілкування з ШІ-психологом

Зворотний зв'язок: Через форми відгуків і пропозицій

3.2 АВТОМАТИЧНИЙ ЗБІР

Файли cookie: Для відстеження переваг і сесій

Веб-аналітика: Через інтеграцію з Google Analytics

Логи сервера: Записи про технічні взаємодії

Пікселі відстеження: Для аналізу ефективності інтерфейсу

3.3 СТОРОННІ ДЖЕРЕЛА

Аналітичні платформи: Google Analytics, Hotjar (лише зі згодою)

Соціальні мережі: При авторизації через соціальні акаунти

Партнерські інтеграції: При використанні сторонніх сервісів

3.4 СИСТЕМА АУТЕНТИФІКАЦІЇ ТА ПСЕВДОНІМІЗАЦІЇ

3.4.1 Clerk Authentication System

Платформа ELLI використовує Clerk — професійну систему управління ідентифікацією та аутентифікацією користувачів, що відповідає стандартам SOC 2 Type II та GDPR.

Процес аутентифікації:

1. Первинна реєстрація: Користувач надає базові дані (email, ім'я) через захищену форму Clerk
2. Генерація хеш-ідентифікатора: Clerk автоматично створює унікальний криптографічний хеш (наприклад, user_2nX8Kq9P3mN7vLbR4tY6wZ1s)
3. Розділення даних:
• Clerk зберігає персональні ідентифікаційні дані в своїй захищеній інфраструктурі
• Платформа ELLI отримує та зберігає лише хеш-ідентифікатор
• Зв'язок між персональними даними та хешем існує виключно в системі Clerk
4. Авторизований доступ: При кожному вході Clerk генерує тимчасовий JWT-токен, що містить хеш-ідентифікатор

3.4.2 Принцип розділення даних (Data Segregation)

Архітектура безпеки:

[Clerk Infrastructure] → Зберігає: Email, Ім'я, Телефон, Пароль

↓ (передає лише хеш)

[ELLI Platform] → Зберігає: Хеш-ідентифікатор + Терапевтичні дані

Переваги цієї архітектури:

• Неможливість реідентифікації: Навіть при витоку даних з ELLI, неможливо пов'язати терапевтичні записи з конкретною особою без доступу до системи Clerk
• Мінімізація даних: ELLI обробляє мінімальний набір ідентифікаційних даних
• Розділення відповідальності: Clerk несе відповідальність за захист персональних даних, ELLI — за терапевтичні дані
• Відповідність Privacy by Design: Архітектура проектується з урахуванням захисту конфіденційності (стаття 25 GDPR)

3.4.3 Механізм ведення записів за хешем

Усі операції на платформі прив'язуються до хеш-ідентифікатора:

• Терапевтичні сесії: Записуються як session_data[user_hash]
• Історія взаємодій: Зберігається в форматі interaction_log[user_hash][timestamp]
• Користувацькі налаштування: Зберігаються як preferences[user_hash]
• Аналітичні дані: Агрегуються за хешами без можливості деанонімізації

Технічний приклад запису:

{

"user_hash": "user_2nX8Kq9P3mN7vLbR4tY6wZ1s",

"session_id": "sess_a7bC9d2E4f6G8h",

"timestamp": "2025-08-15T14:30:00Z",

"session_data": "[зашифрований вміст]"

}

Важливо: Персональні дані (ім'я, email) ніколи не зберігаються в одній базі даних із терапевтичними записами.

3.4.4 Правове підґрунтя для псевдонімізації

Відповідно до статті 4(5) GDPR, псевдонімізація визначається як:

"Обробка персональних даних таким чином, що їх більше не можна віднести до конкретного суб'єкта даних без використання додаткової інформації, за умови, що така додаткова інформація зберігається окремо".

Наша система повністю відповідає цьому визначенню, оскільки:

• Хеш-ідентифікатори технічно неможливо зворотно перетворити
• Додаткова інформація (відповідність хешу реальним даним) зберігається окремо в Clerk
• Доступ до системи Clerk суворо контролюється та логується

Переваги псевдонімізації згідно з Recital 28 GDPR:

• Зниження ризиків для суб'єктів даних
• Допомога контролерам у виконанні зобов'язань із захисту даних
• Додатковий захід безпеки поряд із шифруванням

4. ЦІЛІ ТА ПРАВОВІ ПІДСТАВИ ОБРОБКИ ДАНИХ

4.1 НАДАННЯ ОСНОВНИХ ПОСЛУГ

Правове підґрунтя: Виконання договору (ст. 6(1)(b) GDPR)

• Персоналізація консультацій ШІ-психолога
• Адаптація рекомендацій під індивідуальні потреби
• Забезпечення безперервності терапевтичних сесій
• Моніторинг прогресу користувача

4.2 УДОСКОНАЛЕННЯ ШІ-ТЕХНОЛОГІЙ

Правове підґрунтя: Законний інтерес (ст. 6(1)(f) GDPR)

• Навчання алгоритмів машинного навчання
• Підвищення точності психологічних рекомендацій
• Розробка нових терапевтичних методик
• Оптимізація користувацького досвіду

4.3 МАРКЕТИНГОВІ ЦІЛІ

Правове підґрунтя: Згода користувача (ст. 6(1)(a) GDPR)

• Відправлення персоналізованих пропозицій
• Інформування про нові функції платформи
• Проведення маркетингових кампаній
• Аналіз ефективності рекламних матеріалів

4.4 НАУКОВІ ДОСЛІДЖЕННЯ

Правове підґрунтя: Законний інтерес (ст. 6(1)(f) GDPR) + Згода (ст. 9(2)(a) для спеціальних категорій)

• Дослідження в галузі цифрової психології
• Розробка інноваційних терапевтичних підходів
• Співпраця з науковими інститутами
• Публікація анонімізованих досліджень

Обробка даних про здоров'я здійснюється виключно з вашої явної згоди відповідно до статті 9 GDPR.

5. ПЕРЕДАЧА ДАНИХ ТРЕТІМ СТОРОНАМ

5.1 ОБМЕЖЕНА ПЕРЕДАЧА ДАНИХ

Ми НЕ ПРОДАЄМО і НЕ ЗДАЄМО В ОРЕНДУ ваші персональні дані. Передача можлива лише в таких випадках:

5.1.1 Правоохоронні органи

Умова: Наявність офіційного судового рішення або запиту компетентних органів

Обсяг: Лише персональні дані, надані добровільно через форми

Повідомлення: Користувач повідомляється, якщо це не заборонено законом

5.1.2 Сторонні сервіси та підрядники

Clerk Authentication Services: Обробка аутентифікації та управління ідентифікацією (повна відповідність GDPR, SOC 2 Type II)

Microsoft Azure Cloud Services: Зберігання зашифрованих даних та забезпечення інфраструктури

• Azure SQL Database для структурованих даних
• Azure Blob Storage для медіафайлів
• Azure Key Vault для управління ключами шифрування
• Azure Cognitive Services для обробки ШІ (при використанні)

Google Analytics: Для веб-аналітики (анонімізовані дані)

Hotjar: Для UX-досліджень (лише зі згодою)

Платіжні системи: Для обробки транзакцій (лише необхідні дані)

ІТ-підтримка: Для технічного обслуговування (з обмеженим доступом)

5.1.3 Угоди про обробку даних із ключовими партнерами

Clerk, Inc.:

• Місцезнаходження: США (San Francisco, CA)
• Сертифікації: SOC 2 Type II, GDPR-compliant
• DPA: Стандартна угода про обробку даних із SCC
• Роль: Обробник даних аутентифікації
• Гарантії: Clerk зобов'язується не використовувати дані для власних цілей

Microsoft Corporation (Azure):

• Місцезнаходження: Дата-центри в ЄС (переважно Netherlands, Ireland)
• Сертифікації: ISO 27001, ISO 27018, SOC 1/2/3, GDPR, HIPAA-compliant
• DPA: Microsoft Online Services DPA із SCC
• Роль: Субобробник для хмарної інфраструктури
• Гарантії: Резидентність даних в ЄС, шифрування at-rest та in-transit

5.2 МІЖНАРОДНІ ПЕРЕДАЧІ

Для міжнародних передач даних застосовуються:

• Стандартні договірні положення ЄС (SCC 2021) — для передачі даних до США (Clerk) та інших юрисдикцій
• Рішення про достатність рівня захисту — для країн, визнаних ЄС
• Microsoft EU Data Boundary — для зберігання даних європейських користувачів виключно в ЄС
• Корпоративні обов'язкові правила (BCR) — для груп компаній

Спеціальні гарантії для даних про здоров'я:

• Усі дані спеціальних категорій (психологічні сесії) шифруються до передачі
• Ключі шифрування зберігаються окремо в Azure Key Vault у європейських дата-центрах
• Псевдонімізація через хеш-ідентифікатори мінімізує ризики при транскордонних передачах

6. БЕЗПЕКА ТА ЗБЕРІГАННЯ ДАНИХ

6.1 ТЕХНІЧНІ ЗАХОДИ ЗАХИСТУ

6.1.1 Шифрування даних

У спокої (at-rest):

• AES-256 шифрування для всіх збережених даних в Azure Storage
• Transparent Data Encryption (TDE) для Azure SQL Database
• Подвійне шифрування для даних про здоров'я (клієнтське + серверне)

При передачі (in-transit):

• TLS 1.3 протокол для всіх комунікацій між клієнтом і сервером
• HTTPS Strict Transport Security (HSTS) для веб-додатку
• Взаємна TLS аутентифікація для API-взаємодій між сервісами

Управління ключами:

• Azure Key Vault із HSM (Hardware Security Module) для управління ключами шифрування
• Автоматична ротація ключів кожні 90 днів
• Розділення ключів: окремі ключі для різних категорій даних
• Принцип мінімальних привілеїв для доступу до ключів

6.1.2 Контроль доступу

Багатофакторна аутентифікація:

• Обов'язкова для всього персоналу з доступом до систем
• Azure Active Directory із умовним доступом (Conditional Access)
• Біометрична аутентифікація для критичних операцій

Принцип мінімальних привілеїв:

• Рольова модель доступу (RBAC) через Azure AD
• Just-in-Time (JIT) доступ для адміністративних операцій
• Тимчасові дозволи з автоматичним відкликанням

Контроль доступу до даних:

• Хеш-ідентифікатори обмежують доступ до мінімально необхідного
• Розділення обов'язків: персонал ELLI не має доступу до системи Clerk
• Audit logging: всі операції доступу записуються в Azure Monitor

6.1.3 Моніторинг безпеки

24/7 моніторинг:

• Azure Security Center для постійного відстеження загроз
• Azure Sentinel (SIEM) для аналізу безпеки та реагування на інциденти
• Автоматичні сповіщення при підозрілій активності

Системи виявлення вторгнень:

• Azure DDoS Protection для захисту від атак відмови в обслуговуванні
• Azure Web Application Firewall (WAF) для захисту веб-додатків
• Intrusion Detection System (IDS) на рівні мережі

Логування та аудит:

• Azure Monitor Logs для повного запису операцій із даними
• Clerk Audit Logs для відстеження подій аутентифікації
• Зберігання логів: мінімум 2 роки для відповідності нормативним вимогам
• SIEM-інтеграція для кореляції подій безпеки

Тестування безпеки:

• Квартальні пентести незалежними аудиторами
• Автоматизоване сканування вразливостей щотижня
• Red Team exercises щорічно

6.1.4 Архітектура псевдонімізації та ізоляція даних

Багаторівневий захист:

1. Рівень аутентифікації (Clerk):
• Зберігання персональних даних в ізольованій інфраструктурі
• Генерація та управління хеш-ідентифікаторами
• JWT-токени з коротким терміном дії (15 хвилин)
2. Рівень додатку (ELLI Platform):
• Отримання лише хеш-ідентифікаторів і токенів
• Прив'язка всіх даних сесій до хешів
• Відсутність прямих персональних даних в основній БД
3. Рівень зберігання (Azure):
• Шифрування всіх даних із різними ключами
• Розділення баз даних: ідентифікатори ↔ терапевтичні дані
• Географічне розділення для європейських користувачів

Переваги архітектури:

• Breach containment: витік даних з одного рівня не компрометує інші
• Мінімізація surface attack: зменшення точок атаки
• Відповідність Privacy by Design: захист вбудований в архітектуру

6.2 ОРГАНІЗАЦІЙНІ ЗАХОДИ

6.2.1 Навчання персоналу

Регулярні тренінги із захисту даних та GDPR compliance

Спеціалізоване навчання:

• Робота з даними про здоров'я (HIPAA guidelines)
• Протоколи реагування на інциденти
• Етичні стандарти психологічної практики

Сертифікація співробітників за стандартами безпеки (CISSP, CISM)

Підписання угод:

• NDA (Non-Disclosure Agreement) для всіх співробітників
• DPA (Data Processing Agreement) для підрядників

6.2.2 Фізична безпека

Захищені дата-центри Microsoft Azure:

• Сертифікація: ISO 27001, SOC 2 Type II
• Біометричний контроль доступу до серверних приміщень
• 24/7 відеоспостереження та охорона
• Резервне живлення та системи клімат-контролю
• Автоматичні системи пожежогасіння

Офісна безпека:

• Контроль доступу до робочих місць із конфіденційними даними
• Політика "чистого столу" для запобігання витокам
• Шифрування робочих пристроїв

6.3 ТЕРМІНИ ЗБЕРІГАННЯ ДАНИХ

Примітка про псевдонімізовані дані:

Після видалення акаунта зв'язок між хеш-ідентифікатором і реальною особою знищується в системі Clerk. Терапевтичні дані, прив'язані до хешу, технічно стають анонімними, оскільки відсутній механізм реідентифікації.

6.4 ПРОЦЕДУРИ ВИДАЛЕННЯ

6.4.1 Видалення на запит користувача

Стандартне видалення (право на забуття):

1. День 0: Користувач відправляє запит на видалення через особистий кабінет
2. День 1: Clerk деактивує акаунт і позначає дані для видалення
3. День 30: Автоматичне видалення персональних даних із Clerk
4. День 30: Видалення зв'язку хеш ↔ особа (необоротна анонімізація)
5. День 90: Видалення терапевтичних даних із Azure (якщо запитано негайне видалення)

Екстрене видалення (на запит):

• Негайна деактивація акаунта
• 72 години: Повне видалення всіх даних із усіх систем
• Підтвердження видалення надсилається користувачу

6.4.2 Методи криптографічного стирання

Для персональних даних:

• Secure deletion через перезапис випадковими даними (7 проходів за DoD 5220.22-M)
• Cryptographic erasure: знищення ключів шифрування в Azure Key Vault
• Soft delete + purge: використання вбудованих механізмів Azure

Для хеш-ідентифікаторів:

• Видалення з усіх баз даних і індексів
• Очищення кешів і тимчасових сховищ
• Перевірка видалення через автоматизовані скрипти

Для резервних копій:

• Автоматичне очищення видалених даних із резервних копій через 90 днів
• Зашифровані резервні копії зі знищуваними ключами

6.4.3 Аудит процесу видалення

Сертифікати видалення:

• Документальне підтвердження знищення даних
• Надається користувачу на запит
• Включає деталі про обсяг і типи видалених даних

Автоматичні перевірки:

• Щомісячна верифікація дотримання термінів видалення
• Аудит логів видалення в Azure Monitor
• Звіти про compliance для регуляторів

7. ПРАВА КОРИСТУВАЧІВ

7.1 ПРАВО НА ІНФОРМАЦІЮ ТА ДОСТУП (ст. 15 GDPR)

Підтвердження обробки: Інформація про те, чи обробляються ваші дані

Копія даних: Отримання повної копії всіх персональних даних

Деталі обробки: Цілі, категорії, одержувачі даних

Терміни зберігання: Період зберігання або критерії визначення

Особливості доступу до псевдонімізованих даних:

Ви маєте право отримати:

• Персональні дані з Clerk: email, ім'я, телефон, дата реєстрації
• Терапевтичні дані з ELLI: всі записи сесій, відповіді на опитувальники, прив'язані до вашого хеш-ідентифікатора
• Технічні дані: логи входів, налаштування акаунта

Формат надання:

• JSON для структурованих даних
• PDF-звіт для терапевтичних записів
• CSV для статистики використання

Термін надання: 30 днів із моменту запиту

7.2 ПРАВО НА ВИПРАВЛЕННЯ (ст. 16 GDPR)

Виправлення неточностей: Корекція неправильної інформації в Clerk і ELLI

Доповнення даних: Додавання відсутніх даних у профіль

Оновлення інформації: Актуалізація застарілих даних

Як реалізувати:

• Через особистий кабінет для базових даних
• Через запит на (https://e-lli.com/contact) для терапевтичних записів

7.3 ПРАВО НА ВИДАЛЕННЯ — «ПРАВО НА ЗАБУТТЯ» (ст. 17 GDPR)

Підстави для видалення:

• Дані більше не потрібні для первісних цілей
• Відкликання згоди та відсутність інших законних підстав
• Незаконна обробка даних
• Дотримання правового зобов'язання

Процес видалення через псевдонімізацію:

1. Запит на видалення через особистий кабінет або email: https://e-lli.com/contact
2. Видалення персональних даних із Clerk (деідентифікація)
3. Розрив зв'язку хеш ↔ особа (необоротна анонімізація)
4. Опціонально: Видалення терапевтичних даних за хешем із ELLI

Важливо: Після розриву зв'язку в Clerk терапевтичні дані стають технічно анонімними, оскільки відсутній спосіб пов'язати хеш із реальною особою.

7.4 ПРАВО НА ОБМЕЖЕННЯ ОБРОБКИ (ст. 18 GDPR)

Випадки обмеження:

• Оскарження точності даних
• Незаконна обробка (альтернатива видаленню)
• Дані потрібні для правових вимог
• Очікування перевірки законності обробки

Технічна реалізація:

• Маркування хеш-ідентифікатора як "restricted" у системі
• Блокування обробки нових даних
• Збереження існуючих даних без змін

7.5 ПРАВО НА ПЕРЕНОСИМІСТЬ ДАНИХ (ст. 20 GDPR)

Структурований формат: JSON, CSV, XML

Машиночитані дані: Придатні для автоматичної обробки

Пряма передача: Можливість передачі іншому контролеру

Експорт включає:

• Персональні дані з Clerk (із вашого дозволу)
• Усі терапевтичні записи, прив'язані до вашого хешу
• Метадані сесій і налаштування

Винятки:

• Дані, отримані в результаті ШІ-аналізу (похідні дані), можуть бути виключені
• Дані третіх осіб (наприклад, інших користувачів) не включаються

7.6 ПРАВО НА ЗАПЕРЕЧЕННЯ (ст. 21 GDPR)

• Проти обробки для законного інтересу (з обґрунтуванням)
• Проти прямого маркетингу (безумовне право)
• Проти профілювання для маркетингових цілей

Технічна реалізація:

• Налаштування в особистому кабінеті для маркетингових комунікацій
• Запит через email для інших цілей обробки

7.7 ПРАВО НЕ ПІДДАВАТИСЯ АВТОМАТИЗОВАНОМУ ПРИЙНЯТТЮ РІШЕНЬ (ст. 22 GDPR)

• Винятки з автоматичних рішень ШІ-психолога
• Право на втручання людини в критичних ситуаціях
• Можливість оскарження рішень алгоритму

Особливості для платформи ELLI:

ШІ-психолог надає рекомендації, але не приймає медичних рішень, що впливають на ваші права. Усі критичні випадки ескалюються до фахівця-людини.

7.8 РЕАЛІЗАЦІЯ ПРАВ

Способи звернення:

1. Особистий кабінет: Самостійне управління даними через інтерфейс (доступ до персональних даних, терапевтичних записів, експорт даних)
2. Електронна пошта (для складних запитів і видалення): https://e-lli.com/contact
3. Онлайн-форма (для запитів за правами GDPR): https://e-lli.com/contact

Терміни відповіді:

Стандартні запити: До 30 днів

Складні запити: До 90 днів (із повідомленням про продовження)

Екстрені випадки: До 72 годин (наприклад, видалення при загрозі безпеці)

Верифікація особи:

Для захисту ваших даних ми можемо запитати підтвердження особи при зверненнях:

• Код підтвердження на зареєстрований email
• Відповіді на контрольні питання
• Аутентифікація через Clerk

8. УПРАВЛІННЯ ЗГОДОЮ

8.1 ОТРИМАННЯ ЗГОДИ

Принципи дійсної згоди:

Вільна: Без примусу або негативних наслідків відмови

Конкретна: Для визначених цілей обробки

Інформована: З повним розумінням наслідків

Недвозначна: Через чіткі стверджувальні дії

Способи отримання:

• Прапорці у формах реєстрації (попередньо не відмічені)
• Кнопки підтвердження у спливаючих вікнах
• Електронний підпис документів
• Усна згода (з аудіозаписом)

Гранулярна згода при реєстрації:

При створенні акаунта через Clerk ви надаєте згоду на:

• Обробку персональних даних системою Clerk для аутентифікації
• Передачу хеш-ідентифікатора платформі ELLI
• Обробку терапевтичних даних за хеш-ідентифікатором

8.2 ВІДКЛИКАННЯ ЗГОДИ

Принципи відкликання:

Простота: Не складніше процедури отримання згоди

Доступність: Доступний у будь-який час через особистий кабінет

Негайність: Набирає чинності одразу після підтвердження

Наслідки відкликання:

• Припинення обробки даних для відповідних цілей
• Збереження законності попередньої обробки
• Можливе обмеження функціональності платформи (наприклад, неможливість продовження терапії без згоди на обробку)

Відкликання згоди на аутентифікацію:

При відкликанні згоди на обробку Clerk:

• Акаунт деактивується
• Персональні дані видаляються з Clerk
• Терапевтичні дані стають анонімними (розрив зв'язку хеш ↔ особа)

8.3 ГРАНУЛЯРНЕ УПРАВЛІННЯ ЗГОДОЮ

Користувачі можуть управляти згодою за категоріями:

Аутентифікація та персоналізація послуг: Обов'язково для роботи платформи (засновано на договорі)

Маркетингові комунікації: Опціонально (згоду можна відкликати)

Наукові дослідження: Опціонально (використання знеособлених даних)

Аналітика та покращення: Опціонально (Google Analytics, Hotjar)

Управління згодою:

• Центр налаштувань в особистому кабінеті
• Окремі перемикачі для кожної категорії
• Історія змін згоди

9. ФАЙЛИ COOKIE ТА ТЕХНОЛОГІЇ ВІДСТЕЖЕННЯ

9.1 ТИПИ ФАЙЛІВ COOKIE, ЩО ВИКОРИСТОВУЮТЬСЯ

9.1.1 Необхідні cookie (Strictly Necessary)

Сесійні ідентифікатори: Для підтримання сеансу

Токени Clerk: JWT-токени для аутентифікації (зберігаються в localStorage/cookies)

Налаштування безпеки: Для захисту від CSRF-атак

Вибір мови: Для запам'ятовування мовних переваг

Статус згоди: Для зберігання рішень про cookie

9.1.2 Функціональні cookie (Functional)

Користувацькі переваги: Налаштування інтерфейсу

Хеш-ідентифікатор користувача: Для прив'язки даних сесії (у зашифрованому вигляді)

Формати взаємодії: Улюблені способи зв'язку

Історія сесій: Для продовження перерваних консультацій

9.1.3 Аналітичні cookie (Analytics)

Google Analytics: Аналіз відвідуваності та поведінки (з IP-анонімізацією)

Hotjar: Теплові карти та записи сесій (лише зі згодою)

Azure Application Insights: Внутрішня аналітика продуктивності

9.1.4 Маркетингові cookie (Marketing)

Ретаргетинг: Для показу релевантної реклами

Соціальні мережі: Інтеграція з Facebook, Instagram

Email-кампанії: Відстеження ефективності розсилок

Контекст-кампанії: Інтеграція з Google ADS

9.2 УПРАВЛІННЯ COOKIE

Інструменти управління:

Cookie-банер: При першому відвідуванні сайту з гранулярним вибором

Центр налаштувань: В особистому кабінеті користувача

Налаштування браузера: Стандартні опції браузера

Мобільні налаштування: Управління в мобільному додатку

Clerk і cookie:

Clerk використовує secure, httpOnly cookies для зберігання сесійних токенів. Ці cookie:

• Автоматично видаляються при виході із системи
• Мають короткий термін дії (15 хвилин для access token)
• Захищені від XSS і CSRF атак

9.3 СТОРОННІ ІНТЕГРАЦІЇ

10. ОСОБЛИВОСТІ ОБРОБКИ ДАНИХ НЕПОВНОЛІТНІХ

10.1 ВІКОВІ ОБМЕЖЕННЯ

Мінімальний вік: 18 років

Верифікація віку: При реєстрації через форму Clerk

Винятки: Відсутні навіть зі згодою батьків

10.2 ПРОЦЕДУРИ ВИЯВЛЕННЯ ТА ВИДАЛЕННЯ

При виявленні даних неповнолітніх:

1. Негайне припинення обробки даних
2. Видалення акаунта з Clerk протягом 24 годин
3. Безповоротне стирання всіх пов'язаних даних із Azure
4. Повідомлення відповідних наглядових органів (при необхідності)

10.3 ЗАПОБІГАННЯ РЕЄСТРАЦІЇ

• Вікові фільтри у формах реєстрації Clerk
• Перевірка документів при підозрілих випадках
• Моніторинг патернів поведінки для виявлення неповнолітніх

11. ПОВІДОМЛЕННЯ ПРО ПОРУШЕННЯ БЕЗПЕКИ

11.1 ПРОЦЕДУРИ РЕАГУВАННЯ НА ІНЦИДЕНТИ

Тимчасові рамки:

Виявлення: Системи моніторингу 24/7 (Azure Security Center, Azure Sentinel)

Оцінка ризику: Протягом 6 годин

Повідомлення органів: Протягом 72 годин (якщо високий ризик)

Повідомлення користувачів: Без невиправданої затримки

Специфіка псевдонімізованих даних:

При оцінці ризику враховується, що:

• Витік лише хеш-ідентифікаторів без доступу до Clerk не дозволяє ідентифікувати користувачів
• Витік терапевтичних даних за хешами має знижений ризик завдяки псевдонімізації
• Критичним є компрометація системи Clerk або Azure Key Vault із ключами шифрування

11.2 КРИТЕРІЇ ПОВІДОМЛЕННЯ КОРИСТУВАЧІВ

Високий ризик для прав і свобод:

• Компрометація даних про здоров'я з можливістю реідентифікації
• Витік фінансових даних
• Одночасний витік із Clerk і ELLI, що дозволяє пов'язати хеш із особою
• Компрометація ключів шифрування з Azure Key Vault
• Ризик дискримінації або шахрайства
• Значні економічні або соціальні наслідки

Середній та низький ризик (повідомлення не обов'язкове):

• Витік лише хеш-ідентифікаторів без терапевтичних даних
• Витік агрегованих анонімних даних
• Тимчасові збої в системі без компрометації даних

11.3 ЗМІСТ ПОВІДОМЛЕНЬ

• Характер порушення безпеки
• Категорії та кількість постраждалих даних
• Оцінка ризику: врахування псевдонімізації та шифрування
• Ймовірні наслідки для користувачів
• Вжиті заходи щодо усунення порушення
• Рекомендації для користувачів (наприклад, зміна паролів)
• Контакти для отримання додаткової інформації

Координація з партнерами:

У разі інциденту негайно інформуються:

• Clerk (якщо зачеплена система аутентифікації)
• Microsoft Azure (якщо зачеплена інфраструктура)
• Регулятори (відповідно до GDPR стаття 33)

12. ЗМІНИ В ПОЛІТИЦІ КОНФІДЕНЦІЙНОСТІ

12.2 ПОВІДОМЛЕННЯ ПРО ЗМІНИ

Істотні зміни:

• Email-повідомлення за 14 днів до набрання чинності
• Повідомлення в додатку для активних користувачів
• Банер на сайті про майбутні зміни
• Push-повідомлення в мобільному додатку

Незначні зміни:

• Публікація оновленої версії на сайті
• Зазначення дати останнього оновлення

12.3 ЗГОДА НА ЗМІНИ

• Продовження використання = згода з новими умовами
• Можливість відмови до набрання чинності змінами
• Період адаптації у 14 днів для користувачів
• Експорт даних: можливість запитати дані до набрання чинності змінами

13. ТРАНСКОРДОННІ ПЕРЕДАЧІ ДАНИХ

13.1 КРАЇНИ ТА ТЕРИТОРІЇ ОБРОБКИ

Основні локації:

• Україна: Основні сервери та персонал
• Європейський Союз: Резервні системи Azure (Німеччина, Нідерланди, Ірландія)
• США:
• Clerk, Inc. (San Francisco, CA) — система аутентифікації
• Microsoft Azure (при використанні американських дата-центрів для non-EU користувачів)

Пріоритет зберігання даних:

• Для користувачів з ЄС/ЄЕЗ: Дані зберігаються виключно в європейських дата-центрах Azure (EU Data Boundary)
• Для користувачів з України: Пріоритетне зберігання в ЄС з резервуванням
• Для інших регіонів: Найближчий географічний дата-центр Azure

13.2 МЕХАНІЗМИ ЗАХИСТУ

• Рішення про достатність ЄС для країн з адекватним захистом
• Стандартні договірні положення (SCC 2021) для передачі даних до США (Clerk) та інших країн без рішення про достатність
• Microsoft EU Data Boundary: Гарантія зберігання даних європейських користувачів в ЄС
• Clerk Data Processing Addendum (DPA): Угода зі стандартними договірними положеннями
• Корпоративні обов'язкові правила (BCR) Microsoft для внутрішньогрупових передач

13.3 ДОДАТКОВІ ГАРАНТІЇ

• Шифрування даних на всіх етапах передачі (TLS 1.3)
• Псевдонімізація перед передачею: Лише хеш-ідентифікатори передаються між Clerk та ELLI
• Обмежений доступ лише авторизованого персоналу
• Регулярні аудити відповідності стандартам захисту
• Контрактні гарантії від усіх обробників даних

Спеціальні заходи для транскордонних передач даних про здоров'я:

1. Подвійне шифрування перед будь-якою транскордонною передачею
2. Зберігання ключів в ЄС: Ключі шифрування даних європейських користувачів зберігаються виключно в Azure Key Vault EU
3. Мінімізація передач: Обробка даних відбувається максимально близько до користувача
4. Логування всіх транскордонних операцій для аудиту

13.4 ПРАВА ПРИ ТРАНСКОРДОННИХ ПЕРЕДАЧАХ

Ви маєте право:

• Отримати інформацію про те, до яких країн передаються ваші дані
• Запитати копії механізмів захисту (SCC, DPA)
• Заперечити проти передачі в певні юрисдикції
• Вимагати локалізацію даних (якщо технічно можливо)

14. КОНТРОЛЬНІ ОРГАНИ ТА ПОДАННЯ СКАРГ

14.1 УКРАЇНСЬКІ КОНТРОЛЬНІ ОРГАНИ

Уповноважений Верховної Ради з прав людини

Адреса: вул. Інституцька, 21/8, Київ, 01008

Телефон: +380 44 253-93-48

Сайт: ombudsman.gov.ua

Email: hotline@ombudsman.gov.ua

14.2 ЄВРОПЕЙСЬКІ КОНТРОЛЬНІ ОРГАНИ

При обробці даних суб'єктів ЄС:

Керівний контрольний орган: Визначається за основним місцем діяльності

Місцеві контрольні органи: За місцезнаходженням суб'єкта даних

Приклади контрольних органів ЄС:

• CNIL (Франція)
• ICO (Велика Британія)
• BfDI (Німеччина)
• Autoriteit Persoonsgegevens (Нідерланди)

14.3 ПРОЦЕДУРИ ПОДАННЯ СКАРГ

Внутрішні процедури (рекомендується спочатку):

1. Звернення електронною поштою: https://e-lli.com/contact
2. Детальний опис проблеми
3. Термін розгляду: до 30 днів
4. Письмова відповідь з результатами розгляду

Звернення до контрольних органів:

• Можливо паралельно з внутрішнім розглядом
• Не потребує попереднього звернення до нас
• Розглядається безкоштовно

Координація з партнерами при скаргах:

При скаргах, що стосуються системи аутентифікації або інфраструктури:

• Clerk та Microsoft Azure будуть повідомлені
• Надання спільних пояснень та документації
• Координація заходів щодо усунення проблем

15. ТЕХНІЧНА ТА ПРАВОВА ПІДТРИМКА

15.1 КОНТАКТНА ІНФОРМАЦІЯ

З загальних питань конфіденційності:

Онлайн-форма: https://e-lli.com/contact

Час відповіді: До 48 годин у робочі дні

З технічних питань безпеки:

Email: https://e-lli.com/contact

Екстрені випадки: Відповідь протягом 12 годин

PGP-ключ: Доступний для зашифрованого листування

З правових питань:

Email: https://e-lli.com/contact

Питання про роботу Clerk та аутентифікацію:

Технічна підтримка ELLI: https://e-lli.com/contact

Безпосередньо в Clerk: support@clerk.com (для критичних інцидентів)

Питання про інфраструктуру Azure:

Через службу підтримки ELLI: https://e-lli.com/contact

15.2 МОВНА ПІДТРИМКА

Консультації доступні такими мовами:

• Українська мова;
• Російська мова;
• Англійська мова.

16. ЗАСТОСОВНЕ ЗАКОНОДАВСТВО ТА ЮРИСДИКЦІЯ

16.1 ІЄРАРХІЯ ЗАСТОСОВНИХ НОРМ

1. GDPR — для суб'єктів даних з ЄС/ЄЕЗ
2. Законодавство України — для українських резидентів
3. HIPAA — для даних про здоров'я американських громадян
4. Місцеве законодавство — для користувачів з інших країн

Застосування до партнерів:

• Clerk зобов'язаний дотримуватися GDPR, CCPA та інших застосовних законів
• Microsoft Azure відповідає GDPR, HIPAA, ISO 27001 та регіональним вимогам

16.2 ВИРІШЕННЯ СПОРІВ

Пріоритетний порядок:

1. Добровільне врегулювання через переговори
2. Медіація через незалежних посередників
3. Арбітраж згідно з правилами LCIA
4. Судовий розгляд у судах України

Застосовне право:

• Матеріальне право України
• Процесуальні норми юрисдикції розгляду спору
• Міжнародні договори та конвенції (при застосовності)

16.3 ОСОБЛИВОСТІ ДЛЯ МІЖНАРОДНИХ КОРИСТУВАЧІВ

Для користувачів з ЄС:

• Можливість звернення до місцевих контрольних органів
• Застосування принципу «одного вікна» при транскордонній обробці
• Право вибору юрисдикції для судових спорів

Для користувачів зі США:

• Додаткові гарантії відповідно до HIPAA
• Можливість арбітражу згідно з AAA Rules
• Застосування федерального законодавства США при необхідності

17. СПЕЦІАЛЬНІ ПОЛОЖЕННЯ ДЛЯ ДАНИХ ПРО ЗДОРОВ'Я

17.1 КЛАСИФІКАЦІЯ ДАНИХ ПРО ЗДОРОВ'Я

Відповідно до GDPR (стаття 9) та HIPAA, дані про психічне здоров'я класифікуються як спеціальна категорія даних, що потребує підвищеного захисту:

• Психологічні оцінки та діагнози
• Інформація про емоційний стан
• Зміст терапевтичних сесій
• Результати психометричних тестів
• Інформація про ліки, що приймаються

17.2 ДОДАТКОВІ ЗАХОДИ ЗАХИСТУ

Технічні заходи:

• Подвійне шифрування для даних про здоров'я (клієнтське AES-256 + серверне TDE)
• Роздільне зберігання ключів шифрування в Azure Key Vault
• Псевдонімізація через хеш-ідентифікатори: Терапевтичні дані прив'язані лише до хешів
• Заборона на обробку без явної згоди
• Детальне логування всіх операцій в Azure Monitor

Організаційні заходи:

• Обмежене коло співробітників з доступом (менше 5 осіб)
• Спеціальне навчання персоналу з медичної конфіденційності та етики
• Дотримання етичних принципів медичної практики
• Регулярні аудити відповідності HIPAA та медичним стандартам

Переваги псевдонімізації для даних про здоров'я:

Розділення між Clerk (персональні дані) та ELLI (терапевтичні дані за хешем) забезпечує додатковий рівень захисту:

• Компрометація однієї системи не розкриває повну картину
• Співробітники ELLI не можуть ідентифікувати користувачів за терапевтичними записами
• Зниження ризиків при необхідності передачі даних дослідникам (передаються лише знеособлені дані)

17.3 ПРАВА НА ДАНІ ПРО ЗДОРОВ'Я

Додаткові права користувачів:

• Право на отримання медичної копії у сумісному форматі (FHIR, PDF)
• Право призначити представника для медичних даних (через Clerk)
• Право обмежити розкриття певних категорій даних
• Право на облік розкриттів інформації третім сторонам (HIPAA Accounting of Disclosures)

Спеціальні процедури для даних про здоров'я:

• Посилена верифікація особи при запитах на доступ
• Обов'язкове шифрування при передачі копій даних
• Додаткове підтвердження при видаленні даних про здоров'я

18. АВТОМАТИЗОВАНЕ ПРИЙНЯТТЯ РІШЕНЬ ТА ПРОФІЛЮВАННЯ

18.1 ВИКОРИСТАННЯ ШІ ДЛЯ ПРИЙНЯТТЯ РІШЕНЬ

Платформа ELLI використовує штучний інтелект для:

• Персоналізації рекомендацій на основі ваших відповідей
• Аналізу прогресу терапевтичних сесій
• Виявлення патернів у емоційному стані
• Виявлення кризових ситуацій що потребують втручання

ШІ працює з псевдонімізованими даними:

• Алгоритми обробляють дані, прив'язані до хеш-ідентифікаторів
• ШІ не має доступу до ваших персональних даних з Clerk
• Рекомендації генеруються на основі патернів, а не особистої інформації

18.2 ОБМЕЖЕННЯ АВТОМАТИЧНИХ РІШЕНЬ

ШІ НЕ приймає автоматичні рішення щодо:

• Медичних діагнозів або лікування
• Призначення лікарських препаратів
• Примусового втручання без згоди
• Юридично значущих наслідків для користувача
• Розкриття вашої особи третім сторонам

18.3 ПРАВА ПРИ АВТОМАТИЗОВАНІЙ ОБРОБЦІ

• Право на втручання людини в процес прийняття рішень
• Право на пояснення логіки автоматизованої обробки
• Право не піддаватися виключно автоматизованому прийняттю рішень
• Право оскаржити результати автоматичної обробки

Технічна реалізація:

Ви можете запросити через https://e-lli.com/contact:

• Пояснення конкретної рекомендації ШІ
• Перегляд рішення фахівцем-людиною
• Відключення певних функцій ШІ-аналізу

19. ОБРОБКА ДАНИХ У НАДЗВИЧАЙНИХ СИТУАЦІЯХ

19.1 ВИЗНАЧЕННЯ НАДЗВИЧАЙНИХ СИТУАЦІЙ

Ситуації, що потребують негайного реагування:

• Суїцидальні думки або наміри
• Загроза заподіяння шкоди собі або іншим
• Ознаки тяжкого психічного розладу
• Підозра на злочинну діяльність (наприклад, насильство, торгівля людьми)

19.2 ПРОЦЕДУРИ ЕКСТРЕНОГО РЕАГУВАННЯ

Автоматичні системи:

• ШІ-детекція критичних фраз та станів (працює на рівні хеш-ідентифікаторів)
• Негайні попередження користувачу з контактами допомоги
• Ескалація до людини-фахівця протягом 15 хвилин

19.3 ПРАВОВІ ПІДСТАВИ ЕКСТРЕНОЇ ОБРОБКИ

• Життєві інтереси суб'єкта даних (стаття 6(1)(d) GDPR)
• Медичні цілі в надзвичайних ситуаціях (стаття 9(2)(c) GDPR)
• Захист інших осіб від серйозної шкоди
• Дотримання правового обов'язку щодо повідомлення про загрози (згідно із законодавством України)

20. ДОСЛІДЖЕННЯ ТА РОЗРОБКИ

20.1 ВИКОРИСТАННЯ ДАНИХ ДЛЯ R&D

Цілі наукових досліджень:

• Розвиток методів цифрової терапії
• Покращення алгоритмів ШІ-психології
• Публікація наукових робіт у рецензованих журналах
• Співпраця з університетами та дослідницькими центрами

Використання псевдонімізованих даних:

• Дослідники отримують доступ лише до даних, прив'язаних до хеш-ідентифікаторів
• Повна відсутність персональних даних у дослідницьких наборах
• Додаткова агрегація та узагальнення даних перед передачею

20.2 ПРИНЦИПИ ЕТИЧНИХ ДОСЛІДЖЕНЬ

Дотримання етичних стандартів:

• Схвалення етичними комітетами перед початком досліджень
• Анонімізація всіх даних перед використанням у дослідженнях (видалення навіть хеш-ідентифікаторів, заміна на дослідницькі коди)
• Окрема згода на участь у дослідженнях
• Право відмови від участі без наслідків для основних послуг

20.3 ПУБЛІКАЦІЯ РЕЗУЛЬТАТІВ

Принципи відкритої науки:

• Публікація у відкритому доступі за можливості
• Прозорість методології та використаних даних
• Неможливість реідентифікації учасників досліджень (навіть через хеш-ідентифікатори)
• Надання агрегованих даних для верифікації результатів

Приклади публікацій:

• "Ефективність ШІ-терапії для тривожних розладів" (дані 5000+ анонімних користувачів)
• "Патерни емоційних станів у цифровій терапії" (агрегована статистика)

21. ПАРТНЕРСТВА ТА ІНТЕГРАЦІЇ

21.1 ТИПИ ПАРТНЕРСЬКИХ ВІДНОСИН

Технологічні партнери:

Clerk, Inc. — Система аутентифікації та управління ідентифікацією

• Роль: Обробник персональних даних
• Місцезнаходження: США (San Francisco, CA)
• Відповідність: GDPR, SOC 2 Type II, CCPA

Microsoft Corporation (Azure) — Хмарна інфраструктура

• Роль: Субобробник для зберігання та обробки
• Місцезнаходження: ЄС (Нідерланди, Ірландія, Німеччина) для європейських користувачів
• Відповідність: GDPR, ISO 27001, ISO 27018, HIPAA, SOC 1/2/3

Google LLC (Analytics) — Веб-аналітика

• Роль: Обробник аналітичних даних
• Дані: Анонімізовані метрики

Hotjar Ltd. — UX-дослідження

• Роль: Обробник поведінкових даних
• Дані: Записи сесій (лише зі згодою)

Платіжні системи:

• Stripe, PayPal, MonoBank — Обробка транзакцій
• Дані: Мінімальні платіжні дані

Медичні та наукові партнери:

• Університети для спільних досліджень (передача повністю анонімізованих даних)
• Професійні психологи для консультацій (без доступу до персональних даних)
• Дослідницькі інститути в галузі ментального здоров'я

21.2 УГОДИ ПРО ОБРОБКУ ДАНИХ (DPA)

З кожним партнером укладаються:

• Угоди про обробку даних відповідно до GDPR стаття 28
• Технічні та організаційні заходи захисту даних
• Детальний опис цілей та способів обробки
• Зобов'язання щодо дотримання застосовного законодавства
• Обмеження на субобробку (партнери зобов'язані повідомляти нас про нових субобробників)

Ключові положення DPA з Clerk:

• Clerk виступає виключно в ролі обробника даних
• Обробляє дані лише за нашими інструкціями
• Не використовує дані для власних цілей
• Зобов'язується видалити або повернути дані після закінчення співпраці
• Надає повну прозорість своїх субобробників

Ключові положення DPA з Microsoft Azure:

• Дотримання EU Data Boundary для європейських користувачів
• Шифрування всіх даних at-rest та in-transit
• Зобов'язання не розкривати дані державним органам без повідомлення (за винятком юридично обов'язкових випадків)
• Регулярні аудити безпеки

21.3 КОНТРОЛЬ НАД ПАРТНЕРАМИ

Регулярні перевірки включають:

• Аудити відповідності стандартам захисту даних (щороку)
• Моніторинг дотримання умов DPA
• Звіти про інциденти безпеки (протягом 24 годин)
• Оновлення угод при зміні обставин
• Перевірка сертифікатів (SOC 2, ISO 27001) партнерів

22. ПОВІДОМЛЕННЯ ТА КОМУНІКАЦІЇ

22.1 КАНАЛИ КОМУНІКАЦІЇ

Офіційні канали для важливих повідомлень:

• Email-повідомлення на зареєстровану адресу (через Clerk)
• Повідомлення в особистому кабінеті на платформі
• Публічні оголошення на офіційному сайті

22.2 ТИПИ ПОВІДОМЛЕНЬ

За критичністю:

Критичні (негайно):

• Порушення безпеки даних
• Зміни в системі аутентифікації (Clerk)
• Зміни в умовах обробки даних про здоров'я
• Припинення роботи сервісу

Важливі (до 7 днів):

• Істотні зміни в Політиці
• Нові партнерства, що впливають на обробку даних
• Зміни в правах користувачів
• Міграція інфраструктури (наприклад, зміна дата-центрів Azure)

Інформаційні (до 30 днів):

• Нові функції платформи
• Технічні оновлення
• Маркетингові комунікації (при згоді)

22.3 НАЛАШТУВАННЯ ПОВІДОМЛЕНЬ

Користувачі можуть налаштувати:

• Частоту email-повідомлень (крім критичних)
• Мову комунікації (українська, російська, англійська)
• Бажаний канал (email, push, SMS)

Важливо: Критичні повідомлення про безпеку надсилаються завжди, незалежно від налаштувань.

23. ЗАКЛЮЧНІ ПОЛОЖЕННЯ

23.1 ПОВНОТА ТА АКТУАЛЬНІСТЬ ПОЛІТИКИ

Ця Політика конфіденційності представляє повний та вичерпний опис практик обробки персональних даних платформою ELLI. Усі попередні версії політик та угод втрачають чинність з дати набрання чинності цим документом.

23.2 ПРІОРИТЕТ ДОКУМЕНТІВ

У разі суперечностей між документами:

1. Політика конфіденційності (цей документ)
2. Користувацька угода
3. DPA з партнерами (Clerk, Microsoft Azure)
4. Політика відмови від відповідальності
5. Додаткові угоди та умови

23.3 НЕДІЙСНІСТЬ ОКРЕМИХ ПОЛОЖЕНЬ

Якщо будь-яке положення цієї Політики буде визнано недійсним або невиконуваним компетентним судом або регулюючим органом, це не впливає на чинність решти положень.

23.4 ПЕРЕКЛАДИ ТА МОВНІ ВЕРСІЇ

• Українська версія є основною при тлумаченні
• Російська версія має рівну юридичну силу
• Англійська версія призначена для міжнародних користувачів

Примітка: при суперечностях пріоритет має українська версія

23.5 ТЕХНІЧНИЙ ГЛОСАРІЙ

Для кращого розуміння технічних аспектів:

Хеш-ідентифікатор (Hash ID) — Унікальний криптографічний рядок (наприклад, user_2nX8Kq9P3mN7vLbR4tY6wZ1s), який неможливо зворотно перетворити на вихідні дані. Використовується для прив'язки даних без зберігання персональної інформації.

Clerk — Професійна платформа управління аутентифікацією, яка обробляє ваші персональні дані (email, ім'я) окремо від терапевтичних даних ELLI.

Псевдонімізація — Метод захисту даних, при якому персональні дані обробляються таким чином, що їх більше не можна віднести до конкретної людини без додаткової інформації, яка зберігається окремо.

Azure — Хмарна платформа Microsoft, що використовується для безпечного зберігання зашифрованих даних.

JWT-токен — Тимчасовий зашифрований токен доступу, який підтверджує вашу особу без передачі пароля.

TLS 1.3 — Сучасний протокол шифрування для захисту даних при передачі через інтернет.

AES-256 — Військовий стандарт шифрування для захисту даних у сховищі.

24. НАБРАННЯ ЧИННОСТІ ТА ПЕРЕХІДНІ ПОЛОЖЕННЯ

24.1 ДАТА НАБРАННЯ ЧИННОСТІ

Ця Політика конфіденційності набирає чинності 8 серпня 2025 року та застосовується до всіх операцій обробки персональних даних з зазначеної дати.

24.2 ПЕРЕХІДНІ ПОЛОЖЕННЯ

Для існуючих користувачів:

• Період адаптації: 30 днів з дати набрання чинності
• Автоматичне застосування нових умов при продовженні використання
• Право відмови з видаленням акаунта в перехідний період (без штрафних санкцій)
• Індивідуальні повідомлення про ключові зміни (особливо про впровадження системи Clerk)

Для нових користувачів:

• Негайне застосування всіх положень цієї Політики
• Обов'язкова згода при реєстрації через Clerk
• Повне ознайомлення перед початком використання

24.3 АРХІВУВАННЯ ПОПЕРЕДНІХ ВЕРСІЙ

Усі попередні версії Політики конфіденційності архівуються та залишаються доступними для ознайомлення на сайті протягом 5 років з дати їх заміни.

Доступ до архіву: https://e-lli.com/contact

КОНТАКТНА ІНФОРМАЦІЯ

Загальні питання з конфіденційності; Питання безпеки даних; Технічна підтримка; Та інші:

Contact form: https://e-lli.com/contact

Документ підготовлено з дотриманням вимог:

• Загального регламенту про захист даних ЄС (GDPR)
• Закону України "Про захист персональних даних"
• Закону США про переносимість та підзвітність медичного страхування (HIPAA)
• Принципів Privacy by Design and by Default
• Міжнародних стандартів ISO 27001, ISO 27018

УВАГА: Ця Політика Конфіденційності є юридично обов'язковим документом. Уважно ознайомтеся з усіма положеннями перед використанням Платформи.

Завдяки використанню псевдонімізації через хеш-ідентифікатори та розділенню даних, ми забезпечуємо максимальний захист вашої конфіденційності відповідно до принципів Privacy by Design.

© 2025 ELLI. Усі права захищені.

Дата останнього оновлення: 8 серпня 2025 року

Версія документа: 1.0

Legal