Запобігання проти виявлення: чому анонімізація ПДн у реальному часі є єдиним ефективним захистом від витоку даних через ШІ
Інцидент Samsung з ChatGPT у березні 2023 року наочно продемонстрував фундаментальне обмеження постфактумних засобів контролю безпеки: інженер Samsung вставив пропрієтарний програмний код у ChatGPT ще до того, як будь-яка система моніторингу чи запобігання могла втрутитися. Код вийшов з-під контролю Samsung одним натисканням клавіші.
Моніторинг журналів, кінцевий DLP та анонімізація після передачі — це інструменти виявлення. Вони повідомляють про те, що сталося, вже після того, як це сталося. При витоку даних через ШІ виявлення після передачі запізнилося. Дані вже оброблені моделлю ШІ, потенційно включені у навчальні дані і більше не перебувають під вашим контролем.
Масштаб проблеми
Дослідження Cyberhaven 2025 року проаналізувало використання корпоративних інструментів ШІ у тисячах організацій:
- 11% усіх запитів до ChatGPT містять конфіденційні або персональні дані
- Пересічний співробітник взаємодіє з інструментами ШІ 14 разів на день
- Співробітники з інтенсивним використанням (юристи, аналітики, персонал підтримки клієнтів): 30–50 взаємодій з ШІ щодня
- При 11% запитів, що містять конфіденційні дані: 3–5 конфіденційних передач на активного співробітника щодня
В організації з 500 активними співробітниками це 1 500–2 500 конфіденційних передач до зовнішніх систем ШІ щодня. Кожна передача є потенційним порушенням статті 83 GDPR, якщо містить персональні дані.
Що вважається конфіденційними або персональними даними у запитах до ШІ:
- Імена клієнтів та контактна інформація (при складанні листів клієнтам)
- Номери рахунків і фінансові деталі (при аналізі транзакцій)
- Медична інформація (медичні працівники, які запитують клінічні рекомендації)
- Деталі юридичних справ (юристи, які запитують аналіз договорів)
- Інформація про співробітників (HR при оцінці ефективності)
- Внутрішні бізнес-дані (фінансові прогнози, анонсовані продукти)
Дослідження Cyberhaven не розмежовує навмисне поширення даних (співробітник свідомо ділиться даними клієнта) і випадкове (співробітник включає дані, не задумуючись про наслідки для навчання ШІ). Обидва варіанти створюють однаковий ризик.
Чому виявлення недостатньо
Моніторинг на рівні мережі: HTTPS-шифрування означає, що провайдери та мережеві пристрої не можуть перевіряти вміст запитів до ШІ без TLS-інспекції (MITM). TLS-інспекція сама по собі створює проблеми конфіденційності та безпеки, вносить затримки дешифрування і часто блокується сучасними браузерами.
Кінцевий DLP: Агенти на кінцевих пристроях можуть відстежувати вміст буфера обміну та натискання клавіш, але мають вроджену затримку. До того моменту, як агент DLP обробить послідовність натискань і виявить порушення, дані вже можуть бути відправлені. DLP краще підходить для запобігання витоку через файли, ніж через введення у браузері.
Журнали аудиту ШІ-сервісів: Деякі корпоративні плани ШІ надають журналювання запитів. Це повідомляє вам про те, що було передано, але вже після передачі. Корисно для реагування на інциденти, але не для запобігання.
Навчання співробітників: «Не вставляйте дані клієнтів у ChatGPT» — це правило, а не контроль. Дослідження Cyberhaven показує, що навіть за наявності правил 11% запитів містять конфіденційні дані. Навчання бореться з навмисними порушеннями, але не усуває випадкове поширення або дії співробітників, які знають правила, але забувають про них у потоці роботи.
Блокування інструментів ШІ: Крайній захід. Організації, що блокують усі інструменти ШІ, втрачають переваги продуктивності, які стимулювали впровадження. Тіньові IT зазвичай замінюють заблоковані інструменти — співробітники використовують особисті пристрої або особисті облікові записи ШІ, поза будь-яким моніторингом.
Жоден з цих підходів не запобігає потраплянню конфіденційних даних до систем ШІ в реальному часі.
Запобігання на точці входу
Єдиний ефективний захист від витоку даних через ШІ в реальному часі — це анонімізація до відправлення запиту. Якщо ім'я клієнта «Марія Коваленко» замінити на «[ОСОБА_1]» до того, як запит покине браузер, модель ШІ не отримає жодних персональних даних — незалежно від того, чи спрацюють системи моніторингу.
Як працює вбудоване запобігання:
- Співробітник вводить електронну адресу клієнта в інтерфейс Claude або ChatGPT
- Розширення браузера виявляє ПДн у полі введення в реальному часі
- ПДн підсвічуються з мітками типів сутностей (ОСОБА, ЕЛЕКТРОННА_ПОШТА, НОМЕР_РАХУНКУ)
- Співробітник переглядає підсвічені сутності
- Одним кліком анонімізація замінює ПДн на мічені токени
- Анонімізований запит відправляється
ШІ отримує: «Клієнт [ОСОБА_1] за адресою [ПОШТА_1] має рахунок [РАХУНОК_1] і запитує про..."
ШІ відповідає на запит, не отримавши фактичних даних клієнта. Співробітник може відновити контекст відповіді, знаючи, хто такий [ОСОБА_1].
Що це запобігає:
- Потраплянню персональних даних (стаття 4 GDPR) до зовнішніх ШІ-процесорів без відповідних гарантій
- Включенню ПДн клієнтів у навчальні дані ШІ
- Втраті продуктивності через повне блокування інструментів ШІ
Що це не запобігає:
- Навмисному поширенню (співробітник свідомо вводить імена після отримання попередження)
- Контенту, не ідентифікованому як ПДн (специфічні деталі продукту, внутрішні процеси)
- Поширенню через вкладені файли (потрібен окремий робочий процес анонімізації файлів)
Запобігання через вбудовану анонімізацію не є ідеальним — жоден контроль не є. Але воно знижує показник 11% інцидентів, усуваючи випадкову та недбалу категорію, яка складає більшість випадків.
Впровадження: кейс юридичної фірми
Асоціати юридичної фірми використовували Claude для складання резюме договорів. Робочий процес: копіювати відповідні розділи договору, вставляти в Claude, запитувати резюме.
До впровадження Chrome Extension (6 місяців):
- 3 інциденти з ПДн клієнтів, виявлені під час щоквартальної перевірки відповідності
- Кожен інцидент: ім'я клієнта + посилальний номер справи включено до запиту Claude
- Усі 3 були випадковими — асоціати не усвідомлювали, що посилальні номери справ є ПДн клієнтів
Після впровадження Chrome Extension (6 місяців):
- Нуль інцидентів з ПДн клієнтів
- Асоціати отримують підсвічування в реальному часі при вставці розділів договорів, що містять імена клієнтів
- Одним кліком анонімізація замінила «Справа Johnson Controls 2024-0347» на «[ОСОБА_1] Справа [ПОСИЛАННЯ_1]»
- Робочий процес незмінний — асоціати продовжують використовувати Claude для допомоги у складанні документів
Керуючий партнер пояснює покращення моделлю запобігання, а не кращим навчанням: «Наші асоціати знали правила до появи розширення. Розширення зробило відповідність вимогам найлегшим шляхом."
Документація щодо відповідності GDPR
Для організацій, що впроваджують браузерну анонімізацію ШІ як технічний засіб контролю:
Реєстр операцій з обробки (ROPA): «Взаємодії ШІ у підтримці клієнтів обробляються через анонімізацію ПДн до відправлення зовнішнім ШІ-постачальникам, а виявлення виконується на API anonym.legal, розміщеному в ЄС. Типи виявлених сутностей: [список]. Двигун виявлення: [версія]. Докази контролю: журнали розгортання Chrome Extension показують частку анонімізації по співробітниках.»
Угода з обробником даних: Постачальник ШІ (OpenAI, Anthropic, Google) є обробником даних. Якщо жодні персональні дані не надходять до ШІ-постачальника, зобов'язання DPA спрощуються — персональні дані, за які ви відповідаєте, не надходять до ШІ-постачальника; вони потрапляють лише на API anonym.legal, розміщений в ЄС, для виявлення.
Докази аудиту: Журнали розгортання Chrome Extension показують: кількість виявлених сутностей, відсоток анонімізованих сутностей перед відправленням, найбільш часто виявлені типи сутностей. Організаційні панелі агрегують ці дані для звітності з відповідності.
Висновок
Інцидент Samsung з ChatGPT довів, що витік даних через ШІ в реальному часі може відбутися швидше, ніж будь-який постфактумний засіб контролю безпеки здатний відреагувати. Дослідження Cyberhaven кількісно визначило масштаб: 11% запитів, кілька разів на співробітника щодня, у корпоративному масштабі.
Запобігання через вбудовану анонімізацію в реальному часі усуває першопричину, а не симптоми. Коли персональні дані ніколи не потрапляють до моделі ШІ, немає витоку, який потрібно виявляти, фіксувати або усувати. Співробітник зберігає продуктивність ШІ. Організація зберігає відповідність GDPR.
Виявлення — це те, що ви робите, коли запобігання не спрацювало. Для витоку даних через ШІ вартість невдачі (регуляторні штрафи, репутаційна шкода, ерозія довіри клієнтів) виправдовує інвестиції в запобігання.
Джерела: