By · Last updated 2026-03-03

Atgal į BlogąGDPR ir Atitiktis

Daugiakalbis ADA aptikimas BDAR atitikčiai

Vokietijos Steuer-ID, Prancūzijos NIR ir Švedijos Personnummer reikia skirtingos aptikimo logikos.

March 3, 202610 min skaityti
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Daugiakalbis ADA aptikimas BDAR atitikčiai

Atnaujinta 2026 m.

Paslėpta BDAR spraga

BDAR neturi kalbos nuostatos. 4 straipsnio 1 dalis apibrėžia "asmens duomenis" nenurodydama, kuria kalba jie parašyti. Vokietijos Steuer-ID yra taip pat apsaugota kaip JAV socialinio draudimo numeris. Prancūzijos NIR yra taip pat reglamentuota kaip JK Nacionalinio draudimo numeris.

Dauguma ADA aptikimo įrankių buvo sukurti tik anglų kalbai.

ACL 2024 tyrimas nustatė, kad hibridiniai NLP įrankiai pasiekia F1 balus 0,60–0,83 Europos vietovėms. Tik anglų kalbos įrankiai ne angliškų nacionalinių ID formatams gauna balus artimus nuliui. Spraga yra akivaizdi. Įrankis gali aptikti 95 % anglų kalbos ADA. Tačiau tame pačiame faile jis praleidžia 40–60 % vokiečių, prancūzų, lenkų ar olandų ADA. Tai rimta problema. Ji palieka įmones pažeidžiamas.

Tai tikra BDAR spraga. Ji veikia beveik kiekvieną pasaulinę įmonę, naudojančią tik anglų kalbos redagavimo įrankius. Žr. mūsų BDAR vadovą dėl daugiau informacijos.

Kodėl ADA yra vietovei specifinė

ADA aptikimas turi dvi dalis.

Pirmoji yra šablonu pagrįstas skenavimas. Tai apima struktūrizuotus ID, kaip mokesčių numeriai ir telefono formatai.

Antroji yra NER pagrįstas skenavimas. Tai apima kontekstines esybes, kaip vardai ir adresai.

Abi dalys priklauso nuo vietovės.

Struktūrizuoti ID skiriasi pagal šalį

ŠalisMokesčių IDFormatasPatvirtinimas
VokietijaSteuer-ID11 skaitmenųModulo-11
PrancūzijaNIR15 skaitmenų + 2 skaitmens raktasINSEE
ŠvedijaPersonnummer10 skaitmenųLuhn
LenkijaPESEL11 skaitmenųModulo-10
NyderlandaiBSN9 skaitmenųElfproef
IspanijaDNI/NIE8 skaitmenų + raidėModulo-23
ItalijaCodice Fiscale16 simboliųPasirinktinis kontrolinis suma

Tik anglų kalbos regex SSN (NNN-NN-NNNN) nesutaps su nė vienu iš šių formatų. Kiekvienas reikalauja savo regex. Kiekvienas taip pat reikalauja savo kontrolinės sumos logikos.

NER reikia vietinių modelių

Vokiški vardai skiriasi nuo angliškų. "Hans-Dieter Müller" yra aiškus vietiniam vokiečių modeliui. Anglų kalba apmokytas modelis dažnai praleidžia tokius vardus.

Klaidingai teigiami rezultatai taip pat yra problema. Microsoft Presidio problemų sekiklis rodo, kad vokiški žodžiai yra neteisingai klasifikuojami kaip angliška ADA. Žodis "Null" (vokiškai "nulis") yra vienas pavyzdys. Jis sukelia klaidingus vardų paspaudimus anglų kalba apmokytuose modeliuose. Gamybiniam naudojimui klaidų rodikliai infliuojasi iki 3 klaidingai teigiamų kiekvienai tikrai esybei (Alvaro ir kt., 2024).

Reguliavimo rizika

ES duomenų apsaugos institucijos žino apie šią problemą. Kelios nacionalinės DPA išleido gaires.

Vokietijos BfDI: BDAR 5 straipsnio 1 dalies f punktas taikomas visiems įrašams. Jis apima ne angliškus duomenis, apdorojamus trečiųjų šalių įrankiais.

Prancūzijos CNIL: 2024 m. CNIL metinė ataskaita iškėlė susirūpinimą. Ji atkreipė dėmesį į AI įrankius, tvarkančius prancūziškus įrašus be prancūziškos vietovės ADA skenavimo.

ES DPA apskritai: BDAR 25 straipsnis (Privatumas pagal dizainą) reikalauja apsaugų, tinkamų faktiškai apdorojamiems įrašams. Tai apima ne angliška ADA pasaulinėse diegtyse.

Rizika aiški. Įmonė BDAR audito metu gali parodyti 95 % ADA aptikimą angliškame turinyje. Tačiau jei ji taip pat tvarko vokiškus, prancūziškus ir lenkiškus įrašus tuo pačiu įrankiu, spragos atsiras. Auditoriai pastebi. Baudos gali sekti. Žr. mūsų apsaugų puslapį, kaip mes tai sprendžiame.

Trijų pakopų dizainas

Tyrimai ir gamybinis naudojimas sutaria dėl trijų pakopų hibridinio dizaino kaip geriausio metodo.

1 pakopa: vietiniai spaCy modeliai

spaCy teikia apmokytas modelius 25 vietovėms. Tai apima vokiečių, prancūzų, ispanų, portugalų, italų, olandų, rusų, kinų, japonų, korėjiečių ir lenkų kalbas. Kiekvienas modelis mokosi iš vietinio teksto. Jie mokosi kiekvienos vietovės sintaksės ir esybių šablonų. Tai svarbu. Vietinis mokymas reiškia geresnį atsaukimą ir mažiau klaidingai teigiamų.

Vokiečių kalbai: de_core_news_lg tvarko sudėtinius žodžius ir vokiškus vardų šablonus. Prancūzų kalbai: fr_core_news_lg tvarko prancūziškus objektus, titulus, vietovardžius ir organizacijas.

Vietiniai modeliai lenkia kryžmines kalbų modelius vardų skenavimui didelio išteklių vietovėse.

2 pakopa: Stanza daugiau vietovėms

Stanfordo Stanza biblioteka apima vietoves, kurių nėra spaCy. Tai apima kroatų, slovėnų ir ukrainiečių kalbas. Tai padidina aprėptį ES kalbų grupėms, kurių spaCy netarnauja. Stanza yra nemokama ir atvirojo kodo. Ji gerai integruojasi su likusiu dėklu.

3 pakopa: XLM-RoBERTa platesnei aprėpčiai

Vietovėms, kur spaCy ir Stanza trūksta NER modelių, XLM-RoBERTa užpildo spragą. Ji mokosi iš Common Crawl teksto 100 vietovių. Ji pasiekia 91,4 % kryžminių kalbų F1 ADA aptikimui (HuggingFace 2024). Ji gerai tvarko kodo persijungimą. Tai pagrindinė savybė. Ji svarbi, kai vienas dokumentas turi tekstą keliomis vietovėmis vienu metu.

Apsilankykite mūsų tokenų sistemos dokumentuose, kaip API skambučiai auga su daugiakalbiu tūriu.

Vietovei specifiniai esybių tipai

Modelių vienų nepakanka. BDAR derinimas taip pat reikalauja esybių tipo apimties šaliai skirtų ID.

ES nacionaliniai ID pagal šalį:

  • 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

Telefono formatai: kiekviena ES šalis turi unikalias prefiksų struktūras. +49, +33 ir +48 kiekvienas reikalauja savo patvirtinimo logikos.

Adresų formatai: pašto kodai labai skiriasi. Vokiškas PLZ naudoja 5 skaitmenis. Prancūziški kodai naudoja 5 skaitmenis (01–99 diapazonas). JK pašto kodai yra raidiniai-skaitmeniniai. Ispaniški kodai naudoja 5 skaitmenis (01000–52999).

Realaus pasaulio atvejis: Šveicarijos farmacijos įmonė

Šveicarijos įmonė apdoroja darbo sutartis. Kiekvienoje sutartyje maišomas vokiškas, prancūziškas ir angliškas tekstas. Šveicarijoje yra keturios oficialios kalbos. Jų įrankis buvo sukonfigūruotas tik vokiečių kalbai. Jis praleido visą prancūziškos sekcijos ADA.

Ženevoje gyvenančio darbuotojo sutartyje buvo prancūziškas AVS numeris (13 skaitmenų), Šveicarijos banko IBAN ir prancūziško formato vardas. Tik vokiečių kalbos įrankis praleido prancūziško formato vardą. Jam nepavyko rasti prancūziško AVS numerio. Jis tik iš dalies aptiko IBAN.

Trijų pakopų metodas apdoroja visą dokumentą. Jis aptinka vietovę kiekvienam teksto segmentui. Jis taiko tinkamą NER modelį kiekvienai daliai. Jis patvirtina kiekvieną nacionalinį ID su teisinga šalies logika.

Mišrių vietovių dokumentai

Sunkiausias atvejis yra vidinis dokumentinis vietovių maišymas. Pavyzdžiai:

  • Vokiečių įmonės angliškas kontraktas su vokiškais darbuotojų įrašais (vardai, mokesčių ID)
  • Prancūziškas BDAR sutikimo forma su angliška privatumo ištrauka
  • Pokalbis, kur agentas atsako angliškai, o klientas rašo arabiškai

XLM-RoBERTa tai tvarko vietiškai. Jai nereikia aiškių vietovės žymių. Ji apdoroja mišrių vietovių tekstą be išankstinės segmentacijos. Tai taupo laiką. Tai taip pat išvengia klaidų nuo neteisingų pjūvių.

Gamybiniam naudojimui derinant automatinį vietovės aptikimą (sakinio lygyje) su XLM-RoBERTa išvada gaunamas tvirtas mišrių vietovių dokumentų tvarkymas.

Praktiniai žingsniai

Audituokite savo įrankio aprėptį. Paklauskite savo redagavimo tiekėjo F1 balų jūsų konkrečioms vietovėms. "Palaiko 20 kalbų" dažnai reiškia, kad įrankis pirmiausia nukreipia tekstą per mašininį vertimą. Tai nėra vietinis skenavimas.

Sudarykite žemėlapį, kur yra jūsų įrašai. Atlikite įrašų inventorizaciją, apimančią vietovės pasiskirstymą. Pasaulinė įmonė su 70 % anglišku, 20 % vokišku ir 10 % prancūzišku tekstu susiduria su skirtingomis rizikomis. Ta, kuriai yra 95 % anglų, yra skirtingoje padėtyje.

Testuokite su nacionalinių ID pavyzdžiais. Sukurkite testų rinkinį su 10 jūsų veikloje naudojamų nacionalinių ID pavyzdžių – Steuer-ID, NIR, PESEL, BSN ir kt. Patikrinkite aptikimo rodiklius. Tai greičiau nei visas F1 testas.

Peržiūrėkite savo DPIA. Patikrinkite, ar vietovės apimtis yra įtraukta. Neišsami DPIA, darant prielaidą tik apie anglų kalbos įrašus, gali reikalauti atnaujinimo. Veikite dabar. Nelaukite, kol auditas ras spragą.

Dėl visų esybių tipų apibrėžimų žr. esybių nuorodą ir DUK. Dėl planų ir API skambučių rodiklių apsilankykite kainyne.


anonym.legal ADA aptikimo variklis naudoja trijų pakopų daugiakalbį metodą. Jis apima 25 didelio išteklių vietoves per vietinius spaCy modelius. Stanza prideda papildomą vietovės aprėptį. XLM-RoBERTa kryžminių kalbų transformeriai praplečia aprėptį iki 48 vietovių. Šaliai skirti esybių tipai visiems ES valstybėms narėms yra įtraukti.

Šaltiniai

Pasiruošę apsaugoti savo duomenis?

Pradėkite anonimizuoti PII su 285+ subjektų tipais 48 kalbomis.

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.