Anthropic ships the compliance surface. Your repo still needs the seven files that wire it up.

Anthropic covers transit, storage, the model platform, ASL-3 deployment posture, the Compliance API as a feed of events on their side, SOC 2 Type II, and a BAA on the Claude Enterprise plan and the first-party API for HIPAA-ready services. Your team is responsible for everything that happens before the request reaches Anthropic and after the response leaves it. That means PHI/PII redaction in the prompt, correlation IDs that join Anthropic's events to your traces, audit log retention beyond Anthropic's defaults, gating model and region changes against your signed BAA scope, and a runbook your on-call engineer can read at 02:00. The seven files this guide names are the customer-side wiring for those responsibilities.

compliance/baa_receipt.md is the inventory of endpoints, regions, and model IDs your signed BAA covers, plus the legal reviewer who signed it. compliance/redactor.py runs on every prompt before it hits Claude. compliance/compliance_api_sink.py polls Anthropic's Compliance API on a 5-minute cron and forwards events to your SIEM webhook with a join key. eval/cases_compliance.yaml has rows that fail the build on a single PHI leak. .github/workflows/compliance-gate.yml is the required CI check with three jobs (BAA scope, redactor coverage, PHI eval). runbook/compliance.md is the on-call playbook. rubric.yaml gains a compliance section so model qualification and regression tail mining read the same thresholds. All seven are version-controlled in the client's repo, none are PIAS-hosted.

Because the signed PDF lives in legal's drive, and engineering writes the code that picks endpoints, regions, and model IDs. Without a checked-in receipt that the CI gate can read, a developer flipping a region for latency is a one-line PR that ships in 30 minutes, and the audit finding shows up six months later. baa_receipt.md gives the gate a machine-readable list of (provider, region, model) tuples that are in scope, and a not_covered list of tuples that explicitly are not. The PR cannot merge if any new tuple is missing from covered, and the file's diff is the audit trail of every scope change.

Anthropic's filters operate on the model side. They protect against the model emitting harmful content; they do not promise to strip PHI out of the prompt you sent. If your prompt contains an SSN, an MRN, a member ID, or a date of birth, those values are in the request payload, in the trace, and in any retained audit data until you remove them. The redactor lives in your code so you control which surface forms get scrubbed and which do not, the eval suite asserts that every Claude call site in the repo invokes it, and the CI gate fails if a new call site bypasses it.

Every Claude call sets request_metadata.correlation_id at the SDK call site. Anthropic echoes that ID back on the matching Compliance API event. The sink polls the Compliance API on a 5-minute cron, normalizes each event into your SIEM's schema, sets the correlation_id field to the value Anthropic echoed, and POSTs to your SIEM webhook. Your SIEM then has one ID across both systems, so an end-to-end query (prompt to response to compliance event) is one filter, not a join across two dashboards. The sink also escrows a copy to your audit bucket so retention outlasts Anthropic's defaults.

Three classes of merges. (1) baa-scope rejects any PR that introduces a (provider, region, model) tuple not present in compliance/baa_receipt.md under covered, or any tuple present under not_covered. (2) redactor-coverage AST-walks the repo and rejects any PR that adds a Claude SDK call site reachable without compliance.redactor.redact in its call graph. (3) phi-leak-eval runs eval/cases_compliance.yaml against the proposed code with phi_leak_max=0, so a single PHI surface form surviving the redactor fails the build. On failure, an issue is opened against the engagement owner and your compliance Slack channel is pinged automatically.

Three differences that show up in the SOW. The engineer you meet in the scoping call is the same engineer writing the PRs, named in the SOW, not a partner-plus-grads rotation. The output is seven files on main in your repo, not a 60-page assessment with recommendations to staff a separate implementation. First PR within seven days or billing pauses, week 2 prototype gate, week 6 production gate, with refund and exit clauses on the first two. A typical Big 4 compliance engagement starts with an 8-week kickoff and ends with a slide deck. Ours starts with a PR.

The shape of the seven files does not change. baa_receipt.md gains rows for the AWS or Google BAA scopes you have signed for those providers; the gate reads the same file. The Compliance API sink is replaced by the equivalent CloudTrail or Cloud Audit Logs reader for the model invocation events, with the same correlation_id join key. The redactor and the eval suite are unchanged. The model_provider field in your config tells the gate which scope file and which sink module to enforce, all in the same rubric.yaml. Three of the five named clients we have shipped this on are on Bedrock or Vertex, not direct Anthropic.

Two things, in this order. First, the model qualification PR lists the new model_id in compliance/baa_receipt.md under covered, and the gate confirms the BAA actually covers it (this is a manual step with legal, not an automated assumption). Second, the regression eval, including eval/cases_compliance.yaml, runs the new model against every PHI surface form your repo has ever shipped a row for. If any row regresses, the qualification PR cannot merge. The compliance bar grows as the rubric grows; a new model that passes the original eval but regresses on a year of accumulated PHI surface forms cannot make it to production. This is how compliance becomes a moat instead of a one-time approval.

You do, from clause one of the MSA, in writing, before the engineer starts week 1. No platform license, no proprietary agent framework, no PIAS-hosted runtime, no data residency on PIAS infrastructure. The seven files are version-controlled in your GitHub from the first PR. The runbook is read by your on-call engineers, not ours. The Compliance API key is in your secret store, not ours. The audit bucket is on your cloud, on your encryption keys. At the end of week 6 we are gone and the system runs without us in the room. The engineer who built it is available for paid two-hour consults at a capped rate for 12 months, no retainer.