Protecto Vault Apr’ 26 Release: Multilingual Sensitive Data Detection
A privacy policy that only works in English is not a global privacy policy. It is an English-language policy that a global company happens to be using. That distinction matters more than most teams realize. Enterprises now centralize contracts, HR files, healthcare records, and support conversations from regional offices around the world into a shared AI platform, often assuming that whatever detection and masking logic works for their English-language content will work everywhere else. It does not. The gap tends to surface after data has already moved through a workflow that was never designed to handle it.
Where English-first detection breaks down
Most PII detection was built and tuned against English text first, reflecting where the majority of training data and early enterprise demand originated. That was a practical starting point, not a wrong one. But an HR record written in German, a customer complaint filed in French, a medical note in Spanish, a banking form in Arabic, or a support ticket in Japanese doesn’t announce itself as different to a detection pipeline that was never built to recognize it. It gets processed. It gets missed.
The result is protection that tracks language, not risk. A multinational’s US or UK offices might have complete entity coverage. The same category of sensitive data like employee names, financial details, and medical information moves into AI systems unmasked from offices in Germany, France, Spain, the Netherlands, the Gulf region, or Japan, simply because detection was never trained to catch it in those languages. Risk does not change based on which office a document came from.
What this release adds
The newest update extends Vault’s Mask and Unmask APIs to support seven languages: English, German, French, Spanish, Dutch, Arabic, and Japanese.
| Language | Typical source documents |
| English | Global default: contracts, support tickets, HR records |
| German | DACH-region HR, procurement, and legal documents |
| French | France, Belgium, and Francophone office records |
| Spanish | LatAm and Iberian customer and healthcare documents |
| Dutch | Benelux HR, finance, and internal communications |
| Arabic | Gulf and MENA-region customer, legal, and financial records |
| Japanese | Japan-based HR, finance, and customer support records |
The Mask and Unmask APIs now support all seven languages, allowing teams to apply the same masking workflows directly to native-language content. Teams no longer need to pre-translate documents before running them through the detection pipeline. The pipeline handles the native language directly, including non-Latin scripts like Arabic and Japanese.
Two additional entities are also part of this update: NATIONAL_ID and PASSWORD. CITY, COUNTRY, and PINCODE are now available as derived sub-entities extracted from the existing ADDRESS entity, providing more granular location data without requiring separate detection logic.
Why this is an architecture problem, not a feature gap
Multilingual detection isn’t a quality-of-life improvement. It’s a structural requirement for any enterprise running AI across regional offices. Consider what happens without it. A multinational healthcare network processes patient records from offices in six countries. The masking policy runs correctly against English-language records. German, French, Dutch, Arabic, and Japanese records go through the same pipeline, the same AI workflow, but the detection engine misses entities it was never built to recognize in those languages. The policy appears consistent. The protection is not.
This kind of uneven coverage creates a governance problem that regulators take seriously. Under the EU AI Act, organizations providing or deploying covered high-risk AI systems must address requirements related to risk management, data governance, documentation, monitoring, and oversight. Although the Act does not specifically mandate multilingual PII detection, organizations may struggle to demonstrate consistent controls if protection weakens based on the language of the source data. Governance audits increasingly require organizations to explain what sensitive data their AI systems can access, where controls are applied, and whether those controls work across every operational context, not only English-language workflows.
“We mask PII” is no longer a complete answer. “We mask PII consistently, in every language our offices operate in” is.
How this fits the broader Protecto Vault pattern
This update is part of a consistent direction Protecto Vault has been building toward.
Prefix and suffix masking consistency already applies across all entity types, so format-preserving masking works the same way no matter the entity. These new multilingual capabilities add the language dimension to that same guarantee. And the newest healthcare and regional compliance entities get the same multilingual coverage as every other entity Vault detects.
The goal across all of it is the same: one masking policy, applied consistently, regardless of what entity type is being protected or what language the source document is written in.
What doesn’t change
No breaking changes. Existing APIs and workflows built on Protecto Vault are fully compatible. Teams already in production get the language coverage without re-architecting anything.
Who this changes things for
- Multinational enterprises that need consistent protection for customer and employee data across regional offices, instead of a policy that quietly weakens outside English-language markets.
- Healthcare networks where patient records maintained in local languages need the same PHI protection as English-language ones.
- Global banks that process multilingual customer documents, including Arabic-language financial records across the Gulf region, under one masking policy.
- Shared service centers (HR, finance, procurement, legal) whose workflows already handle documents in multiple languages by design.
