Multi-Region AI Governance Deployment

Organizations operating across jurisdictions need AI governance that respects data residency requirements, minimizes latency, and survives regional outages. This guide covers architecture patterns for deploying Keeptrusts gateways across multiple regions.

Use this page when

You need to deploy Keeptrusts gateways across multiple geographic regions for data residency.
You are implementing regional policy overlays (GDPR, CCPA, PDPA) on top of a shared base config.
You need DNS-based geographic routing with active-passive failover between regions.
You want each region's event data to stay local unless explicitly exported.

Primary audience

Primary: Technical Engineers
Secondary: AI Agents, Technical Leaders

Architecture overview

US users ──→ US gateway (kt gateway) ──→ US LLM provider
                 │
                 └──→ POST /v1/events → US API instance

EU users ──→ EU gateway (kt gateway) ──→ EU LLM provider
                 │
                 └──→ POST /v1/events → EU API instance

APAC users ──→ APAC gateway (kt gateway) ──→ APAC LLM provider
                   │
                   └──→ POST /v1/events → APAC API instance

Each region runs its own gateway and control-plane API. Event data stays within the region unless explicitly exported.

Regional gateway configuration

Each gateway instance loads a region-specific policy config. Common policy rules live in a shared base; regional overrides enforce local requirements.

Base policy config (`base-policy.yaml`)

version: "1"
policies:
  - name: pii-redaction
    type: output
    action: redact
    patterns:
      - type: regex
        pattern: '\b\d{3}-\d{2}-\d{4}\b'
        label: us-ssn
      - type: regex
        pattern: '\b[A-Z]{2}\d{6}[A-Z]\b'
        label: eu-national-id

  - name: prompt-injection-guard
    type: input
    action: block
    detect:
      - prompt_injection

EU regional overlay (`eu-policy.yaml`)

version: "1"
extends: base-policy.yaml

policies:
  - name: gdpr-data-residency
    type: input
    action: block
    conditions:
      - field: target.provider_region
        not_in: [eu-west-1, eu-central-1, eu-north-1]
    message: "Blocked: provider must be in an EU region for GDPR compliance."

  - name: eu-ai-act-disclaimer
    type: output
    action: append
    text: "This content was generated by an AI system."

US regional overlay (`us-policy.yaml`)

version: "1"
extends: base-policy.yaml

policies:
  - name: us-data-boundary
    type: input
    action: block
    conditions:
      - field: target.provider_region
        not_in: [us-east-1, us-west-2]
    message: "Blocked: provider must be in a US region."

Running regional gateways

Start each gateway with its region-specific config:

# EU region
KEEPTRUSTS_API_URL=https://eu-api.keeptrusts.com \
kt gateway run \
  --config eu-policy.yaml \
  --port 41002

# US region
KEEPTRUSTS_API_URL=https://us-api.keeptrusts.com \
kt gateway run \
  --config us-policy.yaml \
  --port 41002

# APAC region
KEEPTRUSTS_API_URL=https://apac-api.keeptrusts.com \
kt gateway run \
  --config apac-policy.yaml \
  --port 41002

Geographic routing

Use DNS-based geographic routing (Route 53, Cloud DNS, Cloudflare) to send users to the nearest gateway:

gateway.yourcompany.com
  → US users   → us-gateway.internal:41002
  → EU users   → eu-gateway.internal:41002
  → APAC users → apac-gateway.internal:41002

Applications use a single gateway hostname. DNS resolves to the regional instance based on client IP geolocation.

Data residency enforcement

The gateway enforces data residency at two levels:

Provider routing — policy rules restrict which provider regions a request can reach (shown above in the regional overlays).
Event storage — each regional API instance writes events to a region-local database. Events never leave the region unless an explicit export job is created.

Validate the configuration before deploying:

kt policy lint --file eu-policy.yaml
kt policy lint --file us-policy.yaml

Regional failover

If a regional gateway becomes unavailable, route traffic to a secondary region while maintaining data residency:

Active-passive failover

Primary: eu-gateway.internal:41002
  └─ health check: GET /v1/models (every 10s)

Failover: eu-backup-gateway.internal:41002
  └─ promoted when primary fails 3 consecutive checks

Configure your load balancer or DNS provider with health checks against the gateway's /v1/models endpoint.

Cross-region failover with policy constraints

When failing over to another region, a stricter policy can prevent data residency violations:

policies:
  - name: failover-residency-guard
    type: input
    action: block
    conditions:
      - field: meta.failover_region
        exists: true
      - field: target.provider_region
        not_in: [eu-west-1, eu-central-1]
    message: "Cross-region failover blocked: data residency constraint."

Latency optimization

Edge gateway placement

Deploy lightweight gateway instances at edge locations. These evaluate input policies locally and forward approved requests to the nearest LLM provider:

Edge (CDN PoP)
  → kt gateway (input policy only, <10ms overhead)
    → nearest LLM provider endpoint

Connection pooling

Configure the gateway's upstream connection pool per region to avoid cold-start latency:

upstream:
  connection_pool:
    max_idle: 50
    idle_timeout_secs: 60

Config sync across regions

Use the Keeptrusts API to push configuration updates to all regional gateways simultaneously.

Push config via API

# Upload a new configuration version
curl -X POST \
  -H "Authorization: Bearer $KEEPTRUSTS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d @config-payload.json \
  https://api.keeptrusts.com/v1/configurations

Git-based config sync

Link a Git repository to each regional API instance. When you push a config change, all regions pull the update on the next sync cycle:

# Verify config status across regions
for region in us eu apac; do
  echo "=== $region ==="
  curl -s -H "Authorization: Bearer $API_KEY" \
    "https://${region}-api.keeptrusts.com/v1/configurations" \
    | jq '.data[0].version'
done

Compliance zones

Map regulatory frameworks to regional gateway deployments:

Zone	Regions	Key policies
EU / GDPR	eu-west-1, eu-central-1, eu-north-1	Data residency, AI Act disclaimer, PII redaction
US / CCPA	us-east-1, us-west-2	US data boundary, SSN redaction, audit logging
APAC / PDPA	ap-southeast-1, ap-northeast-1	APAC data boundary, local consent enforcement
Sovereign	gov-cloud regions	Air-gapped gateway, no external egress

Each zone runs its own policy overlay extending the shared base config.

Monitoring across regions

Tail events from a specific region:

kt events tail --follow --api-url https://eu-api.keeptrusts.com

Query events across regions by hitting each regional API:

for region in us eu apac; do
  echo "=== $region ==="
  curl -s -H "Authorization: Bearer $API_KEY" \
    "https://${region}-api.keeptrusts.com/v1/events?limit=5" \
    | jq '.data[] | {id, decision, region: .metadata.region}'
done

Summary

Concern	Solution
Data residency	Regional policy overlays + region-local event storage
Geographic routing	DNS-based geolocation to nearest gateway
Failover	Active-passive with health checks on `/v1/models`
Latency	Edge gateways + connection pooling
Config sync	Git-linked repos or API push to `/v1/configurations`
Compliance zones	Zone-specific policy overlays extending a shared base

For AI systems

Canonical terms: Keeptrusts gateway, multi-region deployment, policy overlay, extends: directive, data residency, geographic routing, compliance zone, regional API instance.
Key config: target.provider_region condition, extends: base-policy.yaml, DNS geolocation routing, per-region DATABASE_URL and API key.
CLI commands: kt events tail --api-url https://eu-api.keeptrusts.com, kt policy lint.
Best next pages: AWS deployment, Azure deployment, GCP deployment, Terraform IaC.

For engineers

Prerequisites: Multiple cloud regions provisioned, DNS service with geolocation routing (Route 53, Cloud DNS, Azure Traffic Manager), per-region database instances.
Validate: Query each regional API's /v1/events to confirm events stay local; test that EU gateway blocks non-EU provider regions.
Config sync: Use Git-linked repos to push the same base + overlay configs to all regional API instances simultaneously.
Failover: Health check /v1/models on each gateway; DNS failover redirects traffic to the next-nearest region if health check fails.

For leaders

Data sovereignty: Event data stays within the originating region — meets GDPR, CCPA, and sector-specific data residency requirements.
Latency: Geographic routing ensures users hit the nearest gateway, reducing AI call latency.
Resilience: Regional failures don't cascade — each region operates independently with its own database and API instance.
Cost: Multi-region multiplies infrastructure costs proportionally; evaluate which regions require full deployments vs. failover-only.

Next steps

Deploy on AWS for ECS/Fargate regional deployment
Deploy on Azure for AKS regional deployment
Deploy on GCP for Cloud Run regional deployment
Terraform IaC for declarative multi-region infrastructure

Use this page when​

Primary audience​

Architecture overview​

Regional gateway configuration​

Base policy config (base-policy.yaml)​

EU regional overlay (eu-policy.yaml)​

US regional overlay (us-policy.yaml)​

Running regional gateways​

Geographic routing​

Data residency enforcement​

Regional failover​

Active-passive failover​

Cross-region failover with policy constraints​

Latency optimization​

Edge gateway placement​

Connection pooling​

Config sync across regions​

Push config via API​

Git-based config sync​

Compliance zones​

Monitoring across regions​

Summary​

For AI systems​

For engineers​

For leaders​

Next steps​