Вікова верифікація в мобільному застосунку ‒ це вже не просто поле «Дата народження» під час реєстрації. Розробникам доводиться визначати, як перевіряти вік, які дані для цього збирати та який функціонал буде недоступний окремим категоріям користувачів.
Наслідки помилок у цьому механізмі вже видно на рівні регуляторних справ. Один із показових прикладів ‒ справа TikTok, у якій британський ICO оштрафував компанію на £12,7 млн за порушення правил обробки даних дітей. Серед іншого регулятор звернув увагу на недостатні заходи для виявлення та видалення акаунтів користувачів молодше 13 років.
Одночасно з регулюванням змінюються й технологічні рішення. Єврокомісія підготувала EU age verification solution для підтвердження віку без передачі точної дати народження чи інших ідентифікаційних даних. Apple також розвиває Declared Age Range API та оновлює вимоги до вікових обмежень у застосунках. Отже, сценарії доступу для різних вікових категорій варто закладати ще на етапі проєктування продукту.
Чи кожен застосунок повинен перевіряти вік
Універсальної вимоги перевіряти вік кожного користувача немає. Підхід до age assurance залежить від юрисдикції, аудиторії та характеру сервісу. Європейська модель орієнтована на випадки, коли доступ до певного контенту або послуги законно залежить від віку, зокрема для порнографії, азартних ігор та продажу алкоголю. Технологію можна адаптувати й до інших вікових порогів, наприклад 13+.
Спочатку потрібно визначити країни, у яких працюватиме застосунок, мінімальний вік аудиторії та функції з віковими обмеженнями. Цю інформацію зручно звести в age-verification matrix:
- юрисдикція;
- віковий поріг;
- обмежений функціонал;
- спосіб підтвердження віку;
- дані, які отримує продукт.
На основі такої матриці можна сформувати конкретне технічне завдання для команди. Наступний крок ‒ визначити, скільки інформації про користувача справді потрібно для перевірки.
Чи потрібно застосунку знати точну дату народження
Якщо сервісу потрібно знати лише, чи виповнилося користувачу 18 років, йому не завжди потрібні дата народження, ім’я та копія паспорта. EU age verification solution побудована за принципом, який дозволяє користувачу підтвердити, наприклад, що йому виповнилося 18 років, без передачі сервісу точної дати народження та інших даних, що ідентифікують користувача.
Обраний спосіб верифікації впливає і на обробку персональних даних. Потрібно визначити, які дані отримує застосунок, для чого їх обробляє, як довго зберігає та хто має до них доступ. Якщо команда самостійно збирає копії документів, застосунок починає обробляти значно більше ідентифікаційних даних, а разом із цим зростають вимоги до їх захисту.
Створювати власний механізм перевірки потрібно не завжди: частину інформації про віковий діапазон уже може передавати операційна система або магазин застосунків. Для iOS цей підхід особливо актуальний після змін, які Apple запровадила у 2026 році.
Що змінилося для розробників iOS
З вересня 2026 року Apple вимагає під час подання нових версій та оновлень повідомляти про наявність social media capabilities. Якщо такі можливості недоступні користувачам молодше 13 років, самого зазначення вікового обмеження недостатньо: застосунок має визначати відповідний age range через Declared Age Range API та на його основі керувати доступом до відповідного функціоналу. Цю логіку варто окремо описати в технічному завданні.
Але підключити API і вважати завдання виконаним не вийде. 22 вересня 2026 року Ofcom відкрив розслідування щодо оператора Pornhub, зокрема щодо due diligence і тестування механізму age assurance, який використовував сигнали Apple. Для розробника й замовника тут важливий практичний висновок: використання стороннього інструменту не скасовує необхідності перевірити, наскільки ефективно age assurance працює в конкретному сервісі.
Перед інтеграцією зовнішнього age-verification рішення команда має розуміти, який віковий поріг воно перевіряє і що станеться, якщо система помилиться або не зможе визначити вік користувача.
Що передбачити в договорі з розробником
Age verification може бути окремим модулем, сторонньою інтеграцією або частиною інфраструктури платформи. Якщо відповідні вимоги змінюються вже після старту робіт, у замовника та виконавця можуть виникнути розбіжності щодо обсягу доопрацювань, строків та їх вартості.
Тому договір про надання послуг з програмного забезпечення і технічне завдання варто узгодити з моделлю age verification ще до початку розробки. У документах доцільно визначити:
- хто встановлює вікові обмеження та обирає спосіб перевірки;
- які вікові категорії повинен розпізнавати продукт;
- які дані отримує та зберігає виконавець;
- який функціонал обмежується залежно від віку користувача;
- хто перевіряє стороннього age-verification provider перед інтеграцією;
- хто проводить тестування механізму перед релізом;
- хто відповідає за доопрацювання після зміни законодавства або правил App Store;
- чи входять такі роботи до початкової вартості послуг.
Для такого проєкту договір на розробку програмного забезпечення для бізнесу має розмежовувати відповідальність замовника за визначення вікових обмежень і розробника ‒ за їх технічну реалізацію (докладніше: https://stalirov.lawyer/uk/posts/dogovir-na-rozrobku-programnogo-zabezpechennya-z-kliyentami-klyuchovi-punkti). У договорі про надання IT-послуг також варто визначити порядок погодження змін, щоб оновлення механізму age verification не стало причиною спору щодо строків, вартості або обсягу робіт.
Висновок
Вікову верифікацію краще проєктувати як частину продукту, а не додавати перед релізом як окрему перевірку. Пороги, спосіб їх підтвердження, правила доступу до функцій і відповідальність сторін варто визначити ще до початку розробки та закріпити в технічному завданні й договорі.
Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co
