anonym.legal

By · Last updated 2026-06-05

Назад до блогуБезпека ШІ

Запобігання витоку ПДн в реальному часі при використанні ШІ

Коли співробітник вводить ім'я клієнта в ChatGPT, дані миттєво виходять з-під контролю організації. Постфактумні засоби DLP не здатні виправити ситуацію після витоку.

June 5, 20267 хв читання
AI data preventionChatGPT PIIreal-time anonymizationDLP alternativeChrome Extension

Запобігання проти виявлення: чому анонімізація ПДн у реальному часі є єдиним ефективним захистом від витоку даних через ШІ

Інцидент 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]» до того, як запит покине браузер, модель ШІ не отримає жодних персональних даних — незалежно від того, чи спрацюють системи моніторингу.

Як працює вбудоване запобігання:

  1. Співробітник вводить електронну адресу клієнта в інтерфейс Claude або ChatGPT
  2. Розширення браузера виявляє ПДн у полі введення в реальному часі
  3. ПДн підсвічуються з мітками типів сутностей (ОСОБА, ЕЛЕКТРОННА_ПОШТА, НОМЕР_РАХУНКУ)
  4. Співробітник переглядає підсвічені сутності
  5. Одним кліком анонімізація замінює ПДн на мічені токени
  6. Анонімізований запит відправляється

ШІ отримує: «Клієнт [ОСОБА_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): «Взаємодії ШІ у підтримці клієнтів обробляються через клієнтську анонімізацію ПДн до відправлення зовнішнім ШІ-постачальникам. Типи виявлених сутностей: [список]. Двигун виявлення: [версія]. Докази контролю: журнали розгортання Chrome Extension показують частку анонімізації по співробітниках.»

Угода з обробником даних: Постачальник ШІ (OpenAI, Anthropic, Google) є обробником даних. Якщо жодні персональні дані не надходять до ШІ-постачальника, зобов'язання DPA спрощуються — персональні дані, за які ви відповідаєте, ніколи до них не надходять.

Докази аудиту: Журнали розгортання Chrome Extension показують: кількість виявлених сутностей, відсоток анонімізованих сутностей перед відправленням, найбільш часто виявлені типи сутностей. Організаційні панелі агрегують ці дані для звітності з відповідності.

Висновок

Інцидент Samsung з ChatGPT довів, що витік даних через ШІ в реальному часі може відбутися швидше, ніж будь-який постфактумний засіб контролю безпеки здатний відреагувати. Дослідження Cyberhaven кількісно визначило масштаб: 11% запитів, кілька разів на співробітника щодня, у корпоративному масштабі.

Запобігання через вбудовану анонімізацію в реальному часі усуває першопричину, а не симптоми. Коли персональні дані ніколи не потрапляють до моделі ШІ, немає витоку, який потрібно виявляти, фіксувати або усувати. Співробітник зберігає продуктивність ШІ. Організація зберігає відповідність GDPR.

Виявлення — це те, що ви робите, коли запобігання не спрацювало. Для витоку даних через ШІ вартість невдачі (регуляторні штрафи, репутаційна шкода, ерозія довіри клієнтів) виправдовує інвестиції в запобігання.

Джерела:

Готові захистити свої дані?

Почніть анонімізувати PII з 285+ типами сутностей на 48 мовах.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.