←Blog 一覧へ
◆62 分で読了

【Part 4】 How AI leaks data at every stage of its lifecycle — and what actually stops it

Hiroshi Nakagoe, CTO at CODAS & VPoE at Archetype Digital

BLOG

This is the fourth post in a series on privacy preservation for the GenAI era. The first three sat at the application and model layer and assumed a machine to run on. This one is about choosing it, and about how much of your trust each provider needs — with the regions, instance families, retention modes and admitted limits named.

Earlier posts in this series:

【Part 1】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 2】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 3】 How AI leaks data at every stage of its lifecycle — and what actually stops it

What the Cloud Providers Give You

The question underneath that choice is how much of your trust the provider needs — because every control in this post is a way of needing less of it.

Two commitments shape what follows. The first is that the workload uses GPUs, which turns out to matter more than any other single fact, because the accelerator sits outside the boundary that confidential-computing documentation usually describes. The second is the comparison set: AWS, Google Cloud and Microsoft Azure, plus Nebius. Nebius is in a list with three hyperscalers because it is the shape a GPU-first provider takes, and because it answers the privacy question in an entirely different register — which makes it the useful contrast rather than the odd one out.

Vendor documentation is organized by product, which is the right shape for using a service and an awkward one for choosing between services. The sections below are organized by the question instead — most of them literally a question you would put to a provider before signing, naming the threat behind it and then what each provider ships against it. One aside on Oracle appears as a design contrast, outside the comparison set. Two of those questions are regulatory rather than adversarial, and they get the same treatment, because a regulator’s demand constrains an architecture in exactly the way an attacker does — sometimes harder, since it can rule out a service that works perfectly.

One distinction decides what each layer can be asked to do, so it is worth fixing before the catalog starts. Confidentiality is about who can read the data. Privacy is about what can be learned from it.

The infrastructure layer is almost entirely the first. Encryption at rest, in transit and in use, customer-managed keys, attested enclaves, region pinning and audit trails all answer the question of who gets access, and not one of them stops a model memorizing a customer record, prevents an aggregate from identifying the person behind it, or answers a data subject asking to be forgotten.

The platform layer is where providers do offer privacy controls, and it is worth knowing how far each one reaches: differential privacy in the clean rooms, detection and redaction of personally identifiable information (PII) in the guardrail services, and retention limits on the inference endpoints. Every one of those appeared in the three preceding posts with its measured limit attached — scrubbing reduces leakage without preventing it, a guardrail is itself an attackable classifier, and differential privacy protects only at the granularity of its unit. So the platform narrows the privacy gap rather than closing it, and what the sections below try to make visible is which side of that line each control actually sits on.

One note on sourcing. Vendor claims here were checked against vendor documentation except where a cell in the comparison table is marked with a question mark, and the legal position in the compelled-access section against statute, regulator opinions and sworn testimony rather than against vendor summaries of those things — which turns out to matter, because on several points the two disagree.

Can the operator read your data while it is being processed?

Encryption at rest and in transit leaves a gap in the middle: data is plaintext in memory while the CPU works on it, and the party operating that memory is the cloud provider. Confidential computing closes the gap with hardware — memory encrypted by the memory controller, a measured boot chain, and a guest the hypervisor cannot read. This is an infrastructure-layer control; no platform service substitutes for it.

AWS

The Nitro System is the baseline and is always on. AWS states it provides “confidentiality and isolation from AWS operators,” and documents always-on memory encryption from Graviton2, AMD EPYC Milan and Intel Ice Lake onward (“Data Isolation — AWS Confidential Computing”). Note the scope precisely: this is host DRAM encryption — Intel Total Memory Encryption (TME) on the Intel parts, AMD Secure Memory Encryption (SME) on the AMD parts, and on Graviton a mechanism AWS does not name, whose keys it does document as generated inside the host and destroyed on reboot (“Data Protection in Amazon EC2”). It is transparent, and AWS documents no customer key control or attestation for it; attestation on AWS comes from the Nitro Trusted Platform Module (NitroTPM), Nitro Enclaves or SEV-SNP’s own attestation report instead. Nitro Enclaves — isolated environments with “no persistent storage, no interactive access, and no external networking” (“AWS Nitro Enclaves FAQs”) — became available in all AWS Regions on 21 October 2025, with no cost beyond the EC2 instances and other AWS services used with them (“AWS Announces Nitro Enclaves Are Now Available in All AWS Regions”).

The AMD SEV-SNP option — Secure Encrypted Virtualization–Secure Nested Paging, which encrypts a guest’s memory under an instance-specific key and returns a signed attestation report — is scoped more narrowly than the three families imply. It runs only on specific sizes of m6a, c6a and r6a; on Dedicated Hosts in any commercial Region, but on shared tenancy only in US East (Ohio) and Europe (Ireland), where it costs an additional 10% of the On-Demand rate — there is no uplift on Dedicated Hosts. AWS lists Nitro Enclaves alongside hibernation as unsupported, without stating a reason (“AMD SEV-SNP for Amazon EC2 Instances”), so SEV-SNP and Nitro Enclaves are mutually exclusive at the instance level. Whole-instance attestation does not depend on either: NitroTPM covers it across all commercial Regions, as the attestation section sets out.

Google Cloud

AMD SEV-SNP runs on N2D only, in 14 zones: asia-southeast1-a/b/c, europe-west2-b/c, europe-west3-a/b/c, europe-west4-a/b/c and us-central1-a/b/c. Intel TDX — Trust Domain Extensions, Intel’s equivalent confidential-VM technology — runs on c3-standard-* across 24 zones, alongside c3-standard-*-lssd, c4-standard-* and the GPU type a3-highgpu-1g; the figures here are as of 8 October 2026 (“Supported Configurations | Confidential VM”), with c4-standard reaching general availability (GA) on 23 September 2026 (“Confidential VM Release Notes”). Google also runs plain AMD SEV, which emits no hardware attestation report, on C2D, N2D, C3D, C4D and g4-standard-48. Confidential Space sits on top of Confidential VM, in three documented components: a workload, an attestation service, and protected resources. Data collaborators add a provider to their workload identity pool, naming the attestation service that must be used along with attribute mappings and conditions the workload has to satisfy, and a workload that passes verification “is allowed to access and decrypt the confidential data” (“Confidential Space Overview”). Google presents it for parties who want to process shared data “without revealing it to each other or external parties,” which is why it reappears in the multi-party phase.

Microsoft Azure

AMD SEV-SNP across the DCasv5 and ECasv5 families and Intel TDX across DCesv6 and ECesv6. The v6 SEV-SNP series reached general availability in June 2026 (“GA: DCasv6 and ECasv6 Confidential VMs”); the confidential-computing products overview still carries a “currently in gated preview” line for it that the announcement supersedes. Confidential OS disk encryption is optional, supports customer-managed keys, cannot be changed after deployment, and is limited to disks smaller than 128 GB. The Azure Container Instances (ACI) confidential-containers overview and the Azure Kubernetes Service (AKS) how-to for confidential VM node pools carry no status label, though the confidential-computing AKS node-pool page describes the underlying DCasv5 and ECasv5 series as generally available. Intel TDX confidential VMs “aren’t currently supported on AKS,” so only the AMD SEV-SNP families reach AKS node pools today. Kata Confidential Containers on AKS is Preview, with real constraints — Azure Linux 2.0 only, longer pod startup, no v1 images, TCP-only services, resource requests unsupported, and, for the Kata-CC handler, 2 GB of memory for the utility VM (UVM) on top of whatever limits you declare, plus one vCPU for the pod’s base OS that is shared with the workload unless CPU limits are set (“Confidential Containers on Azure Kubernetes Service”).

Nebius

Nebius’s encryption documentation mentions no trusted execution environments (TEEs), GPU confidential computing or attestation (“Encryption in Nebius AI Cloud”), and neither does its most recent platform update, the Q3 2026 roundup of 1 October 2026, nor the “Aether 3.6” release of June 2026. On this control the hyperscalers publish documented offerings and Nebius does not. As with the Azure families above, that is a documentation finding rather than a vendor statement, and worth putting to a Nebius account team in writing before a design depends on hardware isolation.

Does the protection reach the GPU, or stop at the CPU?

A confidential VM protects host memory. Inference and training happen on the accelerator, and the CPU TEE stops at the PCIe bus. Without GPU confidential computing the model weights, the activations and the key-value (KV) cache are plaintext in GPU memory, and the transfers that put them there are plaintext on the bus. For an AI workload this is the gap that matters, and it is the thinnest part of the market.

NVIDIA’s answer is a per-GPU setting its documentation calls confidential computing mode, abbreviated CC mode and reported as such by nvidia-smi. What it adds is worth stating precisely, because the common shorthand is wrong. It does not encrypt GPU memory: device memory is divided into protected and unprotected regions, and the driver “configures the GPU firewall to prevent unauthorized access to the GPU,” while NVIDIA states that on-package high-bandwidth memory (HBM) “is considered secure against common physical attack tools, such as interposers, and is not encrypted.” What CC mode does encrypt is the path — direct memory access (DMA) transfers between CPU and GPU run through bounce buffers protected by engines that “use 256-bit AES-GCM encryption” — and it produces an attestation report signed by an attestation key whose certificate is signed by a per-device identity key, with an on-die root of trust verifying the key fused onto the GPU (Confidential Compute on NVIDIA Hopper H100). Multi-GPU is a separate setting NVIDIA calls Protected PCIe, not CC mode, and the two documents do not agree about it: the 2025 Blackwell paper says that in Hopper’s configuration “data traffic between GPUs over NVLINK remains unencrypted” while in Blackwell’s “the NVLINK pathway is also encrypted, and up to eight GPUs can be passed through to a CVM” — a confidential VM — whereas the 2023 Hopper paper described multi-GPU NVLink transfers as encrypted through bounce buffers (NVIDIA Secure AI with Blackwell and Hopper GPUs).

AWS

No AWS documentation offers NVIDIA CC mode on any EC2 GPU family — not P5, P5e or P5en, not the Blackwell P6 families. AWS does not document a GPU TEE; it makes its accelerator claim at the Nitro level instead, and extends it explicitly to accelerators: “By design, there is no mechanism for any AWS operator to access an Amazon EC2 instance based on the Nitro System or to access data that customers send to a machine learning (ML) accelerator or GPU” (“Data Isolation — AWS Confidential Computing”). That claim is backed by an independent NCC Group design review and by a commitment in the AWS Service Terms that “there are no technical means or APIs available to AWS personnel to read, copy, extract, modify, or otherwise access” customer content on the Nitro System (Overview of the AWS European Sovereign Cloud: Design Approach). It is a design-and-contract assurance rather than one a customer can verify cryptographically before releasing a key. On an H200 instance today, host DRAM is encrypted by Nitro’s always-on platform memory encryption rather than by a confidential VM — no P-family instance type appears in the SEV-SNP list (“AMD SEV-SNP for Amazon EC2 Instances”) — and neither the PCIe path nor GPU memory is encrypted. AWS’s always-on memory-encryption page names Graviton2-or-later, Ice Lake and Sapphire Rapids, and Milan and Genoa hosts by way of example rather than as an inventory, so it does not settle the question for the newest accelerated families — p6e-gb200.36xlarge runs on an NVIDIA Grace CPU and p6-b200.48xlarge on Emerald Rapids, neither of which the page names. AWS makes its P6 security claim at the Nitro level instead, without processor qualification.

Google Cloud

NVIDIA CC on A3 High with H100 has been GA since 31 July 2025, and CC on G4 with RTX PRO 6000 since 7 August 2026 (“Confidential VM Release Notes”). As of 8 October 2026 the H100 configuration runs in three zones worldwide — europe-west4-c, us-central1-a and us-east5-a — against 36 for the G4 (“Supported Configurations | Confidential VM”). The two sit on different CPU technologies: A3 High on Intel TDX, G4 on plain AMD SEV, which emits no AMD hardware report for the VM, so the G4 VM quote is signed by a virtual TPM and Intel Trust Authority is not available for it. GPU attestation is separate and does exist on G4 — Google documents verification of the GPU driver and the video BIOS through its nvattest tool. The G4 part also carries an NVIDIA confidential-computing licence fee. Operationally it wants NVIDIA open kernel module drivers at version 580 or later, which Google phrases as a recommendation rather than a hard floor, plus the Linux Kernel Crypto API and persistence mode to “establish a secure Security Protocol and Data Model (SPDM) connection” (“Create a Confidential VM Instance with GPU”) — the session in which “secure ephemeral encryption keys are exchanged between the host and the device” (Deployment Guide for Confidential Computing). So Google’s broad confidential-GPU footprint is on the RTX PRO 6000 Blackwell Server Edition — a Blackwell-generation server part, though not an H100- or H200-class training GPU — while its H100 confidential footprint is three zones.

Microsoft Azure

NCCadsH100v5 is GA — one SKU, Standard_NCC40ads_H100_v5, 40 vCPU on SEV-SNP with a single NVIDIA H100 NVL at 94 GB, where the “Trusted Execution Environment (TEE) spans confidential VM on the CPU and attached GPU” (“NCCads_H100_v5 Size Series”). Live migration, memory-preserving updates, Generation 1 VMs, accelerated networking and nested virtualization are all unsupported (“NCCads_H100_v5 Size Series”), and resizing is “currently not supported” because the VMs “run on specialized hardware” (“Azure Confidential GPU Options”). Azure publishes this footprint as a live query rather than a static table: the confidential-computing GPU options page supplies an az vm list-skus command returning the regions and availability zones currently offering the NCC family, and points to Azure’s products-available-by-region page for the same answer in a browser (“Azure Confidential GPU Options”). Confirm the footprint per subscription at design time.

Nebius

None documented.

The two structural limits

They are these: no provider documents a confidential H200 or GB200 configuration, and both of the confidential-GPU offerings documented across these four platforms — Google’s and Azure’s — are single-GPU, even though NVIDIA documents multi-GPU modes reaching eight GPUs in one confidential VM on Blackwell. A model that needs tensor parallelism across cards cannot run in a GPU TEE on any of these platforms today, which is the same ceiling the multi-party phase hits from the other direction.

Can you verify what is actually running?

A TEE whose state you cannot check is a promise. Attestation turns it into evidence: a signed measurement of the boot chain and workload, verifiable before you hand over anything worth protecting. The pattern that makes it useful is attestation-gated key release — the key material is withheld until the measurement matches, so a tampered or downgraded environment simply never gets decryption.

AWS

EC2 instance attestation went GA on 23 September 2025, extending cryptographic attestation beyond enclaves using NitroTPM and Attestable Amazon Machine Images, across all commercial Regions and GovCloud (“AWS Announces EC2 Instance Attestation”). Key release is gated in the Key Management Service (KMS) key policy, and in identity and access management (IAM) policies, rather than in a separate service. For enclaves the condition keys are kms:RecipientAttestation:ImageSha384 and conditions on individual Platform Configuration Registers (PCRs) — the measurement slots recording the enclave image, the kernel and bootstrap, the application, the parent instance’s IAM role, the parent instance ID and the image-signing certificate — applied to Decrypt, GenerateDataKey and related operations. KMS then encrypts the plaintext under the public key embedded in the attestation document and returns it in CiphertextForRecipient, so plaintext never exists outside the attested environment (“AWS KMS Condition Keys for AWS Nitro Enclaves”). AWS documents the enclave condition keys and NitroTPM instance attestation separately; the enclave condition-key page does not cover the instance path.

Google Cloud

Google Cloud Attestation issues the token for AMD SEV instances and for Intel TDX on C3 machine types, with Intel Trust Authority as an alternative for Intel TDX only; the gate is workload identity federation, with attribute conditions on image, container and VM resolving to short-lived credentials for Cloud KMS (“Confidential Space Overview”).

Microsoft Azure

Microsoft Azure Attestation (MAA) moves its critical operations — quote validation, token generation, policy evaluation and token signing — into AMD SEV-SNP confidential containers, and attests Software Guard Extensions (SGX) enclaves, enclaves built on virtualization-based security (VBS), Trusted Platform Modules (TPMs), Trusted Launch and Azure confidential VMs. Intel TDX is not among the platforms listed on that page even though Azure offers TDX VMs (“Microsoft Azure Attestation Overview”). Azure documents a TDX path elsewhere, though on a page last revised in 2022 and in terms of the earlier DCesv5 and ECesv5 naming: guest attestation for Intel TDX-backed confidential VMs can use Intel Trust Authority, which “requires registration with Intel” (“Guest Attestation for Confidential VMs”). Secure Key Release from Key Vault or Managed HSM is gated on an attestation token.

Nebius

No attestation service documented — again a documentation finding rather than a vendor statement.

A design contrast

From a provider outside the comparison set: Oracle documents “Bring Your Own Attestation Service” for its E5 and E6 SEV-SNP shapes, though not the older E3 and E4, where “customers deploy and operate their own attestation service using OCI guidance” (“Confidential Computing”). None of the four providers here documents a customer-operated verifier, though Google lets you route attestation to Intel Trust Authority instead of Google Cloud Attestation.

Who holds the keys, and who can refuse to use them?

Customer-managed keys move the policy decision about decryption to you. They become a counterweight to compelled access only in the variants where the key material itself sits outside the provider — an external key store, Cloud EKM, or a customer-operated hardware security module — because only there can the provider genuinely not produce plaintext. The compelled-access section two on from here returns to that limit; what follows is where the key material lives on each platform and who can refuse a request for it.

AWS

Four key-store models — standard, standard with imported key material, an AWS CloudHSM key store, and an external key store — and AWS flags the availability and latency trade-off explicitly in the two custom ones. Only the external key store (XKS) puts key material outside AWS, behind a proxy you run, and AWS says of it: “The greater risk to availability and latency will, for most customers, exceed the perceived security benefits of external key stores” (“External Key Stores”) — the lowest throughput and highest latency of any option, no service-level agreement (SLA) coverage, and the customer responsible for availability and durability of key operations (“Key Stores”). On refusal, XKS is the only AWS path: the proxy you operate can decline a request, and AWS sends per-request metadata it can decide on — caller principal, KMS key ARN, KMS operation, calling service and source VPC — though not a justification or reason code for the access of the kind Google’s Key Access Justifications supplies (“Control Access to Your External Key Store”). Permanently revoke access and “all ciphertext encrypted under a KMS key in your external key store becomes unrecoverable” (“External Key Stores”). Customer managed keys in Amazon Bedrock cover model customization jobs and their output custom models, agents, knowledge-base data source ingestion jobs, OpenSearch vector stores and model evaluation jobs, with prompts, flows and sessions documented separately and batch inference output taking a custom key chosen at job creation (“Data Encryption in Amazon Bedrock”).

Google Cloud

Cloud External Key Manager (Cloud EKM) works with Fortanix, Futurex and Thales, and connecting over a VPC network additionally supports coordinated external keys, where Cloud EKM creates, rotates and destroys key versions while the material stays in the partner’s key manager (“Cloud External Key Manager”). Key Access Justifications is the differentiator: each request carries a justification reason code, and the partner key manager can be configured to allow or deny on it — a per-request, policy-based denial the customer configures rather than a provider-side allowlist, and the sharpest answer any of these providers offers to compelled access. Google publishes a list of services compatible with customer-managed encryption keys (CMEK) rather than a count, and Vertex AI is on it (“Cloud KMS Compatible Services”).

Microsoft Azure

Managed HSM — a hardware security module, the dedicated appliance that holds key material and performs operations on it — is the notable tier, at Federal Information Processing Standard (FIPS) 140-3 Level 3, with each cluster isolated by “a separate customer-specific security domain” and “designated HSM cluster administrators” holding “complete control over the HSMs that even management group, subscription, or resource group administrators cannot override” (“Managed HSM Overview”). Holding key material outside the provider’s boundary is a Managed HSM feature in its own right: Managed HSM external key management keeps the key encryption key “in a customer-owned, customer-operated HSM that runs entirely outside Microsoft infrastructure.” It is in preview, and sovereign clouds are out of scope for that preview (“What Is Managed HSM External Key Management?”). No per-request justification signal or denial mechanism is documented, so refusal here means withholding the key encryption key rather than declining a particular request.

Nebius

Nebius KMS is in Preview, available in all Nebius regions, and described as following the customer-managed encryption keys model, with cryptographic erasure through key destruction for regulated deletion requirements — the one control in this comparison set that bears on an erasure obligation rather than on access (“Key Management Service in Nebius AI Cloud”). What Nebius does not publish is a per-service integration list of the kind Google maintains. Encryption itself is thorough — AES-256 with a two-level hierarchy of data encryption keys wrapped by key encryption keys (DEK/KEK), double encryption at service and infrastructure levels for Compute disks and Object Storage buckets, on by default for Network SSD though manual for the Non-replicated and IO M3 variants, and XTS-AES-256 with two independent keys for WEKA filesystems, which must be enabled at creation (“Encryption in Nebius AI Cloud”). No per-request justification or denial mechanism is documented.

Does the AI platform keep your prompts, and who may read them?

Everything above is infrastructure. The moment you call a managed inference service, a second set of questions opens: who holds the prompt, for how long, who may read it, and whether the company that trained the model is in the path at all.

AWS

Bedrock brokers models rather than proxying them. Bedrock’s own commitment comes first: “Amazon Bedrock never shares your data with model providers or uses it to train foundation models,” and “inputs and outputs are never shared with model providers or used to train base models” (“Security, Privacy, and Responsible AI in Amazon Bedrock”). The architecture behind that is worth seeing. Bedrock’s documentation uses “model provider” for the party that delivers a model to AWS rather than for the operator of any endpoint: after delivery, AWS performs a deep copy of the provider’s inference and training software into a Model Deployment Account, one per provider per Region, “owned and operated by the Amazon Bedrock service team” and inaccessible to the provider, so providers see no prompts, completions or logs (“Data Protection in Amazon Bedrock”). That is the structural difference from calling the same provider’s own API, where the provider is the operator and its retention terms govern — routing through Bedrock does not take a party out of the path, it changes which party holds the data. The claim is scoped to account access: providers cannot reach the accounts. Whether that exhausts the routes to content is a further question the documentation does not answer — it does not assert that no network path exists from the endpoint back to the provider.

AWS’s own retention is a separate question from the provider-sharing commitment. The documented default is favorable and worth stating first: Bedrock “uses a zero data retention (ZDR) data security model,” meaning that by default it does not store model inputs or outputs, alongside a zero operator access model under which “no operators of the service can access model input or output” (“Amazon Bedrock Abuse Detection”). From there it is configurable. The retention mode is set per Region, at account level through PutAccountDataRetention or at project level, and takes none for zero retention, default to permit retention for safety and abuse prevention, aws_review to permit retention for human review conducted inside AWS, the legacy provider_data_share, and inherit — the default for new accounts and projects — which defers to a broader scope (“Data Retention”). Worth noting that the boto3 SDK reference for put_account_data_retention still shows only default, none, provider_data_share and inherit, while both the API reference and the user guide document aws_review as well. Some models cannot be invoked until a review-permitting mode is set (“Data Retention”); for those, prompts and completions are retained inside the AWS boundary for up to 30 days and may be reviewed by AWS to satisfy a human-review requirement the model provider imposes as a condition of access, with content still not shared with that provider. On other named models only classifier-flagged traffic is retained (“Amazon Bedrock Abuse Detection”). Where a provider does require retention, zero data retention has to be arranged per account and per model through an account team rather than set in a console — the AWS account manager in general, but Anthropic’s own account representative for Claude models. Neither adjacent control substitutes: the AWS AI services opt-out policy does not list Bedrock among its named services and governs content use rather than retention, though its default key is documented as covering all currently available AI services (“AI Services Opt-out Policy Syntax and Examples”). The policy governs use of content for service improvement, which Bedrock’s own documentation rules out unconditionally, so the omission is consistent with the control being unnecessary there rather than with a gap, and model invocation logging — opt-in, off by default, writing to the customer’s own Amazon S3 bucket or CloudWatch in their own account and Region — is independent of it (“Monitor Model Invocation Using CloudWatch Logs and Amazon S3”). PrivateLink endpoints keep traffic off the public internet.

Google Cloud

Google’s documentation on this question is organized differently from the other three: granular on retention durations and training use, thinner on the one artifact the others publish as product documentation. Its self-serve zero-data-retention page for the Agent Platform states that “Google won’t use your data to train or fine-tune any AI/ML models without your prior permission or instruction” and that this “applies to all managed models on Gemini Enterprise Agent Platform, including GA and pre-GA models” — a scope broader than either competitor’s. The same page documents that the store parameter defaults to true, that request-response logging is off by default, that grounding retention runs to three days for Google Search, thirty for Google Maps and seven for Deep Research with a 24-hour cache TTL, and that an exception to abuse monitoring can be requested (“Gemini Enterprise Agent Platform and Zero Data Retention”). Its data-governance documentation for Agent Search adds that foundation models are frozen and only process input to provide output for that service (“Data Governance and Generative AI”); CMEK with Cloud EKM extends to Vertex AI, so the key path is strong. On third-party model builders Google’s statement is a product blog rather than current documentation: announcing Claude’s general availability on Vertex AI, Google wrote that customer data “is not shared with model providers” (“Anthropic’s Claude 3 Models Go GA on Vertex AI”). Anthropic’s own documentation says data handling for the offering “is governed by Google Cloud” and that enabling request-response logging “does not give Google or Anthropic any access to your content” (“Claude on Google Cloud”). A clause in current product terms would be the stronger form, and is worth asking an account team to supply. Google publishes an abuse-monitoring page and names durations for the adjacent retention paths, but states no duration for abuse-monitoring logs — and neither does Microsoft for its equivalent store. AWS is the only one of the three that publishes a figure. All of this is best treated as unverified rather than absent, and is worth asking an account team to confirm in writing.

Microsoft Azure

Microsoft’s commitments are organized around a distinction worth establishing first, because it decides which set applies. Foundry divides its catalog into models sold by Azure, which “Microsoft hosts and sells… under Microsoft Product Terms” and which are enumerated on a page of their own, and models from partners and community, which third-party labs provide and support (“Overview of Microsoft Foundry Models (Classic)”). The familiar guarantees attach to the first group. For models sold by Azure, prompts, completions, embeddings and training data are not available to other customers, not available to OpenAI or other providers of those models, not used by those providers to improve their models or services, not used to train any generative AI foundation models without your permission or instruction, and not used to improve Microsoft or third-party products or services without your explicit permission or instruction; Microsoft adds that these models do not interact with any services operated by those providers, naming OpenAI as the example provider (“Data, Privacy, and Security for Foundry Models Sold by Azure in Microsoft Foundry”). Fine-tuned models are available exclusively to the customer whose data created them. Storage stays in the customer’s Azure geography with AES-256 and the option of a customer-managed key, though some preview features do not support one.

Abuse monitoring for that group is documented as a mechanism rather than a duration. Flagged prompts and completions go to a store logically separated by customer resource, with “a separate data store” “located in each geography in which the model sold by Azure is available” and a customer’s content held in the Azure geography where its Foundry resource is deployed. Human reviewers are authorized Microsoft employees working through Secure Access Workstations with just-in-time request approval, and they can reach content only once the system has flagged it or it forms part of a potentially abusive pattern of use; for deployments in the European Economic Area those employees are located in the EEA. Neither the data-privacy page nor the abuse-monitoring page now states how long that store keeps content, so the thirty-day figure that circulates is better confirmed with an account team than cited (“Foundry Models Sold by Azure Abuse Monitoring”). Modified abuse monitoring — the Limited Access exemption customers apply for — removes the storage and the human review, while automated review may continue; it is available only to “customers and partners managed by a Microsoft account team or under an eligible program, and are subject to additional requirements” (“Limited Access for Foundry Models Sold by Azure”), and it is verified by checking that ContentLogging is false (“Data, Privacy, and Security for Foundry Models Sold by Azure in Microsoft Foundry”). Deployment types govern where processing happens: Standard stays within the customer-specified Azure geography and “might be processed between regions within that geography for operational purposes,” Global “may be processed in any Azure region,” and Data Zone stays within the Microsoft-specified US, EU or Asia Pacific zone. Across these types, data stored at rest “remains in the designated Azure geography.” The Developer type — fine-tuned-model evaluation only, with a fixed 24-hour lifetime and automatic deletion — “doesn’t include data residency guarantees or an SLA” (“Deployment Types for Microsoft Foundry Models”).

Partner models answer the provider-in-the-path question differently, and Claude is the clearest worked example because Microsoft documents it separately. Foundry offers two hosting options. Hosted on Azure processes prompts and outputs on Azure infrastructure — request ingress, API services and GPU inference — with data at rest in the selected Azure geography; hosted on Anthropic infrastructure processes them on Anthropic’s own, where data “might be processed outside of Azure including outside of your selected Azure region.” The part that matters for a threat model holds in both cases: “Anthropic is the seller and operator of Claude models in Microsoft Foundry and acts as an independent data processor for prompts and outputs,” and content that automatic safeguards flag may be sent to Anthropic Trust & Safety, where Anthropic personnel review customer content on an exceptions-only basis (“Data, Privacy, and Security for Use of Anthropic Claude Models in Microsoft Foundry”). Anthropic describes the Azure-hosted boundary the same way from its own side — prompts and completions remain within Azure, and only usage metadata and safety-flagged content egress to Anthropic (“Claude in Microsoft Foundry”). Note that Bedrock is no longer the only AWS route to a frontier model either: on Claude Platform on AWS, Anthropic operates the inference stack and is the independent data processor, and its own zero-data-retention programme applies there rather than on Bedrock (“Claude Platform on AWS”). Which route you call decides whether the model builder is excluded from the path or is the operator of it. So selecting Azure hosting moves the computation into Azure without moving the model builder out of the processor role, which is the reverse of the Bedrock arrangement and a reminder that this answer is a property of the platform and the particular model rather than of the cloud.

Nebius

One structural fact shapes everything else in this column: Token Factory serves open-weight models only. Its catalog is DeepSeek, Qwen, GLM, Nemotron, Kimi, MiniMax, Gemma, Hermes, MiniCPM and gpt-oss (“Model Catalog”) — Llama, named in the launch release, no longer appears in the inference catalog, though five Llama models remain documented for fine-tuning and as LoRA bases — and Nebius describes the platform as supporting “all major open models” alongside the option for customers to host their own (“Nebius Launches Nebius Token Factory to Deliver Production AI Inference at Scale”). None of the closed-weight frontier models — Anthropic’s Claude, OpenAI’s GPT line, Google’s Gemini — are offered. The provider-in-the-path question that occupies the other three sections therefore does not arise here: there is no third-party model builder holding weights it will not hand over, and so none that needs excluding from the account or allocating a processor role. What you trade for that is access to the closed-weight frontier specifically; the catalog’s own top end runs to several hundred billion parameters and includes vision and embedding models, so it is a capability decision rather than a privacy one. Note too that Nebius never states the catalog is open-weight only; the exclusivity is read off the catalog rather than from a published commitment.

Within that scope, Token Factory documents its posture in unusual detail. Zero Data Retention is opt-in at the organization level and self-serve: inputs and outputs are not stored after processing and are not used for speculative decoding or to train, fine-tune or improve any model. Nebius notes that zero data retention, abbreviated ZDR, “may impact the level of service provided (e.g., inference speed),” and separately that under it your data is not used for speculative decoding. Customer content is not used to train any models in either mode. Public endpoints process dynamically across global infrastructure with no region guarantee, and Nebius states they are “not intended for production use cases that require a stable, predictable region” — a narrower warning than the blanket version sometimes quoted. Dedicated endpoints make region selection contractually binding under Section 6.1 of the data processing agreement (DPA), with no multi-region routing or automatic overflow. Fine-tuning datasets, artifacts and model outputs are stored exclusively in EU data centers — Nebius notes that a job submitted by a US user is processed in US data centers while the data is still stored in the EU — and sub-processor changes carry at least fifteen days’ prior notice (“Legal Quick Guide”).

What happens when a foreign authority compels production?

This is the threat that defeats most architecture diagrams, because it does not travel over the network. A court orders the provider to hand over data, and the question is whether the provider can.

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act is the instance everyone names, and the first thing to understand is that data residency is not the axis it turns on. 18 U.S.C. § 2713 provides that a provider “shall comply with the obligations of this chapter to preserve, backup, or disclose” data “within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.” It creates no production duty of its own; it extends the duties that already exist elsewhere in the chapter to data held abroad. Choosing a European Region does not, by itself, put data beyond reach; what matters is whether a US entity controls data held by a European one.

That question is genuinely unsettled. The Department of Justice’s own guidance calls whether a company exercises sufficient control over a subsidiary’s data “a fact-dependent inquiry,” while adding in the same answer: “The analysis remains the same regardless of corporate structure” — it treats the question as factual, not as one a corporate form settles (Promoting Public Safety, Privacy, and the Rule of Law Around the World). US courts have split, in the civil-discovery case law on “control,” between a legal-right standard that asks whether the parent has a legal right to demand the documents, which a properly constituted foreign subsidiary can defeat, and a practical-ability standard that asks only whether the parent can in fact obtain them, which a wholly-owned subsidiary struggles to defeat. No court has decided which of those, if either, governs § 2713, and no published decision applying either to a sovereign-cloud entity structure was located — so the legal claim behind these offerings is untested rather than validated.

One statutory detail matters here and rarely appears in sovereignty materials. The CLOUD Act’s motion-to-quash route under § 2703(h) is narrower than it is usually described. It reaches only process for the contents of communications, only where the provider reasonably believes the subscriber is not a US person and does not reside in the US, and only where disclosure would create a material risk of violating the law of a “qualifying foreign government” — which the statute defines as one that both has an executive agreement in force under § 2523 and whose own laws give providers comparable substantive and procedural opportunities. Executive agreements exist with the United Kingdom, in force since 3 October 2022, and Australia, since 30 January 2024 (“CLOUD Act Resources”). Those are also only the conditions for filing, within fourteen days of service; relief then requires the court to find, cumulatively, that disclosure would cause the violation, that the subscriber is not a US person and does not reside in the US, and that on the totality of the circumstances the interests of justice favor quashing. There is no US–EU agreement, so an EU customer of a US-linked provider has no § 2703(h) route and is left with generally applicable objections and discretionary common-law comity.

EU law does not close the gap so much as sharpen the conflict. Article 48 of the General Data Protection Regulation (GDPR) provides that a third-country judgment or administrative decision requiring disclosure “may only be recognised or enforceable in any manner if based on an international agreement” — closing, though, “without prejudice to other grounds for transfer pursuant to this Chapter,” and the European Data Protection Board (EDPB) reads the article as not itself a transfer ground, which leaves a disclosure potentially lawful on another Article 6 basis together with another Chapter V ground. The EDPB reaffirms that “a request from a foreign authority does not in itself constitute a legal basis for the processing or a ground for the transfer” (Guidelines 02/2024 on Article 48 GDPR). Data Act Article 32 imposes a parallel regime for non-personal data, with a narrow conditional path requiring that the third-country system demand reasoned, proportionate and specific orders, that the addressee’s reasoned objection be reviewable by a third-country court, and that the court be able to weigh the provider’s EU-protected interests. The EDPB and the European Data Protection Supervisor (EDPS) assessed the result as a conflict of laws rather than a shield: absent an international agreement, “the lawfulness of such processing cannot be ascertained,” save for exceptional vital-interest cases (Initial Legal Assessment of the Impact of the US CLOUD Act, annexed to the EDPB–EDPS joint reply to the LIBE Committee, 10 July 2019 — a 2019 view the EDPB’s 2025 Article 48 guidelines qualify). The provider ends up exposed to EU illegality for complying and US contempt for refusing.

What the providers actually offer

AWS’s answer is structural. The European Sovereign Cloud launched on 14 January 2026 with its first Region, eusc-de-east-1, in Brandenburg, Germany — a separate aws-eusc partition with independent billing, account and identity systems, operated by German entities under German corporate law whose managing directors are EU nationals resident in the EU, overseen by a five-member advisory board, all EU citizens and residents, including two independent members (“Opening the AWS European Sovereign Cloud”; “AWS European Sovereign Cloud — Governance”). The commitment on government requests is one of effort: redirect the requester to the customer, notify the customer, “use all legally valid efforts to challenge any Request that conflicts with the laws of the EU (including GDPR) or applicable Member State law, or is otherwise overbroad or inappropriate,” and disclose only the minimum content necessary (“AWS European Sovereign Cloud Addendum”). Your contracting party remains a Luxembourg entity within the Amazon group. Google documents a comparable local-entity structure of its own, described below, so the two are better read as two structural answers with different shapes than as a ranking.

Google’s answer is both structural and technical. Structurally, Google Cloud Dedicated is a standalone, physically and logically isolated instance of Google Cloud “operated by independent local partners,” where “the local partner maintains exclusive control over security-critical systems, identity management, authentication, and all cryptographic roots of trust” and “standard Google operators have no direct access”; in France it is operated by S3NS, a standalone French entity whose PREMI3NS offering holds SecNumCloud 3.2 qualification from ANSSI, and it is in preview in Germany (“Google Cloud Dedicated”). Technically, Key Access Justifications gives the customer a per-request approve-or-deny policy on each key access, enforced in Cloud KMS, on by default for new Assured Workloads folders under a qualifying control package, and with select external key-management partners enforced by the external key manager rather than by Cloud KMS (“Key Access Justifications Overview”). Google describes the control of encryption keys as “the strongest and most effective technical measure against extraterritorial requests for data that can be offered to cloud customers today” (“Advancing Digital Sovereignty on Europe’s Terms,” October 2022) — note “technical measure,” not legal guarantee. Google Distributed Cloud air-gapped goes further: the technical documentation states it does not depend on a connection to Google Cloud, and Google’s sovereign-cloud page says it “runs independently and cannot be remotely shut down by Google” (“Sovereign Cloud”).

Microsoft’s answer is contractual and litigative. Announced in April 2025 and reported as executed a year later, the European Digital Resilience Commitment is legally binding on Microsoft Corporation and all its subsidiaries through Microsoft’s contracts with European national governments and the European Commission. It commits Microsoft, should any government order it “to suspend or cease cloud operations” in Europe, to “promptly and vigorously contest such a measure” “using all legal avenues available, including by pursuing litigation in court” (“Microsoft Announces New European Digital Commitments”). That commitment addresses service continuity. A second, separate one reaches data production: under the Defending Your Data Initiative Microsoft commits to “challenge government data requests for EU public-sector or commercial customers” “where we have a lawful basis to do so” (“One Year On: Progress on Our European Digital Commitments”).

Nebius’s position is that it is not a US company. That weakens the CLOUD Act’s primary hook rather than answering it technically — and the control analysis above turns on corporate control rather than parent domicile, while Nebius operates two United States regions, so the question is narrowed rather than closed. It is paired with EU-only fine-tuning storage and region selection bound by the data processing agreement (DPA) — with no confidential computing or external key custody documented.

A useful reference point is what a provider has said under oath. Asked at a French Sénat commission of inquiry on 10 June 2025 whether he could guarantee that French citizens’ data entrusted to Microsoft through UGAP, the French central public-procurement agency, would never be transmitted following a US government order without the explicit agreement of the French authorities, Microsoft France’s director of public and legal affairs answered “Non, je ne peux pas le garantir, mais, encore une fois, cela ne s’est encore jamais produit” — no, I cannot guarantee it, but, once again, it has never yet happened — while adding that Microsoft contractually resists requests it considers unfounded, and that “lorsque nous sommes obligés de les donner, nous les donnons”: where a valid obligation attaches, it complies (Audition de représentants de Microsoft France). No provider offering a stronger assurance on this particular point was located — the stronger claims on offer, such as an air-gapped deployment that cannot be shut down remotely, are about continuity rather than production — and the constraint is the legal position rather than any one company’s posture.

Where that leaves the architecture. External key custody is the hinge, because a provider that holds no key cannot produce plaintext — and the limit is the EDPB’s: for services requiring access to data in the clear it is, “considering the current state of the art, incapable of envisioning an effective technical measure to prevent that access from infringing on the data subject’s fundamental rights” (Recommendations 01/2020). Managed inference is exactly such a service. So key custody protects what the provider never needs to read, and protects nothing in a hosted model that must read the prompt. Note also that the clause people cite as relieving providers of any duty to decrypt, § 2523(b)(3), governs what a CLOUD Act executive agreement may require and does not limit domestic process. The structures reduce exposure; none of them eliminates it.

Can you satisfy a residency, sovereignty or sector regime?

The last threat in this section is not an adversary at all. It is an obligation, and it constrains an architecture as hard as any attack — sometimes harder, because it can rule out a service that is otherwise perfect.

Sovereignty and residency programs

AWS offers the European Sovereign Cloud described above, with Bedrock and SageMaker available at launch (“Opening the AWS European Sovereign Cloud”). Google offers Assured Workloads, with regional data boundaries, regulatory data boundaries covering the International Traffic in Arms Regulations (ITAR), the Federal Risk and Authorization Management Program (FedRAMP) at Moderate and High, Impact Levels 2, 4 and 5, CJIS, IRS Publication 1075, Canada’s Controlled Goods Program and Protected B, and two US healthcare and life-sciences boundaries, and Sovereign Controls by Partners with GA partner boundaries for France (S3NS), Germany (T-Systems), Italy (Polo Strategico Nazionale, PSN) and two Saudi Arabian boundaries (CNTXT); the Assured Workloads controls include data residency, personnel data access controls, and Key Access Justifications for viewing and approving key access requests (“Overview of Assured Workloads”). Microsoft Sovereign Cloud spans a Sovereign Public Cloud within a defined geopolitical boundary such as the EU Data Boundary, with “enhanced sovereignty controls, such as Data Guardian, External Key Management, and tamper-evident access logs”; a Sovereign Private Cloud (Azure Local, Microsoft 365 Local, GitHub Enterprise Local and Foundry Local on Azure Local) supporting “hybrid or disconnected operations”; and National Partner Clouds (“What Is Microsoft Sovereign Cloud?”). Nebius publishes no sovereignty program with a documented control set of this kind. It does hold a named sovereignty partnership — Palantir designated it its preferred sovereign AI infrastructure partner in September 2026, placing Nebius endpoints inside Palantir’s enterprise perimeter — but that announcement defines no control set, residency guarantee or personnel-access restriction. Its documented answer to a residency requirement is region selection on a footprint that is mostly European — Finland, Spain, two French and two UK regions, with Israel and two United States regions alongside, plus a private Iceland region open only to existing deployments — where the core services including identity and access management, audit logs and KMS are listed as available in every region (“Public Regions”), KMS itself still in preview (“Key Management Service in Nebius AI Cloud”), together with the contractual region binding on dedicated endpoints and the commitment that fine-tuning data stays in the EU whatever the customer’s location. That covers residency. It does not reach the personnel-access restrictions the three programs document, nor the key-justification approval workflow Google’s is built around, which is the distinction to hold onto if a regime asks for those specifically. The UK regions are of course outside the EU, which matters for a residency requirement written in EU terms.

What a sector certification actually covers

Two providers make the scoping point most sharply; AWS and Azure publish eligible-service lists this post has not worked through. Google’s business associate agreement (BAA) under the Health Insurance Portability and Accountability Act (HIPAA) expressly covers “Generative AI on Agent Platform,” Gemini Enterprise Agent Platform, Gemini Enterprise, Vertex AI Workbench instances, AI Platform Training and Prediction, and the classic ML APIs — and its best-practice guidance is not to use pre-GA offerings with protected health information “unless expressly noted otherwise in a notice or other terms of the offering” (“HIPAA Compliance on Google Cloud and Google Workspace”); the binding version is in the Service Specific Terms, where no data processing terms apply to pre-GA offerings at all, which is a hard constraint for anyone putting protected health information through a preview AI feature.

Nebius makes the same point more sharply. It publishes a broad certification list with System and Organization Controls (SOC) 2 Type II and HIPAA among it (“Trust Center”), but the operative document is the HIPAA implementation guideline, which for Token Factory determines eligibility “at the capability and API-method level” rather than by product, while AI Cloud eligibility is granted service by service. For Token Factory only the /chat/completions and /completions endpoints are eligible, and only with zero data retention switched on: “Where ZDR is not enabled, Token Factory must not be used with PHI/ePHI under this guideline.” Fine-tuning and training and batch inference are outside HIPAA scope unless separately approved; embeddings, file upload and storage, and dataset management are out of scope by default. On the AI Cloud side eligibility is granted service by service — Object Storage for persistent ePHI, Compute Instances and Managed Kubernetes for transient processing. A business associate agreement has to be fully executed before protected health information is submitted (“HIPAA Implementation Guideline”). On both providers examined here that set is narrower than the certification badge suggests, which is reason to ask any provider which call paths are inside the envelope rather than whether it is HIPAA-capable.

What the platform layer offers against the earlier phases

Two categories of managed service answer threats from the preceding posts rather than from this one, and they belong here only as an inventory.

Guardrails answer the inference-phase input and output threats. Bedrock Guardrails carry no preview labels in the documentation — content filters covering hate, insults, sexual, violence, misconduct and prompt attack, all supported in both the Classic and Standard tiers with the Standard tier extending detection into code, denied topics, word filters, sensitive-information filters with standard PII plus custom regex in block or mask mode, contextual grounding, and automated reasoning checks, generally available since August 2025 (“Automated Reasoning Checks Is Now Available in Amazon Bedrock Guardrails”) — with Amazon Comprehend for standalone PII detection. Google Model Armor screens for prompt injection and jailbreak, applies Responsible-AI categories for hate speech, harassment, sexually explicit and dangerous content at configurable confidence levels, with CSAM a fifth category in the same filter that is “applied by default and cannot be turned off,” integrates Sensitive Data Protection for PII, detects malicious URLs and screens documents, enforced across projects through floor settings; image screening remains Preview and is limited to the us and eu multi-regions (“Model Armor Overview”). Azure AI Content Safety’s overview feature table marks groundedness detection and both custom-categories APIs as preview, and leaves Prompt Shields, protected material text detection and the text and image analysis APIs untagged. Groundedness correction, multimodal analysis and protected material detection for code are listed as preview on the what’s-new page (“Azure AI Content Safety Overview”). Task adherence is public preview; the feature table on the Content Safety overview omits the tag that its own concepts page and the what’s-new entry both carry. Purview DSPM for AI — data security posture management, the discovery-and-policy layer that reports which AI apps are seeing which sensitive data — spans Copilot experiences and agents, enterprise AI apps including Microsoft Foundry, Entra-registered apps, Anthropic Claude Enterprise and ChatGPT Enterprise, and browser-detected “other AI apps” including Google Gemini, DeepSeek and consumer ChatGPT (“Microsoft Purview and AI”). Standalone PII detection on Azure is a different service again, Azure AI Language’s PII detection for text, conversation and document input. Nebius documents nothing comparable, so on the documentation available the pattern there is bring-your-own; NeMo Guardrails, Llama Guard or Presidio in front of vLLM or SGLang on Managed Kubernetes is one way to assemble it.

Clean rooms answer the multi-party threats. AWS Clean Rooms ships Cryptographic Computing for Clean Rooms (C3R), which turns join keys into hash-based message authentication code (HMAC) fingerprint columns and the remaining values into AES-GCM sealed columns, plus Clean Rooms ML for lookalike and custom models, with differential privacy generally available since April 2024 (“AWS Clean Rooms Differential Privacy Is Now Generally Available”). BigQuery data clean rooms enforce three analysis rules — aggregation threshold, differential privacy with per-query and aggregate epsilon and delta budgets, where exhausting a budget across one or more queries stops the view being queried at all, and list overlap. Two details to get right: the join-restriction policy is optional for the first two but mandatory for list overlap, and while differential-privacy enforcement is generally available, the parameter-driven privacy budgeting still carries a Preview badge (“Restrict Data Access Using Analysis Rules”). Azure Confidential Clean Rooms is in limited preview, and Microsoft states that customers “should not use the preview to process personal data or other data that is subject to legal or regulatory compliance requirements”; Spark driver and executors run as attested enclaves on Confidential ACI inside AKS, governed by the Confidential Consortium Framework, with only Spark SQL analytics available — Microsoft directs customers whose requirements fall outside it, such as custom analytics pipelines, ML training and fine-tuning, or inferencing, to submit a request form (“Azure Confidential Clean Rooms”). Nebius documents no clean-room service.

Comparison

GA = generally available · PREV = preview · LTD = limited/gated · n/a = question does not arise · — = nothing found in current vendor documentation, which is not a vendor statement that the capability is absent · ? = unverified.

Statuses and counts are as of 8 October 2026.

Capability AWS Google Cloud Azure Nebius
CPU TEE — AMD SEV-SNP GA, specific sizes of m6a / c6a / r6a; Dedicated Hosts any commercial Region (no uplift); shared tenancy US East (Ohio) + Europe (Ireland) only, +10% of On-Demand GA, N2D only, 14 zones GA, v5 and v6 families —
CPU TEE — Intel TDX — GA, c3-standard-* (24 zones), c3-standard-*-lssd, c4-standard-* (GA 23 Sep 2026) GA, DCesv6/ECesv6 —
Always-on memory encryption GA, host DRAM, platform-keyed, no attestation ? ? ?
Enclave-style isolation Nitro Enclaves, GA all Regions; cannot combine with SEV-SNP Confidential Space — attested workload plus workload-identity gating on a confidential VM, not a separate enclave primitive Conf. Containers ACI and AKS node-pool how-to carry no label; DCasv5/ECasv5 GA; Kata CoCo PREV; TDX not currently on AKS —
GPU confidential computing — GA; H100 in 3 zones (Intel TDX), RTX PRO 6000 in 36 (plain AMD SEV — vTPM-signed VM quote, no AMD hardware report; GPU attestation via nvattest) GA, NCCadsH100v5 single SKU; no published region table — query az vm list-skus —
Confidential H200 / GB200 — — — —
Multi-GPU confidential (both documented offerings are single-GPU) — — — —
Attestation service Nitro Enclaves + SEV-SNP report + EC2 instance attestation GA (all commercial Regions + GovCloud) Google Cloud Attestation (SEV + TDX) / Intel Trust Authority (TDX only) MAA; TDX absent from its listed platforms, routed via Intel Trust Authority elsewhere —
Attestation-gated key release KMS condition keys on Decrypt/GenerateDataKey; response encrypted to enclave key Workload identity federation → Cloud KMS Secure Key Release from Key Vault / Managed HSM —
Hold-your-own-key / external key custody XKS — lowest throughput, no SLA, AWS says risk exceeds benefit for most; per-request metadata but no justification code Cloud EKM + Key Access Justifications (per-request, policy-denyable at the partner) Managed HSM external key management (PREV, sovereign clouds out of scope); Managed HSM FIPS 140-3 L3, customer controls security domain + HSM admin —
Customer-managed keys Bedrock: customization jobs, agents, knowledge-base ingestion, vector stores, eval jobs; prompts/flows/sessions separately; batch output key at job creation Published list, not a count; Vertex AI included Key Vault / Managed HSM; not all preview features KMS PREV, CMEK model described; no per-service list
Model builder sees customer content No on Bedrock — Model Deployment Account, no provider account access; on Claude Platform on AWS the builder is the operator Google blog states data “is not shared with model providers”; Anthropic states logging gives neither party access Depends on category — no for models sold by Azure; for partner models such as Claude the builder is an independent processor under both hosting options n/a — open-weight catalog only, so no third-party builder in the path
No training on customer data Yes — “never shared with model providers or used to train base models” Yes — all managed models on Agent Platform, GA and pre-GA Yes Yes — with or without ZDR
Zero retention ZDR the documented default; none mode settable; per account and model via account team where a provider requires retention store=false on the Interactions API; exception requestable for abuse monitoring Modified abuse monitoring (LTD) — application required ZDR, opt-in, self-serve
Default abuse retention Up to 30 days inside the AWS boundary on review-gated models, to meet a provider’s human-review condition; classifier-flagged only on other named models Durations published for grounding paths; none for abuse-monitoring logs Mechanism published — per-geography store, EEA reviewers for EEA; no duration stated None with ZDR
Guardrails / content safety Bedrock Guardrails, no preview labels in docs; PII filters incl. custom regex Model Armor — prompt-injection and jailbreak screening, Responsible-AI categories, non-optional child-safety filter, SDP for PII, URL and document screening; image screening PREV, us / eu multi-regions Content Safety; several features PREV —
Standalone PII detection Amazon Comprehend Sensitive Data Protection (integrated via Model Armor) Azure AI Language PII detection (text / conversation / document) —
Erasure-relevant control — — — Cryptographic erasure by key destruction
EU sovereign cloud European Sovereign Cloud launched 14 Jan 2026, eusc-de-east-1 (Brandenburg); Bedrock + SageMaker at launch Google Cloud Data Boundary / Assured Workloads; Google Cloud Dedicated (S3NS France, SecNumCloud 3.2; Germany PREV); partner boundaries S3NS (FR) / T-Systems (DE) / PSN (IT); Google Distributed Cloud air-gapped Sovereign Public / Private / National Partner; Foundry Local on Azure Local EU regions FI/ES/2×FR (plus 2×UK and a private Iceland region, non-EU); fine-tuning data EU-only regardless of customer location
CLOUD Act posture (classification) Structural — separate German operating entities, EU-resident directors; contracting party remains a Luxembourg Amazon entity; contractual effort to challenge; no legal immunity claimed Structural and technical — Google Cloud Dedicated operated by independent local entities (S3NS in France, SecNumCloud 3.2; Germany preview), Google operators excluded; Key Access Justifications; air-gapped Google Distributed Cloud Contractual — Resilience Commitment covers service continuity; Defending Your Data covers challenging data requests where a lawful basis exists Jurisdictional — non-US parent; EU-only fine-tuning storage; DPA region binding; no confidential computing or external key custody documented
HIPAA BAA covers AI services ? Yes, named AI services; pre-GA excluded unless noted ? Certification list includes SOC 2 Type II and HIPAA; Token Factory BAA scope /chat/completions + /completions with ZDR; AI Cloud by service — Object Storage for persistent ePHI, Compute and Managed Kubernetes transient only
Clean rooms AWS Clean Rooms + C3R + differential privacy GA BigQuery clean rooms GA; differential-privacy enforcement GA, parameter-driven budgeting PREV LTD/PREV — not for personal or regulated data —

References

「CODAS Community」へのご参加・ご登録について

一般社団法人AIデータ主権共創機構（CODAS）では、「Privacy-First AI」基盤の構築と持続可能なAIエコシステムの発展に向け、研究者・エンジニア・法務・政策・ビジネス・市民など、立場を越えてオープンに集い、秘匿AIの未来を共に創る共創プラットフォーム「CODAS Community」のメンバーを募集しています。

■ 法人企業様のご参画

CODASの理念や取り組みにご賛同いただき、AIエコシステムの社会実装や標準づくり、共創プロジェクトを共に推進していただける法人企業様を募集しております。ご入会や連携に関するお問い合わせ・お申し込みは、下記フォームより承っております。

お問い合わせフォーム：https://codas-ai.org/contact

※件名に「会員の申込」とご明記のうえ、貴社の簡単なご紹介（事業内容等）を添えてご連絡ください。確認後、担当者よりご案内いたします。

■ 個人・一般の皆様のご参加

公式Discordおよびメールマガジンでは、勉強会・ワークショップ・ミートアップ等のイベントへの優先アクセスや、秘匿性技術・ルール標準化に関する最新の知見をお届けします。東京のリアル拠点での交流も含め、立場を問わずどなたでもご参加いただけます。

CODASについて

一般社団法人AIデータ主権共創機構（CODAS）は、「安全・安心なAI社会」の実現を目指す非営利・中立の法人です。データプライバシー技術の研究開発と、そのオープンソース化による社会実装を推進しています。データを外部に出さずにAIを高度活用できる「Privacy-First AI」基盤を「創る・使う・広げる」ことを基本理念に掲げています。

≪本件に関するお問い合わせ先≫

一般社団法人AIデータ主権共創機構（CODAS）イベント事務局 E-mail：info@codas-ai.org