Право на забуття

1) Що таке «право на забуття» і коли воно застосовується

Right to Erasure - право суб'єкта даних вимагати видалення своїх персональних даних. В ЄС закріплено в GDPR ст. 17; аналоги існують в ряді юрисдикцій (видалення по CCPA/CPRA, LGPD і ін.).

• Дані більше не потрібні для цілей, заради яких збиралися.
• Обробка заснована на згоді, і суб'єкт його відкликав.
• Суб'єкт заперечує проти обробки (немає переважаючих законних підстав).
• Дані оброблялися незаконно або потрібно виконати правовий обов'язок щодо видалення.
• Дані зібрані у дитини при пропозиції послуг інформаційного суспільства (спец-основа).

2) Винятки: коли видаляти не можна (або не все)

• Юридичних обов'язків (наприклад, AML/KYC, податковий облік, бухгалтерські документи).
• Встановлення, здійснення або захисту правових вимог (судові/претензійні спори).
• Свободи вираження думок/права на інформацію, суспільних інтересів в галузі охорони здоров'я, наукових/історичних/статистичних цілей з належними гарантіями.

На практиці в iGaming/фінтехе найчастіше діє юридичний hold по AML/KYC (≥5 років після закінчення відносин). У таких випадках дані блокуються для інших цілей, але не видаляються до закінчення терміну.

3) Видалення vs деактивація vs анонімізація

Видалення - безповоротне знищення персональних даних.
Анонімізація - незворотне виключення зв'язку з особистістю; дані можуть залишитися в агрегатній аналітиці/ML без ідентифікаторів.
Деактивація (закриття аккаунта) - відключення доступу/функцій, дані залишаються до закінчення термінів/винятків.

Рекомендація: застосовувати гібрид - максимальне видалення + анонімізація для продуктової аналітики, де це доречно.

4) Процес DSR на видалення: від запиту до підтвердження

1. Прийом запиту по доступних каналах (веб-форма, email, профіль).
2. Верифікація заявника (рівень перевірки залежить від ризику/чутливості).
3. Перевірка винятків (AML/податки/спори, активні chargeback/фрод-розслідування).
4. Класифікація охоплення: повний профіль/конкретні категорії/маркетинг.
5. Mark-for-Deletion + запуск Deletion Orchestrator (див. § 7).
6. Повідомлення вендорів/третіх осіб (процесори/підрядники) і фіксація відгуків.
7. Підтвердження суб'єкту: що видалено, що анонімізовано, що заблоковано за винятками, терміни за бекапами.
8. Логування: WORM-журнал доказів видалення.

SLA (орієнтир): відповідь протягом 30 днів (можна продовжити ще на 60 з повідомленням і обґрунтуванням).

5) Матриця «підстава → рішення → пояснення»

6) Що саме видаляти: охоплення по шарах

Транзакційний шар: профіль, контактні дані, токени (де дозволено), платіжні ідентифікатори, KYC-артефакти (якщо немає винятків).
Шари похідних даних: кеші, пошукові індекси, черги, feature store ML, DWH, вітрини BI, звіти.
Логи/трасування: де є персональні ідентифікатори - маска/видалення; допускається агрегування/анонімізація.
Маркетинг/атрибуція: ідентифікатори (cookie/SDK/MAID), постбеки афіліатів, аудиторії реклами - очищення і suppression.
Профілювання/моделі: видалення з навчальних датасетів майбутніх ітерацій, позначки «do-not-use» у фіче-сторі.

7) Оркестрація видалення (каскад і бекапи)

• Mark-for-Deletion → Grace (7-30 днів) → Soft Delete (відключення доступу/комунікацій) → Hard Delete/Anonymize в первинних системах → Cascade в кеші/індекси/DWH/ML → EL vidence Log.
• Backups: пряме редагування бекапів не допускається; видалення здійснюється через витікання вікна зберігання і заборону відновлень, що призводять до ідентифікації. При відновленні - sanitization-скрипт повторного видалення позначених ID.

• Ідемпотентні завдання, ретраї, дедуплікація команд.
• Трасування lineage (де копії та агрегати).
• Єдиний subject-key для каскаду по всіх системах.
• WORM-архів актів видалення.

8) Вендори/процесори: повідомлення та договори

У DPA зобов'язати процесорів: видаляти/повертати дані за інструкціями, допомагати з DSR, логувати видалення, повідомляти про результати.
Реєстр субпроцесорів; терміни відгуку на запити видалення (SLA).
Для рекламних/аналітичних платформ - режими restricted processing, API-сигнали'delete/suppress'.

9) Шаблони комунікацій (фрагменти)

• "Ми отримали ваш запит на видалення даних. Для захисту вашої приватності нам потрібно підтвердити вашу особистість. Будь ласка, пройдіть коротку перевірку за посиланням/кодом"

• "Ми видалили/знеособили ваші персональні дані в продуктах і системах аналітики. Записи, які зобов'язані зберігатися за законом (наприклад, AML/податки), заблоковані і недоступні для інших цілей до закінчення N років. Дані в резервних копіях будуть видалені за графіком їх зберігання. Ідентифікатор запиту: #XXXX.»

• "Ми не можемо видалити частину записів через правовий обов'язок зберігання (AML/податки/спір). Ці записи ізольовані і використовуються тільки за обов'язковою метою. Ми видалили решту інформації і припинили необов'язкову обробку"

10) Матриця «категорія даних → метод → термін»

11) UX і продуктові нюанси

У профілі - зрозуміла кнопка «Видалити мої дані/закрити аккаунт» з роз'ясненням наслідків (втрата прогресу/бонусів).
Окрема опція «Відмова від маркетингу» (не дорівнює видаленню аккаунта).
Статус запиту (в роботі/виконано), термін завершення, ідентифікатор заявки.
Видалення не повинно ламати фінансову звітність: зберігайте неперсональні агрегати.

12) Метрики та контроль

Deletion SLA: медіана/95-й перцентиль від запиту до завершення.
Cascade Completion Rate: частка систем, де каскад завершено ≤SLA.
Backups Window Compliance: дотримання вікон зберігання бекапів.
Legal Hold Review Rate: своєчасність перегляду холдів.
DSR Rejection Rate (з причин): частка відмов з обґрунтуванням.
Evidence Completeness: частка кейсів з повним пакетом артефактів.
Suppression Effectiveness: відсутність маркетингових звернень після видалення.

13) Чек-листи (операційні)

Перед стартом процесу

• Верифікація особистості виконана.
• Перевірені винятки (AML/податки/спори).
• Визначено охоплення (повний/частковий).
• Створено запис в Evidence Log.

Виконання

• Mark-for-Deletion і Grace задані.
• Виконаний Hard Delete/Anonymize в транзакційному шарі.
• Запущено каскад в кеші/індекси/DWH/ML.
• Надіслані сповіщення процесорам/вендорам.
• Оновлено suppression list.

Завершення

• Підтвердження користувачеві з деталями.
• Оновлений RoPA/Retention-матриця при необхідності.
• Пост-чек звітів: SLA/помилки/повтори.

14) Ролі та відповідальність (RACI)

Support/Privacy Ops: прийом запитів, верифікація, комунікації.
DPO/Legal: оцінка підстав/винятків, legal hold.
Security/CISO: аудит доступу, WORM-логи, бекапи.
Data Engineering: оркестратор видалення, lineage, каскади.
Marketing/CRM: suppression, зупинка комунікацій.
Finance/Compliance: контроль звітності/AML-обов'язків.

15) Дорожня карта впровадження (6 кроків)

1. Політики та реєстри: оновити Privacy Policy (розділ про право на видалення), RoPA, Retention Matrix.
2. Оркестратор: єдиний subject-key, каскади, idempotency, Evidence Log (WORM).
3. Вендори: DPA-вимоги, канали'delete/suppress', SLA.
4. UX: зрозуміла заявка на видалення, статуси, шаблони листів.
5. Бекапи: вікна зберігання, заборона несанкціонованих відновлень, sanitization-скрипти.
6. Вимірювання: дашборд SLA, Cascade, Evidence, Suppression; Квартальні аудити.

16) Відмінності по юрисдикціях (коротко)

GDPR: широке право на видалення + чіткі винятки; термін відповіді 1 місяць.
CCPA/CPRA: право на видалення у споживачів; обов'язкові винятки (безпека/обслуговування/помилки/правові зобов'язання); потрібно облік GPC для opt-out від «sale/share», а також механізми видалення даних, що не підпадають під винятки.
LGPD: видалення при досягненні мети/закінчення терміну/відкликання згоди; винятки і «блокування» аналогічні за духом GDPR.

Підсумок

Право на забуття - це не «кнопка», а наскрізний процес: юридична оцінка підстав і винятків → верифікація → каскадне видалення і/або анонімізація у всіх шарах → управління бекапами і вендорами → доказовість і метрики. Вбудувавши цей контур в архітектуру і операції, ви дотримаєтеся вимог регуляторів, зменшите поверхню ризику і збережете довіру користувачів - без шкоди для бізнесу і якості продукту.