GDPR і ШІ-чат-бот: що мають знати компанії

Які персональні дані обробляє ШІ-чат-бот?

Щойно користувач взаємодіє з ШІ-чат-ботом, виникають дані. Найочевидніші з них — сам зміст розмови: введений текст, запитання, скарги, деталі бронювання. Ці дані розмов у багатьох випадках є персональними в розумінні GDPR — або тому, що містять прямі ідентифікатори, як-от імена чи адреси електронної пошти, або тому, що в поєднанні з іншими доступними даними їх можна пов'язати з певною особою. IP-адреси, які технічно передаються у вебчаті, також вважаються персональними даними.

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

Принцип мінімізації даних (ст. 5 ч. 1 п. c GDPR) вимагає обробляти лише ті дані, які справді потрібні для відповідної мети. Для простого FAQ-чат-бота без автентифікації це означає: зміст розмов не слід зберігати постійно, IP-адреси слід анонімізувати, а особисті дані збирати лише тоді, коли вони конче потрібні для процесу обслуговування. Отже, ретельно налаштований чат-бот з погляду захисту даних значно менш проблемний, ніж погано спланований.

Вимоги GDPR до експлуатації чат-бота

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

По-друге, існує всеосяжний обов'язок інформувати суб'єктів даних. Користувачі мають знати, які дані й з якою метою обробляються, як довго вони зберігаються, хто може бути одержувачем і які права вони мають — зокрема право на доступ, виправлення, видалення та обмеження обробки. Ця інформація має бути доступною чіткою, зрозумілою мовою — зазвичай у політиці конфіденційності та через повідомлення у вікні чату.

По-третє, GDPR приписує принцип «Privacy by Design and by Default» (ст. 25). Це означає: конфігурації, що сприяють захисту даних, від самого початку є налаштуваннями за замовчуванням, а не пізнішими доповненнями. Для ШІ-чат-ботів на практиці це означає: коротші стандартні строки зберігання, анонімізацію даних журналів, суворі права доступу та можливість для користувачів у простий спосіб домогтися видалення своїх даних.

Хмарний ШІ чи On-Premises: що це означає для захисту даних?

У хмарному ШІ-чат-боті дані розмов і запити надсилаються на зовнішні сервери постачальника мовної моделі, обробляються там і — залежно від конфігурації — можуть використовуватися для навчання. Для оцінки з погляду GDPR вирішальне питання: у якій країні розташовані сервери? Щодо американських постачальників правова ситуація після рішення Schrems II є складною. Постачальникам з ЄС або тим, що мають дата-центри в ЄС, європейське законодавство про захист даних віддає явну перевагу. Крім того, необхідно укласти договір про обробку даних (AVV).

On-Premises означає, що вся інфраструктура — включно з ШІ-моделлю — працює на серверах, які компанія контролює сама. За локального виконання ШІ дані розмов не залишають власну інфраструктуру. Тож потреба в AVV із хмарним ШІ-постачальником повністю відпадає; обробка відбувається виключно всередині компанії. Для компаній у регульованих галузях — охорона здоров'я, юридичні послуги, фінансові послуги — On-Premises часто є єдиним прийнятним варіантом.

Можливий і гібридний підхід: інфраструктура чат-бота та база знань працюють у ЄС на захищених серверах, а для певних, менш чутливих сценаріїв використовується хмарна модель. Zentor App підтримує обидва режими роботи — хмарний через зовнішнього ШІ-провайдера та повністю локальний — і дає компаніям змогу самостійно вирішити, яка архітектура відповідає їхній стратегії захисту даних. Це рішення в ідеалі слід ухвалювати разом з уповноваженим із захисту даних і юристом із питань захисту даних.

Договір про обробку даних (AVV): коли він потрібен і що регулює

Договір про обробку даних (AVV) згідно зі ст. 28 GDPR — це головний інструмент правового врегулювання відповідальності між компанією (замовником) і зовнішнім постачальником послуг (обробником), який обробляє персональні дані за дорученням. Під час експлуатації ШІ-чат-бота через SaaS-платформу AVV, як правило, є обов'язковим: постачальник чат-бота обробляє дані розмов на своїх серверах — це класична обробка за дорученням.

AVV має бути укладено в письмовій або рівноцінній електронній формі, і він має охоплювати низку обов'язкових елементів: предмет і тривалість обробки, характер і мету обробки, категорії персональних даних і суб'єктів даних, а також обов'язки та права контролера. Крім того, обробник має гарантувати впровадження належних технічних і організаційних заходів (TOMs) і не залучати субобробників без дозволу.

Важливо: AVV має бути укладено до введення чат-бота в експлуатацію — а не згодом. Відсутність AVV за наявності обробки за дорученням є самостійним порушенням GDPR, за яке передбачено штрафи. Тому перевіряйте в кожного постачальника чат-бота, чи пропонується AVV і в якій формі, які субобробники залучаються (наприклад, хмарні провайдери або зовнішні ШІ-провайдери) і як із цим працюють. Надійні постачальники, як-от Zentor App, надають стандартизовані шаблони AVV і готові прозоро розкрити їхній зміст.

Уповноважений із захисту даних і чат-бот: на що зважати?

Компанії, що мають внутрішнього або зовнішнього уповноваженого із захисту даних (DSB), мають залучати його до впровадження ШІ-чат-бота. Завдання DSB — забезпечити впровадження відповідно до вимог захисту даних, оцінити ризики та контролювати дотримання GDPR. Ідеться не лише про формальний комплаєнс, а й про конкретну технічну конфігурацію: які дані зберігаються? Як довго? Хто має доступ? Як обробляються запити суб'єктів даних на доступ до інформації?

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

Навіть якщо призначення DSB не вимагається законом, перед запуском варто провести перевірку з погляду захисту даних. Саме в менших компаніях, які вперше впроваджують чат-бот, трапляються типові пастки: відсутня або застаріла політика конфіденційності, забутий AVV, надто довгі строки зберігання чи відсутність концепції видалення. Зовнішня консультація експерта із захисту даних тут окупиться в довгостроковій перспективі й захистить від відчутних штрафів, які можуть накласти органи із захисту даних.

Технічні та організаційні заходи (TOMs) для чат-ботів

GDPR у ст. 32 вимагає належних технічних і організаційних заходів (TOMs), щоб забезпечити рівень захисту, який відповідає ризику. Для ШІ-чат-ботів це конкретно означає: уся передача даних між браузером користувача та бекендом чат-бота має відбуватися в зашифрованому вигляді (TLS/HTTPS). Збережені дані розмов і вміст бази знань також слід зберігати зашифрованими — як у базі даних, так і на відповідних носіях.

Щодо доступу GDPR приписує принцип обмеження доступу до даних: доступ до персональних даних можуть мати лише ті співробітники й системи, яким він справді потрібен для роботи. Zentor App реалізує цей принцип за допомогою системи рольового керування доступом (Role-Based Access Control, RBAC), яка доступна як модуль на вибір у тарифі «Індивідуальний»: різні ролі отримують різні права доступу, а всі звернення до даних фіксуються в журналі аудиту. Це дає змогу в разі сумніву довести, хто, коли й до яких даних мав доступ.

В організаційному плані до TOMs належать чіткі внутрішні процеси: хто відповідає за базу знань? Як обробляються запити суб'єктів даних на видалення? Як забезпечується, щоб дані розмов не зберігалися довше, ніж потрібно? Як компанія реагує на інцидент із захистом даних — наприклад, якщо чат-бот ненавмисно розкриє персональні дані іншого користувача? Ці процеси мають бути задокументовані письмово й регулярно перевірятися.

Zentor App і GDPR: хостинг в ЄС та On-Premises як варіанти

Zentor App була розроблена з самого початку з метою забезпечення відповідності GDPR. Платформа може розміщуватися на серверах у ЄС — хостинг, бази даних та логіка застосунків підпадають під європейське законодавство про захист даних. Якщо опціонально підключається зовнішній постачальник ШІ, будь-яке використання поза ЄС здійснюється виключно на основі стандартних контрактних положень ЄС (ст. 46 GDPR) — таким чином усуваються правові невизначеності неконтрольованого трансферу в треті країни. Для компаній, які розглядають хмарне рішення, розміщення в ЄС є першим і найважливішим кроком на шляху до відповідності GDPR.

Для підприємств із найвищими вимогами до захисту даних Zentor App пропонує повну встановлення On-Premises. У цьому режимі роботи вся платформа — двигун чат-бота, база знань, Omnichannel-інбокс та всі компоненти обробки — працює на інфраструктурі, яку контролює саме підприємство. Завдяки локальному виконанню ШІ жодні дані розмов та жодна персональна інформація не виходять за межі власного IT-середовища. Цей підхід особливо підходить для лікарень, юридичних фірм, податкових консультантів та інших галузей, де захист даних є існувальним.

Zentor App надає договори про обробку даних (AVV) для хмарного режиму та документує залучених субобробників із назвою компанії, країною, метою та підставою передачі в пункті 13 політики конфіденційності. Технічні функції захисту даних — RBAC, журнал аудиту, налаштовувані строки зберігання даних і рольовий контроль доступу — можна налаштувати як модулі на вибір у тарифі «Індивідуальний». Так ви створюєте технічні передумови для експлуатації чат-бота відповідно до GDPR — а юридичне оформлення в конкретному випадку завжди залишається завданням вашої команди із захисту даних і юридичних радників.

Часті запитання