anonym.legal

By · Last updated 2026-06-05

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

Відповідність статті 32 GDPR для інструментів ШІ: моніторинг ПДн

Командам корпоративного комплаєнсу потрібні кількісні докази контролю ПДн в інструментах ШІ. Мережевий DLP пропускає взаємодії ШІ у браузері.

June 5, 20267 хв читання
GDPR Article 32AI compliancePII monitoringCISO evidenceenterprise AI governance

Доведення відповідності статті 32 GDPR для інструментів ШІ: моніторинг ризиків ПДн через дані, а не через документи про політику

Стаття 32 GDPR вимагає «відповідних технічних та організаційних заходів» для забезпечення безпеки, пропорційної ризику. Коли співробітники використовують зовнішні інструменти ШІ (ChatGPT, Claude, Gemini), ризик є реальним і вимірюваним. Заходи з усунення цього ризику також мають бути доказовими.

Документ про політику, що стверджує «співробітники не повинні ділитися персональними даними з інструментами ШІ» — це організаційний захід. Це не технічний захід. І цього недостатньо, коли аудитор DPA запитує: «Звідки ви знаєте, що співробітники дійсно це дотримуються?»

На що звертають увагу аудитори DPA при перевірці інструментів ШІ

Піcля інциденту Samsung з ChatGPT (березень 2023 року) та подальшої регуляторної уваги до корпоративного впровадження ШІ, аудитори DPA розробили конкретні запитання щодо програм відповідності для інструментів ШІ:

Технічні засоби контролю:

  • «Які технічні заходи запобігають потраплянню персональних даних до зовнішніх систем ШІ?»
  • «Як ви забезпечуєте вимоги анонімізації у взаємодіях з ШІ в реальному часі?»
  • «Які докази підтверджують, що ці технічні засоби контролю функціонують?»

Моніторинг:

  • «Як ви відстежуєте використання інструментів ШІ співробітниками для виявлення ризиків ПДн?»
  • «Які метрики ви відстежуєте? З якою частотою?»
  • «Звідки ви знаєте, що ваші засоби контролю ефективні, а не обходяться?»

Виявлення інцидентів:

  • «Як ви б виявили, що персональні дані були передані інструменту ШІ?»
  • «Яка ваша процедура реагування на витік даних через ШІ?»

Документи про політику не відповідають жодному з цих запитань доказово. Вони описують, що повинні робити співробітники; вони не демонструють, що вони роблять насправді.

Прогалина у видимості моніторингу

Корпоративні IT-команди стикаються з фундаментальною проблемою моніторингу браузерних інструментів ШІ:

HTTPS-шифрування: Усі основні платформи ШІ (ChatGPT, Claude, Gemini) використовують HTTPS з HSTS і в деяких конфігураціях — закріпленням сертифікатів. Перевірка пакетів на мережевому рівні не може бачити вміст запитів без дешифрування TLS.

Обмеження дешифрування TLS: Впровадження TLS-інспекції (MITM) для трафіку ШІ:

  • Вимагає розгортання корпоративного сертифіката на всіх кінцевих пристроях
  • Порушує закріплення сертифікатів у деяких додатках
  • Створює нові ризики безпеки (дешифрований трафік доступний для перевірки)
  • Може порушувати умови використання платформ ШІ
  • Викликає занепокоєння щодо конфіденційності співробітників у багатьох юрисдикціях

Обмеження кінцевого DLP: Агенти кінцевого DLP можуть відстежувати буфер обміну та натискання клавіш, але:

  • Висока частота хибних спрацювань (легітимні операції з даними ініціюють оповіщення)
  • Не можуть відрізнити «введення конфіденційних даних у Word» від «введення їх у ChatGPT»
  • Затримка обробки може пропустити відправлення в реальному часі
  • Вимагає доступу на рівні ядра, що створює проблеми безпеки та стабільності

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

Панель моніторингу відповідності у фінансових послугах

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

Розгортання: Chrome Extension розповсюджено серед 500 співробітників

Дані моніторингу:

МетрикаТижневе значення
Загальна кількість взаємодій з ШІ8 400
ПДн, виявлені в запитах12 000 сутностей
Частка анонімізації94%
Найбільше: імена клієнтів4 800 виявлень
Найбільше: номери рахунків3 200 виявлень
Найбільше: ідентифікатори транзакцій2 100 виявлень
Відправлення без анонімізації (6%)720 сутностей/тиждень

Що ці дані показують аудиторам:

  • Масштаб використання інструментів ШІ (8 400 взаємодій/тиждень)
  • Обсяг ризику розкриття ПДн (12 000 виявлених сутностей)
  • Ефективність засобу контролю анонімізації (94% частка анонімізації)
  • Залишковий ризик (720 сутностей без анонімізації, що потребують подальших дій)

Що аудитори можуть перевірити:

  • Технічний засіб контролю існує і функціонує (журнали розгортання розширення)
  • Моніторинг активний і генерує дані (щотижневі метрики)
  • Залишковий ризик кількісно визначений і управляється (подальше навчання для 6% невідповідності)

Це різниця між «у нас є політика» і «ось наша виміряна ефективність контролю».

Використання даних моніторингу для постійного вдосконалення

6% виявлених ПДн, відправлених без анонімізації, — це не невдача відповідності, а успіх моніторингу. Організація тепер знає:

  1. 6% співробітників або відхиляють пропозицію анонімізації, або не бачать її
  2. Конкретні типи сутностей, що найчастіше відправляються без анонімізації (імена клієнтів порівняно з номерами рахунків)
  3. Які відділи або ролі мають вищу частку відправлень без анонімізації
  4. Трендові дані (чи зменшується 6% з адаптацією співробітників до робочого процесу?)

Ці дані стимулюють цілеспрямоване втручання:

  • Співробітники з високою часткою відправлень без анонімізації отримують додаткове навчання
  • Типи сутностей з високою частотою обходу можуть потребувати посилених підказок у інтерфейсі
  • Відділи з системною невідповідністю можуть отримати перепроектування робочого процесу

Без даних моніторингу навчання та втручання застосовуються рівномірно. З даними — там, де ризик найвищий.

Документація GDPR для програм інструментів ШІ

Повний пакет документації щодо відповідності статті 32 GDPR для корпоративної програми відповідності інструментів ШІ:

Технічні заходи:

  1. Chrome Extension розгорнуто для [N] співробітників (докази розгортання: журнали MDM)
  2. Виявлення ПДн в реальному часі для [типи сутностей] у полях введення інструментів ШІ
  3. Робочий процес анонімізації з аудиторським слідом (журнали розширення)
  4. Організаційна панель моніторингу (агреговані метрики виявлення)

Організаційні заходи:

  1. Політика використання інструментів ШІ (задокументована)
  2. Записи про завершення навчання співробітників
  3. Процедура реагування на інциденти витоку даних через ШІ
  4. Щоквартальний огляд відповідності на основі даних моніторингу

Докази моніторингу:

  1. Щотижневі метрики панелі (12-місячний ковзний період)
  2. Трендові дані частки анонімізації
  3. Розбивка по типах сутностей
  4. Записи про подальші дії за виявленою невідповідністю

Можливість виявлення інцидентів:

  1. Дані моніторингу дозволяють виявляти аномальну поведінку (раптове падіння частки анонімізації, нові типи сутностей)
  2. Процедура реагування на інциденти перевірена [дата]

Ця документація задовольняє вимогу статті 32 GDPR продемонструвати відповідні технічні та організаційні заходи — з доказами, а не заявами про політику.

Кількісне визначення зниження ризику

Для регуляторного аналізу пропорційності — кількісне визначення зниження ризику, досягнутого технічним засобом контролю:

До технічного засобу контролю:

  • 11% запитів до ШІ містять ПДн (базовий рівень Cyberhaven)
  • 8 400 тижневих взаємодій × 11% = 924 взаємодії з ПДн на тиждень
  • Кожна взаємодія: потенційне порушення статті 83 GDPR при наявності персональних даних ЄС

Після технічного засобу контролю (94% частка анонімізації):

  • 924 взаємодії з виявленими ПДн
  • 94% анонімізовано: 869 взаємодій захищено
  • Залишок: 55 взаємодій на тиждень з неанонімізованими ПДн

Зниження ризику: Зниження на 94% інцидентів розкриття ПДн від використання інструментів ШІ.

Для регуляторів, що застосовують тест пропорційності (відповідні заходи порівняно з ризиком), зниження ризику на 94% від систематично розгорнутого технічного засобу контролю є переконливим доказом відповідних технічних заходів.

Висновок

Відповідність статті 32 GDPR для використання інструментів ШІ не може бути досягнута лише через документи про політику. Технічне завдання — моніторинг браузерних взаємодій з ШІ для виявлення ризиків ПДн — вимагає технічних засобів контролю, що генерують дані моніторингу.

Анонімізація ПДн в реальному часі з інтегрованим моніторингом забезпечує як запобігання (зниження ризику розкриття), так і докази (кількісне визначення ризику та ефективності контролю). Ця комбінація задовольняє технічні вимоги та вимоги доказовості статті 32.

Для директорів з інформаційної безпеки, що готуються до аудитів DPA: на запитання «покажіть мені засоби контролю ПДн для інструментів ШІ» є одна переконлива відповідь — кількісні дані моніторингу, що показують частоту виявлення, частку анонімізації та тренди залишкового ризику. Документи про політику є необхідним відправним пунктом; дані — це докази.

Джерела:

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

Почніть анонімізувати 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.