What data residency actually requires in a government AI project

Data residency is easy to promise and hard to prove. Every proposal we compete against contains a sentence saying that data will remain inside the country. Very few of them say which data, at which moment, on whose hardware, and who would notice if that stopped being true. The distance between that sentence and the actual architecture is where government AI projects get into trouble, usually about two years after signature, and usually in public.

We have been running a phone-use and seat-belt violation detection system for Tahakom in Saudi Arabia since 2018, and we spent 2026 on the digital transformation of the Land and Tax Department in Palestine. In both, residency is not a compliance formality. It shapes where the servers sit, which libraries we may link against, and what the support model looks like for the next decade.

The three ways the promise quietly breaks

The first is inference. A model that is called over an API endpoint sends its input to whoever runs that endpoint. For a traffic system the input is a cropped image of a driver in a vehicle, which is personal data by any reading. Nobody in the department made a decision to export that image. An engineer chose a convenient library and the library had a hosted default.

The second is telemetry. Monitoring, error tracking and analytics products are built to ship data to their own backends, because that is their business model. A stack trace is not usually sensitive. A stack trace with a national ID in the request body is. Log lines leak more than anyone expects, and they leak continuously rather than once.

The third is training. Somebody wants to improve accuracy, so they take a sample of real production images to a machine with a good GPU. That machine is often a rented cloud instance in a region nobody wrote down. The data leaves on a laptop or in an object-storage bucket and never comes back under the department's control. This is the hardest failure to reverse, because a model trained on exported data carries the problem into every future version.

None of these require bad faith. They require only ordinary engineering convenience, and nobody asking the question in writing before the first commit.

Four questions to settle before build starts

Where does inference run? Name the physical location, the owner of the hardware, and the network path. For our enforcement work the answer is the client's own GPU servers inside their own facility. If the answer is a cloud region, name the region, name the legal entity that operates it, and say who holds the encryption keys. "A local region of a global provider" is not an answer until you can say whether the provider's support staff abroad can read the volumes.

Where do logs and metrics go? Our default is Prometheus and Grafana running inside the client network, with retention set by the department and not by us. If a hosted monitoring product is genuinely needed, then every field that leaves has to be enumerated and redacted at source, not filtered at the far end. Filtering at the far end means the data already left.

Where are models trained and stored? Training data is the most sensitive artefact in the system, more sensitive than the production database, because it is a curated concentration of exactly the cases that matter. It should never leave the environment that produced it. Model weights are versioned in the same environment, with a record of which dataset version produced which weights. If the department cannot retrain without us, the residency guarantee has an expiry date.

Who can reach the system from outside? For most enforcement deployments the honest answer is nobody. Support happens on site, or through the client's own remote-access tooling, with sessions recorded and reviewable. That is slower for us. It is the only answer that survives an audit, because an audit will ask for the access log and a vendor VPN that bypasses the department's own gateway will not appear in it.

A worked example: one violation from camera to case file

Consider a single phone-use detection. A roadside camera captures a frame. A local process crops the driver region and runs the classifier on a GPU in the same rack. A candidate violation, with a confidence score, goes onto a queue inside the department network. A human reviewer opens it, confirms or rejects it, and the confirmed case moves to the enforcement system that issues the notice. The rejected ones are kept, because they are the material for the next accuracy review.

Now count the boundaries. Camera to edge server. Edge to GPU host. GPU host to queue. Reviewer to enforcement system. Each is a place where a well-meaning integration can introduce an outbound call. We draw this diagram before writing code, mark each arrow internal or external, and require a written justification for any arrow that leaves the building. In practice the diagram changes the design once, early, when changing it is cheap.

The review step is worth dwelling on. Departments often ask whether the human reviewer can be removed to save staff cost. The answer depends on what happens to a false positive. If it becomes a fine with a right of appeal, the reviewer is not overhead, it is the appeal process working before the citizen has to use it. That is a policy decision, not an engineering one, and the department should make it rather than inherit the vendor's default.

When residency is the wrong requirement

We do not think every system needs a sovereign deployment, and we say so in meetings where saying so costs us scope. Strict residency has real costs. You give up managed services, which means your team now operates the database, the queue and the object store. You give up elastic capacity, so peak load has to be bought as hardware up front and sits idle the rest of the year. You give up the fastest security patching path, because the patch now travels through your own change-control process rather than the provider's.

For a system holding citizen identity data, enforcement evidence, or land and tax records, those costs are clearly worth paying. For an internal booking tool, a public information portal, or a staff training platform with no personal data, they often are not, and insisting on residency there means the department spends its limited operations capacity on the wrong system. We would rather a department run three sovereign systems well than twelve badly.

There is also a middle position that tends to be under-used. Split the system. Keep the personal data, the inference and the audit trail inside the sovereign boundary, and let the static public website and the anonymous usage counters sit on ordinary infrastructure. This is safe only if the split is enforced by the network rather than by convention, and if somebody can demonstrate the enforcement rather than describe it.

What it costs, honestly

Money first. On-premise inference means buying GPUs on a refresh cycle, plus the rack space, power and cooling to match. Plan the hardware refresh before the software reaches end of life, and budget it at the start rather than discovering it in year four. Over a long deployment the total is not dramatically higher than equivalent cloud spend, but the shape differs: heavy at the start, and paid by a capital budget rather than an operating one, which for many departments is the harder conversation.

Then staff. A sovereign deployment needs people who can restore a database, rotate a key, and read a Grafana dashboard at two in the morning. They have to exist inside the department, be named, and be trained before we leave. Budgeting for the hardware and not for the engineers who will run it is the most common planning error we see.

Then time. Procurement, the security review and the network approvals will take longer than the first development milestone. Plan them as parallel work with their own owner, not as a gate after the build. Political capital matters too. Somebody has to defend a slower launch against a stakeholder who has seen a cloud demo that looked instant, and that defence is easier when the architecture diagram exists early and is legible to non-engineers.

What to put in the tender, and what to test before acceptance

Ask for the network diagram rather than the policy statement. A policy statement is a promise about intent. A diagram is a claim you can check. Ask for the software bill of materials, and for every third-party service in it, ask what is contacted, when, and with what payload. Ask who rotates the encryption keys, on what schedule, and what happens to the system if the person holding them leaves.

Put a clause in the tender requiring that the system pass an egress test at acceptance. The test is simple and we recommend the department run it rather than the vendor. Block all outbound traffic from the production network at the firewall, then exercise every major workflow: capture, inference, review, reporting, login, backup. Anything that breaks was making an external call that nobody declared. Then invert it: leave the network open, capture outbound connections for a full week including a month-end reporting cycle, and require the vendor to account for every destination in the capture.

Add a second clause on exit. The department should be able to rebuild the whole environment from its own repository, on its own hardware, without contacting us. Test that before final payment, with department staff at the keyboard and our engineers in the room only to observe. It is an uncomfortable afternoon and it is the single best predictor of whether the system will still be maintainable in five years.

A vendor that has actually delivered inside a sovereign environment will have these answers ready and will not be offended by the tests. Discomfort with the egress test is itself information.