anonym.legal

By · Last updated 2026-03-20

Назад к блогуGDPR и соблюдение

Инструменты защиты ПДн только на английском: пробел в GDPR

Немецкий Steuer-ID (11 цифр с контрольной суммой) структурно отличается от американского SSN. Французский номер NIR содержит 15 цифр. Польский PESEL и шведский Personnummer.

March 20, 20268 мин чтения
GDPR multilingual complianceSteuer-ID detectionFrench NIRSwedish PersonnummerEU PII identifier formats

Инструменты защиты ПДн только на английском: пробел в GDPR

GDPR не отдаёт предпочтения какому-либо языку

GDPR распространяется на персональные данные на любом языке. Немецкий, французский, польский, шведский — все языки защищены в равной мере. Пропущенный Steuer-ID создаёт такой же правовой риск, что и пропущенный номер социального страхования США. Закон не интересуется языком.

Большинство инструментов обнаружения ПДн — интересуются.

Ведущие коммерческие и открытые инструменты создавались для работы с англоязычными текстами. Это отражается на их детекторах сущностей. Они хорошо распознают номера социального страхования США, американские водительские удостоверения и телефонные форматы NANP. Детекторы неанглийских национальных идентификаторов значительно менее точны. Они хуже поддерживаются. Они чаще пропускают реальные идентификаторы.

Для компаний в странах ЕС это создаёт пробел в покрытии. Инструмент сообщает о завершённом обнаружении. Но неанглийские идентификаторы остаются в данных. Нередко именно они несут наибольший риск GDPR в конкретных странах.

Регуляторные органы это понимают. Аудиторы ищут именно это. Инструмент может хорошо работать с англоязычными записями. Но если он не справляется с немецкими или французскими — он не соответствует требованиям. Чистый отчёт этого не изменит.

Национальные идентификаторы различаются по структуре

Разрыв между инструментами, ориентированными на английский язык, и многоязычными решениями — это не вопрос добавления новых регулярных выражений. Национальные идентификаторы ЕС кардинально отличаются друг от друга. Для корректного обнаружения каждого из них нужна своя страновая логика.

Немецкий Steuer-Identifikationsnummer (Steuer-ID): 11 цифр. Использует контрольную сумму по варианту алгоритма Луна. Общее регулярное выражение для SSN не подойдёт. Выражение для любого 11-значного числа даст слишком много ложных срабатываний в немецких документах.

Французский NIR (Numéro d'inscription au répertoire): 15 цифр. Формат кодирует пол, год рождения, месяц рождения и департамент рождения. Также содержит порядковый номер рождения и 2-значный контрольный ключ. Для корректного обнаружения необходима валидация контрольного ключа.

Шведский Personnummer: 10 цифр с контрольной цифрой Луна. Для лиц, рождённых до 1990 года, вместо `-` используется разделитель `+`. Это меняет формат, подлежащий обнаружению.

Польский PESEL: 11 цифр. Кодирует дату рождения, пол и контрольную цифру на основе взвешенных сумм. Корректное обнаружение требует как сопоставления формата, так и валидации контрольной суммы.

Это не вариации одного общего шаблона. У каждого идентификатора своя длина, свой метод проверки и своя позиционная схема кодирования данных. NER-модель, обученная на английском тексте и увидевшая французский NIR, не распознает его как национальный идентификатор — проигнорирует или классифицирует неверно.

Практический риск несоответствия

Рассмотрим сотрудника по комплаенсу в европейском аутсорсинговом процессинговом бизнесе (BPO). Он одновременно обрабатывает данные из Германии, Франции, Польши и Нидерландов. Его инструмент сообщает об успешной анонимизации ПДн.

Но результат неполный. Steuer-ID в немецких записях остались. NIR в французских записях остались. PESEL в польских записях остались. Детекторы этих форматов в инструменте отсутствуют или недостаточно точны.

Позднее набор данных передаётся в аналитику или партнёру по исследованиям. Данные по-прежнему содержат повторно идентифицируемые национальные идентификаторы. Проблема GDPR не отражается в журналах вывода инструмента. Она всплывает при поступлении запроса на доступ к данным. Может всплыть во время аудита регулятора. Может всплыть после утечки данных.

Исследования, сравнивающие гибридные многоязычные подходы с инструментами, ориентированными на английский язык, дали однозначные результаты. Гибридные методы достигают F1-оценок от 0,60 до 0,83 по европейским локалям. Инструменты только для английского языка показывают близкие к нулю значения для неанглийских форматов национальных идентификаторов.

См. наш обзор соответствия требованиям GDPR о том, как эти пробелы соотносятся с обязательствами по GDPR.

Что требует полное покрытие

По-настоящему многоязычное обнаружение ПДн для соблюдения GDPR ЕС требует трёх уровней.

Языконативные модели spaCy обеспечивают семантическое понимание на языке текста. Модель, обученная на немецком тексте, знает, что «Мюллер» — распространённая немецкая фамилия. Модели существуют для 25 высокоресурсных языков ЕС.

Модели Stanza NLP расширяют покрытие на языки, отсутствующие в spaCy. Это увеличивает охват для более широкого круга языковых сообществ ЕС.

Кросс-лингвальные трансформерные модели (XLM-RoBERTa) обрабатывают межъязыковые случаи. Имя в французском предложении распознаётся как имя человека — даже если движок не обучался на конкретном имени.

Регулярные выражения с валидацией по стране охватывают структурированные национальные идентификаторы. Для Steuer-ID, NIR, PESEL и Personnummer требуется своя логика контрольных сумм. Это снижает количество ложных срабатываний: числовые последовательности, не прошедшие страновые правила валидации, отфильтровываются.

Пробел носит структурный характер. Добавление словарей или дополнительных регулярных выражений даёт лишь незначительное улучшение. Единственный надёжный подход — изначально встроить покрытие идентификаторов ЕС.

Проверьте ваш текущий инструмент

Запросите у поставщика F1-оценки для немецких, французских, польских и нидерландских записей. «Поддержка нескольких языков» нередко означает предварительный машинный перевод. Это не нативное сканирование. Соответствие GDPR требует нативного сканирования.

Проведите тест с реальными образцами национальных идентификаторов. Сформируйте небольшой тестовый набор из 10 примеров каждого типа идентификатора, используемого в вашей работе: Steuer-ID, NIR, PESEL, Personnummer. Проверьте показатели обнаружения. Это быстрее полного F1-теста и оперативно выявляет пробелы.

См. нашу страницу безопасности и соответствия требованиям о том, как anonym.legal решает эти задачи. Определения типов сущностей см. в справочнике по сущностям.

Источники

Готовы защитить ваши данные?

Начните анонимизацию 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.