Витік даних через LLM: як захистити корпоративні та клієнтські дані

Більшість розмов про безпеку AI зупиняється на «не вставляй конфіденційні дані у публічний чат». Це правда, але це лише перший, найпростіший вектор. У виробничих системах — асистентах з базою знань, агентах з доступом до CRM, автоматизаціях обслуговування — дані витікають менш очевидним чином: через контекст, який модель тримає в пам’яті, через логи, які хтось колись увімкнув «тимчасово для дебагу», через ліцензійні умови постачальника моделі. Ця стаття розбирає чотири реальні вектори витоку та описує конкретний захист для кожного з них. Ми не обіцяємо «повної герметичності» — у безпеці така обіцянка є тривожним сигналом. Описуємо, як зменшити ризик до рівня, який можна задокументувати та захистити.

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

Найнебезпечніша різновидність — непрямий injection: шкідлива інструкція не вводиться в чаті, а прихована в документі, який система сама завантажує в контекст (електронний лист, PDF-файл, веб-сторінка). Модель сприймає її як частину завдання. Тому сама валідація того, що вводить користувач, недостатня — потрібно також контролювати те, що система завантажує ззовні.

Захист має три шари. Перший: системний промпт ніколи не містить секретів чи даних, розкриття яких болюче — ключі та конфіденційні дані тримаємо поза контекстом моделі. Другий: guardrails на вході виявляють спроби маніпуляції інструкцією (шаблони «ігноруй попередні команди», спроби зміни мови як камуфляжу). Третій: ізоляція per-rola та per-tenant, щоб навіть успішний injection не виходив за межі даних, до яких користувач і так має право. Детальний список тестів описано в статті про аудит безпеки асистента AI, а архітектуру прав доступу — у тексті про безпеку агентів AI.

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

Логи тут особливо підступні. Observability потрібна для діагностики проблем, тому хтось вмикає повне логування вмісту запитів «тимчасово» — і так залишається на місяці. Через пів року у вас репозиторій PII без правової підстави, без політики зберігання та без механізму видалення на вимогу, якого вимагає RODO.

Захист — це маскування PII перед моделлю та перед записом до логу. У нашому підході запит проходить через шар псевдонімізації, перш ніж потрапити до LLM: імена, номери PESEL, електронні адреси та номери рахунків замінюються токенами, а оригінали — якщо вони взагалі потрібні — залишаються на стороні, яку ви контролюєте. Логи зберігають лише операційні метадані (час, статус, вартість токенів), а не вміст у чистому вигляді. Як підготувати корпоративні дані, щоб цей шар працював з самого початку, описано в тексті про підготовку даних під AI.

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

Це питання data-residency та зберігання, а відповіді криються в ліцензійних умовах, а не в технічній документації. Різниця між «API для бізнес-завдань з гарантією zero-retention» та «безкоштовним споживчим чатом, який навчається на розмовах» фундаментальна з точки зору RODO і часто вирішує, чи можна взагалі використовувати цього постачальника для даних клієнтів.

Тут вибір архітектури має найбільше значення. Self-hosting моделі — запуск її на власній або контрольованій інфраструктурі — усуває цей вектор у джерелі: дані не залишають вашого середовища, тому питання «що постачальник з ними робить» зникає. Ціна — це підтримка та зазвичай нижча сира якість найкращих моделей. Компроміси та критерії рішення розбираємо в статті про self-hosting LLM та RODO.

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

Захист поєднує контроль доступу з guardrails на виході. Фільтрація прав доступу має працювати на рівні отримання контексту (модель бачить лише фрагменти, до яких запитувач має право), а не лише на рівні відповіді. На самому виході другий шар guardrails сканує відповідь на наявність шаблонів конфіденційних даних, перш ніж вона потрапить до користувача. Цей самий шар стежить, щоб модель не процитувала секрет чи PII навіть тоді, коли з якоїсь причини вони опинилися в контексті.

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

Жоден рядок не покриває інші. Self-hosting (рядок 3) не захищає від prompt injection (рядок 1). Маскування PII (рядок 2) не зупинить відповідь, що цитує чужий документ (рядок 4). Безпека — це сума шарів, і саме тому аудит перевіряє кожен окремо.

Чотири технічні шари працюють лише тоді, коли за ними стоїть організаційне рішення: які дані взагалі можна передавати моделі, в якій формі та через якого постачальника. Це сфера governance даних для AI — класифікації даних, реєстру потоків та призначення відповідальності. Без неї кожен технічний шар налаштовується ad hoc і з часом дрейфує.

Для даних клієнтів варто перевірити, чи потребує обробка DPIA — оцінки впливу на захист даних. Результат аудиту векторів витоку (з таблиці вище) природно живить таку оцінку: показує, які ризики існують і як вони були обмежені. Обов’язки з документування на 2026 рік, що поєднують RODO з AI Act, описано в статті про обов’язки компаній щодо AI Act та RODO.

Практичний порядок впровадження такий: спочатку класифікація даних і рішення щодо постачальника (governance), потім маскування PII та контроль доступу (технічні шари, які потрібно побудувати раз і назавжди), насамкінець guardrails та аудит як перевірочний шар. Спроба починати з guardrails у системі, яка вже надсилає сирі PII до зовнішнього API, — це лікування симптому замість причини.

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

Закриває один конкретний вектор: дані не потрапляють до зовнішнього постачальника, тому зникає ризик зберігання та навчання на ваших даних. Однак не усуває prompt injection, витік PII до логів чи розкриття даних поза межами прав у відповіді — це залежить від архітектури, а не від місця хостингу. Self-hosting спрощує compliance з RODO, але аудит решти шарів необхідний незалежно від вибору інфраструктури.

Це шар, який перехоплює запит до того, як він потрапить до LLM, і замінює персональні дані (імена, PESEL, електронні адреси, номери рахунків) замісними токенами. Модель працює з анонімізованим контентом, а оригінальні дані — якщо вони взагалі потрібні для відповіді — залишаються на стороні, яку ви контролюєте. Завдяки цьому навіть витік контексту або лог з повним вмістом не розкриває реальних персональних даних.

Відповідь міститься в ліцензійних умовах сервісу, а не в технічній документації — шукайте записи про зберігання даних, навчання та локацію обробки (data-residency). Платні бізнес-API зазвичай пропонують zero-retention та виключення з навчання; безкоштовні споживчі сервіси часто цього не роблять. Якщо обробляєте дані клієнтів, сприймайте відсутність чіткої гарантії zero-retention як відсутність згоди на використання цього постачальника.

Стільки, скільки у вас активних векторів. Якщо система використовує зовнішнє API та обробляє PII клієнтів, у грі всі чотири — і тоді потрібні маскування, guardrails, контроль доступу та рішення щодо retention у постачальника або self-hosting. Кількість витрат і часу залежить від масштабу, тому наводимо їх у діапазонах лише після інвентаризації даних; відправною точкою є класифікація, яка показує, які вектори вас взагалі стосуються.