Most teams treat data residency as a procurement detail. They design the system, build the models, wire the pipelines, and then, near the end, ask where the servers sit and whether the contract says the right things. In Saudi Arabia, that order is backwards. Residency is not the last question. It is the first one, because it decides almost every architectural choice that follows.
The reason is structural. Residency is not a single rule you satisfy with a single location. It is the point where four regulatory regimes meet the physical reality of where data lives, where computation happens, and who can reach both. Get the order right and the system is compliant by construction. Get it wrong and compliance becomes a permanent retrofit, paid for every quarter in audits, exceptions, and rework.
Four Regulators, One Surface
A system that handles Saudi data operates under at least four authorities at once. The Personal Data Protection Law (PDPL) governs how personal data is collected, processed, transferred, and localised. The National Cybersecurity Authority (NCA), through its Essential Cybersecurity Controls (ECC), governs how the system is protected and how that protection is evidenced. The Saudi Data and AI Authority (SDAIA) sets national direction on data governance and the responsible use of AI. The Communications, Space and Technology Commission (CST) governs the connectivity, cloud, and infrastructure layer beneath all of it.
The common mistake is to read these as four separate compliance chores, each owned by a different team, each closed out on its own checklist. That framing produces four parallel projects that touch the same data and contradict each other at the seams. The teams discover the contradictions late, usually during an audit, when the cost of resolving them is highest.
PDPL, NCA, SDAIA and CST are not four chores. They are one operating surface, and a system designed against that surface is cheaper to run than one patched to satisfy it.
The more accurate reading is that these four regimes describe one operating surface. They overlap because they are looking at the same thing from different angles: where data sits, how it moves, how it is protected, and how its use can be accounted for. A residency decision touches all four at the same moment. Choosing where a model runs is simultaneously a PDPL question about transfer, an NCA question about control boundaries, a SDAIA question about governance, and a CST question about infrastructure. When you design against the surface rather than the four checklists, the contradictions never form, because the single decision was made with all four constraints in view.
Why Residency Changes the Architecture
Residency is often described as where data is stored. That is the smallest part of it. In an operational AI system, residency decides three things that reach far deeper into the design.
First, where models run. If personal or regulated data cannot leave Saudi soil, inference cannot leave it either. That rules out the default pattern of sending data to a model hosted elsewhere and rules in models that run inside the Kingdom, on infrastructure that satisfies CST and NCA expectations. This is not a deployment toggle flipped at the end. It changes which models are viable, how they are served, and how they are updated.
Second, where data is stored and queried. Storage location is the easy half. The harder half is query: a question that joins resident data with a service hosted abroad can move regulated data across a boundary without anyone intending it. Residency therefore constrains the data model itself, where joins are allowed to happen, where lineage must be captured, and how an Arabic-native query is resolved without leaking the rows it reads.
Third, how lineage and audit work. When data must stay in place, the record of what happened to it must stay in place too. Lineage cannot be an export to an external observability vendor. It has to be a first-class property of the system, captured where the data lives, queryable by a regulator without a foreign round trip. This is exactly the operating-picture problem that Marsad is built to hold: a single, governed account of the data model, its lineage, and who touched what, expressed in Arabic and answerable in place.
None of these three are configuration. Each is a structural decision that, once residency is fixed, cascades through model serving, the data model, and the audit layer. That is why residency belongs at the first decision, not the last.
Arabic-Native by Design
There is a related mistake that is just as expensive. Teams build the system in English, reason about it in English, and then add Arabic as a presentation layer near the end: a translation pass over the interface, a right-to-left stylesheet, a glossary. The operating logic underneath stays English.
This fails in operation. The entities a Saudi operator works with, the names of places, units, roles, document types, and the categories a regulator expects, are Arabic first. When the ontology is English and Arabic is bolted on top, the system answers Arabic questions by translating them into an English model and translating the answer back. Meaning is lost at both crossings. Worse, the audit record is in the wrong language: a regulator reading an Arabic-native operation cannot accept an account that was reasoned in English and rendered into Arabic after the fact.
Arabic-native operation is therefore an architectural choice, not a translation feature. The ontology is defined in Arabic from the start. Queries are resolved against Arabic entities directly. The decision record is written in the language the operator and the regulator actually use. This is the same principle BOST applies everywhere: ontology before automation. Define what the entities are, in the language they live in, before you automate anything on top of them. A translation layer added at the end can never recover the structure that an Arabic-native ontology had from the first decision.
Built for Audit from Day One
The cheapest audit is the one the system was built to produce. The most expensive is the one reconstructed after the fact from logs that were never designed to answer the question.
Audit-as-retrofit is the common path. The system ships, it works, and then a regulator or an internal review asks who accessed a record, why a model made a decision, and where a piece of data has been. The team goes looking for evidence that was never captured as a first-class fact, stitches together partial logs from several systems, and produces an account that is plausible but not provable. Every such audit costs the same effort again, because nothing about the retrofit made the next one easier.
Audit-from-day-one inverts this. The decision record is a designed output of the system, not a byproduct. Every action that matters in the field carries its own justification at the moment it happens, captured in place, in Arabic, against the same governed ontology the operating picture uses. This is the Maydan discipline: field action that writes its own audit as it acts, so the account exists before anyone asks for it. And because residency keeps that record inside the Kingdom, the regulator can read it where it lives, without a transfer that would itself need to be justified.
The handover test is the one that matters. A system is only compliant if its compliance survives the people who built it leaving. That is the Mashhad concern: operating continuity, the property that the operating picture, the decision record, and the governance around them remain legible and answerable after handover, to a new operator and to a regulator alike. A residency and audit architecture that only its authors can explain has not been built for audit. It has been built to pass one inspection.
None of this is harder than the alternative. It is the same work, done in the right order. Residency first, because it decides where models run and where data is queried. The surface, not the four checklists, because the contradictions never form when the single decision sees all four constraints. Arabic-native from the start, because meaning and audit both live in the operator's language. Audit as a designed output, because the cheapest evidence is the evidence the system was built to produce. The order is the whole point. Measure the result by what survives the handover.