Sovereign Chatbots for Citizen Services: What 12-Language, Air-Gapped Production Looks Like

Two years ago we shipped a citizen-service AI assistant for a national government agency. The deployment was fully air-gapped — zero outbound network connectivity, model weights on agency hardware, every interaction logged into the agency's existing audit infrastructure. It now handles citizen queries in twelve languages across web, mobile, WhatsApp and IVR channels. The technical architecture was unusual; the change-management work was more unusual still. Of the eight months we spent on the project, roughly five were spent on stakeholder management, accessibility, language coverage, refusal-when-out-of-policy patterns, and the procurement-and-accreditation path. The actual model serving and RAG infrastructure was the easier half. Citizen-facing AI in the public sector isn't an engineering problem with a procurement overlay; it's a public-trust problem with an engineering substrate.

Why the air-gap is non-negotiable for citizen services

Three reasons that compound. One: data sovereignty law. Citizen data — even queries that look innocuous, like "how do I renew my passport" — is treated as a controlled disclosure under most national data-protection regimes when the query is paired with the citizen's identifier. Sending those queries to a cloud LLM provider triggers cross-border-transfer scrutiny that doesn't pass. Two: procurement accreditation. Most government IT estates require IL-rated or equivalent infrastructure for sensitive workloads; cloud LLM APIs typically don't meet the bar. Three: explainability obligations. A citizen, an auditor, or a court can ask the agency "why did you tell my constituent X." The agency needs to be able to produce the answer with evidence, in their own infrastructure, on their own timeline. Air-gapped deployment is what makes that answer fast and uncontested.

The multilingual layer that earned its weight

The hardest engineering work in the deployment wasn't model serving — it was multilingual coverage. The agency's mandate covered 12 official languages, three of which are low-resource by global LLM benchmarks. We standardised on BGE-M3 embeddings for retrieval (best-in-class multilingual coverage in 2026) and used Llama 3.3 70B for generation with carefully-engineered prompts that included language detection, refusal-when-translation-uncertain, and explicit language tagging on every response. Per-language eval sets were labelled by native-speaker SMEs at the agency. Six of the twelve languages required no fine-tuning at all; three benefited from a parameter-efficient fine-tune on the agency's specialised vocabulary; three required additional retrieval enhancement. Per-language accuracy was tracked separately and never compressed into an overall "system accuracy" number, because the equity implications of differential accuracy across languages are real and operationally important.

Refusal-when-out-of-policy as a public-trust mechanism

The most operationally important design choice was the agent's refusal behaviour. The system was given an explicit allow-list of question types it could answer (information about policies, forms, deadlines, procedures, eligibility criteria) and an explicit deny-list of question types it would not (advice tailored to the citizen's individual case, predictions about decision outcomes, anything resembling legal or financial advice). The agent's prompt enforces graceful refusal with handoff to a human officer when the citizen's question crosses into the deny-list. The refusal pattern was unpopular with stakeholders who wanted the system to be more capable; it was indispensable for the supervisor and citizen-trust reasons. We track refusals as a positive quality metric — under-refusing is a failure mode, not a target to minimise.

Accessibility as a first-class design constraint

The agency's procurement included WCAG 2.1 AA compliance as a hard requirement; the actual deployment exceeded it because the team treated accessibility as a design constraint from day one. Screen-reader compatibility, keyboard-only navigation, plain-language responses (we deployed a separate prompt pattern that produces simpler-language outputs for users who request them), high-contrast UI options, audio support across all twelve languages. Accessibility was reviewed weekly in the build phase and is reviewed monthly in production. It's the right thing to do; it's also a procurement and supervisory expectation that's only growing.

Operational metrics that matter for citizen services

Three metrics we report monthly. First, deflection rate (the fraction of citizen interactions resolved end-to-end without human handoff) — currently 47% across all languages, with substantial variation by language and topic. Second, refusal rate (the fraction where the agent appropriately handed off to a human officer because the question fell into the deny-list) — currently around 9%, considered healthy. Third, citizen satisfaction (measured via post-interaction survey) — running in the high 70s percent satisfied. The agency tracks all three publicly via an annual transparency report — itself a deliberate public-trust mechanism.

What this generalises to

The pattern is applicable to public-sector agencies across health, social benefits, immigration, tax administration, and licensing. The architecture is the same; the policy corpus differs. The cost of standing up the second deployment on the same substrate, for a different agency, is a small fraction of the cost of the first — because the substrate is the same and the change-management infrastructure has already been built. /ai-for-government covers the broader public-sector architecture; the project this post describes is anonymised but the architecture is reproducible.