# Regulatory Compliance for AI Systems (GDPR, HIPAA, FedRAMP) > Compliance is a match-the-surface-to-the-regime exercise: an architect picks the deployment surface (API direct, AWS Bedrock, GCP Vertex, Microsoft Foundry, Claude for Government) and account tier the workload requires, then explicitly turns on the controls that are not on by default. HIPAA BAA coverage is admin opt-in, not automatic, and has three distinct paths (Enterprise self-activation, sales-enabled API, or the cloud provider's own BAA on Bedrock/Vertex), and FedRAMP High/DoD IL4-5 is tied to specific US-only surfaces that are not simultaneously combinable with an EU-resident deployment on the same workload. **Domain:** CCARP-D5 · Governance, Safety & Risk (14% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/regulatory-compliance-for-ai-systems **Last reviewed:** 2026-05-04 ## Quick stats - **Commercial certifications:** 4 - **Exam domain:** CCA-P D5 (14%) - **Deployment surfaces mapped:** 5 - **HIPAA BAA paths:** 3 (Enterprise / API / cloud BAA) - **Also tested in:** CCA-A D6 ## What it is 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. ## How it works 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, an administrator self-activates HIPAA compliance under "Data & Privacy" admin settings and signs Anthropic's BAA directly, standard Enterprise plans do not include this automatically. (2) On the direct 1P API, BAA eligibility is a *separate*, sales-mediated path: the organization's administrator signs Anthropic's BAA and then has to contact Anthropic sales to get it turned on, it is not the same self-service toggle as Enterprise. (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. ## Where you'll see it in production ### Healthcare clinical-notes summarizer Use Claude for Work/Enterprise or the API, never a consumer plan; have an administrator explicitly enable HIPAA compliance and execute the BAA before any PHI touches the system; choose a regional deployment matching data-residency requirements. ### Federal internal research assistant Route through Bedrock GovCloud or Claude for Government to land inside the FedRAMP High / IL4-5 boundary, a fundamentally different deployment path than the healthcare case, not just a policy toggle on the same one. ## Comparison | Surface | Geography | HIPAA path if PHI involved | FedRAMP High / IL4-5? | Combinable with EU residency on the same workload? | | --- | --- | --- | --- | --- | | Claude for Work / Enterprise (admin BAA) | Anthropic-hosted, region per Anthropic's offering | Path 1 - admin self-activates under Data & Privacy, signs Anthropic BAA | No | N/A - not the FedRAMP surface | | Direct 1P API (sales-enabled BAA) | Anthropic-hosted | Path 2 - admin signs Anthropic BAA + contacts sales to enable | No | N/A - not the FedRAMP surface | | AWS Bedrock / GCP Vertex (regional) | Region-selectable, incl. EU | Path 3 - covered under the cloud provider's own BAA, not Anthropic's | No (this is the commercial regional path, not GovCloud) | Yes - this IS the EU-residency surface | | AWS Bedrock in AWS GovCloud (US) | US-only, isolated | Covered under AWS's GovCloud BAA where applicable | Yes | No - GovCloud (US) and EU-resident Bedrock are different, non-overlapping regions | | Claude for Government / Claude Gov models | US-only, isolated | Government-contract terms, not the standard BAA paths above | Yes | No - a separate, US-only surface | ## Decision tree 1. **Does the workload process Protected Health Information (PHI)?** - **Yes:** Identify which surface it runs on first: Enterprise needs admin self-activation under Data & Privacy plus Anthropic's BAA; the direct 1P API needs an admin-signed BAA activated via Anthropic sales (a different workflow, not the Enterprise toggle); AWS Bedrock/GCP Vertex need the cloud provider's own BAA, not Anthropic's. Confirm the matching path before any PHI touches the system. - **No:** No BAA activation needed for this regime, continue checking the other regimes below. 2. **Does the workload need to sit inside a FedRAMP High or DoD IL4/5 boundary?** - **Yes:** Route through Amazon Bedrock in AWS GovCloud (US) regions, or Claude for Government / Claude Gov models for classified environments, a different deployment surface than the commercial API, not paperwork layered on top of it. Note this surface is US-only. - **No:** No federal-authorization boundary required for this workload. 3. **Does the same workload ALSO need FedRAMP High/IL4-5 AND EU-resident data/inference at once?** - **Yes:** Not achievable on one deployment - GovCloud (US) and EU-resident Bedrock/Vertex/Foundry are separate, non-overlapping regional surfaces. Split into two workloads on two surfaces, or confirm which requirement actually governs this specific data flow. - **No:** Proceed with whichever single surface matches the workload's actual regime. 4. **Does the workload require EU or cross-border data-residency guarantees?** - **Yes:** Choose a regional deployment (available across AWS Bedrock, GCP Vertex, and Microsoft Foundry) and verify the current Data Processing Addendum against the live Trust Center document, GDPR is not a certification Anthropic grants, the DPA plus residency choice are the artifacts. - **No:** Regional residency choice is not a blocking requirement here. 5. **Is the workload currently running on a consumer Claude plan rather than Claude for Work/Enterprise/API?** - **Yes:** Stop, none of the HIPAA BAA path, the ISO 27001/ISO 42001/SOC 2 certification set, or the FedRAMP surfaces apply to consumer plans, move to a commercial surface before layering on any of the checks above. - **No:** Commercial surface confirmed, the regime-specific controls above are reachable from here and can combine on the same deployment. ## Exam-pattern questions ### Q1. A healthcare startup is on Claude's standard Enterprise plan and starts processing PHI without any additional setup. Are they covered by a BAA? No. HIPAA BAA coverage is opt-in on Enterprise: an administrator must explicitly enable HIPAA compliance under Data & Privacy settings and execute Anthropic's BAA before it applies; standard Enterprise plans do not include BAA coverage automatically. Named distractor: "Enterprise plans always include HIPAA BAA coverage by default" - the opposite of Anthropic's documented opt-in mechanism. ### Q2. A team already has an Anthropic BAA signed for their Claude Enterprise seats. They now start sending PHI through the direct 1P API for a separate batch-processing pipeline. Does the Enterprise BAA cover the API usage? Not automatically - Enterprise BAA activation (admin self-service under Data & Privacy) and direct API BAA eligibility are two separate paths; the API path requires the admin to sign Anthropic's BAA and contact sales to have it turned on for API usage specifically. Named distractor: "one signed BAA with Anthropic covers all surfaces, Enterprise and API alike" - it conflates two distinct activation workflows into one. ### Q3. A federal agency wants a FedRAMP High / DoD IL4-5 workload and is currently calling the standard Anthropic API directly. What is the compliance gap? The standard API does not carry FedRAMP High/IL4-5 authorization on its own, that requires routing through Amazon Bedrock in AWS GovCloud (US) regions, or a dedicated Claude for Government / Claude Gov models surface. Named distractor: "request FedRAMP paperwork for the existing API deployment" - the gap is the deployment surface itself, not missing paperwork layered onto the same one. ### Q4. An architect tells a customer "we're GDPR compliant because we use Claude." What's wrong with that claim? GDPR is not an Anthropic certification the vendor grants a customer, it is a legal regime; the load-bearing artifact is the Data Processing Addendum governing Anthropic's role as processor, combined with an explicit regional data-residency choice, and both should be verified against the live Trust Center. Named distractor: "GDPR compliance is bundled automatically into every commercial Claude plan" - no such blanket certification exists in Anthropic's documented posture. ### Q5. A team needs to show SOC 2 Type II compliance to a security-sensitive customer but is prototyping on a free consumer Claude plan. What has to change first? Move to a commercial product, Claude for Work, Claude Enterprise, or the Anthropic API, since the published compliance posture (HIPAA-ready config, ISO 27001:2022, ISO/IEC 42001:2023, SOC 2 Type I & II) is explicitly scoped to commercial products, not consumer plans. Named distractor: "SOC 2 coverage applies to any Claude usage, including consumer plans" - directly contradicted by the documented scoping. ### Q6. A workload needs PHI handling, FedRAMP High authorization, AND EU data residency, all for the same single deployment. Can an architect combine all three on one surface? No - FedRAMP High/IL4-5 (AWS GovCloud US, or Claude for Government) and EU data/inference residency (regional Bedrock/Vertex/Foundry) are different, non-overlapping geographic surfaces; a single workload cannot be both US GovCloud-hosted and EU-resident at once. The architect has to split this into two separate deployments, each satisfying its own regime, or clarify which requirement actually applies to this data flow, HIPAA/BAA can layer onto whichever surface is chosen, but the FedRAMP-vs-EU choice is not itself combinable. Named distractor: "picking the highest-tier surface (FedRAMP High) automatically satisfies EU residency too" - FedRAMP High is a US-only surface; it does not satisfy an EU-residency requirement at all. ## FAQ ### Q1. Does using the Anthropic API automatically give me a HIPAA BAA? No. Direct 1P API BAA eligibility is its own path, separate from Claude Enterprise's admin self-activation: the org's administrator signs Anthropic's BAA and then has to contact sales to get it enabled for the API specifically. Neither applies to consumer plans, and neither is pre-enabled. ### Q2. If I use Claude via AWS Bedrock or GCP Vertex, do I need Anthropic's BAA? No - coverage there runs under the cloud provider's own BAA (AWS's or Google Cloud's), not Anthropic's. It's a third, separate path from the Enterprise and direct-API BAA workflows. ### Q3. Can one deployment be both FedRAMP High and EU data-resident? No. FedRAMP High/IL4-5 (AWS GovCloud US, Claude for Government) and EU residency (regional Bedrock/Vertex/Foundry) are different, non-overlapping geographic surfaces - a single workload runs on one or the other, not both at once. ### Q4. Where do I find current compliance artifacts like SOC 2 reports or the DPA? The Anthropic Trust Center (trust.anthropic.com) is the canonical source. SOC 2 Type 2, CSA STAR L2, and the DPA are request-gated there, not on public marketing pages, and terms should be verified per deployment since they change. --- **Source:** https://claudearchitectcertification.com/concepts/regulatory-compliance-for-ai-systems **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.