Saudi Arabia is an interesting place to build enterprise AI

I build software in Dammam, and most of my clients are operators in the Eastern Province. I want to describe what is actually distinctive about building enterprise AI here, from experience rather than from market commentary.

I am deliberately not quoting market size, adoption rates or growth figures. Those numbers circulate widely, they are frequently unsourced, and I have not verified any of them. What follows is what I see in the work.

The data question arrives immediately#

In most markets the "where does the data go" question surfaces at procurement, after the technical evaluation, when it is expensive to answer.

Here it is in the first meeting. Often the first ten minutes.

That is genuinely better. It means the architecture conversation happens while architecture is still cheap to change, and it filters out projects that were never going to survive their own compliance review. It also means you need a real answer rather than a reassuring one — and "everyone uses the cloud" is not a real answer to somebody whose board has already asked.

What I will not do is tell a client that running a model on-premise makes them compliant with PDPL. It does not. It is an architectural capability that supports an assessment their legal counsel has to make.

Arabic is a product requirement, not a localisation task#

Most international enterprise software arrives here as an English product with Arabic added. It shows, and the people using it notice.

Building Arabic-first changes what you build: retrieval tuned for Arabic legal language, interfaces designed in both directions from the start, terminology chosen for what practitioners actually say. That is a meaningful amount of work and it is a genuine differentiator, because the well-funded alternatives mostly have not done it.

For a smaller team, that is one of the few structural advantages available.

Nothing is greenfield#

The AI deployment fantasy is a clean problem and a new system. The reality is an organisation with an ERP, an access-control system, a document store, a maintenance platform and a directory that disagrees with all of them.

Enterprise AI here means integrating with what exists. Which means the interesting work is frequently not the model at all — it is reconciling two systems that model the same people differently, or getting structured data out of something that was never designed to give it up.

If you like integration work, this is a good place to be. If you wanted to build a chat interface, less so.

Buyers ask about ownership#

A recurring question: what happens if you stop working with us.

That is a good question and one that consumer-influenced AI products answer badly. It pushes toward architectures where the client owns their data, understands the system, and could operate it — which is more work and produces better software.

The honest downsides#

Talent depth is thinner than in larger markets, so hiring senior engineers is harder and takes longer.

Integration-heavy work is slower than product work, and less glamorous. A lot of the value is in unglamorous plumbing.

And the regulatory picture is one where I would defer to specialists. I build architectures that support a client's assessment; I do not make the assessment, and I would be cautious of anyone in a technical role who does.

Why I find it interesting anyway#

The constraints are real, which makes the engineering real. Data that cannot move, a language that has to be first-class, systems that already exist and buyers who ask hard questions early — that is a more interesting set of problems than building another wrapper, and it is much harder to do superficially.