Data Residency and AI Governance

Data Location Is a First-Class Concern

A decade ago, "where is the data?" was a question asked mostly by regulated industries. Financial services, healthcare, and government agencies cared about data location. Everyone else was happy to let their cloud provider handle it.

That has changed completely. GDPR made data residency a legal requirement for any organization handling EU personal data. Brazil's LGPD, China's PIPL, India's DPDP Act, and dozens of other national regulations followed. Today, virtually every organization operating internationally must think about where their data lives.

For AI governance, data residency is especially important because the governance layer processes metadata about every AI agent action. That metadata may include references to users, resources, and systems that fall under data residency requirements. If an AI agent in the EU processes a customer request, and the governance evaluation happens on a server in the US, you may have a compliance problem.

What Governance Data Contains

Understanding data residency requirements for AI governance starts with understanding what data the governance system processes.

Intended processes three categories of data. Intent metadata describes what an AI agent wants to do: the action type, the target resource, the parameters, and the agent identity. This metadata may include references to personally identifiable information (a customer ID, a user email) even though the PII itself is not transmitted to Intended.

Decision records document the governance evaluation: the policy that was applied, the risk score, and the outcome. Decision records include the intent metadata plus the evaluation results.

Audit records are the hash-chained entries that provide tamper-evident proof of governance. They include decision records plus chain hashes and timestamps.

The key distinction: Intended processes metadata about actions, not the underlying data itself. If an agent reads a customer record, Intended sees "agent X read customer record Y in production" but does not see the customer record's contents. This significantly reduces the data classification burden, but it does not eliminate residency concerns because the metadata itself may be regulated.

Multi-Region Architecture

Intended's managed cloud offering supports multi-region deployment. Each region operates as an independent Intended instance with its own compute, database, and audit ledger.

Currently available regions: US (us-east-1, us-west-2), EU (eu-west-1, eu-central-1), and APAC (ap-southeast-1). Additional regions are available for single-tenant and on-premise deployments.

When an organization selects a region, all governance data for that organization is processed and stored within that region. Intent metadata, decision records, audit records, policies, and configuration are all region-local. No governance data crosses regional boundaries.

For organizations operating in multiple regions, Intended supports multi-region configurations where different organizational units are assigned to different regions. The EU subsidiary uses the EU region. The US headquarters uses the US region. Each region has its own governance data, and the data does not cross the boundary.

Cross-Region Considerations

Multi-region deployment introduces governance consistency questions. If the EU region has one set of policies and the US region has another, how do you maintain consistent governance across the organization?

Intended addresses this through policy replication. Policies are authored centrally and replicated to each region. The policy content (the rules themselves) is replicated. The governance data (intents, decisions, audit records) is not. This means policies are globally consistent while data remains regionally isolated.

Policy replication is one-way: from the central policy repository to each region. Changes made in the central repository are propagated to all regions within a configurable sync interval (default: 5 minutes). Regions cannot modify their local copy of replicated policies.

Organizations can also define region-specific policies that apply only in a particular region. This is useful for region-specific regulatory requirements. The EU region might have additional policies for GDPR compliance that do not apply in other regions.

Data Sovereignty vs Data Residency

Data residency and data sovereignty are related but different concepts.

Data residency means data is stored in a specific geographic location. GDPR, for example, requires that EU personal data either stays in the EU or is transferred only to countries with adequate data protection (or under approved transfer mechanisms like Standard Contractual Clauses).

Data sovereignty means the data is subject to the laws of a specific country, regardless of where it is stored. This is a stronger requirement: not only must the data be in the right place, but it must also be governed by the right legal framework.

Intended addresses data residency through multi-region deployment. Data stays in the selected region. We address data sovereignty through deployment model selection. For organizations with strict sovereignty requirements, on-premise deployment ensures that the data is not only in the right location but also under the organization's direct control, subject only to local law.

Transfer Mechanisms

Some organizations need to transfer governance data across regions for analysis, reporting, or centralized compliance review. Intended supports controlled data transfer with appropriate safeguards.

Aggregated analytics can be transferred across regions. These are statistical summaries (decision counts, risk score distributions, escalation rates) that do not contain individual intent metadata. Aggregated analytics support centralized reporting without transferring governed data.

Evidence exports for compliance audits can be transferred under appropriate legal mechanisms (Standard Contractual Clauses for GDPR, or whatever transfer mechanism the organization uses for other data). The export is encrypted in transit and at rest, and access is controlled through the organization's data governance policies.

Raw governance data (individual intent records, decision records, audit entries) is never automatically transferred across regions. If an organization needs to transfer raw data, they must explicitly initiate the transfer and confirm the legal basis for the transfer.

Encryption and Key Management

Data residency is not just about physical location. It is also about who can access the data. Encryption key management is a critical component of data residency compliance.

In Intended's managed cloud offering, each region has its own encryption keys managed through the regional KMS (Key Management Service). Keys do not leave the region. Data encrypted in the EU region cannot be decrypted by Intended infrastructure in the US region.

For organizations that require additional key control, Intended supports customer-managed keys (BYOK). The organization provides their own encryption keys through their regional KMS, and Intended uses those keys for data encryption. The organization retains full control over the keys and can revoke access at any time by disabling the keys.

For on-premise deployments, the organization manages all encryption keys locally. Intended's software uses the keys but never stores or transmits them outside the local environment.

Regulatory Mapping

Here is how Intended's data residency capabilities map to specific regulatory requirements.

**GDPR (EU).** Deploy in the EU region. All governance data stays in the EU. Policy replication from central to EU region uses encrypted channels. Evidence exports for non-EU auditors use Standard Contractual Clauses. Customer-managed keys available for additional control.

**LGPD (Brazil).** Deploy in a South American region or use on-premise deployment. Same data isolation guarantees as EU deployment.

**PIPL (China).** On-premise deployment within China. Air-gapped option available for organizations with strict network isolation requirements. All data processing occurs within China.

**DPDP (India).** Deploy in APAC region or on-premise. Data residency within India for on-premise deployments.

**US State Privacy Laws.** US regional deployment. Data stays within the US. No cross-border transfer concerns for domestic operations.

Data residency is not a nice-to-have feature. It is a requirement for any organization operating internationally. Intended treats data location as a first-class architectural concern, not an afterthought, because that is what compliance demands.