Персональні дані в чат-боті: підстави обробки, зберігання та передавання в AI

Ім’я, телефон, адреса доставки, ID у месенджері та історія звернень можуть бути персональними даними. Для бізнесу важливо знати не лише, що запитує бот, а й куди потрапляє повідомлення: у CRM, журнал помилок, резервну копію чи зовнішній AI-сервіс. Одна кнопка згоди не описує весь цей шлях.

Нижче — практичний підхід до проєктування такого процесу. Юридичні джерела перевірено 28 вересня 2026 року; матеріал допомагає підготувати вимоги до системи й питання юристу, але не замінює індивідуальну юридичну консультацію.

Які дані потрібно врахувати

Персональними можуть бути й дані без імені, якщо за ними можна встановити конкретну людину. Наприклад, ID користувача, пов’язаний із замовленнями, або текст звернення з адресою. Визначення та підстави обробки пояснює Уповноважений Верховної Ради з прав людини.

Перед запуском складіть карту руху даних. Для кожного поля позначте сценарій, мету, джерело, одержувача та місце зберігання. Врахуйте вкладення, аналітику, технічні журнали й ручні експорти менеджерів. Поле, якого немає у формі, може з’явитися у вільному повідомленні.

Окремо винесіть відомості про здоров’я та інші спеціальні категорії. Не переносіть для них стандартний сценарій збору контактів: застосовні підстави й обмеження потрібно перевірити з юристом.

Закон України, GDPR і законопроєкт №8153

Український закон і GDPR мають власні умови застосування. Для українського бізнесу базовим актом є Закон №2297-VI. GDPR може додатково застосовуватися, зокрема, до обробки в контексті діяльності установи в ЄС або до пропонування товарів чи послуг людям у ЄС або моніторингу їхньої поведінки там. Самого громадянства клієнта чи доступності бота з ЄС недостатньо для такого висновку. Ці критерії роз’яснює EDPB щодо статті 3 GDPR.

На дату перевірки офіційна картка №8153 має статус «Готується на друге читання»; прийняття за основу відбулося 20 листопада 2024 року. Перед релізом перевірте статус повторно. Не закладайте в договір дату набрання чинності, якої ще не встановлено.

Згода, повідомлення і мета обробки

Спершу визначте законну підставу для кожної мети; згода є однією з можливих підстав. Законодавство також передбачає інші підстави, зокрема пов’язані з виконанням правочину чи законного обов’язку. Наявність кнопки «Погоджуюсь» сама по собі не робить будь-який збір даних правомірним. Для GDPR дивіться пояснення Єврокомісії про законні підстави.

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

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

Сім рішень для архітектури бота

Юридичні вимоги потрібно перетворити на перевірювані правила системи. Наведені нижче рішення — інженерні рекомендації; конкретний набір залежить від ризиків і процесів компанії.

1. Мінімум полів. Попросіть контакт для зворотного зв’язку, а деталі замовлення — лише на відповідному кроці. Для кожного обов’язкового поля має бути пояснення.
2. Окремі ролі. Менеджер бачить потрібні йому звернення; експорт усієї бази доступний лише визначеним працівникам. Перевірте доступ колишніх співробітників.
3. Перевірка доступу до документа. Володіння номером чи ID месенджера не доводить право читати будь-який запис CRM. Для чутливих дій потрібна перевірка повноважень.
4. Контроль інтеграцій. Зафіксуйте дозволені поля для кожного API. Не передавайте весь профіль там, де достатньо номера заявки.
5. Захищені секрети. Ключі API зберігайте окремо від контенту й користувацьких повідомлень; обмежуйте права службових облікових записів.
6. Журнали без зайвого вмісту. Для діагностики часто достатньо ID операції, часу та коду помилки. Повний текст повідомлення не має автоматично потрапляти в кожен лог.
7. Кероване видалення. Призначте відповідального й перевірте, що команда видалення доходить до всіх потрібних систем, а не лише прибирає рядок з адмін-панелі.

Мапінг полів і обробку помилок варто оформити разом із схемою інтеграції чат-бота з CRM. Розподіл доступів до даних описано також у типовому порядку обробки Уповноваженого.

Строки зберігання й запити користувачів

Для всіх даних бота немає одного універсального строку. Узгодьте строки за метою, необхідністю й законними обов’язками; для GDPR це відображено в принципі обмеження зберігання.

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

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

Месенджери, сховище та AI-провайдери

Власний сервер не прибирає всі зовнішні точки обробки. Повідомлення, вкладення, сповіщення, хостинг і AI API можуть мати різних постачальників. Додайте їх у карту даних і перевірте договори та налаштування саме обраної послуги.

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

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

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

Що перевірити перед запуском

Перевірку краще проходити на тестових даних разом із власником процесу, технічним фахівцем і юристом:

• Пройти заявку від першого повідомлення до CRM та побачити всі копії даних.
• Відкрити запис під різними ролями й перевірити заборонені дії.
• Перевірити текст повідомлення, фіксацію згоди там, де вона потрібна, і відкликання.
• Надіслати тестовий запит на доступ або видалення та відстежити його виконання.
• Перевірити журнали, черги помилок, AI-запити й відновлення з резервної копії.
• Призначити контакт для інцидентів і порядок залучення юриста та відповідальних постачальників.

При виборі платформи перевіряйте ці можливості до укладення договору. Порівняння готової CRM і власної розробки допоможе додати їх до вимог і вартості підтримки.

Висновок

Почніть із карти даних і цілей обробки. Потім узгодьте підстави, доступи, строки, постачальників і процедури запитів. Для пілоту оберіть один робочий сценарій та перевірте його наскрізно. Так юридичні рішення отримають конкретне технічне виконання, а команда знатиме, що саме потрібно підтримувати після запуску.

Поширені запитання

Джерела

• Закон України «Про захист персональних даних» №2297-VI
• Уповноважений: визначення, підстави обробки та права людини
• Офіційна картка законопроєкту №8153
• EDPB: територіальна сфера застосування GDPR
• Єврокомісія: законні підстави обробки
• Єврокомісія: принципи GDPR
• Єврокомісія: обов’язки організацій
• Уповноважений: типовий порядок обробки персональних даних