Компанія підключає систему AI до поштової скриньки. Асистент має відповідати на запитання клієнтів, класифікувати звернення та пропонувати відповіді. Перші тести проходять чудово. Через кілька тижнів хтось запитує: звідки взагалі відомо, що в цих листах є номери PESEL? Чи все це потрапляє до хмари?
Це момент, коли більшість впроваджень AI стикаються з першим серйозним питанням щодо безпеки даних. Це не академічне питання. РОДО накладає обов’язок мінімізації даних: до моделі має потрапляти лише стільки інформації, скільки необхідно для виконання завдання. Ім’я клієнта, номер замовлення, номер PESEL, IP-адреса, електронна пошта — жодна з цих величин не потрібна, щоб модель класифікувала намір запиту чи запропонувала відповідь. Усі вони є PII і мають бути замінені токенами ще до відправки.
Що таке PII і чому вони важливі в контексті AI
#PII (Personally Identifiable Information) — це будь-яка інформація, що дозволяє ідентифікувати або виділити конкретну особу, прямо чи опосередковано. У польському законодавстві обсяг регулює РОДО, яке включає:
- ім’я та прізвище,
- номер PESEL, NIP, номер посвідчення,
- адреса електронної пошти та номер телефону,
- адреса проживання,
- IP-адреса та ідентифікатори сесії,
- біометричні та медичні дані (особлива категорія, ст. 9 РОДО),
- комбінації даних, які разом ідентифікують особу, хоча жодна з них окремо цього не робить.
Мовні моделі не «запам’ятовують» дані в розумінні бази даних. Але вони обробляють їх на стороні постачальника: текст потрапляє до обчислювального середовища постачальника, токенізується, обробляється моделлю, і повертається відповідь. Залежно від угоди та конфігурації, дані можуть використовуватися для вдосконалення моделі або логуватися протягом певного часу. Цього достатньо, щоб юристи та аудитори поставили питання про правову підставу такої передачі.
Маскування PII перед відправкою вирішує цю проблему в корені: модель бачить [ІМ’Я_1], [EMAIL_1], [PESEL_1] замість реальних значень. Завдання класифікації чи пропозиції відповіді виконано. Персональні дані не залишили інфраструктуру.
Три патерни: маскування, псевдонімізація, анонімізація
Не всі підходи рівнозначні. Варто розрізняти три поняття, оскільки правові та технічні наслідки відрізняються.
| Патерн | Як працює | Оборотність | Статус РОДО |
|---|---|---|---|
| Маскування (токенізація) | PII замінюються токеном [ТИП_N] локально, токен-мапа зберігається локально | оборотне (локальна мапа) | персональні дані все ще обробляються локально; до моделі виходить псевдонім |
| Псевдонімізація | PII замінюються постійним, детермінованим хешем або кодом; той самий email завжди → той самий токен | оборотне (ключ) | РОДО: все ще персональні дані, але ризик зменшено |
| Анонімізація | видалення або узагальнення до неможливості ре-ідентифікації | необоротне | РОДО перестає діяти для таких оброблених даних |
У типових потоках RAG застосовується маскування: PII замінюються токеном, відповідь моделі повертається з токенами, а локальний шар відновлює оригінальний контекст там, де це потрібно для дії (наприклад, вставлення імені у відповідь на email). Мапа токен–значення ніколи не залишає вашого сервера.
Повна анонімізація складна і рідко потрібна в операційних потоках. Вона корисна для логування, звітності та тренування моделей: набір даних без можливості ре-ідентифікації не підпадає під РОДО і може використовуватися довільно.
Як виглядає шар маскування PII на практиці
#Стандартна реалізація складається з чотирьох компонентів, що працюють локально, перед будь-яким мережевим трафіком до зовнішнього LLM.
1. Детектор PII. Бібліотека або модель (наприклад, spaCy NER, Microsoft Presidio, власні правила regex) сканує текст і знаходить усі фрагменти, що виглядають як PII. Для польського тексту це означає розпізнавання PESEL (11-значний шаблон із контрольною сумою), NIP (10-значний), номерів телефонів (9-значні послідовності з префіксами), адрес електронної пошти (regex RFC 5322) та власних назв (NER).
2. Токенізатор. Кожне знайдене PII замінюється токеном зі збереженням типу та порядкового номера в документі: Jan Kowalski → [ОСОБА_1], [email protected] → [EMAIL_1], 48123456789 → [ТЕЛЕФОН_1]. Якщо той самий email з’являється тричі, всі три входження отримують той самий токен.
3. Мапа зворотного відображення. Токен-мапа ({„[ОСОБА_1]": „Jan Kowalski"}) зберігається локально (у пам’яті сесії або зашифрованій базі), ніколи не відправляється до моделі.
4. Детокенізатор. Після повернення відповіді від моделі локальний шар опціонально підставляє назад оригінальні значення там, де потрібна дія (наприклад, адресування відповіді). Якщо відповідь потрапляє до аудитного логу, вона залишається з токенами.
У нашій архітектурі цей шар працює як middleware у LLM routerі. Кожен виклик моделі проходить через нього автоматично, без змін з боку застосунку.
Які дані маскувати: пріоритети для українських компаній
Не кожне слово потребує маскування. Пріоритезація за ризиком:
| Категорія PII | Приклади | Пріоритет маскування |
|---|---|---|
| Правові ідентифікатори | PESEL, NIP, номер посвідчення, номер паспорта | критичний — завжди |
| Контактні дані | email, телефон, адреса | високий — завжди |
| Фінансові дані | номер рахунку, номер карти, суми + ім’я | високий — завжди |
| Медичні/біометричні дані | діагноз, результат аналізу | критичний (ст. 9 РОДО) |
| Ім’я та прізвище | у контексті корпоративного документа | високий |
| IP-адреса | у логах, заголовках запитів | середній — залежно від контексту |
| Назви компаній (клієнтів B2B) | у тексті контракту | середній — залежно від угоди NDA |
Практичне правило: якщо дані потрапляють до inference у хмарній моделі, маскуйте принаймні перші три категорії безумовно. Медичні та біометричні категорії — це особлива категорія РОДО (ст. 9) — потребують окремого аналізу DPIA та в багатьох випадках обробки виключно локально.
Self-hosting як межа безпеки
#Маскування PII зменшує ризик, але не усуває всіх векторів. Для особливо чутливих даних (кадри співробітників, медичні дані, контракти з конфіденційними положеннями, дані дітей) правильною відповіддю є self-hosting: мовна модель та модель ембедінгів працюють на вашому обладнанні, жодні запити не виходять за межі внутрішньої мережі.
У нашому стеку локальний BGE-M3 обслуговує шар ембедінгів для RAG без будь-якого вихідного трафіку. Генеративні моделі можуть працювати через Ollama на локальному GPU або через LLM router з політикою fallback: чутливі режими → локальна модель, стандартні режими → хмара з маскованими PII.
У цього рішення є одна вартість: локальні моделі менш просунуті, ніж великі хмарні моделі. Різниця прийнятна для класифікації, екстракції та семантичного пошуку. Вона більш помітна для складного міркування. Відповідь на питання «чи достатньо self-hosting?» залежить від обсягу завдань — докладніше це розглядається в статті про корпоративний GPT на базі знань.
РОДО, AI Act та DPIA: що має бути задокументовано
#Впровадження AI, що обробляє персональні дані, потребує кількох кроків з правового та формального боку, незалежно від якості технічного маскування.
Оцінка впливу на захист даних (DPIA). Якщо обробка є систематичною, у великих масштабах або стосується особливих категорій даних (здоров’я, походження, біометричні дані), DPIA є обов’язковою згідно зі ст. 35 РОДО. Автоматична обробка кореспонденції клієнтів, що містить персональні дані, зазвичай підпадає під DPIA.
Реєстр операцій обробки. Нові потоки AI мають бути внесені до реєстру: мета, правова підстава, категорії даних, отримувачі, час зберігання, заходи безпеки.
AI Act (чинний з 2025/2026). Системи, що класифікують осіб, оцінюють надійність чи приймають рішення, які впливають на права особи, вважаються системами високого ризику. Вони потребують human-oversight, технічної документації та реєстрації в єдиній базі даних ЄС. Допоміжні системи (пропозиції для консультанта, які людина затверджує) мають нижчий поріг вимог. Докладні вимоги розглядаються в статті AI Act та РОДО 2026.
Договір доручення обробки (DPA). Якщо ви користуєтеся хмарною моделлю, навіть з маскуванням PII, формально ви доручаєте обробку постачальнику. DPA з постачальником є обов’язковим згідно зі ст. 28 РОДО.
Пастки: що маскування PII не вирішує
#Маскування PII — це необхідний фундамент, але не повна відповідь на питання безпеки. Три області, які потребують окремих рішень:
Inference attacks. Навіть анонімізовані дані можуть дозволяти ре-ідентифікацію, якщо контекст є достатньо унікальним. Документ, що описує «[ОСОБА_1], директор компанії в маленькому місті на Підкарпатті, яка наймає 12 осіб», може бути ідентифікованим без імені. Пом’якшення: узагальнення контексту в логах, обмеження деталізації.
Prompt injection. Зловмисні інструкції, приховані у вхідних даних, можуть намагатися витягнути токен-мапу або обійти маскування. Рішення — guardrails, що працюють до і після моделі, описані в статті безпека агентів AI.
Model memorization. Якщо ваші дані потрапляють до тренування моделі постачальника, існує ризик, що модель «запам’ятала» фрагменти ваших документів. Для особливо чутливих даних єдиним надійним захистом є вимкнення опції тренування (opt-out в API постачальника) або self-hosting. Перевірте політику постачальника перед впровадженням.
Спробуйте наживо
Вставте фрагмент тексту з потенційними персональними даними, і модель покаже, як шар маскування PII ідентифікує та токенізує дані перед відправкою до моделі (playground: PII маскуються локально, нульове зберігання):
FAQ
#Чи вимагає РОДО маскування PII?
#РОДО прямо не наказує маскування, але ст. 5 п. 1 літ. c (мінімізація даних) та ст. 25 (privacy by design) разом вимагають, щоб до обробки потрапляло лише те, що необхідно. Відправка повних персональних даних до хмарної моделі, коли завдання потребує лише класифікації наміру, порушує принцип мінімізації. Маскування PII — це найпростіша техніка виконання цієї вимоги. Для даних особливих категорій (здоров’я, біометрія) також потрібна DPIA.
Які бібліотеки використовуються для виявлення PII в українській мові?
#Найпопулярніші варіанти: Microsoft Presidio (open source, розширюваний польськими шаблонами NER та regex), spaCy з моделлю uk_core_news_lg (добре розпізнавання власних назв та NER) та власні правила регулярних виразів для детермінованих ідентифікаторів (PESEL, NIP, номер рахунку IBAN). На практиці використовується комбінація: regex для ідентифікаторів із відомими шаблонами + NER для імен та назв місць. Жодна з цих бібліотек не є ідеальною, тому після маскування варто перевіряти випадкові вибірки.
Що робити з даними у файлах PDF та зображеннях, що відправляються до моделей vision?
#Документи PDF та зображення складніші, оскільки PII можуть бути вбудовані в скан, логотип, колонтитул або рукописний підпис. Шар OCR (OCR) спочатку має витягти текст, а вже потім детектор PII обробить його перед відправкою до моделі. Для документів з високою чутливістю (договори, медичні акти) безпечніше використовувати self-hosted модель vision, що працює без доступу до зовнішньої мережі.
Як маскування PII впливає на якість відповідей моделі?
#При добре спроектованому маскуванні вплив мінімальний. Класифікація намірів, екстракція структури, семантичний пошук та генерація відповідей працюють на токенах так само добре, як і на реальних даних, оскільки модель обробляє структуру та контекст, а не числові значення. Проблема виникає, коли логіка бізнесу потребує значень (наприклад, розрахунок віку за PESEL) — тут маскування слід застосовувати після розрахунку, а не до нього.
Як впровадити маскування PII в існуючій системі AI без перебудови?
#Найшвидший шлях — middleware у шарі маршрутизатора LLM: кожен виклик моделі проходить через пре-процесор PII та пост-процесор детокенізації відповіді. Застосунок не повинен знати про маскування. Впровадження такого шару зазвичай займає від кількох днів до кількох тижнів, залежно від складності потоків. Калькулятор обсягу та витрат можна знайти в калькуляторі ROI. Якщо ви тільки досліджуєте можливості, почніть з оцінки готовності.