Track 07 · Data & governanceLesson 07 of 11
Data residency and sovereignty
Where tokens are processed is in the contract; design the deployment to match.
- Specialisation · Government
- 30 min read
- 60 min hands-on
- Pro
What you'll be able to do
01- Explain the difference between residency, sovereignty and localisation, and between where data is stored, processed and accessed from.
- Identify the legal basis for a cross-border flow: GDPR adequacy, Standard Contractual Clauses with a transfer impact assessment, India's DPDP Act and Rules, or a sector rule such as RBI's payment data direction.
- Inventory every place an agent's data goes, including traces, caches, embeddings, eval sets, backups, failover routes and support access.
- Choose a model provider's regional option for each data class and defend it with the provider's documented commitments.
- Implement a residency checker that flags violations in a deployment manifest, including flows nobody declared.
- Defend a residency design to a DPO and a CISO with a residency matrix and the contracts behind it.
Before you start
- Finding where the data really lives: the source map's region column is the starting point.
- Finding and masking personal data: tokenisation changes what a flow carries, and so which rules apply.
- Querying a month of traces: traces and eval sets are data stores in their own right.
- Secrets, dependencies and network isolation: egress controls enforce what this concept decides.
- Beyond English: language, script and region: which models exist in which regions.
The short version
Residency asks "in which jurisdictions may this data be stored, processed and accessed?", per data class, backed by law, regulation and contract. Sovereignty asks "whose law can reach this data, and who controls the keys and the operators?". Agents make both hard because they copy data into places the architecture diagram does not show: a model endpoint that routes globally, a trace exporter pointing at a SaaS tool on another continent, an eval set sampled into a shared bucket, a fallback route added during a load test. Your job is to name every artefact, attach a region and a legal basis to each, pick model endpoints whose documented processing location matches the policy, and prove it with a checker and network evidence. How to build the regional stacks (VPC, self-hosted, air-gapped) belongs to Self-hosted, VPC and air-gapped.
- Stored, processed and accessed are three separate commitments. Storage in the EU says nothing about where inference runs. Remote access from abroad can itself be a transfer.
- Defaults are usually global. Residency is something you select, pin in IaC and verify.
- Every copy carries the source's rules. Traces, eval data, caches, embeddings and backups included.
- The legal basis is per flow. "The vendor is GDPR compliant" is not a transfer mechanism.
- Evidence beats assertion. A manifest checked in CI, egress logs and the provider's documented commitment are what a DPO signs.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI