Більшість AI-функцій обробляють персональні дані — часто без того, щоб хтось це свідомо вирішив. Чат-бот підтримки отримує імена, телефони й деталі замовлень. Пайплайн документів читає рахунки з податковими номерами ФОП. Агент із доступом до CRM підтягує історію клієнтів у свій контекст. Кожен такий потік підпадає під законодавство про захист даних — GDPR в ЄС, український закон про персональні дані вдома і договірні зобов'язання перед клієнтами. Цей гайд перекладає юридичні вимоги в інженерні рішення. Це не юридична консультація; для вашого конкретного випадку залучайте DPO або юриста.

Де в LLM-застосунку течуть персональні дані

Перш ніж обирати контролі, складіть карту потоків:

Потік Приклад Типовий ризик
Ввід користувача Клієнт пише свій телефон і скаргу Передача сторонньому провайдеру моделі
Знайдений контекст (RAG) Нотатки CRM, тікети, договори в промпті Розкриття даних між користувачами; зайві дані в промптах
Результати інструментів Агент отримує замовлення з адресою й платіжними даними Дані в контексті, логах і трасах
Вивід моделі Підсумок із персональними даними Показ не тому користувачу; безстрокове зберігання
Логи й траси Повні промпти в інструментах спостережуваності Довге зберігання, широкий доступ
Пам'ять «Запам'ятовує» факти про користувача між сесіями Важко знайти й стерти
Дані для fine-tuning Минулі розмови використано для навчання Запам'ятовування, неможливість стерти

Кожен рядок — це операція обробки, якій потрібні мета, правова підстава й запобіжники.

Принципи GDPR в інженерних термінах

Ключові принципи GDPR (стаття 5) прямо відображаються на рішення в дизайні:

  • Обмеження мети: використовуйте дані, надіслані асистенту, для відповіді, а не мовчки для навчання чи маркетингу.
  • Мінімізація даних: надсилайте моделі лише те, що їй потрібно. Боту підтримки рідко потрібен повний запис клієнта — передайте релевантне замовлення, а не профіль із датою народження й повною адресою.
  • Точність: не дозволяйте виводу моделі перезаписувати довідникові дані без перевірки.
  • Обмеження зберігання: визначте строки зберігання розмов, промптів у логах, ембеддингів і пам'яті.
  • Цілісність і конфіденційність: шифрування, контроль доступу, захист від prompt injection і витоку даних; див. безпека AI-агентів.
  • Підзвітність: документуйте, що ви робите, — реєстр операцій обробки, DPIA там, де потрібно, оцінки вендорів.

Стаття 25 — захист даних за задумом і за замовчуванням — по суті є вказівкою ухвалювати ці рішення в архітектурі, а не в документі з політикою.

Вибір і налаштування провайдерів моделей

Коли ви надсилаєте дані API-провайдеру, він зазвичай є вашим обробником, і вам потрібна угода про обробку даних (DPA). Перевірте письмово:

  1. Навчання на ваших даних. Бізнес- та API-пропозиції великих провайдерів зазвичай за замовчуванням не навчаються на даних клієнтів; споживчі застосунки можуть. Переконайтеся, що ви на правильному тарифі.
  2. Зберігання. Скільки зберігаються промпти й відповіді — для моніторингу зловживань чи інших цілей? Багато провайдерів пропонують нульове чи скорочене зберігання для відповідних клієнтів.
  3. Місце обробки й передача. Де обробляються дані? Для передачі за межі ЄЕЗ спирайтеся на рішення про адекватність (як-от EU–US Data Privacy Framework для сертифікованих компаній) або стандартні договірні положення і документуйте оцінку передачі. Кілька провайдерів пропонують резидентність даних в ЄС або регіональну обробку через великі хмарні платформи.
  4. Субобробники й сертифікати безпеки (ISO 27001, SOC 2).
  5. Функції, що зберігають дані: завантаження файлів, стан розмови, кешування, пакетні задачі — кожна може мати власний строк зберігання.

Коли дані взагалі не можуть залишати вашу інфраструктуру, self-hosted моделі прибирають передачу третім сторонам, хоча всі інші зобов'язання залишаються.

Правова підстава й прозорість

Типові правові підстави для AI-функцій — виконання договору (користувач попросив асистента допомогти із замовленням) і законний інтерес (внутрішні інструменти продуктивності), причому останній потребує тесту балансу інтересів. Висновок EDPB 28/2024 окремо розглядає AI-моделі — зокрема, коли модель, навчену на персональних даних, можна вважати анонімною і як законний інтерес застосовується до розробки та впровадження.

Діють обов'язки прозорості: оновіть повідомлення про конфіденційність, описавши AI-обробку, провайдерів і цілі. За EU AI Act користувачам також треба повідомляти, що вони взаємодіють з AI-системою; див. гайд з EU AI Act. Якщо AI-система ухвалює рішення з юридичними чи подібно значущими наслідками для людей — кредит, найм, страхування, — застосовується стаття 22 GDPR про автоматизоване ухвалення рішень, і потрібен змістовний людський перегляд.

Маскування PII і псевдонімізація

Маскування перед надсиланням даних моделі — сильний захід мінімізації, коли задача не потребує ідентифікаторів:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()      # додайте власні розпізнавачі для українських форматів
anonymizer = AnonymizerEngine()

def redact(text: str) -> str:
    results = analyzer.analyze(text=text, language="en",
                               entities=["PHONE_NUMBER", "EMAIL_ADDRESS", "IBAN_CODE", "PERSON"])
    return anonymizer.anonymize(text=text, analyzer_results=results).text

Microsoft Presidio та подібні інструменти виявляють поширені ідентифікатори. Для українських даних додайте власні розпізнавачі: РНОКПП (10-значний податковий номер), ЄДРПОУ, формати паспортів, українські телефони (+380…), IBAN (UA + 27 цифр). Розпізнавання імен українською складніше; тестуйте повноту на реальних зразках.

Псевдонімізація часто краща за видалення: замініть ідентифікатори токенами (<CUSTOMER_1>), зберігайте відповідність на сервері й підставляйте реальні значення у відповідь моделі, перш ніж показати її авторизованому користувачу. Модель може міркувати про «замовлення клієнта 1», не бачачи імені.

Будьте реалістами: маскування ніколи не буває ідеальним, а деякі задачі потребують даних (асистент пише відповідь конкретному клієнту). Поєднуйте маскування з договірними й технічними контролями, а не покладайтеся лише на нього.

RAG і агенти: контроль доступу — це контроль приватності

Найпоширеніший інцидент приватності в AI-функціях — не витік у провайдера, а ситуація, коли один користувач бачить дані іншого, бо пошук чи інструменти проігнорували права доступу:

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

Логи, траси й пам'ять

Інструменти спостережуваності — часто забуте сховище даних. Застосовуйте ті самі правила, що й для продакшен-баз:

  • Відокремлюйте вміст від метаданих; вміст зберігайте недовго (наприклад, 14–30 днів).
  • Маскуйте перед експортом, де можливо.
  • Обмежуйте доступ колом людей, яким він потрібен.
  • Включайте LLM-інструменти (SaaS для трасування, датасети для оцінювання) в реєстр операцій обробки й оцінки вендорів.

Інструментальна частина описана у статті спостережуваність LLM. Для пам'яті асистента дайте користувачам бачити й видаляти збережене, а невикористані спогади видаляйте за строком.

Fine-tuning і запам'ятовування

Навчання на персональних даних створює складніші проблеми. Мовні моделі можуть запам'ятовувати й відтворювати частини навчальних даних, включно з персональною інформацією (Carlini et al., 2021). Стерти дані однієї людини з навченої моделі сьогодні практично неможливо; єдиний надійний варіант — перенавчання. Тому:

  • Для всього, що пов'язано з персональними даними, віддавайте перевагу RAG — видалення означає прибрати документ; див. fine-tuning чи RAG.
  • Якщо мусите донавчати на розмовах, ретельно псевдонімізуйте, документуйте правову підставу й тримайте навчальні набори мінімальними.

Права суб'єктів даних

Сплануйте, як оброблятимете запити:

  • Доступ: чи можете ви експортувати розмови людини, збережену пам'ять і похідні дані?
  • Видалення: чи можете видалити їх з бази, векторного індексу, логів, кешів і бекапів (у межах ротації бекапів)?
  • Заперечення й обмеження: чи може користувач відмовитися від AI-обробки й далі користуватися сервісом?

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

Україна: що застосовується

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

Чек-лист приватності для AI-функцій

  • Карта потоків даних: ввід, пошук, інструменти, вивід, логи, пам'ять
  • Провайдер на бізнес-/API-тарифі з DPA, без навчання на ваших даних, з відомим строком зберігання
  • Механізм передачі задокументовано; регіональна обробка там, де потрібно
  • Моделі надсилаються лише необхідні дані; маскування чи псевдонімізація, де можливо
  • Пошук та інструменти забезпечують права кінцевого користувача
  • Строки зберігання встановлені для розмов, логів, трас, ембеддингів і пам'яті
  • Повідомлення про конфіденційність оновлене; користувачів поінформовано, що вони спілкуються з AI
  • Процеси доступу, видалення й відмови охоплюють усі сховища AI-даних
  • DPIA проведено для високоризикової обробки (великий масштаб, чутливі дані, значущі рішення)

FAQ

Чи можна за GDPR надсилати дані клієнтів в API мовної моделі? Так, за наявності правової підстави, DPA з провайдером, належних гарантій передачі, мінімізації та прозорості. Питання не «чи», а «як».

Чи self-hosted модель автоматично відповідає вимогам? Ні. Вона прибирає передачу третім сторонам, але обмеження мети, строки зберігання, безпека й права суб'єктів даних нікуди не зникають.

Чи анонімні ембеддинги? Ні. Ембеддинги, отримані з персональних даних, часто можна пов'язати з вихідним текстом, і їх слід вважати персональними даними.

Чи потрібна DPIA для чат-бота? Для простого FAQ-бота часто ні; часто так — коли обробляються чутливі дані, відбувається моніторинг працівників, великий масштаб чи підтримка значущих рішень. Запитайте свого DPO.

Джерела

  1. Регламент (ЄС) 2016/679 (GDPR).
  2. EDPB (2024). Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models.
  3. Верховна Рада України. Закон України «Про захист персональних даних».
  4. Carlini et al. (2021). Extracting Training Data from Large Language Models.
  5. Microsoft. Presidio.
  6. OWASP. Top 10 for LLM Applications 2025: Sensitive Information Disclosure.