Anyone using AI for work across multiple languages readily assumes that a check in English is representative of the rest. Recent research from 2025 and 2026 shows that this assumption does not hold. By our analysis, multilingual AI verification is not a repeat of an English-language check, but calls for its own benchmarks and error patterns, while European transparency obligations also make the handling of AI translations relevant.
The immediate occasion is the publication of Poly-FEVER, a multilingual benchmark for fact verification and hallucination detection across eleven languages. The setup is clear: claims are presented per language and labelled as Supported or Refuted, after which it is measured how well large language models assess those claims. The outcome is that the same models are often clearly less accurate in low-resource languages. Techniques such as retrieval-augmented generation (RAG) and better task structuring do not help uniformly either: what works in one language can actually disappoint in another.
Why multilingual models have different risks
Poly-FEVER does not stand alone. The broad Large Language Models Hallucination: A Comprehensive Survey describes how cross-lingual training can both help and harm multilingual models. Language mismatch and noise in multilingual training data raise the risk of erroneous output, and models with broader language support display on average higher hallucination rates. More languages on board therefore does not automatically mean more reliable work per language.
Translation models also have their own pathologies. The study Challenging Multilingual LLMs, with the accompanying HalloMTBench, introduces a taxonomy for hallucinating AI translations. It features error types such as wrong-language output (the model answers in the wrong language), instruction detachment and source detachment, where content is added or omitted independently of the source text. The researchers show that these problems do not disappear by simply making the model larger, while a fallback to differently trained models can all but eliminate certain error patterns.
For practice this is concrete. One erroneous translation claim in a 'small' language can lead to wrong decisions in a legal file, a medical package insert or a policy document. That is not a language slip, but an assertion that factually deviates from the source.
Verification as a chain, not as a single check
If the verification models themselves differ per language, then the verification architecture must also be thought of as multilingual. The AILS-NTUA submission for SemEval-2025 Task 3 (Mu-SHROOM) shows a concrete, training-free strategy: first translate claims from other languages into English as a pivot language, in order to check them afterwards. That approach produced good results, including for low-resource languages.
The downside is that such a pivot step is itself a translation, with all the risks that entails. Anyone checking via English can introduce new errors precisely at the point where the source text is converted. That means the choice of a pivot language, the models used and their limitations must be visibly recorded. Otherwise it can no longer be traced whether a rejected or approved claim actually rests on the source text or on an intermediate translation.
The taxonomies from this research translate well into checks in the work: record per translation which source passages were used, which languages and models were deployed and which verification steps (multilingual fact-check, cross-model review, human review) were completed.
The EU AI Act turns translations into verifiable objects
Alongside the technical picture there is a legal development. The analysis EU AI Act Article 50 and AI Translation discusses how AI-generated translations fall under the European transparency obligations. According to that reading, 'standard' AI translations of text are in principle exempt from labelling, unless the translation makes substantively far-reaching changes. Organisations must also be able to demonstrate when and how AI was used in a translation process.
By our assessment this indicates that multilingual AI translation in Europe is not only a quality matter, but also a compliance and verification question. A translation is no longer a fleeting intermediate product, but something whose origin and processing you must be able to show.
What this means for a verification console
This is precisely the point where a verification layer such as Vera connects. Vera is not a chatbot and not its own language model, but a privacy-focused verification layer for professionals working with confidential or high-trust information. A task can be routed through selected, independent AI models, whereby verification steps, corrections, mutual differences and sources are made visible for inspection, without this guaranteeing correctness.
Applied to multilingual output, that can help to make visible per translation which source text was used, which language route was followed and which checks were completed before a translation ends up in a file or public communication. That guarantees no correctness and eliminates no hallucinations, but it makes control possible and gives more insight into the chain behind a claim. With the pivot-language problem from the SemEval submission that is valuable: you then see whether a claim was assessed via an intermediate language.
For sensitive documents the pre-processing is relevant. The Semantic Privacy Shield can replace sensitive values with synthetic, session-only equivalents on EU infrastructure before AI processing takes place; the workflow is designed to send onward only anonymised content and is fail-closed, which means that when a privacy check fails nothing is sent onward. More about that setup is on the Privacy Shield page and about the recording on the evidence page.
The common thread of the research is clear: multilingual AI output is not a single message, but a collection of language-specific translation claims that must be verified per language within a visible, controllable process. The professional final judgement thereby always remains with the user.