On-prem AI translation for government.

Somewhere in most government buildings, a draft regulation, a diplomatic note, or a pre-award tender evaluation has been pasted into a free web translator by someone under deadline pressure. Not out of carelessness: the document needed translating, the approved path was slow or absent, and the browser was right there. This post is about why that path is unacceptable for sensitive work, what the realistic alternatives look like, and how to evaluate them without drowning in vendor language.

What actually happens when you paste

Two things occur the moment sensitive text goes into a public translation site. First, the data physically leaves: it travels to servers operated by a foreign company, usually in another jurisdiction, subject to that jurisdiction's laws and disclosure orders rather than yours. For a government entity, that can mean an unclassified-but-sensitive document is now stored, however briefly, somewhere your legal framework does not reach.

Second, retention is not under your control. Consumer translation services describe what they keep in terms of service that change, vary by product tier, and rarely make promises a security officer can verify. Some retain inputs to improve their models; some log them operationally; the honest general answer is that you cannot know from the outside, and "we cannot know" is precisely the property sensitive-document handling is supposed to eliminate. The issue is not that any particular provider is malicious. It is that confidentiality by policy is weaker than confidentiality by architecture.

The sovereignty spectrum

Deployment is not a binary between "the cloud" and "a bunker". There is a spectrum, and different documents belong at different points on it.

• Public cloud. The vendor's multi-tenant service, wherever it runs. Fine for public or trivial content, not for anything sensitive: data crosses borders, and controls are contractual at best.
• Sovereign cloud. The service runs inside your country, sometimes inside a government-approved data center, so data residency is satisfied. Operational control still sits with the provider, but jurisdiction and residency are addressed.
• On-premises. The software runs on your own servers, inside your own network, operated by your own people. Data never leaves the building. The vendor supplies software and updates; you supply the perimeter.
• Air-gapped. On-premises with the network cable cut: no internet path at all, updates arriving by controlled offline transfer. This is the regime for classified environments, and it rules out any product that phones home to function.

Most institutions run a mixed estate: public material on convenient tiers, sensitive work on-prem, a small classified enclave air-gapped. The mistake is not choosing a point on the spectrum; it is not choosing, and letting the browser choose for everyone.

What actually has to run locally

Here is where vendor claims deserve scrutiny, because "on-premises" is sometimes marketing for "a thin proxy on your network that still calls our cloud". For document translation to be genuinely local, three heavy pieces have to run inside your perimeter:

• The translation model itself. The neural network doing the translating, running on your hardware. If the words leave to be translated, nothing else on this list matters.
• OCR. Scanned PDFs and images are a large fraction of institutional documents, and turning them into text is its own model. If OCR is a cloud call, your scanned documents are leaving even when the translation is local.
• The document pipeline. Parsing PDF, Word, PowerPoint, and Excel files, extracting content, rebuilding the translated document with its layout intact. These processing steps touch the full document, so they have to be inside too.

Plus the supporting cast: glossaries, translation memory, user management, audit logs, all storing their data locally. The test is simple to state: unplug the internet and translate a scanned Arabic PDF. Either it works or the architecture was never local.

What to ask a vendor

How TranslateX approaches it

TranslateX was built with this deployment story as a core requirement rather than a retrofit, which reflects where Lisan works: more than 24 government entities work with Lisan, and sovereignty questions arrive in the first meeting, not the last. Concretely: the product ships with a local, on-premises model option, so the translation engine itself runs inside your network. Deployment is via Docker, and air-gapped installation is a documented, supported path, not a special favor. Around the engine sit the enterprise controls a government IT department expects: roles (admin, manager, translator, reviewer, viewer), LDAP and Active Directory sign-in, MFA, audit logs with SIEM export, and white-label options. The full picture is on security and on-prem deployment, and the government workflow context is in our government use case.

Two honest caveats. On-prem trades convenience for control: your team operates the stack, and model updates arrive on your schedule rather than continuously. And the strongest cloud model tier and the local model are different engines; for most institutional documents the local option is more than capable, but the right comparison is a pilot on your own documents, inside your own network, which is exactly what an on-prem product should make easy.

The deadline pressure that pushes people toward the browser is real and permanent. The fix is not another memo forbidding it. It is an approved path that is as fast as the forbidden one, sitting inside the building, so the easy choice and the safe choice are finally the same choice.