Governance, Safety & Risk Management · Lesson 4 of 5

4.4 - Compliance in the Architecture: GDPR, HIPAA and FedRAMP

Translate GDPR, HIPAA and FedRAMP concerns into architecture decisions: data-flow mapping, minimisation, retention, residency, access control, audit evidence and vendor agreements. Architecture only, not legal advice.

Not legal advice

This lesson covers architecture-level implications only. Which obligations apply to your organization, and whether a particular design satisfies them, are legal determinations for your counsel and compliance officers. The lesson makes no statement about any certification or compliance status of Anthropic or any other vendor beyond what the cited Anthropic pages themselves say. Vendor terms and product eligibility change, so verify against the current documentation and your signed contract.

Compliance is a property of the whole system, its contracts and its operations, never of a model API on its own. Using a vendor that offers a compliance arrangement does not make your application compliant; it makes certain arrangements available to you, inside boundaries you must respect. The architect's job has three parts: know exactly where regulated data flows, choose controls that make the obligations satisfiable and provable, and make sure the evidence exists. Lawyers decide what the obligations are; you decide whether the system can meet them.

Start with the data-flow map, then minimise at the boundary

Personal or regulated data reaches far more places in an LLM system than the prompt: uploaded files, retrieved documents, tool results, conversation memory, logs and traces, evaluation datasets, vector indexes and embeddings, caches, human-review tools and backups. For each store or hop, record the purpose, which processors and sub-processors touch it, where it sits, how long it lives, who can read it, and how you would delete it. Then classify the data before deciding whether it should go to the model at all.

Concern	Architectural lever
Minimisation	Redact or pseudonymise before the model call; retrieve only the fields the task needs; do the stripping in code at a gateway or hook so it does not depend on the prompt
Retention and deletion	A time-to-live per store; the ability to find and delete by data subject across logs, indexes and review tools; vendor retention settings
Access control	Least privilege per agent and tool; per-user scoping of retrieval so the agent cannot read what the user may not; separate workspaces or organizations for regulated workloads
Residency and transfers	Know where inference runs and where data rests; a contractual transfer mechanism where data leaves a jurisdiction
Audit and evidence	Application logs of who, what, which model and which reviewer decision; retention that does not contradict minimisation
Vendor agreements	Signed agreements that cover every processor and every feature actually used

GDPR: what shapes the design

The European Commission's summary of the principles gives the design vocabulary: lawfulness, fairness and transparency; purpose limitation; data minimisation (adequate, relevant and limited to what is necessary); accuracy; storage limitation (keep data no longer than needed); integrity and confidentiality, with data protection by design and by default; and accountability, meaning you must be able to demonstrate compliance. Architectural readings: inaccurate statements about a person that a model generates are an accuracy problem, so ground and make them correctable; do not repurpose prompts or logs into evaluation sets for a new purpose without asking counsel; and give every log, trace and index a retention rule.

Roles matter. The EDPB describes the controller as determining purposes and means, and the processor as acting on the controller's instructions, with the relationship governed by a contract; the controller remains liable for the compliance of the processor it chooses. Which party is which is a legal characterisation, but the design consequence is plain: choose and document the vendor arrangement deliberately. Transfers outside the EEA need a recognised mechanism (the Commission lists adequacy decisions, standard contractual clauses, binding corporate rules and others), so you must know where processing and storage occur. The Commission's guidance on automated decision-making restricts decisions based solely on automated processing that have legal or similarly significant effects, with safeguards including human review and the ability to contest; that is the design driver for Lesson 4.3.

On Anthropic's platform, residency has two independent controls per the documentation reviewed for this lesson: inference geo (the per-request inference_geo parameter, plus workspace defaults and allow-lists) and workspace geo (where data is stored at rest, fixed when the workspace is created). At the time of writing the documented values were global and us for inference, and us for workspace geo. On Amazon Bedrock and Google Cloud the inference region is determined by the endpoint or inference profile, so the parameter does not apply. A requirement for processing in a specific region therefore cannot be assumed satisfiable by a parameter: read the current documentation, and treat platform choice as a design lever.

HIPAA: business associates and the BAA chain

Under 45 CFR 160.103 a business associate is a person who, on behalf of a covered entity, creates, receives, maintains or transmits protected health information (PHI) for regulated functions, and a subcontractor doing so for a business associate is one too. 45 CFR 164.504(e) says the business associate contract must, among other things, establish permitted uses and disclosures, require appropriate safeguards (including the Security Rule for electronic PHI), bind subcontractors to the same restrictions, require reporting of unauthorised uses or disclosures, and provide for return or destruction of PHI at termination. Architecturally, every component that touches PHI is a candidate for the chain: the model provider, the vector database host, logging and observability SaaS, the review tool, the cloud.

What Anthropic documents for its API (read on its data-retention page): HIPAA readiness requires a signed BAA, a HIPAA-enabled organization, and use of eligible features only. The feature-eligibility table lists which features qualify, and a HIPAA-enabled organization that sends a request using a non-eligible feature gets a 400 error (the page describes exceptions for some client-side tools that are accepted but remain outside HIPAA readiness). The signed BAA is stated to be the source of truth. That page lists as not covered: consumer plans, use through the Console, partner-operated platforms (see those platforms' own documentation), third-party integrations and, generally, beta features unless listed. Coverage of other Anthropic products, such as Enterprise plans, is described separately, so read the page for the product you actually use. PHI must not appear in JSON schema definitions used for structured outputs or strict tools (property names, enum and const values, patterns), because compiled schemas are cached separately from message content. HIPAA readiness is enforced per organization, so regulated and general-purpose workloads belong in separate organizations. HIPAA readiness and ZDR are distinct arrangements; and some models are documented as requiring 30-day retention and not being available under ZDR, a conflict to catch at design time.

Common exam distractor

Four tempting shortcuts: 'the vendor is compliant, so we are' (obligations remain with you; the agreement covers named features, and your own logs and indexes are in scope); 'ZDR equals HIPAA' (different arrangements with different purposes); 'one region setting solves residency' (inference location and storage location are separate controls and requirements can target either); and 'the vendor is authorised, so any offering is' (status attaches to a specific offering and boundary).

FedRAMP: an assurance boundary, not a model property

FedRAMP.gov describes a government-wide programme for the security assessment of cloud services, and its marketplace as a searchable database of FedRAMP certified cloud services, authorizing agencies and recognised assessors. Its current material also describes certification classes (A to D) alongside the familiar Low, Moderate and High impact levels, and states that classes indicate the level of assurance, not the level of security, and that agencies should categorise their own information system first and then review the certification package. Check FedRAMP.gov for the current state of that transition.

Three design consequences. Authorization attaches to a specific cloud service offering within a defined boundary, so your system serving a federal customer is only as strong as every component in its data path: the model offering, the hosting for your orchestration, the vector store, the logging service. The same model reached through different channels (first-party API versus a cloud provider's platform) can be a different offering with its own status. So verify the specific offering and level on the FedRAMP Marketplace and in the vendor's own documentation; this lesson makes no claim about any Claude offering. Finally, keep federal data on authorised components and draw the boundary explicitly.

Retention, audit and evidence

Auditors want evidence. Anthropic's Compliance API Activity Feed records authentication, chat, file, project, administrative and platform activity for your organization, makes it queryable within about a minute and retains it for six years, but recording begins only when the Compliance API is enabled and is not backfilled. It is organization-level product activity, not a substitute for your own application logs of prompts, model identifier, tool calls and reviewer decisions. Reconcile audit retention with minimisation by logging references and metadata rather than raw personal data, redacting payloads, and applying retention by category. Also describe vendor retention accurately: the documentation states that even under ZDR or HIPAA arrangements Anthropic may retain data where required by law or where content is flagged by its trust-and-safety systems (up to two years for flagged content), so 'zero retention' does not mean nothing is ever retained.

Key concept

Design so obligations are satisfiable and provable: map the data flow, minimise before the model, scope every vendor and every feature to a signed agreement, control location and retention deliberately, and keep evidence. Match the control to the requirement actually stated (inference versus storage, PHI versus other data, a specific offering versus a vendor in general).

Exam traps

Reasoning that because the model vendor offers a BAA or a zero-data-retention arrangement, the application built on it is compliant.

The arrangement covers named features under stated conditions. The customer still owns its own data flows: logs, vector stores, review tools and third-party connectors need their own controls and agreements, and using an ineligible feature can void the assumption.
Treating zero data retention and HIPAA readiness as the same arrangement, or assuming PHI workloads require both.

Anthropic documents them as distinct: ZDR concerns not storing prompts and responses at rest, while HIPAA readiness adds a signed BAA, an enabled organization, eligible-feature enforcement and a broader set of safeguards. The docs say a PHI workload uses HIPAA readiness rather than also needing ZDR.
Setting a per-request inference location to satisfy a requirement that data be stored in a particular region, or changing storage location to satisfy an inference-location requirement.

Inference geo and workspace geo are separate controls. A residency requirement can target either, so identify which one the requirement actually names before choosing the lever.
Assuming a FedRAMP authorization or impact level held by a vendor applies to every product, channel and configuration it sells, and equates to a given level of security.

Authorization attaches to a specific offering within a defined boundary, and FedRAMP states that certification classes indicate the level of assurance rather than the level of security. Verify the exact offering on the FedRAMP Marketplace.

Practice question

A US health-technology company is building a claims-support assistant on the Claude API that will process PHI. The design includes a nightly Batch API summarisation job, structured outputs whose schema enum values list patient-specific diagnosis codes, a third-party vector database hosting retrieved patient documents, and a log aggregator that stores prompts. Which plan best fits the documented HIPAA arrangement?

A Request zero data retention only and skip the BAA because nothing is stored after the response, keeping the Batch API job, the structured-output schemas, the vector database and the log aggregator exactly as designed.
ZDR is a different arrangement from HIPAA readiness and does not replace a BAA. It also does not cover the customer's own vector database and logs, and the Batch API is not eligible under ZDR.
B Set inference_geo to us on every request, treating it as the mechanism that makes an API workload HIPAA compliant, and keep the rest of the design as is because processing then stays inside the United States.
inference_geo is a residency control for where inference runs. It is not a HIPAA compliance mechanism and does not substitute for a BAA, eligible-feature enforcement or safeguards on the rest of the system.
C Sign a BAA and enable HIPAA readiness in a dedicated organization, replace ineligible features (such as the Batch API job), keep patient values out of schema definitions, and add BAAs for the vector database and log providers. Correct
It covers the vendor arrangement, eligible-feature discipline, the schema-caching restriction, the separate-organization advice, and the rest of the business-associate chain for downstream components that hold PHI.
D Sign a BAA with the model provider only, on the basis that summaries stored downstream stop being PHI once Claude has processed them, and treat the vector database and logging providers as out of scope for HIPAA.
Summaries that contain identifiable health information are still PHI, and any subcontractor that creates, receives, maintains or transmits it on behalf of the business associate falls under the business associate definition.

Build exercise: Produce a compliance-oriented architecture pack: data-flow map, residency decision record, feature audit and a minimisation gateway

Advanced · 75 minutes

You'll practice:

Map data flows and identify every processor, store, retention period and deletion path
Distinguish inference location from storage location and record a residency decision with open legal questions
Audit features and integrations against a vendor's documented eligibility for a compliance arrangement
Implement and test a deterministic minimisation step and state its limits

Take a patient-support assistant that serves EU and US users (chat UI, orchestration service, Claude API, vector database of clinic documents, log aggregator, human-review tool). Draw the data-flow map and add a table with columns: store or hop, data categories, processor, region, retention, who can access, deletion path.

You cannot argue that an obligation is met for a flow you have not drawn. The table also exposes forgotten stores (traces, evaluation sets, backups) where most real gaps live.

You should see: A diagram and a table with at least eight rows, including logs, the vector index and the review tool, with no empty deletion-path cells.
Hints
1. ```
If a user asks to have their data deleted tomorrow, which stores would you need to search, and could you actually do it?
```
2. ```
List every place a chat message or a retrieved document is written, even temporarily, then fill the remaining columns for each place.
```
3. ```
Rows to include: prompt and response at the model API; conversation history in the app database; embeddings and source chunks in the vector index; application logs and traces; the evaluation dataset; the human-review tool; backups; analytics. For each, write a TTL and a delete-by-subject procedure, or mark it as a gap to fix.
```
Write a residency decision record. State the requirement in the words the stakeholder used, decide whether it targets inference location, storage at rest, or both, list the controls the vendor documents for each, and list open questions for counsel. Read the vendor's current data-residency page first and quote the values it currently documents.

The most common error is applying the wrong lever. A decision record forces you to name which one the requirement targets and to record what is not yet known instead of assuming.

You should see: A one-page record with a requirement statement, an inference-versus-storage classification, the documented options with the date you read them, a decision and at least three open legal questions.
Hints
1. ```
Does the requirement say where computation may happen, where data may rest, or both?
```
2. ```
Separate the two controls in two columns. For the platform you use, note what the documentation says can be set per request, per workspace, or by choosing the endpoint on a cloud provider.
```
3. ```
Example open questions: Is regional processing legally required or a customer preference? Which transfer mechanism, if any, covers processing outside the region? Does pseudonymised data still count as personal data for this purpose? Is a data protection impact assessment required for this use?
```
Audit the features and integrations you plan to use (Messages API, batch processing, structured outputs, tools, MCP connectors, agent frameworks, third-party SaaS) against the vendor's feature-eligibility table for the arrangement you need. Produce a table of feature, eligible yes/no/qualified, action.

A compliance arrangement covers listed features under stated conditions. One ineligible feature in the path can quietly move regulated data outside the agreement, or cause hard failures.

You should see: A feature table with a decision for each row, at least one feature flagged for replacement or removal, and a list of third-party integrations that need their own agreements.
Hints
1. ```
Which features store state (jobs, files, sessions), and would that state hold regulated data?
```
2. ```
Go row by row through the vendor's table; for anything marked no or qualified, decide whether to remove it, replace it or accept a documented exception with counsel's sign-off.
```
3. ```
Also check schema hygiene: for structured outputs or strict tools, scan schema property names, enum values, const values and patterns for anything patient-specific, since the vendor documents that schemas are cached separately from message content. Add a CI test that fails if a schema contains an identifier-like string.
```

Implement a minimisation gateway that pseudonymises obvious identifiers (emails, phone numbers) before text is sent to the model, keeps the mapping inside your boundary, and has tests. Write down three kinds of identifier your rules will miss.

Minimisation in code is deterministic and does not depend on the prompt. Documenting what the rules miss stops the gateway being mistaken for a complete anonymisation solution.

You should see: Tests showing that emails and phone numbers never appear in the outbound text, that the vault can restore them in your own systems, and a short limitations list (names, free-text addresses, indirect identifiers).

Hints

What is the failure mode if your patterns miss an identifier: silent leakage or a visible error?

Use one regular expression per identifier type, replace each match with a random token, and store token to original in a vault kept inside your boundary. Test both directions.

import re, uuid

EMAIL = re.compile(r'[\w.+-]+@[\w-]+\.[\w.]+')
PHONE = re.compile(r'\+?\d[\d\s().-]{7,}\d')

def pseudonymise(text, vault):
    def swap(kind, m):
        token = '<' + kind + '_' + uuid.uuid4().hex[:8] + '>'
        vault[token] = m.group(0)
        return token
    text = EMAIL.sub(lambda m: swap('EMAIL', m), text)
    return PHONE.sub(lambda m: swap('PHONE', m), text)

vault = {}
safe = pseudonymise('Call +1 415 555 0100 or mail jo@example.com', vault)
assert 'jo@example.com' not in safe and '555 0100' not in safe and len(vault) == 2
# Limits: names, street addresses, record numbers and indirect identifiers are NOT caught.

Write the retention and evidence plan: an application audit-log schema that records metadata and references rather than raw personal data, a retention period per store, a delete-by-subject runbook, and a paragraph describing what the vendor may retain regardless of arrangement, phrased for your privacy notice draft.

Audit needs and minimisation pull in opposite directions. Writing the schema and TTLs forces the reconciliation, and describing vendor retention accurately avoids over-promising to users.

You should see: A log schema with fields such as timestamp, request ID, model identifier, actor, tool calls and reviewer decision but no raw prompt text by default, a TTL table and a runbook with named owners.
Hints
1. ```
Which questions must an auditor be able to answer, and which of them genuinely require raw content?
```
2. ```
Log the who, what, when and which-version, store payloads separately under a shorter TTL with stricter access, and record a pointer between them so deletion can cascade.
```
3. ```
Schema sketch: {ts, request_id, subject_ref (pseudonymous), model_id, prompt_template_version, tools_called[], reviewer_id, reviewer_decision, payload_ref}. Payload store TTL shorter than metadata TTL. Privacy-notice sentence to review with counsel: 'Our AI provider may retain limited data where required by law or where content is flagged by its safety systems.'
```

Sources

API and data retention: ZDR, HIPAA readiness, feature eligibility (Claude docs) - Anthropic
Data residency: inference geo and workspace geo (Claude docs) - Anthropic
Query the Activity Feed (Compliance API, Claude docs) - Anthropic
Business Associate Agreements (BAA) for Commercial Customers (Anthropic Privacy Center) - Anthropic
Principles of personal data processing under the GDPR (European Commission) - European Commission
Rules for international data transfers (European Commission) - European Commission
Data controller or data processor (European Data Protection Board) - European Data Protection Board
45 CFR 164.504 - Uses and disclosures: organizational requirements (text as published by Cornell LII) - Cornell Legal Information Institute
45 CFR 160.103 - Definitions (text as published by Cornell LII) - Cornell Legal Information Institute
FedRAMP certification classes (FedRAMP.gov) - FedRAMP
FedRAMP.gov home and marketplace description - FedRAMP