Skip to content

Data residency#

Where your data lives — and why that matters for BFSI India, US healthcare, and EU AI Act compliance.

The rules, summarized#

Jurisdiction Residency rule Deadline Consequence
India BFSI RBI Master Direction on IT Outsourcing (Apr 2023) + DPDPA SDF compliance Nov 13, 2026 (MeitY proposing earlier) Core banking data must be stored + processed in India
US healthcare HIPAA + HITECH + state laws (CCPA, NYSHIELD, …) live PHI access controlled by BAA; US-region preferred for US patients
EU GDPR + EU AI Act high-risk provisions Aug 2, 2026 High-risk AI systems face €35M / 7% global turnover penalties; CLOUD Act exposure for US-HQ providers

Default deployment regions#

The managed SaaS + the Helm chart support:

Region code Cloud Use for
ap-south-1 AWS Mumbai India BFSI (primary)
ap-south-2 AWS Hyderabad India BFSI (secondary)
asia-south1 GCP Mumbai India BFSI (alt)
centralindia Azure Pune India BFSI (Azure-first enterprises)
eu-west-3 AWS Paris EU AI Act high-risk (primary)
europe-west3 GCP Frankfurt EU (alt)
westeurope Azure Netherlands EU (Azure-first)
us-east-1 AWS N. Virginia US (HIPAA-eligible)
us-west-2 AWS Oregon US (secondary)

What stays in region#

Everything: - Postgres (runs, events, denials, plugin registry, approvals) - Object storage (pipeline_runs/, models, audit PDFs) - LLM inference requests (if using regional LLM endpoints — see below) - Logs (application + security) - Backups

What does NOT stay in region by default: - LLM provider requests. Anthropic's default endpoint is US-hosted. OpenAI standard endpoint is also US. See below.

Regional LLM endpoints#

Anthropic#

  • US — https://api.anthropic.com (default)
  • EU — available for enterprise customers; negotiate with Anthropic
  • India — not available as of April 2026; use Azure OpenAI or self-hosted vLLM

OpenAI#

  • US — https://api.openai.com (default)
  • EU — data residency available on Enterprise tier with zero-retention contract
  • India — via Azure OpenAI regional deployment in centralindia

Azure OpenAI#

All Azure-deployed OpenAI models inherit Azure region residency. Primary choice for India + EU strict residency.

Self-hosted vLLM#

Full residency control. Host anywhere. See How-to: Bring your own LLM.

CLOUD Act exposure#

The tricky one. Even if you deploy a US-HQ cloud provider's infrastructure in the EU, data may still be subject to US government compulsion under the CLOUD Act (2018).

For EU AI Act high-risk use cases where the prospect's legal team raises this:

  • Option 1: Non-US-HQ cloud in EU region (OVHcloud, IONOS, Scaleway, Hetzner)
  • Option 2: Customer-VPC on their infrastructure with BYOK (they control keys; US-HQ cloud provider cannot decrypt even if compelled)
  • Option 3: Air-gapped on-prem

Managed SaaS on AWS/GCP/Azure in EU region is usually acceptable to moderate-risk customers; strict customers want Option 1 or 2.

BYOK — Bring Your Own Key#

Customer controls KMS keys; swarm uses them via envelope encryption.

Supported backends#

  • AWS KMS (including multi-region keys)
  • GCP Cloud KMS
  • Azure Key Vault
  • HashiCorp Vault (with Transit engine)

How it works#

  customer data
       │
       ▼
  swarm requests envelope encryption
       │
       ▼
  KMS (customer-owned) wraps a DEK
       │
       ▼
  wrapped DEK stored alongside data
       │
       ▼
  at read: unwrap DEK via KMS → decrypt data

swarm never holds raw key material. If the customer revokes the KMS key, their data becomes unrecoverable (including by us). This is the contract.

Enabling BYOK#

byok:
  enabled: true
  provider: aws-kms
  keyArn: "arn:aws:kms:ap-south-1:..."
  serviceAccount:
    eksRoleArn: "arn:aws:iam::...:role/swarm-byok-access"

module "swarm" {
  ...
  enable_byok        = true
  kms_key_admin_arns = ["arn:aws:iam::..."]
}

Auditing BYOK usage#

Every Encrypt / Decrypt KMS call lands in the customer's CloudTrail / Cloud Audit Log. Reconcile against swarm's own logs:

# swarm side
curl /api/v1/audit/kms-usage?since=86400

Returns count + DEK IDs. Should match customer-side CloudTrail events.

Cross-region data flow (disallowed by default)#

swarm does NOT move data between regions unless explicitly configured. In particular:

  • A pipeline run's conversation journal never replicates cross-region
  • Object-storage buckets are per-region
  • The only cross-region flow, if enabled, is audit PDF consolidation (e.g. daily rollup shipped to the customer's EU-region reporting bucket)

If you enable cross-region rollups, it's documented in the audit PDF header (cross_region_rollup: true).

Zero-egress mode#

For zones that cannot allow any egress (defense, some banking cores):

security:
  networkPolicy:
    enabled: true
    denyAllEgress: true
    # LLM calls go to customer-hosted vLLM; no external API allowed
  externalLLM:
    enabled: false
    vllmEndpoint: https://vllm.customer.internal/v1

swarm still functions; LLM inference stays fully inside the customer's perimeter.

Compliance mapping#

Indian BFSI — RBI MD-ITO#

  • ✅ Storage in India — ap-south-1 / asia-south1 / centralindia default
  • ✅ Processing in India — all compute in same region
  • ✅ Exit plan — operator can migrate out (documented in backup/restore procedure)
  • ⚠ Third-party risk — if using Anthropic / OpenAI, document the sub-processor relationship per MD-ITO para 10.2

US Healthcare — HIPAA#

  • ✅ BAA — with swarm (signed); with your LLM provider (customer responsibility to negotiate with Anthropic / OpenAI / Microsoft)
  • ✅ PHI in-region — us-east-1 / us-west-2 default
  • ✅ Audit trail — 6-year retention (HIPAA § 164.316)
  • ✅ BYOK — customer KMS ensures PHI encryption-at-rest even if swarm compromised

EU AI Act high-risk#

  • ✅ EU-region processing — eu-west-3 / europe-west3 / westeurope
  • ✅ Annex IV technical documentation — produced by compliance profile
  • ⚠ CLOUD Act — discuss with customer; strict customers prefer non-US-HQ provider or customer-VPC
  • ✅ 10-year record retention — default retention config for EU AI Act profile

Next#