Running Claude in Regulated Environments

In a regulated environment, “can we use Claude?” is really three questions: where does the data go, who retains it, and can we prove it. Claude is usable under HIPAA, under strict data-residency rules, and under zero-retention requirements — but only if you pick the right access path and wire the controls around it. The capability is there; the work is in the configuration and the proof.

This post maps the compliant ways to run Claude, what each one gives you, and how a gateway lets you enforce residency, retention, and PII controls consistently across them. The Anthropic specifics below are from Anthropic’s privacy documentation on commercial data handling and HIPAA, as of October 2026; always re-confirm current terms.

Three compliant ways to run Claude

The access path determines your data-handling posture, so it is the first decision, not an afterthought.

The Anthropic API, hardened. You can run directly against Anthropic with zero data retention and/or under a HIPAA BAA (more on both below). This is the most direct path and keeps you on Anthropic’s newest models immediately.

Claude on AWS Bedrock. Here Claude runs inside AWS, so the data-handling, region, and compliance posture are your AWS environment’s — the same envelope (and BAA) you already use for other regulated workloads on AWS.

Claude on Google Vertex. The same idea on Google Cloud: Claude runs inside your Vertex/GCP environment and region, under your existing GCP compliance arrangements.

Regulated teams often choose Bedrock or Vertex precisely because the data never leaves a cloud account and region they already have approved and under contract — the compliance question becomes “is our AWS/GCP usage compliant,” which they’ve usually already answered.

Want Claude routed to the right compliant endpoint, with data in your region?

Book a demo

Retention and HIPAA, precisely

Two Anthropic mechanisms matter most in regulated settings, and they are often confused.

Zero Data Retention. Under an approved ZDR arrangement, Anthropic does not store your inputs or outputs except where needed to comply with law or to combat misuse — it still retains User Safety classifier results to enforce its Usage Policy. ZDR is available to approved Claude API and Enterprise customers, reviewed per organization. Platform users can check their status under Settings, Privacy Controls, Data retention period.

HIPAA BAA. A Business Associate Agreement is available for Anthropic’s HIPAA-ready services — the Claude API with HIPAA configuration enabled, and HIPAA-ready Enterprise plans — and, importantly, a BAA does not require ZDR. For Claude Code accessed via a Console API key, the BAA applies only when that organization has ZDR enabled. The exact features each BAA covers and the configuration each needs are listed in Anthropic’s BAA documentation.

The practical point: ZDR and a BAA are different controls for different requirements. If your rule is “the vendor must not retain our data,” that’s ZDR. If your rule is “we need a signed BAA to process PHI,” that’s the HIPAA path, which can run with or without ZDR. Some regulated teams want both; many need only one.

Keeping data in your environment and region

Choosing a compliant endpoint is necessary but not sufficient — you also have to control where request data is stored and prove what happened. That is the layer a gateway adds, regardless of which Claude path you pick.

Routed through the TrueFoundry AI Gateway, Claude traffic can be configured so request and response data is stored in your own blob storage and region, the control plane never sits in the live request path (in hybrid and self-hosted deployments), and every call is logged for audit — the proof regulators ask for. You pick the Bedrock region (and per-model overrides), authenticate with an assumed IAM role or key rather than long-lived root credentials, and address Claude through a logical name so the underlying endpoint can change without touching applications.

Region and least-privilege authentication for Claude on Bedrock. Source: TrueFoundry docs.

And because the gateway deploys as SaaS, in your VPC, on-prem, or air-gapped, you can put the whole data plane inside your own network when residency or sovereignty rules demand it — so LLM traffic and request data never leave your environment at all.

PII controls belong at the boundary

Compliance is not only about retention and region; it is also about what you send in the first place. A support prompt that carries a patient name or an account number into any provider is a problem no BAA fully neutralizes. The gateway is the place to catch it: a PII guardrail can redact sensitive fields on the way in (and in tool results) before the request reaches Claude, Bedrock, or Vertex, so the raw identifier never leaves your boundary. Pair that with the retention and region choices above and you have defense in depth rather than a single contractual control.

Where teams get this wrong

They conflate ZDR and a BAA. They’re different controls. ZDR is about Anthropic not storing data; a BAA is the HIPAA agreement to process PHI, and it doesn’t require ZDR. Pick for your actual rule.

They assume the API path is the only one. For residency or an existing cloud BAA, Bedrock or Vertex keeps Claude inside a cloud account and region you’ve already cleared.

They forget where request logs live. A compliant model endpoint doesn’t help if request data lands in a third party’s storage. Keep logs in your own bucket and region.

They rely on contracts instead of controls. A BAA doesn’t stop a prompt from carrying PII. Redact at the gateway so sensitive data never leaves your boundary.

‍