Skip to lesson

AnthropicClaude Certified Architect – Professional2026-105.4 Ensure compliance with regulations (e.g., GDPR, HIPAA, FedRAMP)

Trace each obligation to control and evidence

Completed by the knowledge check

Learning objective

Map each regulatory obligation to architectural requirements, a named control, an owner, and evidence such as access logs, decision records, prompt and model versions, and compliance exports.

Core idea

An architect turns an obligation into a claim the deployed system can demonstrate. “The provider supports compliance” leaves the system’s prompts, retrieval stores, tools, logs, and outputs unaccounted for. A useful control record says which obligation applies, what behavior satisfies it, who operates that behavior, and which records demonstrate that it worked.

NIST AI RMF 1.0 provides the governance structure: GOVERN 1.1 addresses documented legal and regulatory requirements, GOVERN 1.5 addresses ongoing review, and GOVERN 2.1 addresses clear responsibilities. Use those outcomes to organize an obligation-to-control register. This register is a proposed team artifact, not an Anthropic API object or a substitute for the law. Compliance and legal owners determine applicability and interpretation; engineering owns the implemented requirements they approve.

How it works

Start with the processing activity

Describe the business purpose and follow the data through its full lifecycle. Include input assembly, model processing, tool calls, stored drafts, accepted outputs, operational telemetry, evaluation samples, and deletion. For each flow, record the data category, operator, destination, retention rule, and authorized readers. A diagram of the model call alone cannot identify a debugging service receiving the same personal data.

For GDPR workloads, Article 30’s record of processing activities supplies concrete fields: purposes, categories of data subjects and personal data, recipients, transfers, envisaged erasure periods where possible, and a general description of security measures where possible. Check the Article 30(5) exception with the privacy owner rather than assuming every organization has the same recording duty. Even where the exception applies, the architectural inventory remains useful for implementing the applicable obligations.

Write one traceable row per control

Separate the legal obligation from the engineering decision. The following rows illustrate a team’s proposed register; they do not prescribe universal retention periods or resolve legal applicability:

Obligation or approved requirementArchitectural requirement and named controlOperating ownerVerification record
GDPR Article 5(1)(c), minimizationAn outbound-field allowlist removes unnecessary identifiers before prompt assemblyApplication leadSynthetic leak-test results tied to the released request builder
GDPR Article 5(1)(e), storage limitationA retention schedule and deletion worker cover drafts, traces, and evaluation copiesData platform leadExpiry configuration, deletion-job results, and sampled absence checks
GDPR Article 32, appropriate securityAccess policy limits readers of restricted stores and records privileged accessSecurity operations leadAccess-policy version, access logs, and access-review decisions
Customer’s approved US-only inference requirementWorkspace allowed_inference_geos: ["us"] constrains Claude API routingPlatform leadWorkspace configuration export and response usage.inference_geo checks

The privacy owner approves the interpretation and schedule. The named engineering owner maintains the control, responds to failures, and supplies verification records. “Security” as an unnamed department is insufficient when a failed deletion job needs a decision that day.

Preserve the decision and its deployed version

Explain the chosen service, rejected alternatives, applicable contract, assumptions, and residual risk in a decision record. Associate it with the release that implements it. Record the prompt-template revision, approved model configuration, request-builder revision, and control-policy revision as application metadata; these are proposed record fields, not vendor-generated attestations. See 4.6.1 for the production call-log schema.

This version chain answers a different question from an access log. An access log shows who used a resource and when. A prompt revision identifies the instructions approved for a release. A model configuration identifies the selected inference path. None establishes, alone, that the end-to-end processing purpose was lawful. Join them through an application correlation identifier and a control-register entry, while limiting the personal data stored in that join.

For residency, distinguish the enforcing configuration from the returned observation in your control register; see 2.1.4 for routing mechanics and 5.4.5 for platform selection and transfer requirements.

Use exports within their actual scope

Anthropic’s Compliance API exposes organization activity through GET /v1/compliance/activities. A key needs read:compliance_activities. Claude Console customers can access the Activity Feed with an Admin API key; the broader content endpoints require a Compliance Access Key and serve Claude Enterprise content. Do not describe these endpoints as a universal archive of your application’s Messages API prompts and business decisions.

Ingest applicable activity records into the audit process alongside application records. A downloaded file proves little if nobody can state which organizations, time range, and event types it covers. Store export scope, collection time, and the control it supports. Apply access and retention rules to exports too: an audit copy can create another regulated dataset.

Key distinctions and trade-offs

Design versus operation: A policy document establishes intended behavior. A successful test demonstrates a particular behavior under tested conditions. Production records demonstrate observed operation. Keep all three where the obligation warrants them.

Provider controls versus system controls: Provider documentation supports claims about its service boundary. Your register connects those capabilities to your data paths and remaining responsibilities. Outsourcing inference does not outsource prompt assembly or application retention.

Auditability versus data accumulation: Full prompts can aid investigation while increasing exposure and deletion work. Prefer identifiers and revisions where they answer the audit question; retain restricted content only for an approved purpose and period. See 3.4.5 for telemetry data selection.

Architecture / decision scenario

A financial-services firm must complete a privacy review before launching a complaint-summary assistant in six weeks. A proposal retains every prompt indefinitely so auditors can reproduce any answer. An alternative keeps approved template revisions, model configurations, access events, and control-test results, with content retained only under the privacy-approved schedule.

The architect chooses the second design because indefinite content retention has no approved purpose. The privacy lead owns the Article 5 interpretation; the application lead owns outbound minimization; the data lead owns expiry; security operations owns access review. The launch record joins each obligation to its requirement, control version, owner, and verification result.

A Compliance API activity export supplies relevant organization events, while the application’s release and call records supply prompt and model revisions. A rehearsal exposes traces missing from the deletion worker. The data lead adds that store, verifies deletion, and updates the register before launch. The provider’s activity export cannot close that application defect.

Common exam traps

  • Treating a vendor certificate as proof that every application flow complies.
  • Naming an owner without defining the requirement or verification record.
  • Keeping full content indefinitely under the label of auditability.
  • Confusing an overridable routing default with an enforced restriction.
  • Assuming Compliance API content endpoints archive arbitrary API application traffic.

What to remember

Make each obligation traceable to deployed behavior, a named control, an operating owner, and scoped verification records. Decision records explain the choice; versions identify what ran; access logs and exports demonstrate their own limited subjects. The compliance determination remains with the organization’s compliance and legal owners.

Knowledge check

References