Regulatory Compliance for AI Systems (GDPR, HIPAA, FedRAMP).

An architect's compliance job is to match the deployment surface an organization uses, API direct, AWS Bedrock, GCP Vertex, Azure/Microsoft Foundry, or Claude for Government, and the account tier, to the regulatory regime the workload requires, then explicitly enable the controls that are not on by default. Anthropic's compliance posture is real but conditional: several protections require administrator action rather than automatic inclusion, and the exact certification set differs for consumer versus commercial products.

This is a verify the current tier's paperwork discipline, not a one-time checkbox. GDPR, HIPAA, and FedRAMP are three different kinds of regime, a legal framework, a US healthcare law with a contractual mechanism (the BAA), and a federal authorization program, and each maps to a different artifact or deployment path rather than one universal "Anthropic is compliant" answer.

Commercial certification baseline. Anthropic's commercial products, Claude for Work and the Anthropic API, maintain HIPAA-ready configuration (BAA available), ISO 27001:2022, ISO/IEC 42001:2023 (AI Management Systems), and SOC 2 Type I & II. These are explicitly scoped to commercial products, not consumer plans, a team prototyping on a free or consumer account cannot point to this certification set at all, regardless of what it builds.

HIPAA BAA coverage is opt-in, and it has three genuinely different paths, not one workflow with two names. (1) On Claude Enterprise, specifically the organization's Primary Owner self-activates HIPAA compliance under "Data & Privacy" settings and signs Anthropic's BAA directly — other Owners or Admins cannot complete this on the org's behalf; standard Enterprise plans do not include this automatically. (2) On the direct 1P API, BAA eligibility is a *separate* path from Enterprise's — but for most organizations it's ALSO self-service: eligible orgs review and execute Anthropic's standard BAA directly in Claude Console (Settings > Privacy), no sales contact required. Only organizations needing a negotiated/custom BAA, or where self-serve isn't available, work through Anthropic's sales team instead. Critically, HIPAA readiness on the API does NOT cover every feature — the Batch API is explicitly NOT HIPAA-eligible, so PHI cannot be sent through Batch even with an active BAA; the API enforces this with a 400 error on non-eligible features. (3) Via a cloud-provider surface (AWS Bedrock, GCP Vertex), coverage runs under that provider's own BAA (the AWS or Google Cloud Business Associate Addendum), not Anthropic's BAA at all, the model provider never sees the raw prompts/completions in that path. Conflating the Enterprise activation workflow with API BAA eligibility, or assuming either one covers a Bedrock/Vertex deployment, is a live compliance gap: a healthcare workload touching PHI before the *specific* path's activation step is complete is uncovered, independent of which model or feature is in use.

FedRAMP High and DoD IL4/5 live on a different surface, not a policy toggle, and that surface is not freely combinable with an EU-resident deployment for the same workload. Claude models are approved for FedRAMP High and DoD Impact Level 4/5 workloads via Amazon Bedrock in AWS GovCloud (US) regions, and Anthropic separately offers Claude Gov models for classified environments plus a dedicated Claude for Government application at FedRAMP High, all US-only, isolated surfaces. EU data/inference residency is a *different* regional deployment (available across AWS Bedrock, GCP Vertex, and Microsoft Foundry EU regions). A single workload runs in one geographic surface at a time, so "FedRAMP High AND EU-resident" isn't a combinable pair of controls on one deployment, it describes two separate workloads on two separate surfaces. Reaching the federal regime means routing through a GovCloud/Government surface, not requesting paperwork against the standard commercial API.

Regional residency and GDPR run on a DPA plus a data-location choice. GDPR itself is not an Anthropic certification but a legal regime; the load-bearing artifact for an EU deployment is typically the Data Processing Addendum governing Anthropic's role as processor, combined with a regional data-residency choice available across AWS Bedrock, GCP Vertex, and Microsoft Foundry. Architects should verify current DPA terms against the live document rather than assume blanket "GDPR compliant" status.

The Trust Center is the canonical, living source. trust.anthropic.com hosts the current SOC 2 Type 2 and CSA STAR L2 reports, the DPA, and security-control documentation, request-gated rather than fully public. Because certifications and terms change, the compliance check is per-deployment verification against that live source, not a fact memorized once.