Персональні дані в хмарному ШІ: як організувати роботу з урахуванням GDPR і HIPAA

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

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

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

Коли застосовуються GDPR і HIPAA

GDPR. Регламент ЄС 2016/679 діє не лише всередині ЄС. Стаття 3 поширює його на обробку в контексті діяльності установи контролера або обробника в ЄС, незалежно від того, де фізично відбувається обробка. Також регламент застосовується до компаній без установи в ЄС, якщо обробка пов'язана з пропонуванням товарів чи послуг людям у ЄС або з моніторингом їхньої поведінки в ЄС.

Для української компанії це означає таке. Реєстрація в Україні сама по собі не виключає GDPR. Онлайн-сервіс, який цілеспрямовано працює з клієнтами в Польщі чи Румунії, може підпадати під регламент. Чи підпадає саме ваш процес, вирішується аналізом з юристом за критеріями статті 3, а не загальним правилом.

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

HIPAA. Це законодавство США у сфері медичної інформації. Настанови Міністерства охорони здоров'я та соціальних служб США (HHS) щодо хмарних обчислень адресовані covered entities (визначеним законом організаціям системи охорони здоров'я) та їхнім business associates (діловим партнерам), які працюють з електронною захищеною медичною інформацією, ePHI.

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

Чотири питання, з яких варто почати розмову з юристом:

1. Чи має компанія установу в ЄС, у контексті діяльності якої обробляються дані?
2. Чи пропонує компанія товари чи послуги людям у ЄС або відстежує їхню поведінку в ЄС?
3. Чи є компанія covered entity або business associate за правилами США?
4. Які ще правові режими застосовуються до процесу, зокрема українські?

Відповіді на ці питання визначають, які розділи нижче для вас обов'язкові, а які корисні як добра практика.

Намалюйте рух даних

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

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

Схему корисно малювати для одного конкретного сценарію, а не для «ШІ в компанії» загалом. Чат-бот підтримки, аналіз дзвінків і генерація нагадувань мають різні дані, різних отримувачів і різні строки зберігання.

Документи та ролі

Першими визначаються ролі. За статтею 4 GDPR контролер визначає цілі та засоби обробки, а обробник обробляє дані від імені контролера. Коли компанія використовує ШІ-сервіс для роботи зі своїми клієнтами, вона вирішує, навіщо і які дані обробляти. Постачальник у такій схемі обробляє дані за її дорученням. Але роль залежить від того, хто фактично визначає цілі й засоби, тож розподіл варто зафіксувати письмово для кожного учасника, включно з інтегратором.

Далі ключові вимоги, які стосуються ШІ-процесу, якщо до нього застосовується GDPR. Посилання ведуть на офіційний текст регламенту.

• Підстава обробки, стаття 6. Обробка законна лише за наявності однієї з підстав, перелічених у статті: наприклад, згода, виконання договору, юридичний обов'язок або законний інтерес. Жоден договір з постачальником не створює цієї підстави за вас.
• Спеціальні категорії, стаття 9. До них належать, зокрема, дані про здоров'я. Їхня обробка заборонена, якщо не застосовується один з винятків, визначених у статті.
• Договір з обробником, стаття 28. Обробник діє за документованими інструкціями контролера. Для залучення іншого обробника потрібен попередній конкретний або загальний письмовий дозвіл. За загального дозволу контролера повідомляють про заплановані зміни, щоб він міг заперечити. Договір про обробку даних часто називають DPA (Data Processing Agreement).
• Безпека, стаття 32. Контролер і обробник впроваджують технічні та організаційні заходи, що відповідають ризику. Стаття серед прикладів називає псевдонімізацію та шифрування.
• Оцінка впливу, стаття 35. Якщо обробка ймовірно несе високий ризик для прав людей, перед її початком проводиться оцінка впливу на захист даних (DPIA).
• Міжнародні передачі, стаття 44 і наступні. Для передачі до третіх країн або міжнародних організацій застосовуються умови глави V. У практичній оцінці враховують Європейську економічну зону (ЄЕЗ): до неї входять країни ЄС, Ісландія, Ліхтенштейн і Норвегія. Передачі поза ЄЕЗ потребують відповідного механізму захисту.

Для HIPAA ключовий документ інший. За настановами HHS, якщо covered entity або business associate залучає хмарного провайдера, який створює, отримує, зберігає чи передає ePHI від її імені, з провайдером укладається BAA (Business Associate Agreement). Провайдер вважається business associate навіть тоді, коли зберігає лише зашифровані дані і не має ключа до них. Окрім договору, HHS вимагає аналізу ризиків.

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

Мінімізація перед запитом

Стаття 5 GDPR закріплює принцип мінімізації: дані мають бути адекватними, доречними й обмеженими тим, що необхідно для мети обробки. Для ШІ-процесу з цього випливає практичне правило. Найкраще захищені дані ті, які ви взагалі не надіслали.

Перед підключенням ШІ поставте одне питання: який мінімум даних потрібен моделі, щоб виконати саме цю задачу? Типові прийоми:

• прибрати поля, які не впливають на результат;
• замінити ім'я та контакти внутрішнім ідентифікатором;
• передавати не весь документ, а лише потрібний фрагмент;
• агрегувати дані там, де не потрібен рівень окремої людини;
• зберігати таблицю відповідності «ідентифікатор → людина» у власній системі і не передавати її в ШІ-сервіс.

Тут важливо не переоцінити ефект. Псевдонімізація і анонімізація не одне й те саме. GDPR визначає псевдонімізацію як обробку, після якої дані не можна віднести до конкретної людини без додаткової інформації, що зберігається окремо. Але пункт 26 преамбули регламенту прямо вказує, що псевдонімізовані дані залишаються інформацією про особу, яку можна ідентифікувати. Регламент не застосовується лише до справді анонімної інформації. Тобто заміна імені на ідентифікатор знижує ризик, але не виводить обробку з-під GDPR.

Схожа логіка стосується самих моделей. Європейська рада із захисту даних (EDPB) у висновку 28/2024 не пропонує автоматично вважати анонімною модель, навчену на персональних даних. Оцінка залежить від того, наскільки ймовірно вилучити персональні дані з моделі або отримати їх через запити. Якщо компанія планує донавчати модель на клієнтських даних, це окреме рішення з окремою оцінкою.

Навчальний приклад: нагадування пацієнту про візит

Цей приклад вигаданий. Він ілюструє мінімізацію і не є висновком про законність конкретної обробки.

Клініка хоче, щоб ШІ формулював дружні нагадування пацієнтам про прийом. Розглянемо два варіанти побудови запиту.

Варіант А. У запит до ШІ-сервісу передається повна медична карта пацієнта разом з контактами, щоб «модель мала весь контекст».

Варіант Б. У запит передаються внутрішній ідентифікатор пацієнта, дата й час візиту та тип дозволеного каналу зв'язку. ШІ генерує шаблон тексту. Ім'я, номер телефону чи email підставляє вже система клініки, і вона ж надсилає повідомлення.

Варіант Б суттєво зменшує обсяг переданих даних. Але він не робить обробку автоматично законною чи анонімною. Ідентифікатор разом з часом візиту залишається псевдонімізованими персональними даними. Навіть факт запису до медичного закладу може розкривати відомості про здоров'я, і це має оцінити юрист.

Якщо для всіх пацієнтів достатньо одного шаблону, дані окремого пацієнта можна взагалі не передавати моделі. ШІ допомагає підготувати загальний текст, а система клініки підставляє ім'я, дату й час локально. Псевдонімізований запит варто залишати лише там, де індивідуальні відомості справді потрібні для задачі.

Друга таблиця показує, чому одного рішення недостатньо. Вона розділяє три рівні, які часто змішують в одну фразу «ми все закрили».

Захист і перевірка постачальника

Коли маршрут даних і ролі зрозумілі, переходимо до постачальника. Перевірка не зводиться до питання «чи безпечний сервіс». Вона складається з конкретних питань, відповіді на які мають бути в документації або договорі.

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

Регіони. Де обробляються і зберігаються дані. Чи є передача поза ЄЕЗ або до міжнародної організації і який механізм за главою V GDPR застосовується. Географію слід з'ясовувати для всього маршруту даних, включно із залученими постачальниками.

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

Інциденти. Як і в які строки постачальник повідомляє про інцидент, хто у вас отримує таке повідомлення і що відбувається далі. Ці умови мають бути в договорі, а не лише в маркетинговому описі.

Субобробники. Перелік компаній, які залучає постачальник, вид письмового дозволу та порядок повідомлення про зміни. Стаття 28(2) допускає конкретний або загальний попередній дозвіл. За загального дозволу має бути можливість заперечити проти додавання чи заміни обробника.

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

Окремо про шифрування. Воно потрібне, але не скасовує договорів. Як зазначає HHS, хмарний провайдер залишається business associate навіть без ключа до зашифрованих даних. Шифрування зменшує наслідки інциденту, але не змінює правового статусу учасників.

Що включити в рішення про запуск

Після всіх перевірок рішення варто оформити письмово. Не як загальний дозвіл «використовувати ШІ», а як записку щодо конкретного процесу. Ось поля, які ми рекомендуємо включити:

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

Що зробити найближчим часом:

1. Оберіть один процес, у якому персональні дані вже потрапляють або потраплять у ШІ.
2. Намалюйте для нього маршрут даних за таблицею етапів: від збору до видалення.
3. Пройдіть з юристом чотири питання про застосовність GDPR, HIPAA та інших режимів.
4. Зменште набір полів у запиті до мінімуму, потрібного для задачі.
5. Зберіть договори (DPA, за потреби BAA) і відповіді постачальника на питання про доступи, регіони, зберігання та інциденти.
6. Оформіть рішення про запуск з власником, залишковими ризиками і датою перегляду.

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