Többnyelvű személyes adat felismerés GDPR-megfelelőséghez

A rejtett GDPR-megfelelőségi rés

A GDPR-nak nincs nyelvpreferenciája. A 4. cikk (1) bekezdése az „érintett adatokat” a megjelenési nyelvtől függetlenül határozza meg. Egy német Steuer-ID éppúgy védett, mint egy amerikai TB-szám. Egy francia NIR éppúgy szabályozott, mint egy brit National Insurance szám.

De a legtöbb személyes adat felismerő eszközt angolra fejlesztették.

Az ACL 2024-en közzétett kutatás megállapította, hogy a hibrid NLP-megközelítések 0,60–0,83 közötti F1-értékeket érnek el az európai helyszínekre – de az angol eszközök, ha nem angol szövegre alkalmazzák, közel nullás értéket hoznak a strukturált nemzeti azonosítóknál. A gyakorlati következmény: egy multinacionális szervezetnél alkalmazott anonimizáló eszköz az angol személyes adatok 95%-át felismerheti, miközben a ugyanolyan adatkészletben lévő német, francia, lengyel vagy holland személyes adatok 40–60%-át kihagyja.

Ez egy szisztematikus GDPR-megfelelőségi rés, amely gyakorlatilag minden angol-centrikus anonimizáló eszközt használó multinacionális vállalatot érint.

Miért nyelvspecifikus a személyes adat?

A személyes adat felismerésnek két összetevője van: mintaalapú felismerés (strukturált azonosítók, mint adóazonosítók, telefonformátumok) és NER-alapú felismerés (kontextuális entitások, mint személynevek, szervezetnevek, címek).

Mindkét összetevő mélyen nyelvspecifikus.

A strukturált azonosítók országonként radikálisan eltérnek

Egy angolra vonatkozó SSN regex minta (formátum: NNN-NN-NNNN) egyik azonosítóra sem fog illeszkedni. Mindegyik országspecifikus regex logikát és ellenőrző összeg validációt igényel.

A névfelismerés natív nyelvi modelleket igényel

A német személynevek eltérő mintákat követnek az angolhoz képest. A „Hans-Dieter Müller” és az „Anna-Lena Schreiber-Koch” kontextusból felismerhető mint német nevek – de egy elsősorban angol szövegen tanított modell ezeket frecven kihagyja vagy tévesen osztályozza.

Még problémásabb: az egyik nyelvben előforduló téves pozitívak a másikban téves negatívakká válhatnak. A Microsoft Presidio GitHub-hibakövetője dokumentálja, hogy a német szavakat szisztematikusan tévesen osztályozzák angol személyes adatként. A „Null” (németül „nulla”) szó névfelismerési téves pozitívakat okoz az angolra tanított modellekben. Ez 1 valódi entitásra jutó 3 hibáig emeli a téves pozitív arányt többnyelvű termelési környezetekben (Alvaro et al., 2024).

A szabályozási kitettség

Az EU adatvédelmi hatóságai egyre inkább tudatában vannak ennek a résnek. Több nemzeti adatvédelmi hatóság adott ki iránymutatást vagy hozott végrehajtási intézkedést, amely a többnyelvű feldolgozást érinti:

Német BfDI: Pontosította, hogy a GDPR 5. cikk (1) bekezdésének f) pontja (sértetlenség és bizalmasság) minden feldolgozási formában vonatkozik az adatokra, beleértve a harmadik fél eszközei által feldolgozott nem angol adatokat.

Francia CNIL: A 2024-es CNIL Éves Jelentés megjegyezte a növekvő aggályokat azokkal az AI-eszközökkel kapcsolatban, amelyek francia nyelvű adatokat dolgoznak fel anélkül, hogy rendelkeznének a francia személyes adatok felismerési képességeivel.

Európai adatvédelmi hatóságok általában: A GDPR 25. cikke (beépített adatvédelem) értelmében a technikai intézkedéseknek meg kell felelniük a ténylegesen feldolgozott adatoknak – beleértve a multinacionális telepítéseknél előforduló nem angol személyes adatokat.

A gyakorlati kockázat: egy szervezet bizonyíthatja az angol tartalmak 95%-os személyes adat felismerési hatékonyságát GDPR-ellenőrzés során, de ha ugyanazzal az eszközzel german, french és lengyel tartalmat is feldolgoznak, az ellenőrzés szisztematikus réseket fedhet fel ezeknél a nyelveknél.

A háromszintű megközelítés a többnyelvű személyes adat felismeréshez

Az akadémiai kutatás és a termelési telepítések egy háromszintű hibrid architektúrán converged, mint a leghatékonyabb megközelítés a többnyelvű személyes adat felismeréshez:

1. szint: Natív spaCy-modellek (nagy erőforrású nyelvek)

A spaCy 25 nyelvhez nyújt betanított folyamatkomponenseket, beleértve a németet, franciát, spanyolt, portugált, olaszt, hollandot, oroszt, kínait, japánt, koreait, lengyelt és másokat. Ezek a modellek natív nyelvű korpuszon vannak tanítva, és értik az egyes nyelvek morfológiáját, szintaxisát és entitásmintáit.

Németre: a spaCy de_core_news_lg modellje érti az összetett főneveket, az esetragozást és a német névmintákat. Franciára: a fr_core_news_lg kezeli a francia entitásmintákat, köztük a megszólításokat, helyneveket és szervezeti formátumokat.

A natív nyelvű modellek lényegesen magasabb precizitást és visszahívást érnek el a névfelismerésnél, mint a specifikus nagy erőforrású nyelvekre alkalmazott keresztnyelvű modellek.

2. szint: Stanza (további nyelvek)

A Stanford Stanza könyvtára NER-t biztosít olyan további nyelvekhez, amelyeket a spaCy kereskedelmi kínálata nem fed le, beleértve a horvátot, szlovént, ukránt és másokat. Ez kiterjeszti a lefedettséget olyan nyelvekre, amelyeknek kisebb, de még mindig jelentős EU-s anyanyelvi beszélői vannak.

3. szint: XLM-RoBERTa (keresztnyelvű lefedettség)

Azoknál a nyelveknél, amelyekhez sem a spaCy, sem a Stanza nem nyújt betanított NER-modelleket, az XLM-RoBERTa keresztnyelvű transzfert biztosít. 100 nyelven lévő Common Crawl adatokon tanítva, az XLM-RoBERTa 91,4%-os keresztnyelvű F1-értéket ér el a személyes adat felismerésben (HuggingFace 2024), lehetővé téve az alacsonyabb erőforrású nyelvek ésszerű felismerését.

A keresztnyelvű modell különösen jól kezeli a kódváltást (vegyes nyelvű szöveg) – ez egy kritikus tulajdonság olyan nemzetközi szervezetek számára, ahol egyetlen dokumentum több nyelven is tartalmazhat szöveget.

Nyelvspecifikus entitástípusok

A felismerési modellen túl a GDPR-megfelelőség entitástípus-lefedettséget igényel az országspecifikus azonosítókhoz. Egy többnyelvű eszköznek szüksége van:

EU-s nemzeti azonosítók:

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

Telefonszám-formátumok: Minden EU-s országnak egyedi mobil-előtagstruktúrái, körzetszám-formátumai és helyi tárcsázási konvenciói vannak. A +49 (Németország), +33 (Franciaország), +48 (Lengyelország) mind országspecifikus validációt igényel.

Cím-formátumok: Az irányítószám-formátumok radikálisan eltérnek – a német PLZ (5 számjegy), a francia code postal (5 számjegy, 01–99-vel kezdődik), az brit postcode (alfanumerikus, több formátum), a spanyol código postal (5 számjegy, 01000–52999).

Felhasználási eset: Svájci gyógyszeripari cég többnyelvű dokumentumai

Egy svájci gyógyszeripari cég olyan munkaszerződéseket dolgoz fel, amelyek ugyanazon dokumentumon belül tartalmaznak szöveget németül, franciául és angolul (Svájcnak négy hivatalos nyelve van). Jelenlegi eszközük németre van konfigurálva, és kihagyja az összes francia részben lévő személyes adatot.

Egy genfi munkavállaló munkaszerződése tartalmazza a francia AVS-számát (13 számjegy), svájci bankszámla IBAN-ját, lakóhelyeként megjelölt kantonját és nevét francia formátumban. A németre konfigurált eszköz kihagyja a francia formátumú nevet, nem ismeri fel a francia AVS-szám mintát (eltér a német AHV-szám formátumától), és csak részben azonosítja az IBAN-t.

A háromszintű megközelítés a dokumentumot egészként dolgozza fel, automatikusan felismeri a nyelvet minden szövegszegmensre, alkalmazza a nyelvmegfelelő NER-modelleket, és ország-specifikus regex validátorokat használ minden nemzeti azonosítótípusra – függetlenül attól, hogy melyik nyelvű részben jelenik meg.

Vegyes nyelvű dokumentumok kezelése

A legnehezebb többnyelvű személyes adat probléma a dokumentumon belüli nyelvkeverés: olyan dokumentum, amely különböző nyelvű bekezdéseket tartalmaz, kódváltásos mondatokat, vagy az idegen szöveget más nyelvű szövegkörnyezetben.

Példák:

• Egy német vállalat angol nyelvű szerződése német munkavállalói adatokkal (nevek, adóazonosítók)
• Egy GDPR-hozzájárulási nyomtatvány franciául, amely angol nyelvű adatvédelmi irányelveket tartalmaz
• Egy többnyelvű ügyfélszolgálati csevegésnapló, ahol az ügynök angolul válaszol, de az ügyfél arabul ír

Az XLM-RoBERTa ezt natívan kezeli: keresztnyelvű tanítása azt jelenti, hogy nem igényel explicit nyelvi nyilatkozatokat, és vegyes nyelvű szövegeket dolgoz fel szegmentálás nélkül.

Termelési telepítésnél az automatikus nyelvfelismerés (mondatszinten alkalmazva) és az XLM-RoBERTa keresztnyelvű következtetés kombinációja biztosítja a legrobusztusabb vegyes nyelvű dokumentumkezelést.

Praktikus telepítési útmutató

Auditálja jelenlegi eszköze nyelvi lefedettségét: Kérje jelenlegi anonimizáló szállítójától az F1-értékeket az adataiban szereplő nyelvekre. A „20 nyelvet támogat” ofta azt jelenti, hogy az eszköz Google Fordítón keresztül passzírozza a szöveget, mielőtt angol NER-t alkalmaz – ami nem azonos a natív nyelvű felismeréssel.

Térképezze fel adatait nyelvek szerint: Végezzen adatleltárt, amely tartalmazza a nyelvi megoszlást. Egy olyan multinacionális, amelynek 70%-a angol, 20%-a német és 10%-a francia, eltérő kockázati kitettséggel rendelkezik, mint egy 95%-ban angliai.

Tesztelje nemzeti azonosítókkal: Hozzon létre egy tesztadatkészletet a működéséhez releváns nemzeti azonosítók 10-10 példájával (Steuer-ID, NIR, PESEL, BSN stb.), és ellenőrizze a felismerési arányokat. Ez gyorsabb audit, mint a nagy léptékű F1-kiértékelés.

Tekintse át DPIA-iát: Ha rendelkezik Adatvédelmi Hatásvizsgálatokkal, amelyek lefedik anonimizáló eszközeit, ellenőrizze, hogy a nyelvi lefedettségi elemzés szerepel-e. Egy hiányos DPIA, amely csak az angol lefedettséget feltételezi, frissítésre szorulhat.

Az anonym.legal személyes adat felismerő motorja háromszintű többnyelvű megközelítést alkalmaz: natív spaCy-modellek 25 nagy erőforrású nyelvhez, Stanza a további nyelvekre, és XLM-RoBERTa keresztnyelvű transformerek az összesen 48 nyelvű lefedettséghez. Az összes EU-s tagállam országspecifikus entitástípusai benne vannak.

Források:

• ACL 2024: Hibrid személyes adat felismerés európai helyszínekre
• Skálázható többnyelvű személyes adat annotációs keretrendszer (arXiv 2025)
• HuggingFace XLM-RoBERTa keresztnyelvű NER-összehasonlítók
• Microsoft Presidio GitHub Issue #1071 – Német téves pozitívak
• EDPB iránymutatások a 25. cikk szerinti beépített adatvédelemről
• CNIL 2024-es Éves Jelentés