Most Arabic chatbots lose the user in the first three messages. Someone in Doha types a question the way they actually speak, half Gulf dialect and half English, and the bot answers in stiff textbook Arabic that misses the point. The user tries once more, gets the same treatment, and leaves. Nothing crashed. The system just quietly failed the person it was built for.
Building conversational AI that Gulf users trust depends less on the model than on the decisions you make around it. Here is how we approach those decisions at Qatsol, based on what holds up in production rather than what looks good in a demo.
Dialect and code-switching are the whole problem, not an edge case
Written Arabic and spoken Arabic sit far apart, and the gap is wider in the Gulf than almost anywhere else. A Qatari or Kuwaiti user rarely types in clean Modern Standard Arabic. They write Gulf dialect, drop in English words for anything technical, and switch scripts mid-sentence, spelling an English brand name in Latin letters inside an Arabic question. A bank customer might ask about their “statement” using the English word, written in English, surrounded by Khaleeji Arabic.
A model trained mostly on MSA news text and formal documents treats all of this as noise. It has learned the register that appears in newspapers and government circulars, not the register people use when they are annoyed and in a hurry.
Two practical consequences follow. First, your evaluation data has to look like real messages from your real users, dialect and code-switching included, not translated MSA prompts. If you test on clean Arabic and ship to people who write messy Arabic, your test scores describe a product nobody is using. Second, you usually want the system to understand dialect but reply in a controlled register. Understanding colloquial Gulf Arabic on the way in is a hard requirement. On the way out, MSA that leans slightly conversational tends to read as competent and respectful across all five Gulf markets, whereas one specific dialect can feel out of place to a user from a neighbouring country. That is a design choice worth making on purpose and testing, not one to leave to the model’s default.
MSA versus colloquial is a register decision you own
Teams often treat this as a technical limitation. It is closer to an editorial policy. You decide what the assistant sounds like, the same way a bank decides how its call-centre staff speak.
For a government service, formal MSA signals seriousness and matches the tone of official communication. For a retail or telecom brand aimed at younger users, unbending formality can feel cold and bureaucratic. The right answer depends on who is on the other end, and it is worth writing down as a style guide, the way you would for human agents: how to greet, how to say no, how to handle a frustrated user, and when to use the English terms everyone actually says rather than forcing an Arabic coinage no one uses out loud.
Latency is a trust signal
Users read response time as competence, even though the two have little to do with each other. A pause of four or five seconds before a reply reads as the system struggling, and once someone doubts the system they stop trusting the content of the answer.
Arabic adds specific pressure here. Right-to-left rendering, correct handling of diacritics and letter shaping, and heavier tokeniser overhead for Arabic script all cost time if you are not careful. Streaming the response, so the user sees words appear straight away, helps more than shaving milliseconds off total generation. So does a fast, honest holding message when a real lookup is genuinely slow, rather than a spinner that says nothing. Set a target you can defend, measure it at the ninety-fifth percentile rather than the average, and treat a slow tail as a defect. The average hides the users who wait longest, and those are the users who leave.
Graceful escalation to a human is a feature, not an admission of failure
No assistant should try to answer everything. The ones users trust know their own limits and hand off cleanly. A confidently wrong answer about a medical benefit, a visa rule, or a bank charge does more damage than an honest “let me connect you to someone who can help.”
Good escalation depends on a few things working together. The system needs a sense of its own uncertainty, so it can route low-confidence cases to a person instead of guessing. It needs clear rules for topics that should always reach a human whatever the confidence, such as complaints, legal questions, or anything involving money moving. And the handoff has to carry context, so the user does not repeat everything they already typed. An escalation that drops the person into a fresh queue with no history feels like a punishment for using the bot. In Arabic the handoff wording matters as well: a curt transfer reads as dismissive, so it deserves the same care as the rest of the conversation.
Data privacy and Qatar’s PDPPL are design inputs, not paperwork
For enterprise and government work in Qatar, Law No. 13 of 2016 on Personal Data Privacy Protection sets the ground rules, and it shapes architecture rather than sitting in a legal appendix at the back. Personal data must be processed lawfully and fairly, individuals hold rights over their data, and organisations are expected to protect it and be transparent about how it is used.
In practice that pushes several decisions upstream. Where does the data live, and does it leave the country or the organisation’s control. What gets logged, for how long, and who can read the logs. Whether user messages are used to improve the model, which for many public-sector clients means a firm no without explicit consent and a clear boundary. This is a large part of why on-premises and private-cloud deployment come up so often in Gulf government work. It is a practical way to keep sensitive data inside a controlled environment and to give a client a straight answer when they ask where their citizens’ data sits. Settle these questions before you write the first prompt, because retrofitting privacy into a live system is painful and rarely complete.
Measuring answer quality honestly
This is where most teams quietly fool themselves. A model can score well on a benchmark and still frustrate real users every day, because the benchmark measured fluent-sounding Arabic rather than correct, useful answers to the questions people actually ask.
Honest measurement starts by separating things that get blurred together. Is the Arabic correct and natural. Is the answer factually right for your domain. Did it resolve what the user needed, or just respond politely. A reply can be grammatically flawless, warm in tone, and completely wrong, and a single satisfaction score will not tell you which failure you are looking at.
A few habits keep the picture honest. Build your evaluation set from real conversation logs, dialect and code-switching and all, and refresh it as usage shifts. Have native Gulf Arabic speakers, not MSA-only reviewers, read a sample of real answers every week, because automated scoring misses the tone and dialect errors a person catches in a second. Track how often the assistant escalates and how often it should have escalated but did not, since a system that never hands off is usually hiding wrong answers rather than avoiding them. And watch what people do after the reply. Rephrasing the same question, giving up, or asking for a human tells you more than a thumbs-up button most users never touch.
None of this is exotic. It is the ordinary discipline of building something for a specific group of people and checking, honestly and often, whether it works for them. In the Gulf that group writes in dialect, switches languages without thinking about it, expects a fast answer, and cares a great deal about where its data goes. Build for that person and trust follows. Build for a clean-Arabic benchmark and you will pass the test while losing the user.
