Multilingual IT self-service: fluent isn’t the same as right

Separate language preference from policy selection, and catch missing clauses before employees rely on an answer.

An employee opens the company’s global help assistant and types, in German: “Wie viele Urlaubstage kann ich ins nächste Jahr übertragen?” Roughly: “How many vacation days can I carry over into next year?”

Multilingual IT self-service has to distinguish these replies, not just produce German. These are unreviewed German examples of invented company policies, not national law or legal guidance.

• Reply A: “Sie können bis zu 3 Urlaubstage ins nächste Jahr übertragen. Für die Nutzung dieser Tage gibt es keine Frist.” (“You can carry over up to 3 vacation days into next year. There’s no deadline for using those days.”)
• Reply B: “Laut der für Sie geltenden Urlaubsrichtlinie können Sie bis zu 5 Urlaubstage ins nächste Jahr übertragen. Diese Tage müssen Sie bis zum 31. März des Folgejahres nehmen.” (“Under the leave policy that applies to you, you can carry over up to 5 vacation days into next year. You must take those days by March 31 of the following year.”)

Reply A uses the fictional US handbook. Reply B uses the fictional policy for the employee’s German employing entity. An employee may not spot the wrong source from the wording alone.

A language count tells you the assistant can reply. It doesn’t tell you the reply came from the right country’s policy.

A policy question, not a leave transaction

This request arrives through IT self-service because that’s where the global assistant lives. It isn’t a request to book leave or change a balance in the human resources information system (HRIS). The employee wants to know a rule.

A correct, sourced answer can fulfill the request completely without changing any record. The assistant doesn't need a leave balance or leave history to explain a rule. It may still need an authorized entity or policy-group lookup to select that rule.

If it shows the employee’s own remaining balance, that’s a separate, permission-bound field. It should never surface another employee’s balance, contract terms, or leave history.

So the test isn’t “did the assistant do something?” It’s “did it state the rule that governs this person, from the version in force, in a language they can rely on?”

Signals that look like a country and aren’t

The tempting shortcut is “German means Germany,” and it fails quickly. A German-speaking employee might be employed by an entity in Switzerland or Austria. An employee in Germany might write in English. Someone employed in Germany might be traveling, so their network location points somewhere else entirely.

The W3C has warned about this for years. Its guidance says the HTTP Accept-Language header was meant to express language, and shouldn’t be used alone to determine locale.

It notes that a browser may send only “de,” with no region, and that many users never change their defaults. Language tags defined by BCP 47 can add a region, as in de-DE, de-AT, or de-CH. They describe language varieties, not employing entities.

Directory records split these ideas too. Microsoft’s Graph documentation describes a user’s preferredLanguage as a language preference. It describes usageLocation as a country code used to check license availability. Neither is documented as the policy group that decides which leave rules apply.

The signal you want is a trusted attribute: the employing entity or policy group, read from the system of record your HR team maintains. That’s the same argument behind AI for IT support that reads systems, not just the docs. Here, the system to read is the employee record, under the employee’s own permissions.

The locale and policy evaluation grid

Run every dimension below against the same case: one employee, one German question, one fictional policy set. Each row is a separate check. Passing one row tells you nothing about the next.

The grid works because it refuses to merge rows. “Replied in German” and “correct for this employee” are different results, and a vendor demo can show the first without touching the second.

One request, five outcomes

The question date is November 12, 2026, in this fictional test. Carried-over days belong to 2027. Only the last branch changes the employee’s entity.

Checking the source alone won't catch the third branch. The assistant found the right document and still produced a wrong answer, because a clause disappeared in generation. The error is in the missing condition, not the source selection.

The fourth branch should sound something like this:

“Ich finde keine geprüfte Richtlinie zur Urlaubsübertragung für Ihre Gesellschaft. Ich nenne Ihnen keine Zahl aus einer anderen Richtlinie. Soll ich Ihre Frage an Ihre Personalabteilung weiterleiten?”

Roughly: “I can’t find a verified carry-over policy for your entity. I won’t give you a number from another policy. Should I forward your question to your HR department?”

That reply doesn’t translate the US figure, and it doesn’t invent a confidence score. It names the gap and offers a route the organization has approved. An offered route isn’t an accepted one, though. Until the HR team takes the question, the status is “offered,” not “resolved.”

Coverage isn’t comprehension

Language support usually gets described as coverage: how many languages the assistant detects and replies in. Detection and coverage describe reach. They say nothing about whether a reply means what the policy means.

The same caution applies to how a reply is produced. An assistant might generate German directly or translate a reply drafted in another language. Neither path is automatically better. Native generation can still drop a deadline, and a reviewed translation can still go stale when the source policy changes.

Both paths need the same two-part check. A qualified native-German reviewer confirms the reply says what it appears to say. A domain reviewer, usually the policy owner for that entity, confirms it matches the rule in force. One person can do both only if they’re qualified for both.

The German replies and glosses in this article are illustrative. No native-German or policy-domain reviewer has checked them, and the glosses are approximate. Treat them as a starting fixture your own reviewers correct, not as reference translations.

The verification worksheet

Use one worksheet per test run. Fill each field from evidence you can inspect, and keep the fields apart even when they agree.

A hold isn’t a vague “needs work.” It names the row that failed and the person who fixes it. A grounding failure goes to whoever maintains the entity mapping. An output failure goes back to the language and policy reviewers with the exact wording that drifted.

Build the test set from your own entities and policies. Pair each policy question with at least one speaker whose language doesn’t match their employing country. Use synthetic employees, never real records.

Make a release decision, not a language-count comparison

Give the completed worksheet to the native-language reviewer and the policy owner. They need the exact prompt, entity mapping, cited policy version, and reply, including the missing-policy branch.

For each failure, retain the original wording beside the correction. A dropped deadline needs a language correction; a wrong entity needs a mapping correction. Neither reviewer can clear the other’s work by checking fluency alone. Rerun the affected branch after the correction, then record both decisions against the exact revised reply.

Apply that same release bar if you’re evaluating Computer, by DevRev. Inspect the configuration you’re shown rather than assuming native generation, policy selection, or in-language abstention is supported. The broader service desk automation use case provides employee-support context, not proof of multilingual policy correctness. A language list can’t answer those questions, and a demonstration doesn’t replace review of the words an employee will receive.

Start with your highest-consequence policy answers. Assign the language and policy reviewers, then use the worksheet to record a hold or release for each answer. Keep a missing-policy answer in that set: a clear gap is safer than a polished rule that belongs to someone else.

Evaluating a multilingual assistant? Bring your own highest-consequence policy answers and at least one speaker whose language doesn’t match their employing country, and walk each one through the grid before assuming a language list settles correctness.