anonym.legal

By · Last updated 2026-03-03

Назад към блогаGDPR и съответствие

Многоезично разпознаване на лични данни за GDPR

Германски Steuer-ID, френски NIR и шведски Personnummer изискват различна логика за разпознаване.

March 3, 202610 мин. четене
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Многоезично разпознаване на лични данни за GDPR

Актуализирано за 2026 г.

Скритата пропаст в GDPR

GDPR няма езикови предпочитания. Член 4(1) определя "лични данни" без да посочва на какъв език се появяват. Германски Steuer-ID е толкова защитен, колкото американски номер на социална осигуровка. Френски NIR е толкова регулиран, колкото британски номер на национална осигуровка.

Повечето инструменти за разпознаване на лични данни са създадени само за английски.

Изследвания от ACL 2024 установиха, че хибридните NLP инструменти достигат F1 резултати от 0,60–0,83 за европейски локали. Инструментите само за английски отбелязват почти нула за не-английски формати на национални идентификатори. Разликата е поразителна. Инструментът може да улови 95% от английските лични данни. Но пропуска 40–60% от германски, френски, полски или нидерландски лични данни в същия файл. Това е сериозен проблем. Излага компаниите на риск.

Това е реална пропаст в GDPR. Засяга почти всяка глобална фирма, използваща ориентирани към английски инструменти за редактиране. Вижте нашето ръководство за GDPR за повече.

Защо личните данни са специфични за локала

Разпознаването на лични данни има две части.

Първата е сканиране на базата на шаблони. Обхваща структурирани идентификатори като данъчни номера и телефонни формати.

Втората е сканиране на базата на NER. Обхваща контекстни обекти като имена и адреси.

И двете части зависят от локала.

Структурираните идентификатори се различават по страна

ДържаваДанъчен IDФорматВалидация
ГерманияSteuer-ID11 цифриModulo-11
ФранцияNIR15 цифри + 2-цифрен ключINSEE
ШвецияPersonnummer10 цифриLuhn
ПолшаPESEL11 цифриModulo-10
НидерландияBSN9 цифриElfproef
ИспанияDNI/NIE8 цифри + букваModulo-23
ИталияCodice Fiscale16 знакаПерсонализирана контролна сума

Английски regex за SSN (NNN-NN-NNNN) не съответства на нито един от тези формати. Всеки изисква собствен regex. Всеки изисква и собствена логика за контролна сума.

NER изисква нативни модели

Германските имена се различават от английските. "Hans-Dieter Muller" е ясен за нативен германски модел. Модел, обучен на английски, често пропуска такива имена.

Фалшивите положителни са също проблем. Проследявачът на проблеми на Microsoft Presidio показва германски думи, класифицирани погрешно като английски лични данни. Думата "Null" (немски за "нула") е един пример. Тя предизвиква фалшиви попадания за имена в модели, обучени на английски. При производствена употреба процентите на грешки нарастват до 3 фалшиви положителни на реален обект (Alvaro et al., 2024).

Регулаторен риск

Органите за защита на данни в ЕС са наясно с този проблем. Няколко национални надзорни органа са издали насоки.

Германски BfDI: GDPR член 5(1)(f) се прилага към всички записи. Обхваща не-английски данни, обработвани от инструменти на трети страни.

Френски CNIL: Годишният доклад на CNIL за 2024 г. е изразил загриженост. Той е маркирал AI инструменти, обработващи френски записи без сканиране за лични данни на френски локал.

Органи за защита на данни в ЕС общо: GDPR член 25 (Защита на данните по проект) изисква защитни мерки, подходящи за действително обработваните записи. Това включва не-английски лични данни при глобални разгръщания.

Рискът е ясен. Фирмата може да покаже 95% разпознаване на лични данни за английско съдържание при одит по GDPR. Но ако обработва и германски, френски и полски записи с един и същи инструмент, ще се появят пропуски. Одиторите забелязват. Глоби могат да последват. Вижте нашата страница за защитни мерки за начина, по който се справяме с това.

Триниво решение

Изследванията и производствената практика са съгласни, че трисекторният хибриден дизайн е най-добрият подход.

Ниво 1: Нативни spaCy модели

spaCy предоставя обучени модели за 25 локала. Те включват немски, френски, испански, португалски, италиански, нидерландски, руски, китайски, японски, корейски и полски. Всеки модел се обучава върху нативен текст. Те научават синтаксиса и шаблоните на обекти за всеки локал. Това е важно. Нативното обучение означава по-добра пълнота и по-малко фалшиви положителни.

За немски: de_core_news_lg обработва съставни съществителни и германски именни шаблони. За френски: fr_core_news_lg обработва френски обекти, заглавия, имена на места и организации.

Нативните модели надминават многоезиковите модели при сканиране за имена на локали с богати ресурси.

Ниво 2: Stanza за повече локали

Библиотеката Stanza на Станфорд покрива локали, липсващи в spaCy. Те включват хърватски, словенски и украински. Това добавя обхват за говорещи от ЕС групи, на които spaCy не служи. Stanza е безплатна и с отворен код. Интегрира се добре с останалата част от стека.

Ниво 3: XLM-RoBERTa за широк обхват

За локали, при които spaCy и Stanza нямат NER модели, XLM-RoBERTa запълва пропуската. Обучава се върху Common Crawl текст на 100 локала. Постига 91,4% многоезичен F1 за разпознаване на лични данни (HuggingFace 2024). Обработва добре превключването между кодове. Това е ключова функция. Важна е, когато един документ съдържа текст на няколко локала едновременно.

Посетете нашата документация за токен системата, за да видите как API повикванията се мащабират с многоезичен обем.

Специфични за локала типове обекти

Самите модели не са достатъчни. Съответствието с GDPR изисква и обхват на типове обекти за специфични за страната идентификатори.

Национални идентификатори на ЕС по страна:

  • DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
  • FR: NIR, SIREN, SIRET
  • PL: PESEL, NIP, REGON
  • NL: BSN
  • SE: Personnummer, Samordningsnummer
  • ES: DNI, NIE, NIF, CIF
  • IT: Codice Fiscale, Partita IVA

Телефонни формати: Всяка страна в ЕС има уникални структури с префикс. +49, +33 и +48 всяка изискват собствена логика за валидация.

Адресни формати: Пощенските кодове варират значително. Германски PLZ използва 5 цифри. Френските кодове използват 5 цифри (диапазон 01–99). Британските пощенски кодове са буквено-цифрови. Испанските кодове използват 5 цифри (01000–52999).

Реален случай: Швейцарска фармацевтична компания

Швейцарска фирма обработва трудови договори. Всеки договор смесва немски, френски и английски текст. Швейцария има четири официални езика. Техният инструмент е настроен само за немски. Пропуска всички лични данни в частта на френски.

Договорът за служител от Женева е включвал AVS номер на френски (13 цифри), швейцарски банков IBAN и име в даден французки формат. Инструментът само за немски е пропуснал името на французки формат. Не е открил AVS номера на французки формат. Само частично е разпознал IBAN.

Трисекторният подход обработва целия документ. Разпознава локала за всеки текстов сегмент. Прилага правилния NER модел за всяка част. Валидира всеки национален идентификатор с правилната логика за страната.

Документи с множество локали

Най-трудният случай е смесване на локали вътре в документа. Примери:

  • Английски договор на германска фирма с германски кадрови записи (имена, данъчни идентификатори)
  • Формуляр за съгласие по GDPR на французки с английски откъс за поверителност
  • Чат, в който агентът отговаря на английски, а клиентът пише на арабски

XLM-RoBERTa обработва това нативно. Не изисква изрични флагове за локал. Обработва текст с множество локали без предварителна сегментация. Това спестява време. Избягва и грешки от неправилни разделяния.

За производствена употреба, комбинирането на автоматично разпознаване на локал (на ниво изречение) с XLM-RoBERTa осигурява стабилна обработка на документи с множество локали.

Практически стъпки

Одитирайте обхвата на вашия инструмент. Поискайте от вашия доставчик за редактиране F1 резултати за вашите конкретни локали. "Поддържа 20 езика" често означава, че инструментът насочва текста чрез машинен превод първо. Това не е нативно сканиране.

Картографирайте вашите записи по локали. Направете инвентаризация на записите, която включва разпределението по локали. Глобална фирма с 70% английски, 20% немски и 10% французки е изправена пред различни рискове. Фирма с 95% английски е в различна позиция.

Тествайте с проби от национални идентификатори. Изградете тестов набор с 10 примера за националните идентификатори в операциите ви — Steuer-ID, NIR, PESEL, BSN и други. Проверете нивата на разпознаване. Това е по-бързо от пълен F1 тест.

Прегледайте вашите DPIA. Проверете дали обхватът на локалите е включен. Непълна DPIA, приемаща само английски записи, може да се нуждае от актуализация. Действайте сега. Не чакайте одит да открие пропуска.

За пълни дефиниции на типовете обекти вижте справочника за обекти и ЧЗВ. За планове и нива на API повиквания посетете ценообразуването.


Двигателят за разпознаване на лични данни на anonym.legal използва триниво многоезично решение. Покрива 25 локала с богати ресурси чрез нативни spaCy модели. Stanza добавя допълнителен обхват на локали. XLM-RoBERTa многоезичните трансформери разширяват обхвата до 48 локала. Включени са специфични за страната типове обекти за всички държави-членки на ЕС.

Източници

Готови ли сте да защитите данните си?

Започнете анонимизация на 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.