You run a proof of concept with a leading general-purpose model. In English, the demo is clean. Then a colleague from Riyadh or Doha types a real question in Arabic, the way they actually write it, and the answer comes back stiff, formal, occasionally wrong, and in a register no Gulf employee would use. The model is not broken. It was built for a different language problem than the one you have.
If you are weighing an Arabic deployment for enterprise or government, it helps to understand why this gap exists, what closing it involves, and when the honest answer is not to fine-tune at all.
The training data problem underneath everything
Most frontier models are trained on corpora that are overwhelmingly English, with the rest spread thin across dozens of languages. Arabic gets a small slice, and that slice skews heavily toward Modern Standard Arabic (MSA) scraped from news sites, Wikipedia, and formal publications. The model learns the Arabic of a press release, not the Arabic of a WhatsApp message, a support ticket, or a citizen’s request to a ministry.
That single fact drives almost every failure mode below.
Dialect versus Modern Standard Arabic
MSA is the written standard across the Arab world, the language of official documents and broadcast news. Almost nobody speaks it at home, and increasingly people do not write it in informal channels either. A Qatari, a Saudi from the Eastern Province, and a Kuwaiti share a broad Gulf dialect (Khaleeji) but diverge in vocabulary, common phrases, and how they fold in English loanwords.
A model trained mainly on MSA handles the formal register competently, then stumbles the moment input drifts toward how people actually write. It misreads intent, answers a slightly different question, or replies in a register that feels cold and bureaucratic. In a customer-facing or citizen-facing service, that register mismatch alone erodes trust, even when the underlying answer is correct.
The reverse also matters. A model tuned only on casual dialect can sound inappropriately informal in a legal notice or a formal government reply. Real Gulf deployments need both registers, and need to know which one the moment calls for.
Right-to-left text and the plumbing around the model
Arabic runs right to left, and the failures here are rarely in the model weights. They live in the plumbing.
Tokenizers built for English fragment Arabic words into more tokens than the English equivalent, which inflates cost and quietly eats the context window. Arabic is written with connected letters whose shape changes by position, and it carries optional diacritics that are usually omitted. Mixed Arabic-English strings, common in Gulf business writing, force the text direction to switch mid-sentence, and naive rendering scrambles the order of numbers, dates, and Latin terms.
None of this is exotic, but it surfaces as garbled output, broken formatting in generated documents, and retrieval that silently misses the right passage because the text was normalised inconsistently at index time and query time. Teams that skip careful preprocessing spend weeks blaming the model for what is really a text-handling bug.
Domain and government terminology
General models do not know your terms. Ministry names, programme names, legal and regulatory vocabulary, procurement language, and the specific phrasing of official Gulf correspondence are underrepresented or absent in generic training data. The model guesses, and a plausible-sounding wrong term in a legal or government context is worse than an obvious blank.
This is where fine-tuning earns its place. A model shaped on your document corpus, your glossaries, and examples of correct output learns the vocabulary and the house style of the institution it serves. It is also where you decide, deliberately, which terms must never be paraphrased and must appear verbatim.
Data residency and why it constrains the whole design
For government bodies and regulated enterprises across Qatar, Saudi Arabia, Kuwait, Bahrain, and Oman, where the data lives is often a hard requirement, not a preference. Sending citizen records or classified documents to an external API in another jurisdiction is frequently off the table.
That constraint reaches back into the model choice. It usually points toward open-weight models you can fine-tune and host on-premise or in a sovereign private cloud, rather than a closed API you can only call. Decide this early. It shapes model selection, infrastructure, and cost long before anyone writes a training script, and reversing it late is expensive.
What a real fine-tuning process actually involves
The training run is the short, easy part. The work around it is where projects succeed or fail.
Data curation. You assemble representative examples of the inputs you will actually see and the outputs you want back, in the right dialect and register. Quality beats volume. A few thousand clean, well-labelled examples that match production reality outperform a large, noisy dump. For most enterprise cases this means human review by people who know both the domain and the dialect.
Preprocessing and tokenizer sanity. You normalise text consistently, decide how to treat diacritics and mixed-language strings, and confirm the tokenizer handles Arabic efficiently. Get this right once and every downstream step benefits.
Choosing the adaptation method. Full fine-tuning is rarely necessary. Parameter-efficient methods such as LoRA adapt a base model at a fraction of the compute and are far easier to version, swap, and roll back. Often the strongest results come from combining a lighter fine-tune with retrieval over your own documents, so the model reasons in the right style while pulling facts from a source you control.
Evaluation, which is the real deliverable. This is the part teams underinvest in and later regret. You need a held-out test set drawn from real Gulf Arabic inputs, not translated English. You need native Gulf speakers scoring outputs for correctness, register, and terminology, because automated metrics like BLEU miss exactly the dialect and tone problems you are trying to fix. Define what good looks like before training, measure the base model against it as a baseline, and only claim improvement when the numbers and the human reviewers agree. Add adversarial and safety testing, in Arabic, for anything public-facing, since prompts that are harmless in English can behave differently after translation.
Iteration. The first fine-tune exposes gaps in your data. You patch the data, retrain, and re-evaluate. Two or three honest cycles usually beat one big run.
When fine-tuning is the wrong choice
Fine-tuning is not the default answer, and a good partner will sometimes talk you out of it.
If your problem is that the model lacks facts (current policies, specific documents, changing prices or procedures) fine-tuning is the wrong tool. It teaches style and behaviour, not a live knowledge base, and a fine-tuned model still invents details it was never taught. Retrieval-augmented generation over your own documents fixes this more cheaply and stays current as those documents change.
Skip fine-tuning, at least at first, when you do not yet have enough clean domain data to train on. Training on thin or messy data bakes in bad habits that are harder to remove than to prevent. Prompt engineering and retrieval will take you further while you build the dataset properly.
Reconsider it when a capable base model, given good prompts and good retrieval, already meets your quality bar. Every fine-tune is an asset you then own and maintain: retraining as base models improve, versioning adapters, re-running evaluation. If prompting alone clears the bar, do not take on that burden for a marginal gain.
And be honest about volume. If the use case handles a handful of queries a day, the engineering and maintenance cost of a custom model rarely pays back. Fine-tuning earns its keep at scale, on a well-defined task, where register and terminology genuinely matter and the data exists to teach them.
The practical takeaway
The gap between an English demo and a production Arabic system is real, and it is mostly not about the model being weak. It is about dialect and register, the text plumbing around Arabic, the terminology of your institution, and where your data is legally allowed to live. Fine-tuning helps with some of that and is the wrong tool for the rest. The teams that succeed treat evaluation, not training, as the centre of the work, and they settle the residency and retrieval questions before writing a line of training code.
If you are scoping an Arabic LLM project across the Gulf and want a straight assessment of whether fine-tuning fits, that conversation is worth having before the proof of concept, not after.
