Miksi PII-tunnistustyökalusi on vain...

Piilotettu GDPR-yhteensopivuusaukko

GDPR:llä ei ole kielipreferenssiä. Artikla 4(1) määrittelee "henkilötiedot" ilman viittauksia kieleen, jolla ne esiintyvät. Saksalainen Steuer-ID on yhtä suojattu kuin Yhdysvaltojen sosiaaliturvatunnus. Ranskalainen NIR on yhtä säädelty kuin Yhdistyneen kuningaskunnan kansallinen vakuutusnumero.

Mutta useimmat PII-tunnistustyökalut on rakennettu englanniksi.

ACL 2024:ssä julkaistussa tutkimuksessa todettiin, että hybridit NLP-lähestymistavat saavuttavat F1-pisteitä 0.60-0.83 eurooppalaisilla alueilla — mutta englanninkieliset työkalut, joita sovelletaan ei-englanninkieliseen tekstiin, saavat lähes nollatuloksia rakenteellisille kansallisille tunnisteille. Käytännön seuraus: anonymisointityökalu, jota käytetään monikansallisessa organisaatiossa, voi tunnistaa 95 % englanninkielisestä PII:stä samalla kun se jättää huomiotta 40-60 % saksalaisesta, ranskalaisesta, puolalaisesta tai hollantilaisesta PII:stä samassa tietojoukossa.

Tämä on systemaattinen GDPR-yhteensopivuusaukko, joka vaikuttaa käytännössä jokaiseen monikansalliseen yritykseen, joka käyttää englanninkeskeisiä anonymisointityökaluja.

Miksi PII on kielikohtainen

PII-tunnistus koostuu kahdesta osasta: kuvioon perustuvasta tunnistamisesta (rakenteelliset tunnisteet kuten verotunnukset, puhelinmuodot) ja NER-pohjaisesta tunnistamisesta (kontekstuaaliset entiteetit kuten henkilön nimet, organisaatioiden nimet, osoitteet).

Molemmat osat ovat syvästi kielikohtaisia.

Rakenteelliset tunnisteet eroavat radikaalisti maittain

Englanninkielinen regex-malli SSN:ille (muoto: NNN-NN-NNNN) ei vastaa mitään näistä tunnisteista. Kukin vaatii maakohtaisen regex-logiikan sekä tarkistusvalidoinnin.

Nimettyjen entiteettien tunnistus vaatii kielikohtaisia malleja

Saksalaiset henkilön nimet seuraavat erilaisia kaavoja kuin englanninkieliset nimet. "Hans-Dieter Müller" ja "Anna-Lena Schreiber-Koch" tunnistetaan saksalaisiksi nimiksi kontekstin perusteella — mutta malli, joka on koulutettu pääasiassa englanninkielisellä tekstillä, ohittaa ne usein tai luokittelee ne väärin.

Ongelmallisempaa: vääriä positiivisia tuloksia yhdellä kielellä voi tulla vääriä negatiivisia tuloksia toisella. Microsoft Presidio GitHub -ongelmasivustolla dokumentoidaan systemaattisia vääriä positiivisia tuloksia saksankielisistä sanoista, jotka luokitellaan väärin englanninkieliseksi PII:ksi. Sama sana "Null" (saksaksi "nolla") laukaisee nimien tunnistuksessa vääriä positiivisia tuloksia englanninkielisissä malleissa. Tämä nostaa vääriä positiivisia tuloksia 3 virheeseen per 1 oikea entiteetti monikielisissä tuotantoympäristöissä (Alvaro et al., 2024).

Sääntelyaltistus

EU:n tietosuojaviranomaiset ovat yhä tietoisempia tästä aukosta. Useat kansalliset DPAt ovat julkaisseet ohjeita tai täytäntöönpanotoimia, jotka liittyvät monikieliseen käsittelyyn:

Saksalainen BfDI: On selventänyt, että GDPR:n artikla 5(1)(f) (integraatio ja luottamuksellisuus) koskee tietoja kaikissa käsittelymuodoissa, mukaan lukien ei-englanninkieliset tiedot, joita käsitellään kolmannen osapuolen työkaluilla.

Ranskalainen CNIL: Vuoden 2024 CNIL:n vuosikertomuksessa todettiin kasvavaa huolta AI-työkaluista, jotka käsittelevät ranskankielisiä tietoja ilman ranskankielisiä PII-tunnistuskykyjä.

Euroopan DPAt yleensä: GDPR:n artiklan 25 (Yksityisyys suunnittelussa) mukaan teknisten toimenpiteiden on oltava asianmukaisia käsiteltävien tietojen osalta — mikä sisältää ei-englanninkielisen PII:n monikansallisissa käyttöönottoissa.

Käytännön riski: organisaatio voi osoittaa 95 % PII-tunnistustehokkuuden englanninkieliselle sisällölle GDPR-auditoinnin aikana, mutta jos ne myös käsittelevät saksankielistä, ranskankielistä ja puolankielistä sisältöä samalla työkalulla, auditointi voi paljastaa systemaattisia aukkoja näille kielille.

Kolmitasoinen lähestymistapa monikieliseen PII-tunnistukseen

Akateeminen tutkimus ja tuotantokäytännöt ovat yhtyneet kolmitasoiseen hybridirakenteeseen tehokkaimpana lähestymistapana monikieliseen PII-tunnistukseen:

Taso 1: Kielikohtaiset spaCy-mallit (korkean resurssin kielet)

spaCy tarjoaa koulutettuja putkikomponentteja 25 kielelle, mukaan lukien saksa, ranska, espanja, portugali, italia, hollanti, venäjä, kiina, japani, korea, puola ja muita. Nämä mallit on koulutettu äidinkielisillä korpuksilla ja ne ymmärtävät kunkin kielen morfologiaa, syntaksia ja entiteettikaavoja.

Saksalle: spaCy de_core_news_lg -malli ymmärtää yhdyssanoja, taivutusmuotoja ja saksalaisia nimikaavoja. Ranskalle: fr_core_news_lg käsittelee ranskankielisiä entiteettikaavoja, mukaan lukien otsikot, paikannimet ja organisaatiomuodot.

Kielikohtaiset mallit saavuttavat merkittävästi korkeamman tarkkuuden ja palautuksen nimien tunnistuksessa kuin kielirajat ylittävät mallit, joita sovelletaan erityisiin korkean resurssin kieliin.

Taso 2: Stanza (lisäkielet)

Stanfordin Stanza-kirjasto tarjoaa NER:ää lisäkielille, joita spaCy:n kaupallinen tarjonta ei kata, mukaan lukien kroatia, sloveeni, ukraina ja muita. Tämä laajentaa kattavuutta kielille, joilla on pienempi mutta silti merkittävä EU:n puhujakanta.

Taso 3: XLM-RoBERTa (kielirajat ylittävä kattavuus)

Kielille, joille ei spaCy eikä Stanza tarjoa koulutettuja NER-malleja, XLM-RoBERTa tarjoaa kielirajat ylittävää siirtoa. Koulutettu Common Crawl -datalla 100 kielellä, XLM-RoBERTa saavuttaa 91.4 % kielirajat ylittävän F1:n PII-tunnistuksessa (HuggingFace 2024), mahdollistaen kohtuullisen tunnistuksen alhaisemman resurssin kielille.

Kielirajat ylittävä malli käsittelee koodinvaihtoa (sekoitettu kieliteksti) erityisen hyvin — ominaisuus, joka on kriittinen kansainvälisille organisaatioille, joissa yksittäisessä asiakirjassa voi olla tekstiä useilla kielillä.

Kielikohtaiset entiteettityypit

Tunnistusmallin lisäksi GDPR-yhteensopivuus vaatii entiteettityyppien kattavuutta maakohtaisille tunnisteille. Monikielisen työkalun on tarpeen:

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

Puhelinnumeromuodot: Jokaisella EU-maalla on ainutlaatuiset matkapuhelinprefiksirakenteet, aluekoodimuodot ja paikalliset puhelinsoittokäytännöt. +49 (Saksa), +33 (Ranska), +48 (Puola) vaativat kaikki maakohtaista validointia.

Osoitemuodot: Postinumeroformaatit eroavat radikaalisti — saksalainen PLZ (5 numeroa), ranskalainen code postal (5 numeroa, jotka alkavat 01-99), brittiläinen postinumero (alfanumeerinen, useita muotoja), espanjalainen código postal (5 numeroa 01000-52999).

Käyttötapa: Sveitsiläiset lääketeollisuuden monikieliset asiakirjat

Sveitsiläinen lääketeollisuuden yritys 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ää huomiotta kaikki ranskankielisen osaston PII:t.

Työsopimus Genevessä asuvan työntekijän kanssa viittaa heidän ranskalaiseen AVS-numeroonsa (13 numeroa), heidän sveitsiläiseen pankkitili IBAN:iin, heidän asualueeseensa ja heidän nimeensä ranskankielisessä muodossa. Saksaksi konfiguroitu työkalu ohittaa ranskankielisen nimen, ei tunnista ranskalaista AVS-numeron kaavaa (joka on erilainen kuin saksalainen AHV-Nummer-muoto) ja tunnistaa vain osittain IBAN:in.

Kolmitasoinen lähestymistapa käsittelee asiakirjaa kokonaisuutena, tunnistaen kielen automaattisesti jokaiselle tekstisegmentille, soveltaen kielelle sopivia NER-malleja ja käyttäen maakohtaisia regex-validointityökaluja jokaiselle kansalliselle tunnistetyypille — riippumatta siitä, missä kieliosassa se esiintyy.

Sekakielisten asiakirjojen käsittely

Vaikein monikielinen PII-ongelma on asiakirjojen sisäinen kieliseos: asiakirja, joka sisältää kappaleita eri kielillä, koodinvaihtolauseita tai lainattua tekstiä eri kielellä kuin ympäröivä konteksti.

Esimerkkejä:

• Saksalaisen yrityksen englanninkielinen sopimus saksankielisillä työntekijätiedoilla (nimet, verotunnukset)
• Ranskalainen GDPR-sitoumuslomake, joka sisältää englanninkielisen tietosuojakäytännön katkelman
• Monikielinen asiakaspalveluchat-loki, jossa agentti vastaa englanniksi, mutta asiakas kirjoittaa arabiaksi

XLM-RoBERTa käsittelee tätä natiivisti: sen kielirajat ylittävä koulutus tarkoittaa, että se ei vaadi eksplisiittisiä kieli-ilmoituksia ja käsittelee sekoitettua kielitekstiä ilman segmentointivaatimuksia.

Tuotantokäytännöissä automaattisen kielentunnistuksen (sovellettuna lauseen tasolla) ja XLM-RoBERTa:n kielirajat ylittävän päättelyn yhdistelmä tarjoaa parhaan mahdollisen käsittelyn sekakielisille asiakirjoille.

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

Tarkista nykyisen työkalusi kielikattavuus: Pyydä nykyiseltä anonymisointitoimittajaltasi F1-pisteitä tiettyjen kielten osalta, jotka ovat datassasi. "Tukee 20 kieltä" tarkoittaa usein, että työkalu kuljettaa tekstiä Google Kääntäjän läpi ennen englanninkielisen NER:n soveltamista — mikä ei ole sama kuin kielikohtainen tunnistus.

Kartoitus datasi kielille: Suorita datainventaario, joka sisältää kielijakauman. Monikansallinen yritys, jolla on 70 % englanninkielistä, 20 % saksankielistä ja 10 % ranskankielistä dataa, altistuu erilaisille riskeille kuin yritys, jolla on 95 % englanninkielistä dataa.

Testaa kansallisten tunnisteiden näytteillä: Luo testidatasetti, jossa on 10 esimerkkiä jokaisesta kansallisesta tunnisteesta, joka on relevantti toiminnallesi (Steuer-ID, NIR, PESEL, BSN jne.) ja tarkista tunnistustasot. Tämä on nopeampi auditointi kuin laaja F1-arviointi.

Tarkista DPIA:si: Jos sinulla on tietosuojavaikutusten arviointeja, jotka kattavat anonymisointityökalusi, varmista, että kielikattavuusanalyysi on mukana. Puutteellinen DPIA, joka olettaa vain englanninkielisen kattavuuden, saattaa vaatia päivitystä.

anonym.legalin PII-tunnistusmoottori käyttää kolmitasoista monikielistä lähestymistapaa: kielikohtaisia spaCy-malleja 25 korkean resurssin kielelle, Stanzaa lisäkielikattavuuteen ja XLM-RoBERTa:n kielirajat ylittäviä transformereita 48-kieliseen kattavuuteen yhteensä.

Lähteet:

• ACL 2024: Hybrid PII Detection for European Locales
• Scalable Multilingual PII Annotation Framework (arXiv 2025)
• HuggingFace XLM-RoBERTa Cross-Lingual NER Benchmarks
• Microsoft Presidio GitHub Issue #1071 — German False Positives
• EDPB Guidelines on Article 25 Privacy by Design
• CNIL 2024 Annual Report