Monikielinen PII-tunnistus GDPR-vaatimustenmukaisuuteen

Piilevä GDPR-vaatimustenmukaisuuden aukko

GDPR:llä ei ole kielimääritystä. Artikla 4(1) määrittelee "henkilötiedon" viittaamatta kieleen, jolla se esiintyy. Saksan Steuer-ID on yhtä suojattu kuin yhdysvaltalainen sosiaaliturvatunnus. Ranskan NIR on yhtä säännelty kuin Yhdistyneen kuningaskunnan kansallinen vakuutusnumero.

Mutta useimmat PII-tunnistustyökalut on rakennettu englannille.

ACL 2024 -konferenssissa julkaistu tutkimus osoitti, että hybridit NLP-lähestymistavat saavuttavat 0,60–0,83:n F1-pisteet eurooppalaisille paikanomaisille aineistoille – mutta englanninkeskeiset työkalut, joita sovelletaan ei-englanninkieliseen tekstiin, saavat lähes nollapisteita rakenteellisille kansallisille tunnisteille. Käytännön merkitys: anonymisointityökalu, joka otetaan käyttöön monikansallisessa organisaatiossa, saattaa tunnistaa 95 % englanninkielisestä PII:stä samalla kun se jättää huomaamatta 40–60 % saksan-, ranskan-, puolan- tai hollanninkielisestä PII:stä samassa aineistossa.

Tämä on systemaattinen GDPR-vaatimustenmukaisuuden aukko, joka koskee lähes kaikkia monikansallisia yrityksiä, jotka käyttävät englanninkeskeisiä anonymisointityökaluja.

Miksi PII on kielikohtaista?

PII-tunnistuksessa on kaksi komponenttia: kaavoihin perustuva tunnistus (rakenteelliset tunnisteet kuten verotunnukset, puhelinformaatit) ja NER-pohjainen tunnistus (kontekstuaaliset entiteetit kuten henkilön nimet, organisaatioiden nimet, osoitteet).

Molemmat komponentit ovat syvällisesti kielikohtaisia.

Rakenteelliset tunnisteet eroavat radikaalisti maittain

Englanninkielinen regex-kaava sosiaaliturvatunnuksille (muoto: NNN-NN-NNNN) ei vastaa mitään näistä tunnisteista. Jokainen vaatii maakohtaisen regex-logiikan sekä tarkistussummavalidoinnin.

Nimettyjä entiteettejä tunnistava NER vaatii kielen omia malleja

Saksan kielessä henkilönnimet noudattavat erilaisia kaavoja kuin englanninkieliset nimet. "Hans-Dieter Müller" ja "Anna-Lena Schreiber-Koch" ovat kontekstin perusteella tunnistettavissa saksalaisiksi nimiksi – mutta pääasiassa englanninkielisellä tekstillä koulutettu malli jättää ne usein huomaamatta tai luokittelee ne väärin.

Vielä ongelmallisempaa: vääriä positiiveja yhdessä kielessä voi syntyä väärien negatiivisten seurauksena toisessa. Microsoft Presidion GitHub-ongelmaseuranta dokumentoi systemaattisia vääriä positiiveja, joissa saksankieliset sanat luokitellaan virheellisesti englanninkieliseksi PII:ksi. Sana "Null" (saksaksi "nolla") laukaisee nimidetektoinnin vääriä positiiveja englanninkielisissä malleissa. Tämä nostaa väärät positiivit 3 virheeseen jokaista todellista entiteettiä kohti monikielisissä tuotantoympäristöissä (Alvaro et al., 2024).

Sääntelyaltistuminen

EU:n tietosuojaviranomaiset ovat yhä tietoisempia tästä aukosta. Useat kansalliset tietosuojaviranomaiset ovat antaneet ohjeistuksia tai täytäntöönpanotoimenpiteitä, jotka koskevat monikielistä käsittelyä:

Saksan BfDI: On selventänyt, että GDPR:n artikla 5(1)(f) (eheys ja luottamuksellisuus) koskee dataa kaikissa käsittelymuodoissa, mukaan lukien ei-englanninkielistä dataa kolmansien osapuolten työkalujen käsittelemänä.

Ranskan CNIL: CNIL:n vuosikertomus 2024 mainitsi kasvavat huolenaiheet AI-työkaluista, jotka käsittelevät ranskankielistä dataa ilman ranskankielisiä PII-tunnistusominaisuuksia.

Eurooppalaiset tietosuojaviranomaiset yleisesti: GDPR:n artiklan 25 (tietosuoja suunnitteluvaiheessa) nojalla teknisten toimenpiteiden on oltava asianmukaisia todelliselle käsiteltävälle datalle – mukaan lukien ei-englanninkielinen PII monikansallisissa käyttöönotoissa.

Käytännön riski: organisaatio voi osoittaa 95 %:n PII-tunnistustehokkuuden englanninkieliselle sisällölle GDPR-tarkastuksessa, mutta jos he myös käsittelevät saksan-, ranskan- ja puolankielistä sisältöä samalla työkalulla, tarkastus saattaa paljastaa systemaattisia aukkoja näille kielille.

Kolmitasoinen lähestymistapa monikieliseen PII-tunnistukseen

Akateeminen tutkimus ja tuotantokäyttöönotot ovat lähentyneet kolmitasoiseen hybridiarkkitehtuuriin tehokkaimpana lähestymistapana monikieliseen PII-tunnistukseen:

Taso 1: Kielen omat spaCy-mallit (korkean resurssitason kielet)

spaCy tarjoaa koulutetut putkikomponentit 25 kielelle, mukaan lukien saksa, ranska, espanja, portugali, italia, hollanti, venäjä, kiina, japani, korea, puola ja muut. Nämä mallit on koulutettu kielen omilla korpuksilla ja ymmärtävät kunkin kielen morfologian, syntaksin ja entiteettikaavat.

Saksalle: spaCyn de_core_news_lg-malli ymmärtää yhdyssanoja, sijataivutuksia ja saksalaisia nimikaavoja. Ranskalle: fr_core_news_lg käsittelee ranskan entiteettikaavat, mukaan lukien arvonimet, paikkakunnat ja organisaatiomuodot.

Kielen omat mallit saavuttavat merkittävästi korkeamman tarkkuuden ja kattavuuden nimitunnistuksessa kuin ristikielelliset mallit sovellettuna tiettyihin korkean resurssitason kieliin.

Taso 2: Stanza (lisäkielet)

Stanfordin Stanza-kirjasto tarjoaa NER:n lisäkielille, joita spaCyn kaupallinen tarjonta ei kata, mukaan lukien kroatia, sloveeni, ukraina ja muut. Tämä laajentaa kattavuuden kieliin, joilla on pienempi mutta silti merkittävä EU:n puhujapopulaatio.

Taso 3: XLM-RoBERTa (ristikielinen kattavuus)

Kielille, joille kummallakaan spaCy:llä eikä Stanzalla ole koulutettuja NER-malleja, XLM-RoBERTa tarjoaa ristikielisen siirron. Koulutettu Common Crawl -datalla 100 kielellä, XLM-RoBERTa saavuttaa 91,4 %:n ristikielisen F1:n PII-tunnistuksessa (HuggingFace 2024), mahdollistaen kohtuullisen tunnistuksen matalan resurssitason kielille.

Ristikielinen malli käsittelee koodinvaihtoa (sekakielinen teksti) erityisen hyvin – ominaisuus, josta tulee kriittinen kansainvälisille organisaatioille, joissa yksittäinen asiakirja saattaa sisältää tekstiä useilla kielillä.

Kielikohtaiset entiteettityypit

Tunnistusmallin lisäksi GDPR-vaatimustenmukaisuus vaatii entiteettityyppien kattavuuden maakohtaisille tunnisteille. Monikielinen työkalu tarvitsee:

EU:n kansalliset tunnisteet:

• 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

Puhelinnumeroformaatit: Jokaisella EU-maalla on omat mobiilinumeron etuliiterakenteet, suuntanumeroformaatit ja paikalliset soittokonventiot. +49 (Saksa), +33 (Ranska), +48 (Puola) vaativat kaikki maakohtaisen validoinnin.

Osoiteformaatit: Postinumeroformaatit eroavat radikaalisti – saksan PLZ (5 numeroa), ranskan code postal (5 numeroa, alkaa 01–99), Yhdistyneen kuningaskunnan postcode (aakkosnumeerinen, useita formaatteja), espanjan código postal (5 numeroa 01000–52999).

Käyttötapaus: sveitsiläisen lääkeyrityksen monikieliset asiakirjat

Sveitsiläinen lääkeyritys käsittelee työsopimuksia, jotka sisältävät tekstiä saksaksi, ranskaksi ja englanniksi samassa asiakirjassa (Sveitsissä on neljä virallista kieltä). Heidän nykyinen työkalunsa on konfiguroitu saksaksi ja jättää huomaamatta kaiken ranskankielisen PII:n.

Genevestä kotoisin olevan työntekijän työsopimus viittaa heidän ranskalaiseen AVS-numeroonsa (13 numeroa), sveitsiläiseen pankkitiliin IBAN-muodossa, kotikantoniin ja nimeen ranskankielisessä muodossa. Saksankieliseksi konfiguroitu työkalu jättää ranskankielisen nimen huomaamatta, epäonnistuu tunnistamaan ranskan AVS-numerokaavoita (eroaa saksan AHV-Nummer-muodosta) ja tunnistaa IBAN:in vain osittain.

Kolmitasoinen lähestymistapa käsittelee asiakirjan kokonaisuudessaan, tunnistaa kielen automaattisesti jokaiselle tekstisegmentille, soveltaa kielen omia NER-malleja ja käyttää maakohtaisia regex-validaattoreita kansallisille tunniste-tyypeille – riippumatta siitä, missä kielisektiossa ne esiintyvät.

Sekakielisten asiakirjojen käsittely

Vaikein monikielinen PII-ongelma on asiakirjan sisäinen kielen sekoittuminen: asiakirja, joka sisältää eri kielillä olevia kappaleita, koodinvaihtoisia lauseita tai eri kielellä kirjoitettua lainattua tekstiä kuin ympäröivä teksti.

Esimerkkejä:

• Saksalaisen yrityksen englanninkielinen sopimus, jossa on saksankielistä henkilöstödataa (nimiä, verotunnuksia)
• Ranskankielinen GDPR-suostumuslomake, joka sisältää englanninkielisen tietosuojakäytännön otteen
• Monikielinen asiakaspalveluchat-loki, jossa agentti vastaa englanniksi mutta asiakas kirjoittaa arabiaksi

XLM-RoBERTa käsittelee tämän natiivisti: sen ristikielinen koulutus tarkoittaa, ettei se vaadi eksplisiittisiä kieliilmoituksia ja käsittelee sekakielistä tekstiä ilman segmentointia.

Tuotantokäyttöönotoissa automaattisen kielen tunnistuksen (sovellettuna lausetasolla) ja XLM-RoBERTan ristikielisen inferenssin yhdistelmä tarjoaa kestävimmän käsittelyn sekakielisille asiakirjoille.

Käytännön käyttöönotto-ohjeistus

Tarkasta nykyisen työkalusi kielikattavuus: Pyydä nykyistä anonymisointitoimittajaasi toimittamaan F1-pisteet datassasi esiintyville kielille. "Tukee 20 kieltä" tarkoittaa usein, että työkalu käyttää Google Translatea ennen englanninkielisen NER:n soveltamista – mikä ei ole sama kuin kielen oma tunnistus.

Kartoita datasi kieliin: Tee datan inventaario, joka sisältää kielijakauman. Monikansallisella yrityksellä, jonka data on 70 % englanniksi, 20 % saksaksi ja 10 % ranskaksi, on erilainen riskialtistuminen kuin yrityksellä, jonka data on 95 % englanniksi.

Testaa kansallisilla tunniste-esimerkeillä: Luo testiaineisto, jossa on 10 esimerkkiä kustakin toimintaasi liittyvistä kansallisista tunnisteista (Steuer-ID, NIR, PESEL, BSN jne.) ja varmista tunnistusasteet. Tämä on nopeampi tarkastus kuin laajamittainen F1-arviointi.

Tarkista DPIA:si: Jos sinulla on anonymisointityökalujasi koskevia tietosuojavaikutusten arviointeja, varmista, että kielikattavuusanalyysi on sisällytetty niihin. Epätäydellinen DPIA, joka olettaa vain englanninkielisen kattavuuden, saattaa vaatia päivitystä.

anonym.legalin PII-tunnistusmoottori käyttää kolmitasoista monikielistä lähestymistapaa: kielen omia spaCy-malleja 25 korkean resurssitason kielelle, Stanzaa lisäkielikattavuuteen ja XLM-RoBERTan ristikielisiä transformereita 48 kielen kokonaiskattavuuteen. Maakohtaiset entiteettityypit kaikille EU:n jäsenvaltioille sisältyvät.

Lähteet:

• ACL 2024: Hybriidi PII-tunnistus eurooppalaisille alueille
• Skaalautuva monikielinen PII-merkintäkehys (arXiv 2025)
• HuggingFace XLM-RoBERTa ristikielisen NER:n benchmarkit
• Microsoft Presidio GitHub-ongelma #1071 – saksalaiset väärät positiivit
• EDPB:n ohjeet artiklan 25 tietosuojasta suunnitteluvaiheessa
• CNIL:n vuosikertomus 2024