GDPR Consent — суть, вимоги та отримання згоди

Що таке GDPR Consent?

GDPR Consent — це правова підстава для обробки персональних даних, визначена в статті 4(11) і статті 7 Загального регламенту про захист даних Європейського Союзу. Регламент набрав чинності 25 травня 2018 року і замінив застарілу Директиву 95/46/EC, встановивши єдині стандарти захисту даних для всіх країн-членів ЄС.

Згідно з GDPR, згода має бути вільною — у користувача має бути реальний вибір без негативних наслідків за відмову. Якщо відмова від згоди призводить до відмови в доступі до послуги, яка не вимагає обробки даних, така згода вважається вимушеною та недійсною. Стаття 7(4) прямо вказує, що пов'язані договірні умови не можуть зумовлювати виконання договору отриманням згоди на обробку даних, не необхідних для цього договору.

Інформованість — другий ключовий елемент: суб'єкт даних повинен розуміти, які саме дані збираються, з якою метою, хто їх оброблятиме і як довго вони зберігатимуться. Європейська рада із захисту даних (EDPB) у керівництві 05/2020 наголошує, що інформація має надаватися зрозумілою мовою, без складних юридичних формулювань. Практика показує, що згода визнається недійсною, якщо політика конфіденційності містить двозначні або загальні формулювання.

Однозначність означає, що згода має бути виражена активною дією — встановленням прапорця, натисканням кнопки або підписанням форми. Бездіяльність, мовчання або попередньо встановлені прапорці не відповідають вимозі однозначності. У рішенні по справі Planet49 GmbH (C-673/17) Суд Європейського Союзу підтвердив, що згода не може матися на увазі з бездіяльності користувача.

Які дані підпадають під GDPR

Персональні дані за GDPR — це будь-яка інформація, що відноситься до ідентифікованої або ідентифікованої фізичної особи. Сюди входять не лише очевидні ідентифікатори — ім'я, адреса, email, телефон, — але й IP-адреси, cookie-ідентифікатори, рекламні ідентифікатори пристроїв (IDFA, GAID), біометричні дані, геолокація та генетична інформація.

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

Коли GDPR Consent обов'язкове

GDPR Consent вимагається, коли обробка даних не може ґрунтуватися на інших законних підставах: договірній необхідності (стаття 6(1)(b)), законному інтересі (стаття 6(1)(f)) або виконанні юридичного зобов'язання (стаття 6(1)(c)). На практиці згода необхідна для маркетингових розсилок, відстеження в рекламних цілях, збору необов'язкових даних та використання файлів cookie, що не є строго необхідними для функціонування сервісу.

За даними дослідження IAPP-EY Annual Governance Report (2024), 67% компаній використовують згоду як основну правову підставу для обробки даних у мобільних додатках, незважаючи на зростаючу тенденцію переходу до законного інтересу там, де це можливо. Це пов'язано з тим, що згода забезпечує найбільш прозорі відносини з користувачем, але одночасно накладає максимальні зобов'язання щодо обліку та управління згодами.

Основні вимоги GDPR до згоди

Стаття 7 GDPR встановлює шість умов дійсності згоди, кожна з яких має бути виконана одночасно. Порушення хоча б однієї умови робить згоду недійсною, а обробку даних — незаконною. Розберемо кожну умову докладно з урахуванням керівництв EDPB та судової практики.

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

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

Доказовість — найскладніша технологічна вимога. Стаття 7(1) прямо вказує, що контролер несе тягар доказування отримання згоди. На практиці це означає необхідність вести журнал усіх дій користувача: хто, коли, на які цілі дав згоду, яка версія політики конфіденційності була показана та як користувач її відкликав.

Як реалізувати збір згоди в мобільному додатку

Реалізація GDPR Consent в мобільному додатку вимагає комплексного підходу, що поєднує юридичні вимоги з технічною реалізацією. Основний інструмент — Consent Management Platform (CMP), яка керує життєвим циклом згоди: відображення запиту, фіксація вибору, зберігання даних та синхронізація з рекламними та аналітичними SDK.

Використання Google UMP SDK

Google надає User Messaging Platform (UMP) SDK для Android та iOS, який інтегрується з AdMob, Google Analytics та іншими сервісами Google. UMP SDK автоматично визначає необхідність показу згоди на основі геолокації користувача та вимог GDPR. Розглянемо інтеграцію на Kotlin для Android:

val requestParams = ConsentRequestParameters
    .Builder()
    .setTagForUnderAgeOfConsent(false)
    .build()

ConsentInformation
    .getInstance(this)
    .requestConsentInfoUpdate(requestParams, { @Override
        fun onConsentInfoUpdateSuccess() {
            if (ConsentInformation
                    .getInstance(this@MainActivity)
                    .isConsentFormAvailable()
            ) {
                loadConsentForm()
            }
        }
    }, { @Override
        fun onConsentInfoUpdateFailure(error: FormError) {
            Log.e("UMP", error.message)
        }
    })

Після завантаження форми згоди її необхідно показати користувачеві. UMP SDK підтримує два типи форм: для отримання згоди на персоналізовану рекламу та для управління вибором надалі. Обробка результату повинна враховувати всі можливі результати — користувач може дати згоду, відмовитися або закрити форму без вибору.

Зберігання та верифікація згоди

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

data class ConsentRecord(
    val userId: String,
    val timestamp: Long,
    val privacyPolicyVersion: String,
    val purposes: List<String>,
    val consentGiven: Boolean
)

class ConsentRepository(
    private val dao: ConsentDao
) {
    suspend fun saveConsent(record: ConsentRecord) {
        dao.insert(record.toEntity())
        AnalyticsManager.logConsentEvent(record)
    }
}

European Data Protection Board (EDPB) в рекомендаціях 01/2023 наголошує, що записи про згоду повинні зберігатися протягом усього періоду обробки даних і до трьох років після її припинення. Для мобільних додатків це означає необхідність серверного зберігання записів, а не лише локального, оскільки користувач може перевстановити додаток або змінити пристрій.

Чим GDPR відрізняється від інших регуляторів приватності

GDPR — не єдиний регулятор приватності у світі, але він став зразком для багатьох національних законів про захист даних. Розуміння відмінностей між GDPR та іншими регуляторами критично важливе для розробників міжнародних додатків, які працюють з користувачами з різних юрисдикцій.

CCPA (California Consumer Privacy Act) принципово відрізняється від GDPR: він працює за моделлю opt-out, а не opt-in. За CCPA компанії зобов'язані надати користувачеві право відмовитися від продажу своїх даних, але не зобов'язані отримувати попередню згоду на збір. Однак з прийняттям CPRA (California Privacy Rights Act) у 2023 році вимоги до згоди для чутливих даних стали ближчими до GDPR.

ePrivacy Directive (Директива про конфіденційність в електронних комунікаціях) доповнює GDPR в частині файлів cookie та електронного маркетингу. На відміну від GDPR, який регулює всі персональні дані, ePrivacy фокусується на комунікаційних даних. Вимога отримання згоди на необов'язкові файли cookie випливає саме з ePrivacy, а не з GDPR, хоча механізм згоди збігається.

LGPD Бразилії практично повністю копіює структуру GDPR з незначними змінами: вік згоди підвищено до 18 років, а обробка даних померлих осіб вимагає згоди спадкоємців. PIPL Китаю, навпаки, вводить більш суворі вимоги: обов'язкова локалізація даних, оцінка впливу на захист даних (DPIA) для всіх автоматизованих рішень та повідомлення про передачу даних за кордон.

Типові помилки при впровадженні GDPR Consent

Аналіз штрафів та приписів європейських наглядових органів за 2018-2024 роки показує повторювані порушення при реалізації згоди. За даними Enforcement Tracker (CMS Law, 2024), понад 40% усіх штрафів за GDPR пов'язані з некоректним отриманням та управлінням згодою. Розглянемо найпоширеніші помилки.

Попередньо встановлені прапорці та пасивна згода

Найпоширеніша помилка — використання попередньо встановлених прапорців для отримання згоди. Рішення Суду ЄС у справі Planet49 GmbH (C-673/17) однозначно встановило, що згода не може матися на увазі з бездіяльності користувача. Незважаючи на це, багато додатків продовжують використовувати попередньо встановлені опції, особливо для cookie-банерів, що веде до прямих штрафів та приписів.

Національна комісія з інформатики та свобод Франції (CNIL) у 2024 році оштрафувала великий рекламний RTB-холдинг на 250 мільйонів євро за використання попередньо встановлених прапорців та недостатньо прозоре інформування користувачів. Це найбільший штраф за статтею, пов'язаною зі згодою, який демонструє пріоритетність контролю згод для європейських регуляторів.

Об'єднання цілей в одну згоду

Багато додатків запитують одну загальну згоду на всі види обробки: аналітику, персоналізацію, рекламу, передачу третім особам. Це прямо порушує вимогу конкретності (purpose limitation). EDPB у керівництві 05/2020 наголошує: якщо одна мета може бути досягнута без іншої, користувач повинен мати можливість погодитися на кожну мету окремо.

Ірландська комісія із захисту даних (DPC) у рішенні по справі Meta Platforms Ireland (2023) вказала, що об'єднання персоналізації реклами та покращення сервісу в одну згоду є порушенням. Meta була зобов'язана впровадити роздільні механізми згоди для різних цілей обробки у Facebook та Instagram.

Складне або неможливе відкликання згоди

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

Рекомендована практика — додавання окремого екрану управління згодами в налаштування додатку з можливістю відкликати кожну згоду окремо одним перемикачем. UMP SDK від Google надає вбудований механізм для повторного показу форми згоди, який користувач може викликати з налаштувань додатку в будь-який момент.

Відсутність доказів отримання згоди

Багато розробників покладаються на усні згоди або не зберігають записи про отримання згоди. Це унеможливлює виконання вимоги доказовості (accountability) за статтею 5(2) GDPR. При перевірці наглядовий орган запросить не лише політику конфіденційності, але й логи отримання згод за весь період обробки даних.

Рішення проблеми — використання Consent Management Platform (CMP) з автоматичним логуванням усіх подій: показ форми, вибір користувача, версія документа, часова мітка. Популярні CMP для мобільних додатків включають Usercentrics, OneTrust та ConsentManager — всі вони підтримують автоматичний запис аудиту згод.