How to Build Multilingual AI Onboarding Without Mistranslating Company Policy

Serve a human-reviewed translation of each policy, and treat live machine translation as a labelled fallback. A fluent answer can still turn "must" into "should", drop an exception or swap an approved term for a familiar synonym, and the employee has no way to see it. Choose the governing source before any translation, using role, country, worker type and date. Protect approved terms, check the result against the source, and send high-impact doubt to a bilingual reviewer. We recommend this order because the safest translation of a policy is the one a qualified person has already read.

Choose the source before the language

Translation is one stage in an onboarding answer. The system identifies the employee, understands the question, selects an applicable source, extracts the passage, translates it and presents it with enough context to act, and an error in any stage can look like a translation problem. Policy scope is not a language feature: a French-speaking employee in Canada should not receive the France policy because both documents are in French. Select the governing source by role, location, employment type and effective date before translation begins, in this order:

context = resolve_employee_context(identity, question)
candidates = filter_by_access_scope_and_date(context)
source = select_governing_source(candidates)
passage = retrieve_supporting_passage(source, question)
terms = load_approved_terms(source.policy_family, context.output_language)
translation = translate(passage, terms, context.output_language)
return verify_or_route(source, passage, translation, context)

Collect only the context the task needs: preferred answer language, location, role, worker type, start date and access groups. Keep language preference separate from jurisdiction, and do not treat the interface locale as proof of where someone is employed. When a required item is missing, ask: "I can explain the leave process, but I need your employing country to select the applicable policy." Label the language of every page and every variant, including mixed-language sections and tables. W3C lists the software that reads the label: translation tools use it to recognize pages or sections in a given language, and search, spell checkers, font selection and speech synthesizers use it too (W3C on declaring language). Use codes precise enough for your content, because Spanish for Mexico and Spanish for Spain share most prose but not policy names or local terms.

Store translations as managed variants and not as independent pages with unclear relationships. Each variant points back to its canonical source:

policy_id: security-training-001
canonical_language: en
variant_language: es-MX
applies_to:
 countries: [MX]
 worker_types: [employee]
effective_from: 2026-07-01
owner: security-operations
approved_terms_version: 4
translation_status: human-reviewed
canonical_revision: 18

Make these fields part of the publication workflow and do not infer them from body text at answer time. When a canonical policy changes, mark its variants stale until they are reviewed or regenerated, so an old translation is never served as equivalent to the current source.

Decide which language governs before you decide which language is the source. The canonical text does not have to be English everywhere. In France, Article L1321-6 of the Code du travail says the internal rules, and any document that sets obligations for an employee or that the employee needs to do the work, must be written in French and may be accompanied by translations. The rule does not apply to documents received from abroad or intended for foreigners. For a French workforce, the assistant's English or Spanish answer is meant to accompany the French text and not to replace it. Ask legal which text governs in each country, and store the answer next to the policy record.

GitLab's onboarding handbook points the same way in structure: it keeps one employment onboarding template per country and role in a public repository, which means one policy per country with translations attached to it, and no single global text translated everywhere.

Reviewed variants first, live translation second

We recommend serving the human-reviewed variant whenever one exists and translating live only when it does not. A policy translated at answer time is translated again, and risked again, on every question. For high-impact families such as pay, leave, safety and security, publish reviewed variants and let the assistant retrieve them. Use live machine translation for the rest, label it as machine translated, and make the passages employees ask for most the review queue, so the fallback shrinks over time.

Microsoft's Translator overview shows how much the fallback can be tuned: you can choose between neural machine translation and an LLM deployment, and up to five reference translations can influence the LLM's terminology and style. Use that to improve the fallback, and keep the review.

Protect terms, and check what you cannot protect

Internal names such as "production access", "restricted customer data" and "probation review" usually have approved equivalents, and a general translation may choose a synonym with a different legal or operational meaning. Keep a glossary with the source term, the approved target term, the prohibited alternatives, the owner, the locale and the review date, and keep phrases and not only single words: "paid time off" may need a different controlled translation than "paid", "time" and "off".

Do not treat term injection as a safety control. Microsoft documents its dynamic dictionary, which lets a request prescribe the translation of a term, as safe only for compound nouns like proper names and product names, and it needs English on one side of the pair and an explicit source language instead of autodetection. Policy language is full of terms that inflect or change with context in the target language, so check after translation as well.

Flag protected terms that disappeared, were inflected wrongly or were replaced by a prohibited synonym, and compare dates, amounts, negation, exceptions and mandatory verbs against the source. When a safe correction is not deterministic, route the segment and do not overwrite the sentence.

Show the evidence, and write down what every answer must hold

Every multilingual answer carries the canonical source identifier and revision, the source and output languages, the employee context used to select the source, the translated answer with the exact supporting passage, the protected terms applied, a risk class with a review decision, and a link to the governing source. That contract stops the interface from presenting free-standing translated prose, and it lets a reviewer tell whether a failure came from retrieval, terminology, translation or presentation. Show the policy title, effective date, scope and source link beside the answer, put the original passage behind an expandable control or side by side, and mark machine-generated or unreviewed translations clearly for high-impact instructions. A reviewer can then point at one translated clause and not argue with an answer that has no visible basis.

NIST built its AI Risk Management Framework to manage AI risk to individuals, organizations and society, and a mistranslated policy lands on the individual who reads it. Start from that consequence: give each policy family an owner, define what a wrong answer costs the reader, and classify by consequence, because an office map tolerates different handling from payroll, benefits, safety, security or legal instructions.

Kipwise's new hire onboarding platform provides product context for assigned reading and searchable company knowledge. Use that type of maintained source layer as the basis for multilingual answers rather than translating old chat messages that have no accountable owner.

Route doubt by consequence

Do not use one confidence threshold for every question, and do not send every question to a reviewer either: universal review creates a queue that employees bypass. Route an answer when any of these holds:

• No single governing source survives filtering.
• The source variant is stale or has no owner.
• A protected term is missing or ambiguous.
• Dates, amounts, negation, exceptions or mandatory verbs differ.
• The request combines jurisdictions or worker types.
• The employee asks for an official interpretation and not a summary.
• The answer affects compensation, benefits, safety, security, compliance or employment rights.

The handoff carries the question, the employee context, the canonical passage, the proposed translation, the glossary version and the detected risk. It goes to the policy owner and a qualified bilingual reviewer, and the new hire does not repeat the question in another channel.

A worked example: must versus should

Suppose the canonical policy is the sentence "Employees must complete security training before production access is approved, unless Security Operations records a temporary exception." A weak pipeline translates the whole retrieved page and returns a sentence that effectively says training is recommended before access. It has turned a mandatory condition into advice. Another translation might attach the exception to the training requirement and not to the access approval.

The controlled pipeline first confirms that the policy applies to the employee. It extracts the exact sentence, protects the approved translations of "security training", "production access" and "temporary exception", and checks the modal verb and the placement of the exception. The interface returns the translated instruction with the original clause, the effective date and the policy link, and if the verifier finds a verb weaker than "must", the answer does not ship automatically. Conditions, actors, actions, timing, negation and exceptions must survive. Style can vary.

Test meaning, not sentence similarity

Build the test set from real onboarding tasks, with the questions new hires actually ask and the policies that govern them. For each language, test direct questions in official terminology, informal questions and abbreviations, mixed-language questions, questions with a missing country or worker type, policies with dates, amounts, tables, negation and exceptions, questions that should be refused or routed, and a canonical revision that makes a translation stale. Have bilingual reviewers score factual equivalence, applicability, terminology, citation accuracy and actionability separately, because a smooth answer can pass readability and fail equivalence, and record each defect by stage so the fix reaches the right owner.

Use release gates and not an average score. Fail the release if any critical test changes a mandatory action, omits an exception, cites the wrong jurisdiction or exposes a restricted source, and track lower-impact issues as improvement work without averaging them against critical failures.

Start with one policy and two languages

Pick one high-consequence onboarding policy, define its canonical source, the governing language for each country and the approved terms, and write ten bilingual test questions for each language, including missing-context and stale-variant cases, before connecting a translation model. Run it with a few bilingual employees and the policy owner, compare every answer with the governing document, and check that reviewers get enough context to decide quickly. That small test shows whether your problem is language, source governance or policy scope.