Building a Multilingual Policy Pipeline: A Technical Approach to GDPR/LGPD Documentation

If you work at a company with employees across multiple countries, you've probably seen this pattern: legal/compliance drops a new data protection policy in a shared drive, HR sends a link, and someone in the Luanda or São Paulo office opens a PDF written in dense European Portuguese or English legalese. Nobody reads it. If there's ever an audit or a dispute, that's a problem.

There's a good write-up on the legal side of this from M21Global, covering what GDPR, Angola's Law No. 22/11, and Brazil's LGPD actually require in terms of linguistic clarity. That article is aimed at compliance teams deciding whether to hire a translation service. This one is for the people who end up building and maintaining the actual document pipeline, because "just translate the policy" turns into a surprisingly gnarly content-ops problem once you have more than two jurisdictions.

Why this isn't a one-off translation task

A data protection policy isn't static. It changes when:

• Legislation changes (new guidance from a supervisory authority, amendments to local law)
• The org changes (new data processors, new retention periods, new subsidiaries)
• Internal tooling changes (new HR system, new vendor handling payroll data)

If you're maintaining four jurisdiction-specific versions of the same policy by hand, in four separate Word docs, you will eventually ship a version where the GDPR complaints procedure in the Portuguese file doesn't match the one in the French file. This is a content synchronization problem, and it should be treated like one.

Treat policy documents like source code

The cleanest approach I've seen (and used) is to version-control policy content the same way you'd version-control i18n strings in an app.

1. Structure the policy as modular content, not a monolithic doc.

Break it into sections that map to legal concepts rather than paragraphs:

# policy/sections/data-controller.yml
id: data_controller_definition
source_lang: en
last_legal_review: 2024-11-03
requires_jurisdiction_adaptation: true
content:
  en: "The data controller is the entity that determines..."

This lets you flag, at the content level, which sections are pure translation versus which require legal adaptation (complaints mechanisms, supervisory authority names, specific statutory rights). That distinction matters a lot operationally — the source article makes the legal case for why "responsável pelo tratamento" isn't just a stylistic choice over "gestor de dados"; from a pipeline perspective, that means certain sections need a legal reviewer in the loop, not just a linguist.

2. Use a translation management system (TMS) with a review workflow, not raw files in a repo.

Tools like Crowdin, Phrase, or Lokalise support multi-step review pipelines (translator → reviewer → QA) and, critically, translation memory. For legal documents this matters because:

• Translation memory ensures "data subject" is translated identically everywhere it appears in a given language, instead of drifting across documents translated at different times.
• You can lock terminology with a glossary feature so "titular dos dados" (Brazil) vs "titular de dados" (Portugal) doesn't get mixed up between your BR and PT locales, which look similar but are legally distinct markets.

// glossary.json — enforced terms per locale
{
  "data_controller": {
    "pt-PT": "responsável pelo tratamento",
    "pt-BR": "controlador",
    "fr-FR": "responsable du traitement"
  }
}

3. Automate the diff-and-flag step when the source changes.

When the master policy changes, you want an automatic flag on every derived version showing exactly what changed, not a full re-translation. A simple approach:

# pseudo-pipeline, runs on PR to policy/source/en.md
git diff --unified=0 policy/source/en.md > changes.diff
./scripts/extract_changed_sections.py changes.diff > flagged_sections.json
# flagged_sections.json feeds into your TMS as a new translation job,
# scoped only to the changed sections

This keeps turnaround fast and cheap for minor updates (a new vendor added to a processing list) versus a full-document legal re-translation (a new retention policy across the board).

Where human legal review has to stay in the loop

Automation gets you consistency and speed, not legal accuracy. The source article's point about terminology (controller vs. processor, jurisdiction-specific complaints procedures, correct name of the supervisory authority) is the part no pipeline can fully automate. What the pipeline can do is make sure those sections are reliably routed to a qualified reviewer every time, instead of relying on someone remembering to flag them.

Practical rule of thumb for a CI-style workflow:

• Sections tagged requires_jurisdiction_adaptation: true always route to a legal/linguistic reviewer, no exceptions, even for a one-word change.
• Sections tagged direct_translation: true can go through MT + human post-edit for speed.
• Every merged version gets a changelog entry and a last_legal_review date, so you can prove, in an audit, when each jurisdiction's version was last checked against local law.

Don't skip the distribution problem

Translating the policy correctly doesn't help if employees in Angola are still getting the English PDF because HR's distribution list wasn't updated. If you're pushing policies through an internal portal or onboarding flow, tie locale to employee jurisdiction at the data model level:

SELECT employee_id, policy_version, jurisdiction_locale
FROM policy_acknowledgements
WHERE jurisdiction_locale != employee.jurisdiction_locale;

Run that query periodically. If it returns rows, someone received a policy in the wrong language, which is exactly the failure mode the legal frameworks are trying to prevent.

The takeaway

Legal teams decide what the policy needs to say in each jurisdiction. Engineering and content-ops decide how reliably that gets maintained, versioned, and delivered to the right person in the right language. If your org is scaling into new markets, it's worth building the pipeline before you have six jurisdictions and a spreadsheet nobody trusts. For the legal and compliance side of why this matters jurisdiction by jurisdiction, the original breakdown is worth reading: https://www.m21global.com/en/blog/translating-data-protection-policies-staff-jurisdictions/.