By · Last updated 2026-03-03

Tagasi BlogisseGDPR ja Vastavus

Mitmekeelne isikuandmete tuvastamine GDPR jaoks

Saksa Steuer-ID, prantsuse NIR ja rootsi Personnummer nõuavad kõik erinevat tuvastusloogikat. Vaata, kuidas ehitada tõeliselt GDPR-ühilduvat mitmekeelset isikuandmete kaitset.

March 3, 202610 min lugemist
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Mitmekeelne isikuandmete tuvastamine GDPR jaoks

Uuendatud 2026. aastaks

Varjatud GDPR-i lünk

GDPR-il pole keeleeelistust. Artikkel 4(1) määratleb "isikuandmeid" ilma märkimata, millises keeles need esinevad. Saksa Steuer-ID on sama kaitstud kui USA sotsiaalkindlustuse number. Prantsuse NIR on sama reguleeritud kui Ühendkuningriigi riiklik kindlustusnumber.

Enamik isikuandmete tuvastamise tööriistu on ehitatud ainult inglise keele jaoks.

ACL 2024 uuring leidis, et hübriidsed NLP tööriistad saavutavad Euroopa lokaalide jaoks F1-skoore 0,60–0,83. Ainult ingliskeelsed tööriistad saavad mitteingliskeelsete rahvuslike ID-formaatide puhul lähedase nulli. Vahe on ilmne. Tööriist võib tabada 95% ingliskeelseid isikuandmeid. Kuid see jätab vahele 40–60% saksa, prantsuse, poola või hollandi isikuandmeid samas failis. See on tõsine probleem. See jätab ettevõtted haavatavaks.

See on reaalne GDPR-i lünk. See mõjutab peaaegu iga ülemaailmset ettevõtet, kes kasutab ingliskeskseid redaktsiooniilriistu. Vaata meie GDPR-i juhendit lisateabe saamiseks.

Miks isikuandmed on lokaadispetsiifilised

Isikuandmete tuvastamisel on kaks osa.

Esimene on mustripõhine skannimine. See hõlmab struktureeritud ID-sid nagu maksunumbrid ja telefoninumbrite formaadid.

Teine on NER-põhine skannimine. See hõlmab kontekstipõhiseid entiteete nagu nimed ja aadressid.

Mõlemad osad sõltuvad lokaadist.

Struktureeritud ID-d erinevad riigiti

RiikMaksu IDFormaatValideerimine
SaksamaaSteuer-ID11 numbritModulo-11
PrantsusmaaNIR15 numbrit + 2-numbriline võtiINSEE
RootsiPersonnummer10 numbritLuhn
PoolaPESEL11 numbritModulo-10
HollandBSN9 numbritElfproef
HispaaniaDNI/NIE8 numbrit + tähtModulo-23
ItaaliaCodice Fiscale16 märkiKohandatud kontrollsumma

Ingliskeelne regex SSN-ide jaoks (NNN-NN-NNNN) ei vasta ühelegi neist formaatidest. Igaüks vajab oma regexi. Igaüks vajab ka oma kontrollsumma loogikat.

NER vajab natiivseid mudeleid

Saksa nimed erinevad ingliskeelsetest. "Hans-Dieter Muller" on natiivse saksa mudeli jaoks selge. Ingliskeelsel treenitud mudel jätab sellised nimed sageli vahele.

Valetulemused on ka probleem. Microsoft Presidio probleemide jälgija näitab saksa sõnade valesti liigitamist ingliskeelsete isikuandmetena. Sõna "Null" (saksa keeles "null") on üks näide. See käivitab ingliskeeletes mudelites vale nimetabamuse. Tootmiskasutuses paisuvad veamäärad 3 valetulemuseni ühe tegeliku entiteedi kohta (Alvaro jt, 2024).

Regulatiivne risk

EL-i andmekaitseasutused on sellest probleemist teadlikud. Mitmed riiklikud andmekaitseasutused on juhiseid andnud.

Saksa BfDI: GDPR artikkel 5(1)(f) kehtib kõikidele andmetele. See hõlmab mitteingliskeelseid andmeid, mida kolmanda osapoole tööriistad töötlevad.

Prantsuse CNIL: 2024. aasta CNIL aastaaruanne tõstatas murekohti. See tõi esile AI tööriistad, mis käsitlevad prantsuse andmeid ilma prantsuse lokaadi isikuandmete skannimiseta.

EL-i andmekaitseasutused laiemalt: GDPR artikkel 25 (Privacy by Design) nõuab tegelikult töödeldavatele andmetele sobivaid kaitsemeetmeid. See hõlmab mitteingliskeelseid isikuandmeid ülemaailmsetes paigaldistes.

Risk on selge. Ettevõte võib GDPR-i auditis näidata 95% isikuandmete tuvastamist ingliskeelsel sisusl. Kuid kui see käsitleb ka saksa, prantsuse ja poola andmeid sama tööriistaga, ilmnevad lüngad. Audiitorid märkavad. Trahvid võivad järgneda. Vaata meie kaitsemeetmete lehte, kuidas me sellega tegeleme.

Kolmeastmeline kujundus

Uuringutulemused ja tootmiskasutus lepivad kokku kolmeastmelises hübriidkujunduses kui parimas lähenemises.

1. aste: natiivsed spaCy mudelid

spaCy pakub treenitud mudeleid 25 lokaadi jaoks. Need hõlmavad saksa, prantsuse, hispaania, portugali, itaalia, hollandi, vene, hiina, jaapani, korea ja poola keelt. Iga mudel treenib natiivsele tekstile. Need õpivad iga lokaadi süntaksit ja entiteedimustreid. See on oluline. Natiivne treenimine tähendab paremat leidlikkust ja vähem valetulemuseid.

Saksa keele jaoks: de_core_news_lg käsitleb liitmärgisõnu ja saksa nimemustreid. Prantsuse keele jaoks: fr_core_news_lg käsitleb prantsuse entiteete, tiitleid, kohanimesid ja organisatsioone.

Natiivsed mudelid ületavad keelteüleseid mudeleid kõrgekvaliteediliste lokaalide nimede skannimiseks.

2. aste: Stanza rohkemate lokaalide jaoks

Stanfordi Stanza teek katab lokaalid, mida spaCys pole. Nende hulgas on horvaatia, sloveenia ja ukraina keel. See lisab ulatust EL-i kõneleverühmadele, mida spaCy ei teeni. Stanza on tasuta ja avatud lähtekoodiga. See integreerub hästi ülejäänud pinuga.

3. aste: XLM-RoBERTa laiema ulatuse jaoks

Lokaalide jaoks, kus spaCy-l ja Stanzal puuduvad NER-mudelid, täidab XLM-RoBERTa lünga. See treenib Common Crawli tekstil 100 lokaadis. See saavutab 91,4% keelteülese F1 isikuandmete tuvastamiseks (HuggingFace 2024). See käsitleb koodivahetust hästi. See on oluline funktsioon. See on oluline, kui ühes dokumendis on korraga teksti mitmes lokaadis.

Külasta meie tokenisüsteemi dokumentatsiooni, et näha, kuidas API kutsed skaleeruvad mitmekeelsete mahtudega.

Lokaadispetsiifilised entiteedi tüübid

Mudelid üksi ei piisa. GDPR-i joondamine nõuab ka riigispetsiifiliste ID-de entiteedi tüübi ulatust.

EL-i rahvuslikud ID-d riigi järgi:

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

Telefoninumbri formaadid: Igal EL-i riigil on unikaalsed prefeksistruktuurid. +49, +33 ja +48 vajavad igaüks oma validerimisloogikat.

Aadresside formaadid: Postiindeksid varieeruvad oluliselt. Saksa PLZ kasutab 5 numbrit. Prantsuse koodid kasutavad 5 numbrit (01–99 vahemik). Ühendkuningriigi postiindeksid on tähe-numbri kombinatsioonid. Hispaania koodid kasutavad 5 numbrit (01000–52999).

Reaalse elu juhtum: Šveitsi farmaatsiaettevõte

Shveitsi ettevõte töötleb töölepinguid. Iga leping segab saksa, prantsuse ja inglise teksti. Šveitsil on neli ametlikku keelt. Nende tööriist oli seadistatud ainult saksa keelele. See jättis vahele kõik prantsuskeelsed isikuandmed.

Genfi töötaja leping sisaldas prantsuse AVS-numbrit (13 numbrit), Šveitsi panga IBAN-i ja nime prantsuse formaadis. Ainult saksa keele tööriist jättis prantsuse formaadis nime vahele. See ei suutnud leida prantsuse AVS-numbrit. See tuvastas IBAN-i vaid osaliselt.

Kolmeastmeline lähenemine töötleb kogu dokumenti. See tuvastab lokaadi tekstisegmendi kaupa. See rakendab iga osa jaoks õiget NER-mudelit. See valideerib iga rahvusliku ID-ga korrektse riigi loogika.

Segalokaalid dokumendis

Kõige keerulisem juhtum on dokumendisisene lokaalide segamine. Näited:

  • Saksa ettevõtte ingliskeelne leping saksa töötaja andmetega (nimed, maksu ID-d)
  • Prantsuse GDPR-nõusoleku vorm ingliskeelse privaatsusväljavõttega
  • Vestlus, kus agent vastab inglise keeles ja klient kirjutab araabia keeles

XLM-RoBERTa käsitleb seda natiivselt. See ei vaja selgeid lokaadilippe. See töötleb segalokaadiga teksti ilma eelneva segmenteerimiseta. See säästab aega. Samuti väldib see vigu vale jagamise tõttu.

Tootmiskasutuseks annab automaatse lokaadi tuvastamise (lause tasemel) kombineerimine XLM-RoBERTa järeldamisega robustse käsitluse segalokaadiga dokumentide jaoks.

Praktilised sammud

Auditeeri oma tööriista ulatust. Küsi oma redaktsiooni müüjalt F1-skoore sinu spetsiifiliste lokaalide jaoks. "Toetab 20 keelt" tähendab sageli, et tööriist suunab teksti esmalt masintõlke kaudu. See pole natiivne skannimine.

Kaardista oma andmed lokaalide järgi. Tee andmete inventuur, mis sisaldab lokaadi jaotust. Ülemaailmsel ettevõttel, kellel on 70% inglise, 20% saksa ja 10% prantsuse andmeid, on erinevad riskid. Ettevõte 95% ingliskeelsete andmetega on erinevas olukorras.

Testa rahvuslike ID-näidistega. Loo testikogum 10 näitega oma tegevuses kasutatavatest rahvuslikest ID-dest — Steuer-ID, NIR, PESEL, BSN ja teised. Kinnita tuvastamismäärad. See on kiirem kui täielik F1-test.

Vaata üle oma DPIA-d. Kontrolli, kas lokaadi ulatus on kaasatud. Puudulik DPIA, mis eeldab ainult ingliskeelseid andmeid, võib vajada uuendamist. Tegutse kohe. Ära oota, kuni audit lünka leiab.

Täielike entiteedi tüüpide definitsioonide jaoks vaata entiteetide viidet ja KKK-d. Plaanide ja API kõnede määrade jaoks külasta hinnakirja.


anonym.legal-i isikuandmete tuvastamise mootor kasutab kolmeastmelist mitmekeelset lähenemist. See katab 25 kõrge ressursiga lokaadi natiivsete spaCy mudelite kaudu. Stanza lisab täiendavat lokaadi ulatust. XLM-RoBERTa keelteülesed transformerid laiendavad ulatust 48 lokaadile. Riigispetsiifilised entiteedi tüübid kõikidele EL-i liikmesriikidele on kaasas.

Allikad

Kas olete valmis oma andmeid kaitsma?

Alustage PII anonüümitamist 285+ üksustüübi abil 48 keeles.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.