Приватність і AI: захист даних клієнтів при ШІ

Уявіть: менеджер вашого відділу продажів вигружає базу клієнтів у ChatGPT, щоб швидко сформулювати персоналізовані листи. Він не думає про ризики — він просто хоче зробити роботу швидше. Але щойно ця таблиця потрапила у промпт, імена, телефони й суми угод ваших клієнтів опинилися на серверах OpenAI без жодного договору на обробку даних. Якщо серед ваших клієнтів є громадяни ЄС — ви щойно порушили GDPR.

Більшість статей про AI і конфіденційність написані для юристів або ІТ-директорів: вони сповнені термінів на кшталт «суб’єкт обробки», «законна підстава» і «транскордонна передача». Ця стаття написана для власника бізнесу або операційного директора, який сам вирішує, впроваджувати AI чи ні. Ви дізнаєтесь, які конкретні дії несуть ризик, скільки це може коштувати і що зробити до запуску AI-інструменту, щоб не наражати компанію на штрафи й репутаційні втрати.

Чому питання безпеки даних треба закрити до запуску AI, а не після

Типова логіка: спочатку запускаємо, потім розберемось із юридичними питаннями. Із AI це не працює. Причина проста: як тільки дані потрапили до стороннього сервісу, забрати їх назад неможливо. Витік уже стався — неважливо, чи дізнались про нього ви, регулятор або клієнт.

За даними досліджень у сфері корпоративної кібербезпеки, 87% витоків корпоративних даних через AI-інструменти відбуваються саме через безкоштовні акаунти співробітників на публічних платформах. Не через злам, не через зовнішню атаку — через звичайну необережність усередині компанії. При цьому 71,2% інцидентів, пов’язаних із несанкціонованою передачею даних, стосуються ChatGPT.

Три реальні сценарії, коли бізнес втрачає дані клієнтів через AI

Сценарій перший. HR-менеджер просить ChatGPT скласти оцінку ефективності для конкретного співробітника і копіює його персональні дані в промпт. Ім’я, посада, зарплата, причини попереджень — все це тепер у системі OpenAI.

Сценарій другий. Бухгалтер завантажує фінансовий звіт із реквізитами клієнтів у Gemini, щоб той «підбив підсумки» по кварталу. Контрагенти, суми, терміни оплати — дані передані третій стороні без відома клієнтів.

Сценарій третій. Компанія наймає AI-агентство для автоматизації підтримки клієнтів. Агентство підключає чатбот до вашої CRM через API, але в договорі нічого не сказано про те, хто зберігає дані і де. Ваша клієнтська база тепер «живе» ще й на серверах підрядника.

Скільки коштує «необережність»: штрафи і репутація

GDPR — це не лише для великих корпорацій. Штрафи: до €20 млн або 4% від річного глобального обороту компанії — залежно від того, що більше. У 2021 році Amazon отримав штраф у розмірі €746 млн від Люксембурзького регулятора за порушення GDPR при обробці персональних даних. Google (Ireland) — €150 млн від французького CNIL. Навіть невеликі компанії отримують штрафи від €5 000 до €200 000 за конкретні порушення.

Крім штрафів — репутація. Якщо клієнт дізнається, що його дані потрапили в стороннє AI-рішення без його згоди, він втрачає довіру. На B2B-ринку, де угоди на десятки і сотні тисяч гривень будуються на особистих відносинах, одного такого інциденту достатньо, щоб втратити ключового клієнта.

Яке законодавство регулює AI і дані в Україні у 2026 році

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

Закон «Про захист персональних даних» і новий проект №8153

Базовий закон України «Про захист персональних даних» від 2010 року вже давно застарів технологічно. Але він діє, і Уповноважений Верховної Ради з прав людини (омбудсмен) має право накладати санкції за його порушення. За чинним законом обробка персональних даних допускається лише за умови отримання згоди суб’єкта або наявності іншої законної підстави — договір, законний обов’язок, захист життєво важливих інтересів.

Що конкретно означає «обробка»? Закон трактує це широко: будь-яка дія з даними — збір, зберігання, передача, зміна, знищення. Тобто передача клієнтської таблиці у ChatGPT — це юридично «передача третій стороні». Без відповідної підстави і без угоди про обробку — порушення.

Законопроект №8153 розроблений із метою гармонізації з GDPR. Він кардинально змінює рамку відповідальності для бізнесу з кількох ключових напрямків.

По-перше, штрафна шкала. Якщо зараз санкції за порушення закону про ПДн фактично символічні (від кількох до кількох десятків тисяч гривень), то №8153 закладає штрафи до 3–5% від річного обороту компанії — аналогічно до GDPR. Для компанії з оборотом 50 млн грн це потенційно 1,5–2,5 млн грн штрафу за один серйозний інцидент.

По-друге, обов’язковий DPO. Для компаній, які систематично і у великих обсягах обробляють персональні дані, законопроект вводить обов’язок призначити відповідальну особу за захист даних (Data Protection Officer). Це не обов’язково окрема штатна одиниця — функцію може виконувати існуючий менеджер або зовнішній консультант, але він повинен бути офіційно призначений і мати відповідні повноваження.

По-третє, строки повідомлення про витоки. Законопроект закладає зобов’язання повідомляти наглядовий орган (Уповноважений з прав людини або спеціалізований регулятор) впродовж 72 годин після виявлення витоку — так само, як це передбачено GDPR.

Навіть якщо №8153 ще на стадії розгляду, логіка проста: AI-системи, які ви запускаєте сьогодні, працюватимуть ще два–три роки. Будувати їх архітектуру без урахування майбутніх вимог — значить закладати технічний і юридичний борг, який пізніше доведеться виплачувати дорожчою ціною.

GDPR (General Data Protection Regulation — загальний регламент ЄС із захисту даних) поширюється на вас, якщо виконується хоча б одна умова:

ви обробляєте дані громадян або резидентів ЄС;
ви пропонуєте товари або послуги особам в ЄС (навіть безкоштовно);
ви відстежуєте поведінку людей у ЄС (через cookies, аналітику).

Для українського бізнесу з релокованими власниками, EU-клієнтами або партнерами в ЄС — GDPR практично завжди актуальний. Він не запитує, де знаходиться ваш юридична адреса. Він запитує, чиї дані ви обробляєте.

Практичні наслідки для МСБ такі. Якщо ваш менеджер із продажів надсилає email потенційному клієнту у Варшаві — ви вже обробляєте персональні дані громадянина ЄС. Якщо ваш сайт встановлює Google Analytics або Meta Pixel без належного cookie-consent — ви відстежуєте поведінку людей у ЄС. Якщо ваш бухгалтер зберігає рахунки-фактури клієнтів з Берліна в Google Sheets — ці дані підпадають під GDPR.

Ключове поняття в GDPR — «законна підстава» (lawful basis) для обробки даних. Всього їх шість: згода, виконання договору, законний обов’язок, захист життєво важливих інтересів, завдання публічного інтересу, законний інтерес. Більшість B2B-компаній можуть спиратися на «виконання договору» або «законний інтерес» для обробки контактних даних клієнтів — але передача цих даних стороннім AI-системам потребує або окремої законної підстави, або DPA з чітко визначеними рамками обробки.

Важливо розуміти різницю між «контролером» (controller) і «обробником» (processor) за GDPR. Ваша компанія як контролер визначає мету і засоби обробки. AI-сервіс (або AI-підрядник) — обробник, який діє за вашими інструкціями. Ви несете первинну відповідальність. Якщо обробник порушив умови і стався витік — регулятор прийде до вас.

EU AI Act: що вже діє і що чекає МСБ до серпня 2026

EU AI Act (Акт ЄС про штучний інтелект) — перший у світі комплексний закон, що регулює саме AI-системи. Ухвалений у 2024 році, він вводиться поетапно:

Серпень 2024 — заборонені практики (маніпуляція свідомістю через AI, соціальний скоринг) набули чинності.
Серпень 2025 — вимоги до моделей загального призначення (GPAI), включно з GPT-4, Claude, Gemini.
Серпень 2026 — повне застосування до систем високого ризику (HR, фінанси, освіта, охорона здоров’я).

Що означає «система високого ризику» на практиці для МСБ? Act відносить до цієї категорії AI-системи, які використовуються у восьми сферах: критична інфраструктура, освіта, зайнятість і управління персоналом, надання основних послуг (кредити, страхування), правоохоронна діяльність, міграція, відправлення правосуддя, демократичні процеси.

Для типового українського бізнесу з 20–200 людей найрелевантніші два пункти: зайнятість і HR та надання основних послуг. Якщо ви використовуєте AI для ранжування резюме, оцінки ефективності співробітників або прийняття рішень про наймання — ваша система потрапляє в категорію «високий ризик». Якщо ви використовуєте AI для кредитного скорингу клієнтів або оцінки платоспроможності — також.

Вимоги до систем високого ризику за Act включають: ведення технічної документації, реєстрацію системи в базі даних ЄС, механізм людського нагляду (human oversight), пояснення рішень, що впливають на людей, та оцінку ризиків перед запуском. Штрафи за порушення сягають €35 млн або 7% від річного глобального обороту для найсерйозніших порушень і €15 млн або 3% — за інші.

Для МСБ, що використовує готові AI-інструменти (ChatGPT, Copilot, Gemini), більша частина відповідальності за відповідність Act лежить на розробниках цих систем. Але якщо ви замовляєте кастомне AI-рішення або інтегруєте модель у власний продукт — зобов’язання щодо документації і прозорості автоматично переходять до вас як до «deployer» (розгортальника системи).

Два принципово різні сценарії впровадження AI — і різні ризики

Одна з найбільших помилок у розумінні AI-безпеки — вважати, що всі AI-інструменти однаково ризиковані. Насправді ризики кардинально різняться залежно від того, як саме ви використовуєте AI.

Сценарій 1. Публічні AI-інструменти (ChatGPT, Gemini, Copilot) і дані клієнтів

Публічні платформи — це сервіси, де ви або ваші співробітники просто заходите через браузер і вводите промпти. ChatGPT від OpenAI, Gemini від Google, Microsoft Copilot.

Ключова проблема: безкоштовні і навіть частково платні тарифи цих сервісів не надають Data Processing Agreement (DPA — угода про обробку даних). Без DPA будь-яка передача персональних даних у ці системи є порушенням GDPR. Крім того, за стандартними налаштуваннями OpenAI може використовувати введені вами дані для вдосконалення своїх моделей.

Корпоративні тарифи (ChatGPT Enterprise, Google Workspace з Gemini) надають DPA і гарантують, що ваші дані не використовуються для навчання моделей. Але навіть тоді важливо розуміти, що дані фізично обробляються на серверах третьої сторони.

Практичний висновок: публічні AI-інструменти допустимі для роботи з неперсоналізованими, знеособленими даними. Для роботи з клієнтськими базами, угодами, персональними даними — тільки корпоративний тариф з DPA або власна інфраструктура.

Сценарій 2. Власна модель або RAG на корпоративних даних

RAG (Retrieval-Augmented Generation — генерація з підтримкою пошуку) — технологія, коли модель AI відповідає на запити, спираючись на вашу власну базу знань. Наприклад, корпоративна вікі, документи, угоди клієнтів завантажені у векторну базу даних, а AI відповідає на запити, дістаючи релевантну інформацію звідти.

При правильному налаштуванні це найбезпечніший варіант: дані не виходять за межі вашої інфраструктури. Але тут є свої ризики:

Хто має доступ до векторної бази? Якщо всі 50 менеджерів можуть запитати AI про умови угоди будь-якого клієнта — це проблема контролю доступу.
Де фізично розгорнута система? На ваших серверах, у хмарі Ukraine (Datagroup, GigaCloud) або на AWS/Azure?
Хто обслуговує систему? Підрядник-розробник також може мати доступ.

Детальніше про захищені AI-системи для підтримки клієнтів — на сторінці послуги AI-асистента підтримки.

Сценарій 3. AI-підрядник має доступ до вашої бази клієнтів

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

З точки зору GDPR ви в цьому випадку є «контролером даних» (controller), а підрядник — «обробником» (processor). Ви несете відповідальність за те, як підрядник поводиться з цими даними. Якщо підрядник зловживе доступом або допустить витік — штраф прийде до вас.

Що категорично не можна передавати в публічний AI

Правило просте: якщо ця інформація ідентифікує конкретну людину або розкриває комерційну таємницю — вона не повинна потрапляти у публічний AI-інструмент без DPA.

Персональні дані: ім’я, телефон, email, ІПН

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

ПІБ у поєднанні з посадою або компанією;
номер телефону або email;
ІПН, номер паспорта, РНОКПП;
IP-адреса, cookie-ідентифікатори;
геолокаційні дані;
фотографії, голосові записи.

Навіть якщо ви «прибрали» ім’я, але залишили все інше (компанія, посада, розмір угоди) — така інформація часто лишається «квазіперсональною» і може дозволити ідентифікацію.

Конкретний приклад: ваш менеджер хоче підготувати персоналізований комерційний лист і вставляє у ChatGPT текст на кшталт: «Напиши лист клієнту Олексій Мороз, директор ТОВ “Металоконструкції”, телефон 0971234567, куплено обладнання на 450 000 грн, хочемо запропонувати сервісний контракт». Цей промпт містить мінімум три категорії персональних даних: ім’я, посаду й телефон фізичної особи. Якщо Олексій Мороз є директором як посадова особа і його дані зібрані в рамках B2B-відносин, ситуація неоднозначна — але якщо серед ваших клієнтів є ФОПи або фізичні особи, це безумовно персональні дані, і передача без DPA є порушенням.

Окремо варто виділити спеціальні категорії даних за GDPR (ст. 9), для яких встановлено суворіший захист: дані про здоров’я, расове та етнічне походження, політичні погляди, релігійні переконання, членство в профспілках, генетичні та біометричні дані, дані про сексуальне життя. Передача таких даних у будь-який публічний AI є порушенням за замовчуванням — навіть якщо є DPA, потрібна окрема явна підстава (explicit consent або одна зі спеціальних виключень ст. 9(2)).

Фінансові та комерційні дані

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

Кейс для розуміння масштабу: у 2023 році Samsung довелося тимчасово заборонити використання ChatGPT співробітниками після того, як кілька інженерів завантажили у чат фрагменти вихідного коду власних продуктів і внутрішні нотатки зустрічей. Технічно витоку ще не сталось — але секретна корпоративна інформація опинилась у системі стороннього підрядника без будь-якого договору.

Для українського МСБ ризики аналогічні, тільки без гучного PR-ефекту. Типова ситуація: фінансовий директор завантажує Excel із дебіторською заборгованістю у Gemini, щоб той побудував аналіз прострочень і зробив зведену таблицю. У цьому файлі — назви компаній, ІПН або ЄДРПОУ контрагентів, суми, терміни. Навіть якщо конкретних фізичних осіб у файлі немає, ІПН ФОПа є персональними даними фізичної особи-підприємця. А умови договорів із конкретними клієнтами — комерційна таємниця, яку ви зобов’язані захищати відповідно до укладених угод.

Практичне правило: перед тим як завантажити будь-який фінансовий документ в AI, запитайте себе: «Якби цей файл опинився у відкритому доступі, це завдало б шкоди клієнту або компанії?». Якщо так — файл не можна передавати в публічний AI без DPA і знеособлення.

Внутрішні документи і угоди

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

Цей ризик часто недооцінюють, тому що юридична логіка тут не очевидна. Коли ваш менеджер завантажує NDA клієнта у ChatGPT із проханням «перефразуй пункт 4.2 простішою мовою» — він технічно передає конфіденційну інформацію «третій стороні» (OpenAI), хоча в NDA прямо написано, що це заборонено без письмової згоди. Якщо клієнт дізнається — він може зажадати пояснень або, в гіршому випадку, визнати NDA порушеним.

Окремий ризик — переговорні матеріали. Скажімо, ваш менеджер під час переговорів із великим клієнтом просить AI допомогти розробити стратегію заперечень і вставляє у промпт реальну інформацію: «Клієнт — ТОВ “Альфа”, вони зараз платять конкуренту X 80 тисяч на місяць, хочуть знизити до 60 тисяч, ключова особа Іванченко Василь». Ця інформація — конфіденційні комерційні відомості, які стали відомі вам у процесі ділових відносин. Передача їх у стороннє AI-рішення може порушувати і умови ваших угод, і загальні принципи добросовісної ділової практики.

Облікові дані CRM і ERP

Це окремий, часто недооцінений ризик. Якщо співробітник просить AI «підключитися до нашої CRM» або вставляє API-ключі у промпт, щоб AI міг прочитати дані, — ці ключі потрапляють в логи системи. Компрометований API-ключ від CRM із 10 000 клієнтів — це вже не просто порушення GDPR, а реальний вектор атаки.

Проблема наростає зі зростанням популярності AI-агентів — систем, які не просто відповідають на запити, а самостійно виконують дії: надсилають email, редагують документи, дзвонять клієнтам. Щоб AI-агент міг виконувати ці дії, йому потрібні облікові дані або токени доступу до ваших систем. Якщо ці токени зберігаються або передаються через публічну AI-платформу без відповідних гарантій — ризик несанкціонованого доступу суттєво зростає.

Практичне правило щодо облікових даних: жодний пароль, API-ключ, токен або секретний рядок не повинен з’являтися в жодному промпті жодного AI-інструменту. Для автоматизації використовуйте виключно спеціальні механізми безпечного зберігання секретів (vault, secrets manager) — і тільки у систем, де ви контролюєте інфраструктуру або де підписано відповідний DPA.

Як безпечно підключити AI-інструмент до бізнес-процесів

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

Крок 1. Аудит даних — що і куди передається

Перш ніж щось підключати, зрозумійте, які дані є у вашому бізнесі і які з них можуть «потрапити» до AI:

Які дані є в CRM (Pipedrive, KeyCRM, NetHunt, HubSpot)?
Які дані зберігаються у email-сервісі?
Чи є у вас дані про здоров’я, фінанси або дітей клієнтів (спеціальні категорії за GDPR — вимагають особливого захисту)?
Чи є у вас клієнти з ЄС? Якщо так — GDPR автоматично застосовний.

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

Крок 2. Вибір тарифу і DPA (Data Processing Agreement)

DPA — це угода між вами (контролером) і AI-сервісом (обробником), яка регламентує, що сервіс може і не може робити з вашими даними. Без DPA — будь-яка передача персональних даних у AI-систему незаконна за GDPR.

Де взяти DPA:

ChatGPT Enterprise / ChatGPT Team — DPA доступний у налаштуваннях акаунту, підписується онлайн.
Google Workspace з Gemini — DPA включений в умови Google Workspace.
Microsoft Copilot для організацій — DPA через Microsoft Volume Licensing.
Anthropic Claude для бізнесу — DPA за запитом через sales@anthropic.com.

Якщо AI-сервіс не пропонує DPA — він не підходить для обробки персональних даних клієнтів. Крапка.

Але підписання DPA — це не фінішна пряма, а стартова позиція. DPA визначає, що сервіс зобов’язується зробити для захисту ваших даних, але він не скасовує вашого обов’язку як контролера перевірити, чи виконуються ці зобов’язання. Ось на що треба звернути увагу при читанні DPA перед підписанням.

Де фізично зберігаються дані. DPA повинен містити або вказувати список субобробників (sub-processors) і країн, де зберігаються дані. Якщо дані ваших EU-клієнтів обробляються на серверах у США, DPA повинен містити посилання на механізм передачі: стандартні договірні clauses (SCC), Privacy Shield Framework або інший адекватний механізм за ст. 46 GDPR.

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

Строки зберігання і видалення. DPA повинен вказувати, як довго сервіс зберігає введені дані після завершення сесії або скасування підписки, і підтверджувати процедуру видалення на ваш запит.

Порядок повідомлення про інциденти. За GDPR обробник зобов’язаний повідомити контролера про витік «без невиправданої затримки» — на практиці DPA зазвичай фіксує строк у 24–48 годин. Перевірте, чи є цей пункт у DPA і чи вказано конкретний канал повідомлення.

Крок 3. Технічні заходи: middleware, маскування, логування

Маскування (anonymization / pseudonymization): перед передачею даних у AI-систему замініть реальні імена та ідентифікатори на псевдоніми або токени. Наприклад, «Іванов Петро Сергійович, +380991234567» стає «Клієнт #4521». AI виконує завдання, результат повертається, а в CRM ви самі співставляєте токен з реальним клієнтом.

Важливо розрізняти два рівні маскування. Псевдонімізація (pseudonymization) — дані замінені на токени, але відповідність збережена в окремій таблиці (яка зберігається у вас, не в AI). Технічно ці дані все ще є персональними за GDPR, але ризик суттєво знижений. Анонімізація (anonymization) — зв’язок між даними і особою незворотньо знищений, і тоді GDPR взагалі не застосовується до переданих даних. Справжня анонімізація складніша, ніж здається: недостатньо просто прибрати ім’я — потрібно переконатись, що залишена інформація не дозволяє ідентифікацію навіть непрямим способом.

Для більшості бізнес-задач достатньо псевдонімізації. Практична схема: ваша CRM або ERP на першому кроці замінює ім’я клієнта на ID, телефон — на хеш, email — на маскований варіант (наприклад, i***@gmail.com). Цей знеособлений запис передається в AI для аналізу або генерації тексту. Результат повертається назад, а ваша система підставляє реальні дані вже після обробки.

Middleware (проміжний шар): замість прямого підключення CRM до AI-сервісу використовуйте проміжний мікросервіс, який фільтрує і маскує дані до передачі. Це технічне рішення, яке реалізує ваш розробник або AI-підрядник.

Як виглядає middleware на практиці? Це окремий серверний компонент (може бути невеликим Node.js або Python-сервісом), який стоїть між вашою CRM і AI-API. Кожен запит до AI проходить через нього: middleware перехоплює запит, сканує його на наявність персональних даних за заданими правилами (регулярні вирази для телефонів, ІПН, email, ПІБ), маскує знайдені дані, передає очищений запит в AI, отримує відповідь і логує транзакцію. Такий підхід особливо важливий, якщо AI-інструменти використовують кілька різних команд — middleware забезпечує єдину точку контролю незалежно від того, хто і як формулює запит.

Логування запитів: зберігайте лог того, які дані і коли були передані в AI-систему. Це дозволяє виявити інцидент і довести регулятору, що ви вжили заходи обережності.

Мінімальний лог-запис повинен містити: мітку часу, ідентифікатор користувача (хто з співробітників зробив запит), ідентифікатор AI-системи (яка саме платформа, який тариф), категорію переданих даних (не самі дані, а їхній тип — «знеособлені контактні дані», «фінансовий звіт без ПДн»), хеш запиту (для ідентифікації без зберігання вмісту). Логи зберігайте не менше 12 місяців — GDPR не вказує конкретний строк, але при розслідуванні інциденту наявність логів за рік суттєво полегшує захист.

Обмеження доступу для персоналу: не всі співробітники мають потребу у доступі до AI-інструментів з клієнтськими даними. Встановіть корпоративний тариф, де ви контролюєте, які акаунти мають доступ і з якими правами.

На практиці це означає: менеджер із продажів може мати доступ до AI-асистента для складання листів, але без можливості завантажувати файли. Бухгалтер може використовувати AI для аналізу фінансових звітів, але тільки через middleware, що автоматично маскує ПДн. HR-менеджер може мати доступ до AI для HR-завдань, але за умови, що система відповідає вимогам EU AI Act щодо систем прийняття рішень у сфері зайнятості. Принцип мінімальних привілеїв (least privilege) тут застосовується точно так само, як і в будь-якій іншій інформаційній системі.

Крок 4. Корпоративна політика використання AI для команди

Один із найдешевших і найефективніших захисних заходів — написаний і підписаний усіма співробітниками внутрішній регламент. Він повинен містити:

перелік дозволених AI-інструментів (конкретні назви і тарифи);
список даних, які заборонено передавати в AI (наприклад, ПДн клієнтів, фінансові документи, паролі);
порядок дій при підозрі на витік даних;
відповідальних осіб (хто відповідає за AI-інструменти, хто — за інциденти).

Без такого регламенту ви не зможете довести регулятору, що вжили «розумних заходів» для захисту даних — а це один із критеріїв зменшення штрафів.

Як перевірити AI-підрядника перед підписанням контракту

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

Чотири питання, які треба поставити агентству

1. На яких серверах і в яких країнах будуть зберігатися дані? Якщо дані клієнтів з ЄС передаються на сервери в США без механізму стандартних договірних clauses (SCC) або іншого адекватного захисту — це порушення GDPR. Підрядник повинен відповісти конкретно: AWS Frankfurt, GigaCloud Ukraine, Azure Netherlands — не «в хмарі».

2. Чи є у вас DPA, яку можна підписати перед початком роботи? Якщо підрядник не знає, що таке DPA — або каже, що «оформимо потім» — це тривожний сигнал. Серйозна компанія має шаблон DPA і готова підписати його до отримання доступу до ваших даних.

3. Хто конкретно матиме доступ до клієнтських даних і на яких умовах? Підрядник зобов’язаний надати список осіб або ролей, які матимуть доступ, і підтвердити, що вони підписали NDA та пройшли навчання з захисту даних.

4. Що відбудеться з даними після завершення проекту? Клієнтська база, тестові дані, логи — все це повинно бути видалене або повернуте вам після завершення роботи. Якщо підрядник каже «ми зберігаємо дані для підтримки» — уточніть термін і умови зберігання, занесіть їх у договір.

Що має бути в договорі про обробку даних

Мінімальний набір пунктів у договорі з AI-підрядником:

Предмет і обсяг обробки: які конкретно дані, з якою метою, протягом якого часу.
Заборона субпідряду без вашої письмової згоди: підрядник не може передати ваші дані ще одному підряднику без дозволу.
Зобов’язання щодо конфіденційності для всіх співробітників підрядника.
Технічні та організаційні заходи безпеки (шифрування, контроль доступу, резервне копіювання).
Порядок сповіщення про витік — підрядник зобов’язаний повідомити вас не пізніше ніж через 24–72 годин після виявлення інциденту.
Умови видалення або повернення даних після закінчення договору.
Право на аудит: ви або уповноважена вами особа має право перевірити, як підрядник виконує умови DPA.

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

Практичний чеклист: Privacy-ready AI-впровадження

Цей чеклист призначений для власника бізнесу або операційного директора. Збережіть його і пройдіться по ньому перед тим, як підписати договір з AI-агентством або дати дозвіл команді використовувати новий AI-інструмент.

Законодавча база:

[ ] Визначено, чи підпадає компанія під дію GDPR (є клієнти або партнери в ЄС?).
[ ] Перевірено, чи є AI-система, що впроваджується, «системою високого ризику» за EU AI Act.
[ ] Призначено відповідальну особу за захист персональних даних всередині компанії.

Дані і категорії:

[ ] Складено перелік персональних даних клієнтів, які обробляє компанія.
[ ] Визначено, які з цих даних можуть потрапити в AI-систему.
[ ] Категорії особливо чутливих даних (здоров’я, фінанси, дані дітей) — виведені з AI-процесів або захищені додатково.

Договори і DPA:

[ ] Обраний тариф AI-сервісу (ChatGPT, Gemini тощо) — корпоративний, з DPA.
[ ] DPA підписано до передачі будь-яких персональних даних.
[ ] Договір з AI-підрядником містить всі пункти, описані в попередньому розділі.

Технічні заходи:

[ ] Налаштовано маскування або знеособлення даних перед передачею в AI.
[ ] Ведеться логування запитів до AI-систем.
[ ] Обмежений доступ співробітників до AI-інструментів з клієнтськими даними.

Процеси і команда:

[ ] Написано і підписано всіма співробітниками внутрішній регламент використання AI.
[ ] Проведено базовий інструктаж для менеджерів: що можна і що не можна передавати в AI.
[ ] Є чіткий порядок дій на випадок підозри на витік даних.

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

Якщо наш менеджер уже вставив базу клієнтів у ChatGPT — що робити?

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

Чи достатньо просто перейти на платний ChatGPT Plus?

Ні. ChatGPT Plus (індивідуальний платний план) не надає Data Processing Agreement. Для роботи з персональними даними потрібен ChatGPT Team або ChatGPT Enterprise — вони дають DPA і гарантують, що ваші дані не використовуються для навчання моделей.

GDPR не має порогу за кількістю співробітників. Якщо ви обробляєте дані громадян ЄС — GDPR застосовний. Виняток: компанії, для яких обробка даних є «побічною» діяльністю без систематичного характеру і без особливих категорій даних — їх може звільняти від обов’язку вести детальний реєстр обробки. Але заборону на несанкціоновану передачу даних третім сторонам це не скасовує.

EU AI Act стосується лише великих компаній?

Ні, але малий бізнес має менше обов’язків. Якщо ви використовуєте готові AI-інструменти (ChatGPT, Gemini, Copilot) — більша частина відповідальності за відповідність Act лежить на їхніх розробниках. Але якщо ви замовляєте власне AI-рішення, яке потрапляє в категорію «високий ризик» (HR, фінанси, робота з споживачами) — зобов’язання щодо документації, прозорості та аудиту поширюються і на вас.

Що таке «data breach» і коли про нього потрібно повідомляти?

Data breach (витік даних) — будь-яка ненавмисна або незаконна передача, розкриття, знищення або втрата персональних даних. За GDPR, якщо витік може завдати шкоди правам і свободам фізичних осіб — контролер зобов’язаний повідомити наглядовий орган впродовж 72 годин після виявлення і, у певних випадках, самих постраждалих осіб. Якщо компанія не повідомила вчасно — це окремий склад порушення з окремим штрафом.

Чи можна повністю уникнути ризиків, використовуючи тільки OpenSource AI?

OpenSource-моделі (Llama, Mistral, Gemma), розгорнуті на власних серверах, усувають ризик передачі даних стороннім постачальникам. Але не усувають усі ризики: безпека залежить від налаштування вашої інфраструктури, контролю доступу, шифрування і надійності тих, хто обслуговує систему. OpenSource — не гарантія безпеки, а лише інший профіль ризиків.

Що якщо підрядник відмовляється підписувати DPA?

Не підписуйте договір. Відмова від DPA означає або незнання законодавства, або свідоме небажання брати на себе зобов’язання щодо обробки ваших даних. Жоден з цих варіантів не є прийнятним при роботі з клієнтськими базами.

Висновок: безпека даних — конкурентна перевага, а не витрата

Компанії, які ставляться до захисту даних серйозно, отримують не лише захист від штрафів. Вони отримують перевагу в тендерах із EU-компаніями, які перевіряють GDPR-compliance підрядників. Вони отримують довіру від клієнтів, яким небайдуже, де зберігаються їхні дані. І вони отримують спокій — бо не чекають, що будь-якої миті хтось із менеджерів зробить помилку, яка обійдеться в кілька річних бюджетів.

Захист даних при впровадженні AI — це не мистецтво великих корпоративних юристів. Це чотири конкретні кроки: аудит даних, DPA з постачальником, технічне маскування і регламент для команди. Ці кроки доступні будь-якому бізнесу з 20–200 людей.

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

Замовте безкоштовний AI-аудит — покажемо, які дані клієнтів зараз під ризиком.