# Data Residency

The platform is multi-region aware. Each service reads its deployment region from environment configuration at startup, enabling deployments across multiple geographic regions. When a region is not explicitly configured, services default to a primary region and log a warning in non-development environments so operators can identify and update configurations before expanding to additional regions.

Amigo supports multi-region deployments where each workspace's data stays in a single geographic region. Data does not cross regional boundaries.

## Available Regions

| Region             | Platform API Endpoint                  |
| ------------------ | -------------------------------------- |
| **United States**  | `api.platform.amigo.ai`                |
| **Canada**         | `api-ca-central-1.platform.amigo.ai`   |
| **European Union** | `api-eu-central-1.platform.amigo.ai`   |
| **Australia**      | `api-ap-southeast-2.platform.amigo.ai` |

The global endpoint (`api.platform.amigo.ai`) routes to the correct regional infrastructure based on the workspace's configured region. Regional endpoints are available when API traffic itself must stay within a specific jurisdiction.

## Regional Isolation

Each workspace is bound to a single region. All data generated by that workspace - conversations, world model events, entity projections, call recordings, agent configurations - stays within the region's infrastructure. There is no cross-region data replication.

Data isolation is enforced at the storage layer. Each workspace's data is physically separated - this is structural isolation, not access control.

## Multi-Region Deployments

If you operate across multiple regions (for example, clinics in both the US and Canada), you create separate workspaces in each region. Each workspace has its own data store, its own phone numbers, and its own set of services. The [Deployment Model](/platform-overview/deployment-model.md) page covers multi-workspace tenancy patterns for this use case.

There is no cross-region data replication or migration between workspaces. If a patient transfers between a US clinic and a Canadian clinic, they exist as separate entities in each region's data store. This is intentional - some jurisdictions prohibit cross-border transfer of health data entirely.

## Choosing a Region

Region selection is permanent for a workspace. Choose based on:

* **Regulatory requirements**: Where must your patient data reside? US healthcare deployments typically require US residency for HIPAA. Canadian provincial health acts may mandate in-country storage. EU GDPR has specific rules about data transfer outside the EU.
* **Latency**: Voice calls are latency-sensitive. Choose the region closest to your patient population to minimize audio round-trip time. For text-based interactions, regional latency differences are negligible.
* **Existing infrastructure**: If your EHR systems are hosted in a specific region, co-locating your workspace in the same region minimizes latency for connector runner polling and write-back operations.

If you are unsure, start with the region where your primary patient population and EHR systems are located.

## PHI Handling

Protected health information is isolated at the workspace level. PHI is encrypted at rest and in transit. Workspace boundaries enforce that one clinic's patient data is not accessible to another clinic's workspace, even when both workspaces are in the same region.

Call recordings follow the same regional isolation. Recordings are stored in the workspace's region and are not replicated elsewhere. Time-limited access URLs for recordings are scoped to the requesting workspace.

## Compliance by Region

Region selection determines which jurisdiction's data protection rules apply to your deployment:

| Region             | Primary Frameworks                                            |
| ------------------ | ------------------------------------------------------------- |
| **United States**  | HIPAA, state-specific health information laws                 |
| **Canada**         | PIPEDA, provincial health information acts (PHIPA, HIA, PHIA) |
| **European Union** | GDPR, national health data regulations                        |
| **Australia**      | Privacy Act 1988, My Health Records Act 2012                  |

Amigo's regional isolation ensures that data stays within the jurisdictional boundaries your compliance team requires. Business Associate Agreements (BAAs) are executed per workspace. For audit and compliance controls, see [Compliance and Audit](/safety-and-compliance/compliance.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.amigo.ai/platform-overview/data-residency.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.