データの保存地域と、各国・組織の管理下で動かすAI

Enterprise AIでは「データが日本/欧州にある」「リージョンを選んだ」という一文だけでは、保存・推論・検索/grounding・agent runtime・ログ・abuse monitoring・backup/DR・support/debug・metadata/control planeの所在地を説明できない。さらにData ResidencyとSovereign AIは同義ではなく、法的管轄、運用主体、供給網、技術的自律性まで含む場合がある。将来版では、providerの地域機能を単一の○×ではなく、データ面/処理面/運用面に分解して記載しなければ過大保証になる。

Enterprise AI Core / provider mapping / organization overlay / interoperability / governance / security & privacy / implementation / non-LLM component

• Data residencyの対象は何か。保存(at rest)と推論/処理(inference/processing)は同一境界か。
• ログ、abuse monitoring、backup、routing、metadata、support/debug、RAG/grounding/agent機能は同じ地域保証に含まれるか。
• providerのGlobal/Data Zone/Regional等のdeployment方式はどこまで処理場所を拘束するか。
• Sovereign AI/sovereign cloudはresidencyと何が異なるか。
• 後続Workがprovider横断で比較できる最小のresidency/sovereignty記述単位は何か。

E1 | official product docs | "Data residency and inference residency for ChatGPT" | OpenAI | https://help.openai.com/en/articles/9903489-data-residency-for-chatgpt | access 2026-09-14; page current as-of access | current product docs; no API revision | locators: definitions of Data Residency / Inference Residency; supported regions; "What is not included" / limitations | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - Data residencyは対象customer contentのat-rest保存地域、inference residencyは対象contentのGPU execution地域として別概念。現行ページはat-rest対象地域としてAustralia/Canada/Europe/India/Japan/Singapore/South Korea/UAE/UK/USを列挙し、inference residencyは現行対応地域が限定される。inference residency利用には同一地域のdata residencyが前提。 - authentication、routing、contentを含まないlogging、indexing等は選択地域外で処理され得ると明記。すべてのfeature/modelが同じresidency対象ではない。

E2 | official product docs | "Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry" | Microsoft | https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy | access 2026-09-14 | current Microsoft Foundry docs | locators: Global deployment / DataZone deployment / data at rest | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - Global deploymentではprompt/response処理がmodel提供可能な複数geographyへ回り得る。Data Zoneでは指定data zone内の複数地域で処理され得る。一方、uploaded dataやabuse-monitoring store等のat-rest dataはcustomer-designated geographyに保持されるとする。処理場所と保存場所を分離する一次根拠。

E3 | official product docs | "Region availability for Foundry Models sold by Azure" | Microsoft | https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability | access 2026-09-14; current page published/updated 2026 | model/version/deployment-type specific | locators: deployment type descriptions; model-region tables | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - Global/Data Zone/Regional(Standard)等で処理境界が異なる。利用可否はmodel ID/version、deployment type、resource regionの組合せで変動するため、「Azureで利用可能」だけではresidencyを確定できない。

E4 | official product docs | "Geographic cross-Region inference" | Amazon Web Services | https://docs.aws.amazon.com/bedrock/latest/userguide/geographic-cross-region-inference.html | access 2026-09-14 | current Amazon Bedrock docs | locators: source Region / destination Region / prompt-output movement / abuse detection storage | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - cross-Region inferenceでは、既定でdataはsource Regionに保存される一方、input prompt/output resultがsource Region外へ移動し得る。abuse detectionのため保存する場合はdestination Regionに保存され得る。at-restの既定位置だけではinference pathを説明できない。

E5 | official product docs | "Data retention" | Amazon Web Services | https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html | access 2026-09-14 | current Amazon Bedrock data-retention modes | locators: data_retention_mode; none/ZDR; model compatibility; cross-region retained data | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - retention mode none はZero Data Retentionを構成するprovider controlだが、対応しないmodelは利用できない。store=falseだけで常にZDRを保証するわけではない。cross-region inferenceでretentionが発生する場合、destination側保存も考慮が必要。modelごとのpolicy gateが存在する。

E6 | official product docs | "Monitor model invocation using CloudWatch Logs and Amazon S3" | Amazon Web Services | https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html | access 2026-09-14 | current Bedrock invocation logging | locators: logging disabled by default; CloudWatch/S3 destinations | VERIFIED_SPEC + PRODUCT_VOLATILE | context + limit - invocation loggingは別設定面であり、default disabled。enable時のCloudWatch/S3 destinationは独立して設計する必要がある。推論リージョンだけでログ所在地/保存を代表させてはならない。

E7 | official contractual/product terms | "Google Cloud Platform Services with Data Residency" | Google Cloud | https://cloud.google.com/terms/data-residency | last modified 2026-09-08; access 2026-09-14 | current service list | locators: AI/ML Data Location; Generative AI / Gemini Enterprise Agent Platform exceptions | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - current Data Residency対象service一覧はGenerative AIを含むが、Grounding with Google Search/Maps、RAG Engine等に例外がある。AI/ML Data Locationでも対象model/featureが限定され、Gemini Enterprise Agent PlatformのFeature Store、Agent Runtime、Memory Bank、Sessions、Sandboxes、RAG Engine、Agent Evaluations等に個別例外が示される。製品単位の地域保証をagent subsystem全体へ拡張してはならない。

E8 | official contractual terms | "Service Specific Terms" | Google Cloud | https://cloud.google.com/terms/service-terms | access 2026-09-14 | current terms | locators: Data Location; storage at rest; same-country/multi-region replication; resource identifiers/attributes exclusions | VERIFIED_SPEC + PRODUCT_VOLATILE | support + limit - 対象serviceでは選択Region/Multi-RegionでCustomer Data at restを保管するとしつつ、backup/reliability/debugging/support/maintenance/securityのため同一国またはselected Multi-Region内でreplicationし得る。resource identifiers、attributes、other data labels等はCustomer Data定義から外れる場合がある。customer側のaccess/movementもprovider residency保証とは別。

E9 | official public-policy/procurement framework | "Sovereign Cloud Framework explained" | European Commission | https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en | published 2026-06-01; access 2026-09-14 | Sovereign Cloud Framework / SEAL | locators: eight sovereignty categories; SEAL levels | VERIFIED_SPEC | context + limit - EU Commissionのframeworkはsovereigntyをdata locationだけに限定せず、strategic、legal/jurisdictional、data and AI、operational、supply chain、technological、security/compliance、environmental sustainabilityの8領域で評価する。したがってsovereignty=residencyという同一視は不適切。このframeworkはEU調達文脈の評価枠であり、全クラウド/全法域に自動適用される普遍的技術標準ではない。

• VERIFIED_SPEC: Data ResidencyとInference/Processing Residencyは別面である。OpenAIが用語として明示的に分離し、Azure/AWSもdeployment/routingの実装として同じ差を示す。
• VERIFIED_SPEC: at-rest保証がsource geography/regionにあっても、Global/Data Zone/cross-region inferenceではprompt/response処理が別region/zoneへ移動し得る。
• VERIFIED_SPEC: logging、abuse monitoring、backup/DR、metadata/control plane、grounding/RAG、agent runtime/memory/session等は、base inference/storageとは別の適用範囲・例外を持ち得る。
• VERIFIED_SPEC + PRODUCT_VOLATILE: 利用可否はprovider名ではなく、plan/tenant、region、model ID/version、deployment type、feature/subsystem、retention mode等の組合せで決まる。
• VERIFIED_SPEC: Sovereign AI/cloudはdata residencyより広い。少なくともEU Commissionの現行sovereignty frameworkではlegal/jurisdictional、operational、supply-chain、technological autonomy等を別評価する。
• INFERENCE: provider横断のEnterprise AI Coreでは「どの国/regionか」だけでなく、「何のdata/artifactを、どのoperationで、誰/どのserviceが、どこで扱い、どの期間残すか」を最小比較単位にする必要がある。
• INFERENCE: regional endpointやregional storageの存在は、workload全体のregionality/sovereigntyを証明しない。最も境界の弱いsubsystem/feature/tool/log pathが実効境界を決める。

• "Japan region available"や"EU data residency"を、全processing/全feature/全metadata/全operator accessの国内・域内固定と読み替えない。
• Global/Data Zone/cross-region inferenceは可用性/容量面の利点と引換えに処理場所が広がる場合がある。
• RAG、web/search/maps grounding、agent runtime、memory、sandbox、session、evaluation、connector/toolはbase modelと異なるresidency scopeを持ち得る。
• abuse/safety monitoringにretentionやdestination-side storageが存在し得る。ZDR/retention設定はmodel compatibilityを変える場合がある。
• providerのログ機能は別途enable/routeされることがあり、推論地域からログ地域を推定できない。
• backup/DR/support/debugのreplica境界は「exact region」と同じとは限らない。
• control-plane metadata、billing、resource identifiers、routing/authentication等がcustomer-content residencyの対象外となる場合がある。
• customer自身またはthird-party tool/connectorによるexport/egressはproviderのbase residency guarantee外になり得る。
• residencyはjurisdiction、operator nationality/control、supply-chain independence、cryptographic/key sovereignty、technical autonomyを自動的に満たさない。
• provider docs/region tablesは高頻度に変わるため、公開後アップデート時に再確認必須。

OpenAI: eligible workspace/plan、選択data-residency region、inference-residency supported region、model/feature limitation。inference residencyとdata residencyは同一regionでの対応が必要。 Microsoft Foundry: model ID/version × deployment type(Global/Data Zone/Regional等) × resource region/geography × feature。 Amazon Bedrock: source region × inference profile/cross-region mode × destination region set × model × data-retention mode × logging configuration。 Google Cloud: service × region/multi-region × AI/ML Data Location対象model × feature/subsystem exceptions。Agent/RAG/grounding系は個別確認が必要。 Sovereign offering/framework: residencyだけでなく法的/運用/供給網/技術統制の適用条件を個別確認。

• Provider-native residency/region controlsは複数社で実装済み。ただしsemantic scopeは統一されていない。
• provider横断で同じ意味を持つ単一の"AI residency" switch/specは本RUNでは確認できない。
• PROPOSAL: Enterprise AI Coreに Residency & Sovereignty Matrix を置く。最低列は artifact/data class | operation(store/process/route/log/backup/support/review) | provider/service/feature | model/version | deployment type | region/country/zone | retention | access actor | third party/subprocessor | key/control plane | evidence date/version | status(VERIFIED/UNKNOWN)。
• PROPOSAL: workload release gateは、policy-required cellがUNKNOWNまたはallowed boundary外ならpromotion不可とする。これは既存provider仕様ではなく将来運用設計案。
• PROPOSAL: runtime/asset inventoryからmodel/feature/deployment変更を検知し、MatrixのPRODUCT_VOLATILE cellを再検証対象にする。

通常のmodel benchmarkはresidency/sovereigntyを評価しないため、benchmark scoreの外挿は禁止。 適切なのはconformance evaluation: 各data planeについてdocumentation/contract/configuration/observable telemetryを突合し、store/process/route/log/backup/supportごとにPASS/FAIL/UNKNOWNを付ける。 SAFE TEST_PROFILE（未実施）: synthetic/non-sensitive inputだけを用い、指定region deploymentで公開configuration、request routing metadata、provider-exposed log destination、retention settingを確認する。tenant secrets、実顧客データ、課金変更、危険なcross-border testは実施しない。

residency boundary外へのtool/grounding/log/monitoring pathをdata-flow threat modelへ含める。ZDRとdata residencyは別controlとして記録する。 AUDIT: 実行時にはprovider/service、model/version、deployment type、requested region、resolved processing policy、retention/log settings、Matrix revisionをtrace/audit provenanceへ残す。ただしproviderが実destinationを公開しない場合はUNKNOWNを維持する。

Global/cross-region routing、dedicated/sovereign offering、regional capacity reservation等はcost/throughput/availability trade-offを持ち得るため、価格は公開後Workでcurrent claimとして再採集する。本RUNでは価格を確定しない。

failover時に地域境界を拡大する設計は、通常時とincident時でpolicyが変わる。availability failoverとresidency policyの優先順位を事前に明示する必要がある。

「データレジデンシーは『リージョンを選べばすべてがその地域に留まる』という単一機能ではない。保存、推論、ルーティング、ログ、監視、バックアップ、検索/grounding、エージェント実行などで適用範囲が異なり、provider・model・deployment type・featureごとに確認が必要である。Sovereign AIはさらに法的管轄、運用統制、供給網、技術的自律性などを含み得るため、Data Residencyと同義に扱わない。」

• 将来版でData Residencyのprovider mappingを作る場合、OpenAI/Azure/Bedrock/Googleを同じ「地域対応○」表にせず、Storage / Inference / Routing / Logs & Monitoring / Backup & Support / RAG & Grounding / Agent Runtime & Memory / Metadata-Control Planeで分割する。
• current product claimは公開時点で必ず再取得する。特にOpenAI supported inference regions、Azure model-version-region table、Bedrock retention/model restrictions、Google AI/ML Data Location exception listを再確認。
• Residency & Sovereignty Matrix はCore候補として、EA-061 Data Classificationのdata class/provenanceと接続する。classification labelだけでは処理地域を決めず、purpose/principal/provider/feature/retentionと組み合わせる。
• Sovereign AI章では「residency」「jurisdiction/control」「operational sovereignty」「supply chain」「technical autonomy」を別軸で採否する。EU Sovereign Cloud Frameworkは有力な比較枠だが、EU procurement contextを明記する。
• tenant実証が必要になった場合は上記SAFE TEST_PROFILEを使用し、未観測部分をpublic docsで埋めたことにしない。

• provider横断で共通利用できる正式なAI residency/sovereignty machine-readable schemaは未確認。
• 各providerが内部routingした実処理regionをrequest単位でどこまで監査可能に露出するかはprovider/feature別に未確定。
• agent tool/connector先third-partyまで含むend-to-end residency attestationの一般標準は未確認。
• exact sovereign controls（key ownership/operator access/jurisdiction/supply-chain）をAI service単位で比較できる共通証明形式は未確認。

EA-062の初回Evidence Packetとして、主要4 providerの保存/処理/ログ・subsystem差、Sovereign AIとの概念差、availability gates、failure envelope、future Core用matrix案まで一次公式資料でboundedに確立した。次回は同一claim/source versionを再採集せず、上記OPEN_UNKNOWNに直接答える標準/attestationまたは新version差分がある場合のみ補完する。

---

Storage-at-rest, inference/processing residency, routing, logs, backup/support, grounding/RAG, agent runtime/memory/session and control-plane metadata are separate scopes. Sovereignty is broader than residency. Provider-native residency statements apply only to stated content/features/operations. ZDR, retention and residency are separate.