By · Last updated 2026-03-03

Bumalik sa BlogGDPR & Pagsunod

Multilingual na Pagtuklas ng PII para sa GDPR

Ang isang German Steuer-ID, French NIR, at Swedish Personnummer ay nangangailangan ng iba't ibang lohika ng pagtuklas. Alamin kung bakit nabibigo ang mga tool na Ingles lamang para sa pagsunod sa GDPR.

March 3, 202610 min basahin
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Multilingual na Pagtuklas ng PII para sa GDPR

Na-update para sa 2026

Ang Nakatagong Agwat sa GDPR

Walang kagustuhan sa wika ang GDPR. Ang Artikulo 4(1) ay nagtatakda ng "personal na datos" nang hindi pinangalanan ang wikang lumilitaw dito. Ang isang German Steuer-ID ay kasingprotektado ng isang US Social Security Number. Ang isang French NIR ay kasinregulado ng isang UK National Insurance number.

Karamihan sa mga tool sa pagtuklas ng PII ay itinayo para sa Ingles lamang.

Natuklasan ng pananaliksik mula sa ACL 2024 na ang mga hybrid NLP tool ay nakakamit ng mga F1 score na 0.60-0.83 para sa mga locale ng European. Ang mga tool na Ingles lamang ay nagmamarka ng malapit sa zero para sa mga format ng pambansang ID na hindi Ingles. Malinaw ang agwat. Maaaring mahuli ng isang tool ang 95% ng PII sa Ingles. Gayunman ay napapalalagpas nito ang 40-60% ng PII sa German, Pranses, Polish, o Dutch sa parehong file. Iyon ay isang seryosong problema. Nag-iwan ito ng mga kumpanya na nakalantad.

Ito ay isang tunay na agwat sa GDPR. Nakakaapekto ito sa halos bawat pandaigdigang kumpanyang gumagamit ng mga tool na nakasentro sa Ingles para sa redaksyon. Tingnan ang aming gabay sa GDPR para sa higit pa.

Bakit Partikular sa Locale ang PII

Ang pagtuklas ng PII ay may dalawang bahagi.

Ang una ay pag-scan batay sa pattern. Sumasaklaw ito sa mga structured na ID tulad ng mga numero ng buwis at mga format ng telepono.

Ang pangalawa ay pag-scan batay sa NER. Sumasaklaw ito sa mga contextual na entidad tulad ng mga pangalan at address.

Ang parehong bahagi ay depende sa locale.

Nag-iiba ang mga Structured ID ayon sa Bansa

BansaTax IDFormatValidation
GermanySteuer-ID11 digitModulo-11
FranceNIR15 digit + 2-digit na susiINSEE
SwedenPersonnummer10 digitLuhn
PolandPESEL11 digitModulo-10
NetherlandsBSN9 digitElfproef
SpainDNI/NIE8 digit + titikModulo-23
ItalyCodice Fiscale16 karakterCustom checksum

Ang isang Ingles-lamang na regex para sa mga SSN (NNN-NN-NNNN) ay hindi tugma sa alinman sa mga format na ito. Ang bawat isa ay nangangailangan ng sariling regex. Ang bawat isa ay nangangailangan din ng sariling lohika ng checksum.

Kailangan ng Native na Modelo ng NER

Nag-iiba ang mga pangalang Aleman mula sa mga Ingles. Ang "Hans-Dieter Muller" ay malinaw sa isang native na modelo ng Aleman. Madalas na napalampas ng modelo na sinanay sa Ingles ang mga ganitong pangalan.

Ang mga false positive ay isang problema rin. Ipinapakita ng issue tracker ng Microsoft Presidio ang mga salitang Aleman na maling inuuri bilang PII sa Ingles. Ang salitang "Null" (Aleman para sa "zero") ay isa sa mga halimbawa. Nagti-trigger ito ng mga maling hit ng pangalan sa mga modelo na sinanay sa Ingles. Sa produksyon, ang mga rate ng error ay nagpapalaki sa 3 false positive bawat tunay na entidad (Alvaro et al., 2024).

Panganib sa Regulasyon

Nakakaalam ang mga katawan ng datos ng EU sa problemang ito. Ilang pambansang DPA ang naglabas ng gabay.

German BfDI: Naaangkop ang GDPR Artikulo 5(1)(f) sa lahat ng rekord. Sumasaklaw ito sa datos na hindi Ingles na pinoproseso ng mga third-party na tool.

French CNIL: Ang 2024 CNIL Annual Report ay nagpahayag ng mga alalahanin. Nag-flag ito ng mga AI tool na humahawak ng mga rekord sa Pranses nang walang pag-scan ng PII sa French locale.

Mga DPA ng EU sa pangkalahatan: Nangangailangan ang GDPR Artikulo 25 (Privacy by Design) ng mga safeguard na angkop sa aktwal na mga rekord na pinoproseso. Kasama dito ang hindi Ingles na PII sa mga pandaigdigang deployment.

Malinaw ang panganib. Ang isang kumpanya ay maaaring magpakita ng 95% na pagtuklas ng PII sa nilalaman ng Ingles sa isang GDPR audit. Ngunit kung humahawak din ito ng mga rekord sa Aleman, Pranses, at Polish gamit ang parehong tool, lalabas ang mga agwat. Napapansin ng mga auditor. Maaaring sumunod ang mga multa. Tingnan ang aming pahina ng safeguard kung paano namin tinugunan ito.

Disenyo sa Tatlong Antas

Nagkakasundo ang pananaliksik at produksyon sa paggamit ng three-tier hybrid na disenyo bilang pinakamahusay na diskarte.

Antas 1: Mga Native na Modelo ng spaCy

Nagbibigay ang spaCy ng mga sinanay na modelo para sa 25 locale. Kasama dito ang Aleman, Pranses, Espanyol, Portuges, Italyano, Dutch, Ruso, Tsino, Hapon, Koreano, at Polish. Ang bawat modelo ay nagsasanay sa native na teksto. Natututo sila ng syntax at mga pattern ng entidad ng bawat locale. Mahalaga ito. Ang native na pagsasanay ay nangangahulugang mas mahusay na recall at mas kaunting false positive.

Para sa Aleman: de_core_news_lg ay humahawak ng mga tambalan na pangngalan at mga pattern ng pangalang Aleman. Para sa Pranses: fr_core_news_lg ay humahawak ng mga entidad sa Pranses, mga titulo, mga pangalan ng lugar, at mga organisasyon.

Ninalalampasan ng mga native na modelo ang mga cross-lingual na modelo para sa pag-scan ng pangalan sa mga high-resource na locale.

Antas 2: Stanza para sa Higit pang mga Locale

Sinasaklaw ng library ng Stanza ng Stanford ang mga locale na wala sa spaCy. Kasama dito ang Croatian, Slovenian, at Ukrainian. Nagdaragdag ito ng abot para sa mga grupo ng nagsasalita ng EU na hindi pinaglilingkuran ng spaCy. Ang Stanza ay libre at open source. Maayos itong nag-integrate sa natitirang bahagi ng stack.

Antas 3: XLM-RoBERTa para sa Malawak na Abot

Para sa mga locale kung saan wala ang mga modelo ng NER ng spaCy at Stanza, pinupunan ng XLM-RoBERTa ang agwat. Nagsasanay ito sa teksto ng Common Crawl sa 100 locale. Nakakamit nito ang 91.4% na cross-lingual na F1 para sa pagtuklas ng PII (HuggingFace 2024). Mahusay itong humahawak ng code-switching. Iyon ay isang pangunahing tampok. Mahalaga ito kapag ang isang dokumento ay nagtataglay ng teksto sa ilang locale nang sabay-sabay.

Bisitahin ang aming mga dokumento ng sistema ng token upang makita kung paano sumusukat ang mga tawag sa API sa multilingual na dami.

Mga Uri ng Entidad na Partikular sa Locale

Ang mga modelo lamang ay hindi sapat. Ang pagkahanay sa GDPR ay nangangailangan din ng saklaw ng uri ng entidad para sa mga ID na partikular sa bansa.

Mga Pambansang ID ng EU ayon sa bansa:

  • 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

Mga format ng telepono: Ang bawat bansa ng EU ay may natatanging mga istruktura ng prefix. Ang +49, +33, at +48 ay bawat isa ay nangangailangan ng sariling lohika ng validation.

Mga format ng address: Malawak ang pagkakaiba ng mga postal code. Ang German PLZ ay gumagamit ng 5 digit. Ang mga code sa Pranses ay gumagamit ng 5 digit (saklaw na 01-99). Ang mga postcode ng UK ay alphanumeric. Ang mga code ng Espanyol ay gumagamit ng 5 digit (01000-52999).

Totoong Mundo na Kaso: Swiss Pharma

Isang kumpanya ng Switzerland ang nagpoproseso ng mga kontrata sa trabaho. Ang bawat kontrata ay naghahalo ng teksto sa Aleman, Pranses, at Ingles. Ang Switzerland ay may apat na opisyal na wika. Ang kanilang tool ay naka-setup para sa Aleman lamang. Napalampas nito ang lahat ng PII sa seksyon ng Pranses.

Isang kontrata para sa isang empleyado na nakabase sa Geneva ay may kasamang isang French AVS number (13 digit), isang Swiss bank IBAN, at isang pangalan sa format ng Pranses. Napalampas ng tool na Aleman lamang ang pangalan sa format ng Pranses. Nabigo itong mahanap ang French AVS number. Bahagi lamang ang natukoy nitong IBAN.

Pinoproseso ng three-tier na diskarte ang buong dokumento. Nag-de-detect ito ng locale bawat segment ng teksto. Inilalapat nito ang tamang modelo ng NER para sa bawat bahagi. Bino-validate nito ang bawat pambansang ID gamit ang tamang lohika ng bansa.

Mga Dokumento na Halo ng Locale

Ang pinakamahirap na kaso ay ang intra-document na paghahalo ng locale. Mga halimbawa:

  • Isang kontrata ng Ingles ng kumpanyang Aleman na may mga rekord ng empleyadong Aleman (mga pangalan, tax ID)
  • Isang French GDPR consent form na may English privacy excerpt
  • Isang chat kung saan sumasagot ang ahente sa Ingles at sumusulat ang customer sa Arabe

Hinahawakan nito ang XLM-RoBERTa nang native. Hindi ito nangangailangan ng mga explicit na flag ng locale. Pinoproseso nito ang mixed-locale na teksto nang walang paunang segmentasyon. Nakatitipid ito ng oras. Iniiwasan din nito ang mga error mula sa mga maling paghahati.

Para sa produksyon, ang pagsasama ng auto locale detection (sa antas ng pangungusap) sa XLM-RoBERTa inference ay nagbibigay ng matibay na paghawak ng mga mixed-locale na dokumento.

Mga Praktikal na Hakbang

I-audit ang abot ng iyong tool. Hilingin sa iyong vendor ng redaksyon ang mga F1 score para sa iyong mga tiyak na locale. Ang "Sumusuporta sa 20 wika" ay madalas na nangangahulugang ang tool ay nagro-ruta ng teksto sa pamamagitan ng machine translation muna. Hindi iyon native na pag-scan.

Mapa ang iyong mga rekord sa mga locale. Gumawa ng imbentaryo ng mga rekord na may kasamang distribusyon ng locale. Ang isang pandaigdigang kumpanyang may 70% Ingles, 20% Aleman, at 10% Pranses ay nahaharap sa iba't ibang panganib. Ang isa na may 95% Ingles ay nasa ibang posisyon.

Subukan gamit ang mga sample ng pambansang ID. Bumuo ng test set na may 10 halimbawa ng mga pambansang ID sa iyong mga operasyon — Steuer-ID, NIR, PESEL, BSN, at iba pa. Beripikahin ang mga rate ng pagtuklas. Ito ay mas mabilis kaysa sa isang buong F1 test.

Suriin ang iyong mga DPIA. Suriin kung kasama ang saklaw ng locale. Maaaring kailangan ng update ng isang hindi kumpletong DPIA na inaakala ang mga rekord na Ingles lamang. Kumilos ngayon. Huwag maghintay ng isang audit upang mahanap ang agwat.

Para sa buong mga kahulugan ng uri ng entidad, tingnan ang sanggunian ng entidad at ang FAQ. Para sa mga plano at rate ng tawag ng API, bisitahin ang pagpepresyo.


Ang engine ng pagtuklas ng PII ng anonym.legal ay gumagamit ng tatlong-antas na multilingual na diskarte. Sumasaklaw ito sa 25 high-resource na locale sa pamamagitan ng mga native na modelo ng spaCy. Nagdaragdag ng karagdagang abot ng locale ang Stanza. Nagpapalawak ng saklaw ang mga XLM-RoBERTa cross-lingual transformer sa 48 locale. Kasama ang mga uri ng entidad na partikular sa bansa para sa lahat ng miyembro ng EU.

Mga Pinagmulan

Handa nang protektahan ang iyong data?

Simulan ang anonymization ng PII gamit ang 285+ uri ng entidad sa 48 wika.

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.