Повеќејазично откривање на PII за GDPR

Повеќејазично откривање на PII за GDPR

Ажурирано за 2026 година

Скриениот јаз во GDPR

GDPR нема јазична преференца. Член 4(1) ги дефинира "личните податоци" без да го именува јазикот во кој се наоѓаат. Германско Steuer-ID е исто толку заштитено колку и американски број за социјално осигурување. Француско NIR е исто толку регулирано колку и британски број за национално осигурување.

Повеќето алатки за откривање на PII беа изградени само за англиски.

Истражувањето на ACL 2024 открило дека хибридните NLP алатки достигнуваат F1 резултати од 0,60-0,83 за европски локализации. Алатките само за англиски резултати скоро нула за формати на национални ID-ови кои не се на англиски. Јазот е голем. Алатка може да фати 95% од английскиот PII. Сепак пропушта 40-60% од германскиот, францускиот, полскиот или холандскиот PII во истата датотека. Тоа е сериозен проблем. Ги изложува компаниите.

Ова е реален јаз во GDPR. Тоа влијае на речиси секоја глобална фирма која користи алатки за редакција центрирани на англиски. Видете го нашиот водич за GDPR за повеќе.

Зошто PII е специфично за локалот

Откривањето на PII има два дела.

Првиот е скенирање базирано на обрасци. Ова покрива структурирани ИД-ови како даночни броеви и телефонски формати.

Вториот е скенирање базирано на NER. Ова покрива контекстуални ентитети како имиња и адреси.

Обата дела зависат од локалот.

Структурираните ИД-ови се разликуваат по земји

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

NER потребува нативни модели

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

Лажни позитиви се исто така проблем. Следачот на проблеми на Microsoft Presidio покажува германски зборови погрешно класифицирани како англиски PII. Зборот "Null" (германски за "нула") е еден пример. Предизвикува лажни удари на имиња во модели обучени на англиски. Во производна употреба, стапките на грешки се зголемуваат на 3 лажни позитиви по реален ентитет (Alvaro et al., 2024).

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

Органите за податоци на ЕУ се свесни за овој проблем. Неколку национални DPA-и издале насоки.

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

Француски CNIL: Годишниот извештај на CNIL 2024 изрази загриженост. Означи AI алатки кои ракуваат со французски записи без скенирање на PII во француска локализација.

EU DPA-и во целина: GDPR член 25 (Приватност по дизајн) бара заштитни мерки соодветни за вистинските записи кои се обработуваат. Ова вклучува не-английски PII во глобални распоредувања.

Ризикот е јасен. Фирма може да покаже 95% откривање на PII на содржина на англиски во GDPR ревизија. Но ако исто така ракува со германски, француски и полски записи со истата алатка, ќе се появат јазови. Ревизорите забележуваат. Казните можат да следат. Видете ја нашата страница за заштитни мерки за тоа kako го решаваме ова.

Дизајн со три нивоа

Истражувањето и производствената употреба се согласуваат дека хибридниот дизајн со три нивоа е најдобриот пристап.

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

spaCy обезбедува обучени модели за 25 локализации. Тие вклучуваат германски, француски, шпански, португалски, италијански, холандски, руски, кинески, јапонски, корејски и полски. Секој модел се обучува на нативен текст. Учат ја синтаксата и обрасците на ентитети на секоја локализација. Ова е важно. Нативната обука значи подобро повикување и помалку лажни позитиви.

За германски: de_core_news_lg ракува со составени именки и германски обрасци на имиња. За француски: fr_core_news_lg ракува со француски ентитети, наслови, имиња на места и организации.

Нативните модели ги надминуваат меѓујазичните модели за скенирање на имиња на локализации со многу ресурси.

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

Библиотеката Stanza на Stanford ги покрива локализациите кои не се во spaCy. Тие вклучуваат хрватски, словенечки и украински. Ова додава опсег за говорни групи во ЕУ кои spaCy не ги опслужува. Stanza е бесплатна и со отворен код. Добро се интегрира со остатокот од стекот.

Ниво 3: XLM-RoBERTa за широк опсег

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

Посетете ги нашите документи за системот на токени за да видите kako повиците на 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).

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

Швајцарска фирма обработува договори за вработување. Секој договор меша германски, француски и англиски текст. Швајцарија има четири официјални јазика. Нивната алатка беше поставена само за германски. Го пропуштила сиот PII во францускиот дел.

Договорот за вработен базиран во Женева вклучувал француски 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 кој претпоставува само английски записи може да потреба ажурирање. Делувајте сега. Не чекајте ревизијата да го открие јазот.

За целосни дефиниции на типови на ентитети, видете ја референцата за ентитети и FAQ. За планови и стапки на повик на API, посетете ги цените.

Моторот за откривање на PII на anonym.legal користи тро-нивовски повеќејазичен пристап. Покрива 25 локализации со многу ресурси преку нативни modeli на spaCy. Stanza додава дополнителен опсег на локализации. Меѓујазичните трансформери XLM-RoBERTa го прошируваат опсегот на 48 локализации. Типовите на ентитети специфични за земјата за сите земји-членки на ЕУ се вклучени.

Извори

• ACL 2024: Хибридно откривање на PII за европски локализации
• Скалабилна рамка за повеќејазично означување на PII (arXiv 2025)
• HuggingFace XLM-RoBERTa Меѓујазични NER бенчмаркови
• Microsoft Presidio GitHub Проблем #1071 — Германски лажни позитиви
• Упатства на EDPB за член 25 Приватност по дизајн
• Годишен извештај на CNIL 2024