anonym.legal

By · Last updated 2026-03-03

Atpakaļ uz BloguGDPR un Atbilstība

Daudzvalodu personas datu noteikšana VDAR atbilstībai

Vācu Steuer-ID, franču NIR un zviedru Personnummer prasa atšķirīgu noteikšanas loģiku. Uzziniet, kā aptvert visas ES valodas personas datu noteikšanā.

March 3, 202610 min lasīšanai
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Daudzvalodu personas datu noteikšana VDAR atbilstībai

Atjaunināts 2026. gadam

Slēptā VDAR plaisa

VDAR nav valodas preferences. 4.(1) pants definē "personas datus" bez valodas nosaukšanas. Vācu Steuer-ID ir tikpat aizsargāta kā ASV sociālās apdrošināšanas numurs. Franču NIR ir tikpat regulēts kā Apvienotās Karalistes Nacionālās apdrošināšanas numurs.

Vairums personas datu noteikšanas rīku tika veidoti tikai angļu valodai.

ACL 2024 pētījums atklāja, ka hibrīdā NLP rīki sasniedz F1 rādītājus 0,60–0,83 Eiropas lokālām. Tikai angļu valodas rīki nacionālo ID formātiem neangliskā valodā iegūst gandrīz nulli. Atšķirība ir acīmredzama. Rīks var uztvert 95% angļu personas datu. Tomēr tas palaiž garām 40–60% vācu, franču, poļu vai nīderlandiešu personas datu tajā pašā failā. Tā ir nopietna problēma. Tā pakļauj uzņēmumus riskam.

Šī ir reāla VDAR plaisa. Tā skar gandrīz katru globālo uzņēmumu, kas izmanto angļu centriskus rediģēšanas rīkus. Skatiet mūsu VDAR rokasgrāmatu plašākai informācijai.

Kāpēc personas dati ir lokāli specifiski

Personas datu noteikšanai ir divas daļas.

Pirmā ir modeļu bāzēta skenēšana. Tā aptver strukturētos ID, piemēram, nodokļu numurus un tālruņa formātus.

Otrā ir NER bāzēta skenēšana. Tā aptver kontekstuālās entitātes, piemēram, vārdus un adreses.

Abas daļas ir atkarīgas no lokāles.

Strukturētie ID atšķiras pēc valsts

ValstsNodokļu IDFormātsValidācija
VācijaSteuer-ID11 cipariModulo-11
FrancijaNIR15 cipari + 2 ciparu atslēgaINSEE
ZviedrijaPersonnummer10 cipariLuhn
PolijaPESEL11 cipariModulo-10
NīderlandeBSN9 cipariElfproef
SpānijaDNI/NIE8 cipari + burtsModulo-23
ItālijaCodice Fiscale16 simboliPielāgota kontrolsumma

Tikai angļu valodas regex SSN (NNN-NN-NNNN) neatbildīs nevienam no šiem formātiem. Katram vajadzīgs savs regex. Katram arī vajadzīga sava kontrolsummas loģika.

NER vajadzīgi vietējie modeļi

Vācu vārdi atšķiras no angļu. "Hans-Dieter Muller" ir skaidrs vietējam vācu modelim. Angļu apmācīts modelis bieži palaiž garām šādus vārdus.

Viltus pozitīvie rezultāti arī ir problēma. Microsoft Presidio izsekošanas sistēma uzrāda vācu vārdus, kas tiek nepareizi klasificēti kā angļu personas dati. Vārds "Null" (vācu val.: nulle) ir viens piemērs. Tas izraisa viltus vārdu atbilsmes angļu apmācītos modeļos. Ražošanas izmantošanā kļūdu koeficients palielinās līdz 3 viltus pozitīviem uz katru reālo entitāti (Alvaro et al., 2024).

Regulatīvais risks

ES datu iestādes apzinās šo problēmu. Vairākas nacionālās DPA ir izdevušas norādījumus.

Vācu BfDI: VDAR 5.(1).(f) pants attiecas uz visiem ierakstiem. Tas aptver neangliskos datus, ko apstrādā trešo pušu rīki.

Franču CNIL: 2024. gada CNIL gada ziņojums izteica bažas. Tas atzīmēja AI rīkus, kas apstrādā franču ierakstus bez franču lokāles personas datu skenēšanas.

ES DPA kopumā: VDAR 25. pants (Privātums pēc dizaina) prasa aizsardzību, kas pielāgota faktiskajiem apstrādātajiem ierakstiem. Tas ietver neangliskos personas datus globālos izvietojumos.

Risks ir skaidrs. Uzņēmums VDAR auditā var parādīt 95% personas datu noteikšanu angļu saturā. Bet, ja tas arī apstrādā vācu, franču un poļu ierakstus ar to pašu rīku, parādīsies robi. Revizori pamanīs. Var sekot naudas sodi. Skatiet mūsu aizsardzības lapu, kā mēs to risinām.

Trīs līmeņu dizains

Pētījumi un ražošanas prakse vienojas par trīs līmeņu hibrīda dizainu kā labāko pieeju.

1. līmenis: Vietējie spaCy modeļi

spaCy nodrošina apmācītus modeļus 25 lokālām. Tie ietver vācu, franču, spāņu, portugāļu, itāļu, nīderlandiešu, krievu, ķīniešu, japāņu, korejiešu un poļu valodu. Katrs modelis apmācīts uz vietējo tekstu. Tie mācās katras lokāles sintakses un entitāšu modeļus. Tas ir svarīgi. Vietējā apmācība nozīmē labāku atsaukumu un mazāk viltus pozitīvo.

Vācu valodai: de_core_news_lg apstrādā salikteņus un vācu vārdu modeļus. Franču valodai: fr_core_news_lg apstrādā franču entitātes, titulus, vietu nosaukumus un organizācijas.

Vietējie modeļi pārspēj starptautiskos modeļus vārdu skenēšanai augstas resursu lokālās.

2. līmenis: Stanza vairāk lokālēm

Stanford Stanza bibliotēka aptver lokāles, kuras nav spaCy. Tās ietver horvātu, slovēniešu un ukraiņu valodu. Tas palielina piekļuvi ES runātāju grupām, ko spaCy neapkalpo. Stanza ir bezmaksas un atvērtā koda. Tā labi integrējas ar pārējo komplektu.

3. līmenis: XLM-RoBERTa plašākai piekļuvei

Lokālēm, kur spaCy un Stanza trūkst NER modeļu, XLM-RoBERTa aizpilda plaisu. Tas apmācīts uz Common Crawl tekstu 100 lokālās. Tas sasniedz 91,4% starptautisko F1 personas datu noteikšanai (HuggingFace 2024). Tas labi apstrādā kodu maiņu. Tā ir galvenā funkcija. Tas svarīgi, kad viens dokuments satur tekstu vairākās lokālās vienlaikus.

Apmeklējiet mūsu tokenu sistēmas dokumentus, lai uzzinātu, kā API zvani mērogojas ar daudzvalodu apjomu.

Lokālei specifiskie entitāšu tipi

Modeļi vien nav pietiekami. VDAR saskaņošanai arī vajadzīgs entitāšu tipa tvērums valstij specifiskiem ID.

ES nacionālie ID pēc valsts:

  • 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

Tālruņa formāti: Katrai ES valstij ir unikālas prefiksa struktūras. +49, +33 un +48 katram vajadzīga sava validācijas loģika.

Adrešu formāti: Pasta kodi ļoti atšķiras. Vācu PLZ izmanto 5 ciparus. Franču kodi izmanto 5 ciparus (01–99 diapazons). Apvienotās Karalistes pasta kodi ir burtciparisks. Spāņu kodi izmanto 5 ciparus (01000–52999).

Reālās pasaules gadījums: Šveices farmācijas uzņēmums

Šveices uzņēmums apstrādā darba līgumus. Katrs līgums sajauc vācu, franču un angļu tekstu. Šveicē ir četras oficiālās valodas. Viņu rīks bija iestatīts tikai vācu valodai. Tas palaidīs garām visus franču sekciju personas datus.

Īenēvas bāzēta darbinieka līgums ietvēra franču AVS numuru (13 cipari), Šveices bankas IBAN un vārdu franču formātā. Tikai vācu rīks palaidīs garām franču formāta vārdu. Tas neatradīs franču AVS numuru. Tas tikai daļēji noteiks IBAN.

Trīs līmeņu pieeja apstrādā visu dokumentu. Tā nosaka lokāli katrā teksta segmentā. Tā piemēro pareizo NER modeli katrai daļai. Tā validē katru nacionālo ID ar pareizo valsts loģiku.

Jauktas lokāles dokumenti

Vissarežģītākais gadījums ir dokumenta iekšienē esošā lokāļu maiņa. Piemēri:

  • Vācu uzņēmuma angļu līgums ar vācu darbinieku ierakstiem (vārdi, nodokļu ID)
  • Franču VDAR piekrišanas veidlapa ar angļu privātuma fragmentu
  • Tērzēšana, kurā aģents atbild angliski un klients raksta arābiski

XLM-RoBERTa to apstrādā dabiski. Tam nav vajadzīgu skaidru lokāles atzīmju. Tas apstrādā jauktas lokāles tekstu bez iepriekšējas segmentācijas. Tas ietaupa laiku. Tas arī izvairās no kļūdām no nepareizas dalīšanas.

Ražošanas izmantošanai, apvienojot automātisko lokāles noteikšanu (teikuma līmenī) ar XLM-RoBERTa secinājumiem, tiek nodrošināta stabila jauktas lokāles dokumentu apstrāde.

Praktiskie soļi

Auditējiet sava rīka tvērumu. Jautājiet savam rediģēšanas pārdevējam par F1 rādītājiem jūsu specifiskajām lokālēm. "Atbalsta 20 valodas" bieži nozīmē, ka rīks vispirms nosūta tekstu caur mašīntulkošanu. Tā nav vietējā skenēšana.

Kartējiet savus ierakstus uz lokālēm. Veiciet ierakstu inventarizāciju, kas ietver lokāļu sadalījumu. Globāls uzņēmums ar 70% angļu, 20% vācu un 10% franču saskaras ar atšķirīgiem riskiem. Viens ar 95% angļu ir atšķirīgā pozīcijā.

Testējiet ar nacionālo ID paraugiem. Veidojiet testa kopu ar 10 nacionālo ID piemēriem jūsu darbībā — Steuer-ID, NIR, PESEL, BSN un citiem. Pārbaudiet noteikšanas koeficientus. Tas ir ātrāk nekā pilns F1 tests.

Pārskatiet savus DPIA. Pārbaudiet, vai lokāles tvērums ir iekļauts. Nepilnīgs DPIA, kas pieņem tikai angļu valodas ierakstus, var prasīt atjauninājumu. Rīkojieties tagad. Negaidiet, kamēr audits atklāj plaisu.

Pilnām entitāšu tipa definīcijām skatiet entitāšu atsauci un BUJ. Plāniem un API zvanu koeficientiem apmeklējiet cenas.

anonym.legal personas datu noteikšanas dzinējs izmanto trīs līmeņu daudzvalodu pieeju. Tas aptver 25 augstas resursu lokāles caur vietējiem spaCy modeļiem. Stanza pievieno papildu lokāles tvērumu. XLM-RoBERTa starptautiskie transformatoru modeļi paplašina tvērumu līdz 48 lokālēm. Valstij specifiskie entitāšu tipi visām ES dalībvalstīm ir iekļauti.

Avoti

Saistītie Raksti

GDPR un Atbilstība

Japan My Number: Verhoeff & APPI

63% of generic tools fail My Number detection in Japanese documents. My Number uses Verhoeff algorithm — the most complex national ID checksum in Asia.

GDPR un Atbilstība

HDPA Greece: AFM & AMKA Detection

Greek AFM detected with 52% accuracy by generic tools. HDPA issued 89 decisions in 2024 — up 162% from 2022. Tourism and maritime sectors face distinct.

GDPR un Atbilstība

NAIH Hungary: TAJ-Szám and Adóazonosító Jel

Hungarian NER accuracy is 67% vs. EU average 82% — NAIH's 2024 assessment. TAJ-szám weighted checksum and adóazonosító jel detection gaps.

Vai esat gatavi aizsargāt savus datus?

Sāciet PII anonimizāciju ar 285+ entitāšu veidiem 48 valodās.

Sākt Bezmaksas IzmēģinājumuSkatīt Funkcijas

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.