RTL-vaatimustenmukaisuuden aukko
GDPR ei pääty Bosporin salmelle. EU-yritykset, jotka käyttävät latinalaisen kirjaimiston työkaluja, ovat sokeita tietylle alueelle. Ongelma on todellinen ja sitä laajalti sivuutetaan.
Kyse ei ole pelkästään tekstin suunnasta. Oikealta vasemmalle -kirjaimistot vaativat erilaista tokenisointia ja erilaista segmentointia. Entiteettien rajat toimivat eri tavalla kuin vasemmalta oikealle -tekstissä. Englanninkielisiin datoihin koulutetut NER-järjestelmät soveltavat LTR-sääntöjä. Nämä säännöt hajoavat RTL-tekstissä ja tuottavat vääriä entiteettirajoituksia.
Arabialaiset morfologia tekee asioista hankalampia. Kieli käyttää juuria. Yksi juuri tuottaa kymmeniä sanamuotoja. Nimi kuten Mohammed voi esiintyä muodoissa "Al-Mohammed", "bin Mohammed" tai "Mohammed al-Rashid". Länsimaisille nimille rakennetut regeksikaavat eivät tunnista näitä muotoja. Englanninkieliset mallit eivät myöskään.
GDPR ei pidä kieltä vaatimustenmukaisuuden rajana. EU-yrityksen, joka käsittelee MENA-alueen asiakkaiden postia, on noudatettava samoja sääntöjä kuin ranskankielisen postin kanssa. PII:n puuttuminen RTL-tekstistä on oikeudellinen epäonnistuminen GDPR:n artiklan 32 nojalla.
KYC-käyttötapaus
Dubailainen fintech, joka käsittelee EU-asiakkaidensa KYC-asiakirjoja, osoittaa tämän selvästi.
Arabialaisten asiakkaiden KYC-tiedostot sisältävät nimiä RTL-kirjaimistolla, UAE:n Emirates-henkilötunnuksia ja RTL-osoitteita. Nämä sijaitsevat englanninkielisen liiketoimintatekstin rinnalla.
Emirates ID -muoto on 784-XXXX-XXXXXXX-X. Maakoodi 784. Syntymävuosi. Seitsemän numeroa. Tarkistusnumero. Länsimaiset PII-työkalut, joilla ei ole UAE:n entiteettimääritelmiä, eivät löydä tätä muotoa. Nimikentät kulkevat latinalaisen kirjaimiston NER:n kautta. Segmentointi on väärä. PII muuttuu näkymättömäksi työnkulussa.
Yrityksille, joilla on GDPR-velvoitteita tähän dataan, aukko luo todellisen oikeudellisen riskin. GDPR:n artikla 32 edellyttää asianmukaisia teknisiä toimenpiteitä. Työkalu, joka ei tunnista tunnisteita 22 %:ssa maailman kielistä, ei ole asianmukainen toimenpide.
Heprea ja sekakieliset asiakirjat
Heprea esittää samanlaisia ongelmia. Kirjaimisto kulkee oikealta vasemmalle. Israelin henkilötunnukset käyttävät tarkistussummaa — Luhn-algoritmin kaltainen testi yhdeksälle numerolle.
Israelilaiset oikeusasiakirjat sekoittavat usein hepreaa, arabiankielistä tekstiä ja englantia samassa tiedostossa. Tämä on yleistä sopimuksissa, joissa heprea on pääkieli ja englanninkieliset termit on lisätty viitteenä.
Sekakieliset tiedostot vaativat kirjaimiston tunnistuksen ennen NER:ää. Ilman sitä yksi NER-läpikäynti soveltaa latinalaisia sääntöjä RTL-kirjaimistoihin. Tulos on väärä.
Nature Scientific Reports -lehden tutkimus (2025) testasi monikielistä NER:ää RTL-PII:lle. Standardimallit saivat F1-pisteet 0,60–0,83. RTL NER -datalla hienosäädetty XLM-RoBERTa sai pistemäärän 0,88 ja yli.
Monikielisen arkkitehtuurin vaatimus
Hyvä RTL-PII-tunnistus vaatii kolme asiaa, joita länsimaislähtöisiltä työkaluilta yleensä puuttuu.
RTL-tekstinkäsittely: Unicode-kaksisuuntainen vaatimustenmukaisuus oikeaan tekstivirtaukseen. RTL-tietoinen tokenisointia, joka löytää sanatavurajoitukset oikealta vasemmalle -tekstissä.
Morfologiaa tunnistava NER: Morfologinen analysaattori, kuten Farasa arabialaiseen tekstiin, tai RTL NER -datalla hienosäädetty transformer-malli. Mallin on täytynyt oppia morfologinen vaihtelu.
Aluekohtaiset entiteettityypit: Emirates ID, Israeli ID, Saudi National ID ja Egyptian National ID tarvitsevat kukin eksplisiittiset määritelmät muotosäännöillä. Geneerisillä länsimaisilla työkaluilla ei ole näitä.
Katso, miten monikielinen NER-putkistomme käsittelee kirjaimistontunnistuksen 48 kielessä. Täydellinen lista tukemistamme MENA-tunnistetyypeistä löytyy entiteettikatalogista. GDPR-vaatimustenmukaisuusoppaastamme löytyy tietoa siitä, miten tunnistusaukot luovat artiklan 32 altistumista.