anonym.legal

By · Last updated 2026-06-05

Назад до блогуТехнічні

Чому бінарне виявлення ПДн не відповідає вимогам комплаєнсу

«Виявлено/не виявлено» недостатньо для контекстів відповідності, що вимагають людського судження. Ось чому оцінювання довіри перетворює анонімізацію ПДн на справжнє рішення для дотримання вимог.

June 5, 20268 хв читання
confidence scoringPII detectionlegal discoverycomplianceGDPR audit

Обмеження бінарного виявлення

Кожна система виявлення ПДн стикається з фундаментальним завданням: один і той самий рядок може бути ПДн в одному контексті і не бути ним в іншому. «Іван» у скарзі клієнта — це суб'єкт даних. «Іван» як посилання на Івана Мазепу в історичному документі — ні. Номер соціального страхування в медичному записі — це ідентифікатор HIPAA. Дев'ятизначний код продукту, що випадково збігається з форматом SSN, — ні.

Бінарне виявлення — прапор «виявлено/не виявлено» — не може представити цю неоднозначність. Воно примушує або до надмірного редагування (позначати все, що може бути ПДн), або до недостатнього редагування (позначати лише збіги з високою впевненістю). Для контекстів відповідності, що вимагають захищених, аудиторських рішень щодо анонімізації, жоден варіант не є прийнятним.

Оцінювання довіри надає середній шлях: значення довіри від 0 до 100% на виявлену сутність, що забезпечує ярусне прийняття рішень, процеси огляду людиною та аудиторську документацію.

Кейс юридичного розкриття

Анонімізація при юридичному розкритті має явні вимоги, що роблять оцінювання довіри обов'язковим:

Проблема надмірного редагування: Неправильне редагування імен адвокатів, посилань на суд або юридичних цитат руйнує доказову цінність документів. Суди накладали санкції на адвокатів за надмірне редагування при електронному розкритті — та сама судова практика, що санкціонує недостатнє редагування, охоплює і надмірне.

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

Вимога захищеності: Коли суд оскаржує рішення про редагування, адвокати повинні мати можливість пояснити, чому конкретні сутності були відредаговані, а інші — ні. «Програма так сказала» — не є захищеним поясненням. «Програма позначила це з 94%-ю довірою як номер соціального страхування, і наш протокол автоматично редагує вище 85%» — це захищено.

Бінарне виявлення не може надати захищені пояснення. Оцінювання довіри з документованими порогами рішень — може.

Трирівнева структура довіри

Найефективніша реалізація відповідності використовує три рівні довіри:

Рівень 1 — Автоматичний (>85% довіри):

  • Сутності, що відповідають шаблонам з високою довірою (повний формат SSN, IBAN, структурований MRN)
  • Автоматично анонімізовані без огляду людиною
  • Запис у журналі аудиту: тип сутності, довіра, метод, мітка часу
  • Приклад: «571-44-9283» виявлено як SSN з 97% довірою → автоматично відредаговано

Рівень 2 — Огляд обов'язковий (50–85% довіри):

  • Сутності, що можуть бути ПДн, але вимагають контекстного судження
  • Позначені для дії рецензента (прийняти редагування / відхилити / перекласифікувати)
  • Запис у журналі аудиту: тип сутності, довіра, ID рецензента, рішення, мітка часу
  • Приклад: «Іван Петренко» в технічному документі → 67% довіри ім'я → рецензент підтверджує, що це ім'я людини в контексті → відредаговано

Рівень 3 — Лише інформація (<50% довіри):

  • Виявлення з низькою довірою, що надаються як пропозиції
  • Не редагуються автоматично; рецензент може діяти
  • Запис у журналі аудиту: тип сутності, довіра, надано як пропозицію, рішення рецензента
  • Приклад: «Коваленко» у контексті іменника власного → 42% довіри → надано → рецензент визначає, що це назва компанії → не відредаговано

Ця структура знижує навантаження на огляд (лише рівень 2 вимагає дій людини), зберігаючи повне аудиторське покриття.

Як технічно працює оцінювання довіри

Системи виявлення ПДн поєднують кілька сигналів для визначення оцінок довіри:

Шаблони регулярних виразів: Рядок, що точно відповідає формату SSN (###-##-####), отримує високу базову довіру. Часткова відповідність отримує нижчу.

Вивід моделі NER: Моделі розпізнавання іменованих сутностей виводять логітові ймовірності для кожної класифікації сутностей. Модель NER на основі BERT, що присвоює ймовірність 0,93 класифікації PERSON для рядка, дає виявлення з високою довірою.

Контекстні сигнали: Навколишній текст змінює довіру. «Мій SSN — 571-44-9283» підвищує довіру SSN. «Код продукту 571-44-9283» знижує її. Контекстно-обізнані моделі налаштовують довіру на основі цих сигналів.

Ансамблеве оцінювання: Виробничі системи поєднують кілька сигналів — довіру збігу регулярного виразу + довіру моделі NER + контекстний сигнал — за допомогою зваженого оцінювання. Кінцеве значення довіри відображає всі доступні докази.

Вивід — значення довіри для кожної сутності, яке можна використовувати для прийняття рішень на основі порогів у процесах відповідності.

Застосування у страховій галузі: захищений огляд документів про претензії

Страхові компанії майна обробляють документи про претензії, що поєднують чіткі дані ПДн (імена власників полісів, адреси, SSN) з контекстно неоднозначними даними (імена свідків у звітах про аварії, назви компаній-підрядників, підписи оціночників).

Бінарний підхід до виявлення або:

  • Редагує всі імена людей (руйнуючи контекст назви компанії-підрядника)
  • Редагує лише очевидні шаблони (пропускаючи імена свідків)

Підхід з оцінюванням довіри:

  • SSN (відповідність формату, контекст «SSN власника полісу»): 96% → автоматично редагувати
  • Ім'я власника полісу (NER PERSON, контекст «власник полісу»): 91% → автоматично редагувати
  • Компанія-підрядник (NER ORG, не PERSON): 78% → огляд — рецензент відхиляє редагування
  • Ім'я свідка (NER PERSON, контекст «заява свідка»): 82% → огляд — рецензент приймає редагування
  • Ім'я оціночника (NER PERSON, контекст «підпис»): 71% → огляд — рецензент приймає редагування (оціночник є даними третьої сторони)

Результат: аудиторський слід, що документує кожне рішення з основою довіри, знижуючи юридичний ризик для оскаржуваних претензій.

Побудова документації відповідності через оцінювання довіри

Для вимог аудиту за статтею 5(1)(f) GDPR та Правилом безпеки HIPAA анонімізація з оцінюванням довіри автоматично генерує документацію відповідності:

Записи аудиту на рівні сутностей:

  • Тип сутності, значення довіри, рішення (авто/вручну), ID рецензента, мітка часу
  • Можна експортувати у форматі CSV для розслідувань DPA
  • Пошук за діапазоном дат, типом сутності, діапазоном довіри, рецензентом

Документація конфігурації порогів:

  • Поточні налаштування порогів задокументовані в конфігурації системи
  • Журнал змін (хто змінив пороги, коли, обґрунтування)
  • Демонструє навмисну, керовану політику анонімізації

Статистична звітність:

  • Частота виявлення по типах сутностей за період обробки
  • Частота завершення огляду (сутності рівня 2, переглянуті порівняно з тими, що в черзі)
  • Частота перевизначення (рецензент відхиляє автоматичне редагування порівняно з прийняттям)

Для запиту 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.