By · Last updated 2026-03-03

Tillbaka till BloggenGDPR & Efterlevnad

Flerspråkig PII-detektering för GDPR-efterlevnad

Ett tyskt Steuer-ID, ett franskt NIR och ett svenskt personnummer kräver alla olika detekteringslogik.

March 3, 202610 min läsning
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

Flerspråkig PII-detektering för GDPR

Uppdaterad för 2026

Det dolda GDPR-gapet

GDPR har ingen språkpreferens. Artikel 4(1) definierar "personuppgifter" utan att namnge det språk de förekommer på. Ett tyskt Steuer-ID är lika skyddat som ett amerikanskt personnummer. Ett franskt NIR är lika reglerat som ett brittiskt National Insurance-nummer.

De flesta PII-detekteringsverktyg byggdes för engelska.

Forskning från ACL 2024 visade att hybrida NLP-verktyg når F1-poäng på 0,60–0,83 för europeiska lokaler. Engelska-only-verktyg når nära noll för icke-engelska nationella ID-format. Gapet är tydligt. Ett verktyg kan fånga 95% av engelska PII. Men det missar 40–60% av tyska, franska, polska eller nederländska PII i samma fil. Det är ett allvarligt problem. Det lämnar företag exponerade.

Detta är ett verkligt GDPR-gap. Det påverkar nästan varje globalt företag som använder engelskcentrerade redaktionsverktyg. Se vår GDPR-guide för mer.

Varför PII är lokalespecifikt

PII-detektering har två delar.

Den första är mönsterbaserad skanning. Det täcker strukturerade ID:n som skattenummer och telefonformat.

Den andra är NER-baserad skanning. Det täcker kontextuella entiteter som namn och adresser.

Båda delarna beror på lokalen.

Strukturerade ID:n skiljer sig per land

LandSkatte-IDFormatValidering
TysklandSteuer-ID11 siffrorModulo-11
FrankrikeNIR15 siffror + 2-siffrig nyckelINSEE
SverigePersonnummer10 siffrorLuhn
PolenPESEL11 siffrorModulo-10
NederländernaBSN9 siffrorElfproef
SpanienDNI/NIE8 siffror + bokstavModulo-23
ItalienCodice Fiscale16 teckenAnpassad kontrollsumma

Ett engelskt regex för SSN (NNN-NN-NNNN) matchar inget av dessa format. Vart och ett behöver sitt eget regex. Vart och ett behöver också sin egen kontrollsummelogik.

NER behöver inbyggda modeller

Tyska namn skiljer sig från engelska. "Hans-Dieter Müller" är tydligt för en infödd tysk modell. En modell tränad på engelska missar ofta sådana namn.

Falska positiver är också ett problem. Microsoft Presidio:s ärendelogg visar att tyska ord felklassificeras som engelsk PII. Ordet "Null" (tyska för "noll") är ett exempel. Det utlöser falska namnträffar i modeller tränade på engelska. I produktionsanvändning blåser felfrekvensen upp till 3 falska positiver per verklig entitet (Alvaro et al., 2024).

Regulatorisk risk

EU:s dataskyddsorgan är medvetna om detta problem. Flera nationella DPA:er har utfärdat vägledning.

Tyskt BfDI: GDPR Artikel 5(1)(f) gäller för alla uppgifter. Det täcker icke-engelska data som bearbetas av tredjepartsverktyg.

Franska CNIL: 2024 CNIL-årsrapporten lyfte fram problem. Den flaggade AI-verktyg som hanterar franska uppgifter utan franska lokala PII-skanningar.

EU:s DPA:er generellt: GDPR Artikel 25 (Privacy by Design) kräver skyddsåtgärder som är lämpade för de faktiska uppgifter som bearbetas. Det inkluderar icke-engelska PII i globala driftsättningar.

Risken är tydlig. Ett företag kan visa 95% PII-detektering på engelskt innehåll i en GDPR-revision. Men om det också hanterar tyska, franska och polska uppgifter med samma verktyg, uppstår luckor. Revisorer märker det. Böter kan följa. Se vår skyddsåtgärdssida för hur vi hanterar detta.

Trelagers design

Forskning och produktionsanvändning är ense om en trelagers hybriddesign som den bästa metoden.

Lager 1: Inbyggda spaCy-modeller

spaCy tillhandahåller tränade modeller för 25 lokaler. Dessa inkluderar tyska, franska, spanska, portugisiska, italienska, holländska, ryska, kinesiska, japanska, koreanska och polska. Varje modell tränar på inbyggd text. De lär sig syntaxen och entitetsmönstren för varje lokal. Det spelar roll. Inbyggd träning innebär bättre recall och färre falska positiver.

För tyska: `de_core_news_lg` hanterar sammansatta substantiv och tyska namnmönster. För franska: `fr_core_news_lg` hanterar franska entiteter, titlar, ortnamn och organisationer.

Inbyggda modeller slår korslingvistiska modeller för namnigenkänning på resursstarka lokaler.

Lager 2: Stanza för fler lokaler

Stanfords Stanza-bibliotek täcker lokaler som inte finns i spaCy. Dessa inkluderar kroatiska, slovenska och ukrainska. Det utökar räckvidden för EU-språkgrupper som spaCy inte betjänar. Stanza är gratis och öppen källkod. Det integreras väl med resten av stacken.

Lager 3: XLM-RoBERTa för bred räckvidd

För lokaler där spaCy och Stanza saknar NER-modeller fyller XLM-RoBERTa gapet. Det tränar på Common Crawl-text över 100 lokaler. Det uppnår 91,4% korslingvistisk F1 för PII-detektering (HuggingFace 2024). Det hanterar kodväxling bra. Det är en nyckelfunktion. Det spelar roll när ett dokument innehåller text på flera lokaler samtidigt.

Besök våra tokensystem-dokument för att se hur API-anrop skalas med flerspråkig volym.

Lokalespecifika entitetstyper

Modeller ensamma räcker inte. GDPR-anpassning kräver också entitetstypomfång för landsspecifika ID:n.

EU:s nationella ID:n per land:

  • 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

Telefonformat: Varje EU-land har unika prefixstrukturer. +49, +33 och +48 behöver var sin valideringslogik.

Adressformat: Postnummer varierar mycket. Tyskt PLZ använder 5 siffror. Franska koder använder 5 siffror (01–99-intervall). Brittiska postnummer är alfanumeriska. Spanska koder använder 5 siffror (01000–52999).

Verkligt fall: Schweiziskt läkemedelsföretag

Ett schweiziskt företag bearbetar anställningsavtal. Varje avtal blandar tyska, franska och engelska texter. Schweiz har fyra officiella språk. Deras verktyg var konfigurerat för tyska. Det missade all PII i franska avsnitt.

Ett avtal för en Genèvebaserad anställd inkluderade ett franskt AVS-nummer (13 siffror), ett schweiziskt bank-IBAN och ett namn i franskt format. Det tyska-only-verktyget missade det franskformaterade namnet. Det misslyckades med att hitta det franska AVS-numret. Det detekterade bara delvis IBAN.

Trelagersmetoden bearbetar hela dokumentet. Den detekterar lokal per textsegment. Den applicerar rätt NER-modell för varje del. Den validerar varje nationellt ID med rätt landlogik.

Dokument med blandade lokaler

Det svåraste fallet är blandning av lokaler inom ett dokument. Exempel:

  • Ett tyskt företags engelska kontrakt med tyska anställdas uppgifter (namn, skatte-ID:n)
  • Ett franskt GDPR-samtyckesformulär med ett engelskt integritetsutdrag
  • En chatt där agenten svarar på engelska och kunden skriver på arabiska

XLM-RoBERTa hanterar detta inbyggt. Det behöver inga explicita lokalflaggor. Det bearbetar text med blandade lokaler utan föregående segmentering. Det sparar tid. Det undviker också fel från felaktiga uppdelningar.

För produktionsanvändning ger kombinationen av auto-lokaldetektering (på meningsnivå) med XLM-RoBERTa-inferens robust hantering av dokument med blandade lokaler.

Praktiska steg

Granska ditt verktygs räckvidd. Fråga din redaktionsleverantör om F1-poäng för dina specifika lokaler. "Stöder 20 språk" innebär ofta att verktyget leder text genom maskinöversättning först. Det är inte inbyggd skanning.

Kartlägg dina uppgifter till lokaler. Gör en uppgiftsinventering som inkluderar lokalfördelning. Ett globalt företag med 70% engelska, 20% tyska och 10% franska möter olika risker. Ett med 95% engelska befinner sig i en annan position.

Testa med nationella ID-prov. Bygg en testuppsättning med 10 exempel på de nationella ID:n i din verksamhet — Steuer-ID, NIR, PESEL, BSN och andra. Verifiera detekteringsfrekvenser. Det är snabbare än ett fullständigt F1-test.

Granska dina DPIA:er. Kontrollera om lokala omfånget ingår. En ofullständig DPIA som antar engelska-only-uppgifter kan behöva uppdateras. Agera nu. Vänta inte på att en revision hittar gapet.

För fullständiga entitetstypsdefinitioner, se entitetsreferensen och FAQ. För planer och API-anropsfrekvenser, besök prissättning.


anonym.legal:s PII-detekteringsmotor använder ett trelagers flerspråkigt tillvägagångssätt. Det täcker 25 resursstarka lokaler via inbyggda spaCy-modeller. Stanza lägger till extra lokalräckvidd. XLM-RoBERTa korslingvistiska transformers utökar omfånget till 48 lokaler. Landsspecifika entitetstyper för alla EU-medlemsstater ingår.

Källor

Redo att skydda din data?

Börja anonymisera PII med 285+ entitetstyper på 48 språk.

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.