← Resources
By Leila Haddad
— Solutions Architect, Enterprise
·
· GUIDE
AI Data Residency Japan EU US: A Practical Guide
I spend most of my week answering data-residency questions for enterprise customers — Japanese pharmaceutical firms, EU banks, US healthcare systems. The shape of the question is always the same: where does the data live, where does the inference happen, and what does the model provider keep? osFoundry's answer is per-region pinning by default and BYO Cloud for the strongest residency guarantee. Here's how the three big jurisdictions differ and what to actually check.
The three jurisdictions in 90 seconds
**Japan — APPI (Act on the Protection of Personal Information).** Personal data may leave Japan only with explicit consent or to a country with equivalent protections (EU is on that list; US is not unless the recipient is bound by APEC CBPR or contractual clauses). The 2022 amendment added mandatory breach notification within 3 days. Sensitive data (medical, criminal history) requires explicit consent for any processing, not just transfer.
**EU — GDPR.** Personal data of EU residents can be processed inside the EU freely. Transfers outside require either an adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules. The 2023 EU-US Data Privacy Framework restored some legal basis for US transfers but is being challenged again. Schrems III is a real risk.
**US — sectoral, not horizontal.** No general federal privacy law. HIPAA covers protected health information and requires Business Associate Agreements. FERPA covers student records. State laws (CCPA in California, CPRA, plus 18 other state laws as of 2026) impose patchy obligations. Defense and federal contracts add FedRAMP and ITAR. Most US enterprise residency questions reduce to 'is this covered data, and which sectoral law applies?'
What 'data residency' actually means at the AI layer
Residency is not one thing. At the AI layer it splits into at least six surfaces:
1. **Primary storage** — the database where source documents and chat history live.
2. **Vector indexes** — embeddings are derived data but can be reversed to original text with the right model; treat them as personal data.
3. **Inference compute** — where the model runs. A US-hosted Sonnet endpoint processes EU data the moment a prompt is sent.
4. **Logs and telemetry** — request logs, error traces, performance metrics. Often the most-overlooked surface.
5. **Prompt caching** — Anthropic, OpenAI, and others cache prompt prefixes for up to 60 minutes. That cache lives somewhere.
6. **Training data** — what the model provider may use to improve future models. This is what your enterprise contract clause governs.
A compliant residency story has to pin all six. Pinning only storage and missing logs is the most common mistake I see.
Common gotchas — logs, vector indexes, prompt caching
**Logs.** CloudWatch, Stackdriver, and Azure Monitor default to the region of the service, but a multi-region deployment can spray logs across regions if a global log aggregator is wired in. We had a customer discover their EU pharma logs were being shipped to a US-based observability vendor — a six-figure remediation.
**Vector indexes.** Pinecone's free and starter tiers run only in us-east-1. Weaviate Cloud has a similar story. If your residency story depends on EU-only data, you must self-host or use a managed vector store that supports EU regions explicitly. osFoundry uses pgvector inside per-workspace Postgres, which inherits the workspace's regional pin.
**Prompt caching.** When you enable Anthropic prompt caching, the cached prefix is stored in the region you sent the request to. Cross-region requests recompute the cache. If you want to keep prompts in-region, route inference through a regional endpoint and don't let load balancers spill cross-region.
**Embedding API calls.** Most embedding providers don't have regional endpoints. A Japanese customer sending a Japanese-language document to OpenAI's embedding API has just transferred that document to the US. We use Voyage AI's EU endpoint where available, and bundle local embedding models for the strict cases.
Per-region pinning in osFoundry
An osFoundry workspace is created with a region pin. The default for new workspaces is the region nearest the creator (ap-northeast-1 for Japan, eu-central-1 for Germany, us-east-1 for the US east coast). Once pinned, every workspace-owned resource — Postgres database, file storage bucket, vector indexes, Room App containers, knowledge graphs, audit logs — provisions in that region. Cross-region traffic is opt-in per integration.
For inference, the pin selects which model-provider endpoint we route to. Sonnet 4.6 has regional endpoints in us-east-1, us-west-2, eu-west-1, and ap-northeast-1. If a model has no regional endpoint matching the workspace pin, we surface a warning before the first call and require explicit acknowledgment.
The workspace pin is shown on the Settings → Region panel and is recorded in the audit log when it's changed. Migrating a workspace across regions is a supported operation but requires a maintenance window because vector indexes have to be re-indexed.
BYO Cloud as the strongest answer
For customers where the regulator wants control plane and data plane both inside a specific jurisdiction, osFoundry's BYO Cloud deployment is the strongest answer. The full osFoundry stack — API, workers, Postgres, container runtime, secrets — is deployed via CloudFormation or Terraform into your own AWS, GCP, or Azure account, in the region of your choice.
What that buys you:
- Data never leaves your cloud account. Not even for telemetry — the BYO deployment ships with a local logging stack.
- Your existing AWS/Azure DPA, EU SCCs, or APPI cross-border consent paperwork applies as-is.
- You retain root access to the data plane. Audit logs are written to your S3 bucket, not ours.
- Model inference still has to go somewhere — you bring your own endpoints (Bedrock, Azure OpenAI, self-hosted llama.cpp servers).
The trade is operational. BYO Cloud is more expensive ($2-8K/month base depending on tier) and you take on patching responsibility. For regulated industries it's usually still cheaper than the alternative of building from scratch.
Model-provider contract clauses you must check
The most important paragraph in any model-provider contract is the training-data clause. Default consumer terms typically allow the provider to use prompts and responses to improve their models. Default API terms typically do not, but you must read the version that applies to you.
Anthropic API terms (as of 2026-05): inputs and outputs are not used for training by default. Zero Data Retention is available on enterprise tier.
OpenAI API terms: not used for training by default since March 2023. ZDR available on enterprise tier and required for HIPAA workloads.
Google Gemini API: not used for training in paid tier; free tier has different terms.
Other clauses worth checking: log retention period (default is often 30 days), incident-notification SLA, subprocessor list (who else touches your data), DPA availability for GDPR, and the ability to delete data on demand. For BYOK setups, your contract is with the model provider directly, not osFoundry — which is often easier to negotiate.
Audit-trail requirements
Every regulator I've worked with eventually asks the same question: 'Show me who accessed what, when.' The audit-trail requirements differ:
- **APPI** — minimum 1 year retention for access logs to sensitive data, longer for medical.
- **GDPR** — no fixed retention but Article 30 records of processing activities must be maintained for the duration of processing.
- **HIPAA** — 6 years from the date of creation or last effective date for audit logs.
- **FERPA** — 5 years typical, varies by state.
- **SOX / SOC 2** — 7 years for financial controls.
osFoundry's audit log records every interaction at the workspace boundary — prompts, tool calls, file access, model used, tokens consumed, user identity. Logs are immutable (append-only, hash-chained) and exportable. For BYO Cloud deployments the audit log lands in your own S3 bucket, which makes the regulatory answer straightforward: 'It's in our account, in our region, under our control.'
Frequently asked questions
- Can osFoundry data stay in a single region?
- Yes. osFoundry workspaces are pinned to a region at creation (eu-central-1, ap-northeast-1, us-east-1, etc.), and every workspace-owned resource — Postgres, file storage, vector indexes, knowledge graphs, audit logs — provisions in that region. Cross-region traffic is opt-in per integration. For the strongest guarantee, BYO Cloud deploys the full stack into your own cloud account.
- Does prompt caching break AI data residency?
- Prompt caching introduces a hidden storage surface. osFoundry routes inference through regional model endpoints when available, so cached prefixes stay in the workspace's region. For providers without regional endpoints, prompt caching should be disabled for residency-sensitive workloads, or BYO Cloud should be used with regional inference endpoints under your control.
- What is BYO Cloud and when do I need it?
- osFoundry BYO Cloud deploys the full stack — API, workers, Postgres, container runtime, secrets vault — into your own AWS, GCP, or Azure account via CloudFormation or Terraform. Data never leaves your cloud account, not even for telemetry. Recommended when regulators require control plane and data plane both inside a specific jurisdiction (regulated healthcare, defense, large EU banks).
- How does APPI differ from GDPR for AI workloads?
- APPI requires explicit consent or equivalent-protections countries for cross-border transfers — the US is not on Japan's equivalent list without contractual clauses or APEC CBPR. APPI also mandates 3-day breach notification (vs GDPR's 72 hours) and treats medical data as sensitive requiring explicit processing consent. osFoundry's ap-northeast-1 region pin satisfies the in-Japan requirement.
- Are embeddings considered personal data under GDPR?
- Yes — embeddings are derived data but can be partially reversed to original text with embedding-inversion attacks, so European Data Protection Board guidance treats them as personal data when derived from personal data. osFoundry stores embeddings in workspace-scoped pgvector, inheriting the workspace's regional pin, so embeddings never cross the residency boundary set for source data.
- What model-contract clauses matter most for residency?
- The training-data clause (whether prompts/outputs may be used to improve future models), log retention period (often 30 days by default), subprocessor list (who else touches your data), and Zero Data Retention availability. Anthropic, OpenAI, and Google API tiers do not use API data for training by default since 2023, but verify the exact contract version applying to your account.
- How long must AI audit logs be retained?
- Retention requirements vary: APPI requires minimum 1 year for sensitive access logs, HIPAA requires 6 years from creation, FERPA typically 5 years, SOX/SOC 2 typically 7 years for financial controls, GDPR has no fixed period but Article 30 records must persist throughout processing. osFoundry audit logs are immutable append-only and hash-chained, exportable to S3 for long-term retention.
Sources