What running AI systems inside government infrastructure in the GCC actually requires

The gap between an AI proof of concept and a system a ministry depends on daily is not a matter of scale. It is a different set of questions, asked by different people, and most of them have nothing to do with the model.

The cloud is not one answer across the Gulf

Data residency requirements differ between the United Arab Emirates, Saudi Arabia and the wider region, and they differ again between a ministry and a regulated commercial entity in the same country. Treating this as a deployment detail to be settled later is how projects stall after the technical work is finished.

In practice there are three shapes, and they are different builds rather than a switch: on-premise inside the client’s own infrastructure, fully air-gapped with no outbound connection at all, and hosted inside a specified jurisdiction. The second one has a cost that suppliers rarely state plainly: an air-gapped system gives up hosted frontier models and hosted speech synthesis, and on some tasks that costs accuracy. Which tasks, and by how much, should be measured on the client’s own evaluation set before anyone commits, not discovered together afterwards.

Arabic-first is an architecture decision, not an interface option

Adding Arabic to a system built around English means translating the interface. Building Arabic-first means the retrieval model, the tokenisation, the document structure handling and the evaluation set are all shaped around Arabic from the start.

The difference shows up in the failure cases. A system with Arabic added on top handles clean Modern Standard Arabic and degrades on dialect, on domain register and on mixed-script documents, which is most of what a government archive actually contains. Those are not edge cases in this region. They are the normal input.

What auditability means when someone actually asks

Every serious procurement process eventually asks how a decision was reached. For a retrieval-based system that answer is straightforward: the response is built from retrieved passages and carries them, so it can be traced back to the source document.

For anything with autonomy the answer has to be a trace: the input, the tool that was called, what came back, the decision, the output. If a system cannot reconstruct why it did something three weeks later, it should not be making that decision unsupervised in a government process. This is also why an agent that changes state either has to be idempotent or has to wait for a person.

Monitoring the thing most dashboards miss

Uptime monitoring tells you the system responded. It does not tell you whether the answer was any good. A system that is fast and confidently wrong looks perfectly healthy on a standard dashboard, and that is precisely the failure mode that matters once real users depend on it.

So quality is monitored alongside availability: sampled output review, retrieval hit rate, and the rate at which the system declines to answer. A sudden drop in declines usually means the system has started guessing.

What changes between the pilot and the third year

Accuracy drifts. Language moves, new document types arrive, and people ask in ways nobody anticipated during the pilot. Retraining triggered by measured drift rather than by a calendar is the difference between a system that stays useful and one that quietly gets worse while everyone assumes it is fine.

The other thing that changes is the team. Written architecture decisions, reviewed code and a documented evaluation harness are not process for its own sake. They are what makes the system transferable rather than resident in one engineer’s head, and that is a question every procurement reviewer should ask and few do.