There is a reason for the shrug. Applicability in the Gulf is not a property of a company — it is a property of a legal entity, in a jurisdiction, holding a licence, doing a particular thing with particular data. A group with a mainland UAE trading arm, a DIFC-licensed advisory business and a Saudi joint venture does not have one obligation set. It has three, and they overlap only partly.

Why the safe answer is the expensive one

Faced with that, the defensible-looking move is to apply the strictest requirement everywhere. It feels conservative. In practice it means building model validation for systems nobody supervises, writing registers nobody will read, and appointing roles the entity does not need — while the one obligation that genuinely bites goes unnoticed, because it was buried in a list of forty.

An obligation set you cannot justify line by line is not a compliance position. It is a budget.

What a determination has to produce

A determination is worth something only if every line carries the clause that puts it there, and if it is willing to say no. Four outcomes, not two: applicable, with the trigger; conditionally applicable, with the condition stated plainly, so you know what would change the answer; not applicable, with the reason; and watchlist, for what is proposed but not yet in force.

The third of those is the one that saves money, and it is the one nobody wants to sign. Telling a client that a rule does not reach them is a position you have to be prepared to defend to their regulator. That is precisely why it is worth paying for, and why it cannot be produced by a model that infers an answer from patterns. Applicability is deterministic or it is worthless.

The order matters

Discovery before determination sounds sensible — find the systems, then work out the rules. It is backwards. Which questions are worth asking about a system depends on which obligations reach the entity that runs it. Start from the obligations and the inventory scopes itself. Start from the inventory and you catalogue everything, learn nothing, and still have to do the determination afterwards.

Ask a business unit to list its AI systems and it will name the things that were procured as AI: the chatbot, the document tool, the model somebody's data science team trained. That list is real, and it is the smallest part of the estate.

Three layers, and only one of them declares itself

The declared layer comes out of interviews. The detected layer comes out of read-only connectors into the cloud accounts — endpoints, model deployments, inference spend — and it routinely contradicts the interviews, because a team stood something up in a sandbox eighteen months ago and it quietly became load-bearing.

The third layer is the one that matters most and is hardest to see: AI embedded in software the enterprise bought for another reason entirely. Scoring inside a lending platform. Anomaly detection inside a fraud engine. Ranking and summarisation shipped into an ERP module or a service desk in a vendor release note nobody read. None of it was procured as AI. All of it can be caught by an instrument that defines AI by what a system does rather than what it is called.

The exposure is rarely in the system you built. It is in the feature that arrived in an upgrade.

Why this is a systems problem first

Finding embedded AI is not a governance skill. It is the ability to read an enterprise landscape — to know which modules of a given ERP suite acquired inference capability in which release, which vendor SaaS products enabled a model by default, and where the integration layer is quietly calling a third-party API. A governance specialist who cannot read an architecture will produce a register of the things people volunteered.

What good looks like

Each system carries where it was found and how, so the register can be argued rather than asserted. Each one is risk-classified on evidence, not on the owner's opinion. And the whole thing has an expiry, because an inventory is a photograph: models change, vendors ship, and a register nobody refreshes is a document that was true once.