Sekakielinen henkilötieto: miksi yksikieliset työkalut jäävät vajaaksi
Päivitetty 2026.
Asiakirjat ylittävät kielirajat
Sveitsiläisen lääkeyhtiön työsopimus ei ole yhdellä kielellä. Sveitsissä on neljä virallista kieltä. Sveitsiläiset yritykset sekoittavat saksaa pääosioon, ranskaa oikeudellisiin lausekkeisiin ja englantia globaaleihin osioihin. Tämä voi tapahtua yhdessä kappaleessa.
Belgialaisessa hallituspöytäkirjassa on hollanninkielistä tekstiä, ranskankielisiä muodollisia osuuksia ja englanninkielisiä tiivistelmiä. Globaalissa dataoikeussopimuksessa voi olla englanninkieliset tekniset tiedot ja saksankieliset oikeuslausekkeet.
Tämä ei ole harvinaista. Se on normi DACH- ja EU-yrityksissä. Yksikieliset henkilötietotyökalut epäonnistuvat näissä tiedostoissa.
45 %:n jäämisaste
Yksikielisillä NER-työkaluilla on 45 % korkeampi henkilötietojen jäämisaste sekakielisissä tiedostoissa verrattuna puhtaisiin yksikielisiin tiedostoihin.
Juurisyy on suunnittelu. Saksankielisessä tekstissä koulutettu malli tuntee paikalliset nimirakenteet ja osoitesäännöt. Kun se kohtaa ranskankielisen osion, se on koulutusalueensa ulkopuolella. Nimet ja tunnisteet tuossa osassa saavat heikon tunnistuksen. Malli ei ole heikko — se on rakennettu eri kielelle.
EDPB 2024 havaitsi, että 72 % EU-yrityksistä käsittelee tiedostoja kolmella tai useammalla kielellä samanaikaisesti. Gartner 2024 havaitsi, että monikielisissä HR-tiedostoissa on 67 % enemmän henkilötietoja sivua kohden kuin yksikielisissä. Enemmän henkilötietoa ja enemmän jäämisiä yhdistyvät aukkoon.
Katso GDPR-oppaamme sovellettavista säännöistä.
Missä virheet kasautuvat
Virhe ei jakaudu tasaisesti tiedoston läpi. Osiovälien henkilötieto on suurimmassa vaarassa.
Harkitse tätä lauseketta: saksalainen lauserakenne, ranskalainen työntekijän nimi ja ranskalainen syntymäpäivä — kaikki yhdellä rivillä. NER-malli näkee ranskalaisen nimen siellä, missä odottaa paikallista nimeä. Se ei välttämättä merkitse sitä. Ranskankielinen malli näkee saksankieliset kontekstisanat eikä pysty lukemaan rakennetta.
HR-tiedostot tekevät tästä kallista. Gartner havaitsi 67 % enemmän henkilötietoja sivua kohden sekakielisissä HR-tiedostoissa. Osiovälien virheet sattuvat eniten siinä tiedostotyypissä, jossa on eniten henkilötietoja.
Monikieliset mallit korjaavat tämän
XLM-RoBERTa koulutetaan 100 kielen tekstillä samanaikaisesti. Se ei käytä erillistä mallia kullekin kielelle. Se oppii, että nimentunnistus toimii samalla tavalla eri kielisissä konteksteissa. Nimi ja sen konteksti jakavat saman rakenteen saksaksi, ranskaksi ja englanniksi.
Sekakielisillä tiedostoilla malli ei vaihdu osiovälissä. Se lukee koko tekstin yhtenä lohkona. Se soveltaa samoja entiteettisääntöjä kaikkialla.
Saksan ja ranskan hienosäätö lisää tarkkuutta kummallekin kielelle erikseen. Mutta monikielinen pohja napaa henkilötiedot välissä, joissa yksikieliset mallit epäonnistuvat.
DACH-yrityksille, joiden tiedostot ylittävät kieliosuuksia, tämä on todellinen hyöty. Yksikielisten työkalujen välissä jäämät entiteetit löytyvät monikielisillä malleilla.
Katso turvallisuussivumme kuinka anonym.legal käsittelee tämän.
Toimenpiteet nyt
Tarkista työkalusi laajuus. Kysy toimittajalta muistiinpalautuspisteytyksiä kielen mukaan. "Tukee useita kieliä" voi tarkoittaa, että teksti käy ensin konekäännöksen läpi. Se ei ole alkuperäinen skannaus.
Kartoita tiedostosi kielen mukaan. DACH-yrityksellä, jossa 60 % on saksaa, 30 % ranskaa ja 10 % englantia, on erilaisia aukkoja.
Testaa osiovälien esimerkeillä. Rakenna testijoukko kymmenellä sekakielisellä lauseke-esimerkillä. Tarkista muistiin palautuminen koko tiedoston läpi, ei vain pääkielisissä osissa.
Tarkista DPIA:si. Yksikielisiin tietueisiin perustuva DPIA voi olla puutteellinen. Korjaa se ennen kuin tarkastus tekee sen.
API-tietoja ja entiteettikattavuutta varten katso hinnoittelusivumme.
anonym.legal käyttää XLM-RoBERTaa sekä natiiveja spaCy- ja Stanza-malleja. Se löytää henkilötiedot osiovälien yli saksaksi, ranskaksi, englanniksi ja 45 muulla kielellä.