Защо вашият инструмент за откриване на PII е...

Скритият пропуск в съответствието на GDPR

GDPR няма езикови предпочитания. Член 4, параграф 1 дефинира „лични данни“ без препратка към езика, на който се появяват. Германският Steuer-ID е толкова защитен, колкото и социалноосигурителният номер в САЩ. Френският NIR е толкова регулиран, колкото националният осигурителен номер на Обединеното кралство.

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

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

Това е систематичен пропуск в съответствието на GDPR, който засяга почти всяко мултинационално предприятие, използващо ориентирани към английския език инструменти за анонимизиране.

Защо PII е специфичен за езика

Откриването на PII има два компонента: откриване въз основа на шаблони (структурирани идентификатори като данъчни номера, телефонни формати) и откриване въз основа на NER (контекстуални обекти като имена на лица, имена на организации, адреси).

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

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

Образец на регулярен израз само на английски за SSN (формат: NNN-NN-NNNN) няма да съответства на нито един от тези идентификатори. Всеки изисква логика на регулярен израз, специфична за държавата, плюс проверка на контролната сума.

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

Имената на хората на немски следват различни модели от английските имена. „Hans-Dieter Müller“ и „Anna-Lena Schreiber-Koch“ са разпознаваеми като немски имена по контекст — но модел, обучен предимно на английски текст, често ще ги пропусне или ще ги класифицира погрешно.

По-проблематично: фалшивите положителни резултати на един език могат да станат фалшиви отрицателни на друг. Програмата за проследяване на проблеми Microsoft Presidio GitHub документира систематични фалшиви положителни резултати за немски думи, които са погрешно класифицирани като английски PII. Същата дума „Null“ (на немски „нула“) задейства фалшиви положителни резултати при откриване на име в модели, обучени на английски език. Това увеличава процента на фалшивите положителни резултати до 3 грешки на 1 реален обект в многоезични производствени среди (Alvaro et al., 2024).

Регулаторната експозиция

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

Немски BfDI: Поясни, че GDPR член 5(1)(f) (цялостност и поверителност) се прилага за данни във всички форми на обработка, включително неанглийски данни, обработвани от инструменти на трети страни.

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

Общо европейски DPAs: Съгласно член 25 на GDPR (Поверителност още при проектирането), техническите мерки трябва да са подходящи за действителните данни, които се обработват — което включва PII на неанглийски език при многонационални внедрявания.

Практическият риск: една организация може да демонстрира 95% ефективност на откриване на PII на съдържание на английски език по време на одит GDPR, но ако обработва и немско, френско и полско съдържание със същия инструмент, одитът може да разкрие систематични пропуски за тези езици.

Тристепенният подход към многоезичното откриване на PII

Разгръщането на академичните изследвания и производство се обедини върху тристепенна хибридна архитектура като най-ефективния подход за откриване на многоезични PII:

Ниво 1: Модели на родния език spaCy (езици с голям ресурс)

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

За немски: моделът spaCy de_core_news_lg разбира сложни съществителни имена, склонение на падеж и модели на немски имена. За френски: fr_core_news_lg обработва френски модели на обекти, включително заглавия, имена на места и организационни формати.

Езиковите модели постигат значително по-висока прецизност и запомняне за откриване на име, отколкото междуезиковите модели, прилагани към конкретни езици с голям ресурс.

Ниво 2: Строфа (допълнителни езици)

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

Ниво 3: XLM-RoBERTa (междуезично покритие)

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

Междуезичният модел се справя особено добре с превключването на кодове (текст на смесени езици) – свойство, което става критично за международни организации, където един документ може да съдържа текст на множество езици.

Типове обекти, специфични за езика

Освен модела за откриване, съответствието на GDPR изисква покритие на тип обект за специфични за държавата идентификатори. Многоезичният инструмент се нуждае от:

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

• DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
• FR: NIR, SIREN, SIRET, телефонен номер
• PL: PESEL, NIP, REGON
• NL: BSN, BurgerServiceNummer
• SE: Personnummer, Samordningsnummer
• ES: DNI, NIE, NIF, CIF
• IT: Codice Fiscale, Partita IVA

Формати на телефонни номера: Всяка държава от ЕС има уникални структури на мобилни префикси, формати на регионални кодове и местни конвенции за набиране. +49 (Германия), +33 (Франция), +48 (Полша) всички изискват валидиране за конкретна държава.

Адресни формати: Форматите на пощенските кодове се различават коренно — немски PLZ (5 цифри), френски пощенски код (5 цифри, започващи 01-99), пощенски код на Обединеното кралство (буквено-цифров, множество формати), испански código postal (5 цифри 01000-52999).

Случаят на използване: Многоезични документи на Swiss Pharmaceutical

Швейцарска фармацевтична компания обработва трудови договори, които съдържат текст на немски, френски и английски в рамките на един и същи документ (Швейцария има четири официални езика). Текущият им инструмент е конфигуриран за немски и пропуска всички PII на френски раздел.

В трудов договор за служител, базиран в Женева, се посочва техният френски AVS номер (13 цифри), тяхната швейцарска банкова сметка IBAN, техният кантон на пребиваване и тяхното име във френски формат. Инструментът, конфигуриран на немски, пропуска името във френски формат, не успява да открие френския AVS номер модел (различен от немския формат AHV-Nummer) и само частично открива IBAN.

Тристепенният подход обработва документа като цяло, откривайки езика автоматично за всеки текстов сегмент, прилагайки подходящи за езика NER модели и използвайки валидатори на регулярни изрази, специфични за държавата, за всеки тип национален идентификатор — независимо в кой езиков раздел се появява.

Обработка на смесени езици

Най-трудният многоезичен проблем с PII е смесването на езици в рамките на документа: документ, който съдържа абзаци на различни езици, изречения с кодово превключване или цитиран текст на език, различен от заобикалящия контекст.

Примери:

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

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

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

Практическо ръководство за внедряване

Проверете езиковото покритие на текущия си инструмент: Помолете текущия си доставчик на анонимизиране да предостави F1 резултати за конкретните езици във вашите данни. „Поддържа 20 езика“ често означава, че инструментът преминава текст през Google Translate, преди да приложи NER, обучен на английски език — което не е същото като откриването на роден език.

Съпоставете данните си с езици: Направете инвентаризация на данните, която включва езиково разпространение. Мултинационална компания със 70% английски, 20% немски и 10% френски данни има различна експозиция на риск от тази с 95% английски.

Тествайте с проби от национални идентификатори: Създайте набор от тестови данни с 10 примера за всеки от националните идентификатори, подходящи за вашите операции (Steuer-ID, NIR, PESEL, BSN и т.н.) и проверете нивата на откриване. Това е по-бърз одит от широкомащабната F1 оценка.

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

• Механизмът за откриване на PII на anonym.legal използва тристепенен многоезичен подход: модели spaCy с роден език за 25 езика с голям ресурс, Stanza за допълнително езиково покритие и XLM-RoBERTa междуезични трансформатори за общо 48-езично покритие. Включени са специфични за държавата типове юридически лица за всички държави-членки на ЕС.*

Източници:

• [ACL 2024: Хибридно откриване на PII за европейски локали] (https://dl.acm.org/doi/10.1145/3675888.3676036)
• [Мащабируема многоезична рамка за анотации на PII (arXiv 2025)] (https://arxiv.org/html/2510.06250v2)
• [HuggingFace XLM-RoBERTa междуезични NER бенчмаркове] (https://huggingface.co/xlm-roberta-large-finetuned-conll03-english)
• [Microsoft Presidio GitHub Издание #1071 — Немски фалшиви положителни резултати] (https://github.com/microsoft/presidio/issues/1071)
• [EDPB Насоки относно член 25 за поверителност още при проектирането] (https://edpb.europa.eu/our-work-tools/documents/public-consultations/2020/guidelines-42019-article-25-data-protection-design_en)
• CNIL Годишен отчет за 2024 г.