Building Bilingual AI: Lessons From Deploying Arabic-First Systems

Almost every vendor claiming Arabic support in the Gulf built an English-first product and added a translation step at the edges: translate the user's Arabic input to English, run the model, translate the output back. This works well enough in a sales demo, where the input is a clean sentence and the output is a paragraph of prose. It falls apart the moment real documents enter the picture, because business documents in this region are rarely monolingual. A contract might be drafted in Arabic with English clause references. A medical record might carry Arabic patient notes alongside English lab codes. A translation-layer architecture treats this code-switching as noise to be cleaned up before processing, when it is actually the normal shape of the data.

I learned this the hard way early on, watching a translation-layer system silently drop half the meaning of a mixed-language invoice because its translation step assumed a single source language and picked the wrong one. Nobody flagged an error. The system just produced a confidently wrong summary, because nothing in its pipeline was built to notice that the document did not match its assumptions. That is the specific danger of Arabic-added architecture: it does not fail loudly, it fails quietly, and by the time someone notices the summaries have been subtly wrong for weeks.

Even systems that get Modern Standard Arabic right routinely fail on dialect, and dialect is not a rounding error in the Gulf — it is how people actually write in chat support, voice notes, and internal communication. A model trained predominantly on MSA news text and formal documents will parse a customer service message written in Gulf Arabic dialect with noticeably worse accuracy than the same complaint written formally, which means the customers least likely to write formally, often the ones with the most urgent or emotionally charged complaints, get the worst service from the AI system meant to help them. I have seen this show up as a quiet fairness problem long before anyone frames it as a technical one: certain customers simply get worse outcomes, and the pattern correlates with how they write, not what they are asking for.

The fix is not exotic, but it is genuine engineering work rather than a configuration toggle: training and evaluation data has to include dialect variation deliberately, and evaluation metrics have to be checked separately for MSA and dialect inputs rather than averaged into a single accuracy number that hides the gap. We do this at Hayya Med AI specifically because our clients' actual users write in dialect far more often than in formal Arabic, and a system that only performs well on the formal register is a system that quietly underperforms for most of the people using it.

Right-to-left layout is treated as a cosmetic detail by teams that have not shipped a bilingual product, and it is not a cosmetic detail. Numbers, dates, mixed-direction text, and UI elements that were designed left-to-right and then mirrored programmatically break in specific, embarrassing ways: a currency figure renders with the sign on the wrong side, a form field's cursor behavior contradicts the reading direction, a chat bubble's timestamp ends up misaligned in a way that reads as unprofessional even when every underlying number is correct. None of this is a model problem. It is an interface problem that gets treated as an afterthought because the team building the product was thinking in English first and Arabic second.

Getting bilingual products right in production means building the Arabic experience as a first-class target from the earliest design decisions, not as a localization pass applied after the English version ships. That is a genuinely more expensive way to build, and it is the only way I have seen actually hold up once real Gulf users, writing in their own dialects, in mixed-language documents, on right-to-left interfaces, start using the system at volume.