By · Last updated 2026-04-01

Torna al BlogTecnico

PII in arabo e in ebraico: gli strumenti occidentali non bastano

Il GDPR non si ferma al Bosforo. I dati personali in arabo ed ebraico nei flussi di lavoro aziendali europei sono sistematicamente privi di protezione. Il rilevamento cross-linguistico basato su XLM-RoBERTa e.

April 1, 20268 min di lettura
Arabic PII detectionHebrew NERRTL text processingMENA GDPR complianceXLM-RoBERTa multilingual

Il divario di conformità per le scritture da destra a sinistra

Il GDPR non si ferma al Bosforo. Le aziende europee che utilizzano strumenti orientati alla scrittura latina hanno un punto cieco. È reale ed è in larga misura ignorato.

Il problema non riguarda solo la direzione del testo. Le scritture da destra a sinistra richiedono una tokenizzazione diversa e una segmentazione diversa. I confini delle entità funzionano in modo differente rispetto al testo da sinistra a destra. I sistemi NER addestrati sull'inglese applicano regole LTR che si rompono sul testo RTL, generando confini di entità errati.

La morfologia araba complica ulteriormente le cose. La lingua si basa su radici: da una singola radice derivano decine di forme. Un nome come Mohammed può comparire come "Al-Mohammed", "bin Mohammed" o "Mohammed al-Rashid". I pattern regex costruiti per nomi occidentali mancano queste varianti, e lo stesso vale per i modelli addestrati sull'inglese.

Il GDPR non considera la lingua come un confine di conformità. Un'azienda europea che elabora corrispondenza di clienti della regione MENA deve rispettare le stesse regole applicabili alla posta in francese. Non rilevare i dati personali in testo RTL è un'inadempienza giuridica ai sensi dell'Articolo 32 del GDPR.

Il caso d'uso KYC

Una fintech di Dubai che elabora documenti KYC per clienti europei illustra chiaramente il problema.

I fascicoli KYC per i clienti arabi contengono nomi in scrittura RTL, Emirates ID degli EAU e indirizzi RTL, affiancati a testo aziendale in inglese.

Il formato dell'Emirates ID è 784-XXXX-XXXXXXX-X: codice paese 784, anno di nascita, sette cifre, cifra di controllo. Gli strumenti occidentali privi di definizioni di entità per gli EAU non riescono a individuare questo formato. I campi nome vengono elaborati da sistemi NER orientati alla scrittura latina, con una segmentazione errata. Il risultato: i dati personali diventano invisibili nel flusso di lavoro.

Per le aziende con obblighi GDPR su questi dati, il divario crea un rischio giuridico concreto. L'Articolo 32 del GDPR richiede misure tecniche adeguate. Uno strumento che manca gli identificatori nel 22% delle lingue del mondo non può essere considerato una misura adeguata.

L'ebraico e i documenti multilingue

L'ebraico presenta problemi analoghi. La scrittura procede da destra a sinistra. I numeri di identificazione israeliani utilizzano un checksum — un test simile a Luhn su nove cifre.

I documenti legali israeliani spesso combinano ebraico, testo in scrittura araba e inglese in un unico file. È una situazione comune nei contratti in cui l'ebraico è la lingua principale e i termini inglesi sono incorporati per riferimento.

I file con scritture miste richiedono il rilevamento dello script prima del passaggio NER. Senza di esso, un singolo passaggio NER applica le regole latine alle scritture RTL, producendo output errati.

Una ricerca pubblicata su Nature Scientific Reports (2025) ha testato sistemi NER cross-linguistici su dati PII RTL. I modelli standard hanno ottenuto un F1 compreso tra 0,60 e 0,83. XLM-RoBERTa ottimizzato su dati NER RTL ha raggiunto 0,88 e oltre.

Il requisito architetturale cross-linguistico

Un rilevamento efficace dei dati personali RTL richiede tre componenti che gli strumenti orientati al mondo occidentale solitamente non possiedono.

Gestione del testo RTL: conformità Unicode bidirezionale per il corretto flusso del testo, con tokenizzazione RTL-aware in grado di identificare i confini delle parole nelle scritture da destra a sinistra.

NER con consapevolezza morfologica: un analizzatore morfologico come Farasa per l'arabo, o un modello transformer ottimizzato su dati NER RTL, che abbia appreso le variazioni morfologiche.

Tipi di entità specifici per regione: Emirates ID, numero di identificazione israeliano, Saudi National ID ed Egyptian National ID richiedono ciascuno definizioni esplicite con regole di formato. Gli strumenti occidentali generici non li includono.

Scopri come la nostra pipeline NER multilingue gestisce il rilevamento degli script in 48 lingue. Per l'elenco completo dei tipi di identificatori MENA supportati, visita il catalogo entità. La nostra guida alla conformità GDPR illustra come le lacune nel rilevamento creino esposizione ai sensi dell'Articolo 32.

Fonti

Pronto a proteggere i tuoi dati?

Inizia ad anonimizzare i PII con oltre 285 tipi di entità in 48 lingue.

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.