Why Healthcare and Finance Engineering Teams Can't Just Use Cursor or Claude Code

Engineers at healthcare companies, financial services firms, and legal tech organizations are watching their colleagues at other companies describe 40% productivity gains from AI coding tools — and then looking at their own compliance requirements and wondering how to get there without creating a regulatory problem. The answer, for most of the popular AI coding tools in 2026, is: you cannot, under the default configuration, without some combination of significant risk or significant setup burden.

Cursor has no HIPAA BAA. No SOC 2. No FedRAMP. It is built for individual developers and does not have enterprise compliance certifications that regulated industries require. Claude Code's BAA situation is better — Anthropic does offer a BAA — but the BAA only applies to API usage with Zero Data Retention configuration. Teams using Claude Code on Pro or Team plans, or using any of the tool's web-facing features, are operating outside the BAA regardless of what plan they are on. GitHub Copilot has SOC 2 but no HIPAA BAA for most configurations.

The result is that engineering teams in regulated industries are facing a genuine tooling gap: the tools that give teams the most codebase intelligence are either not compliant or compliant only under configurations so specific and burdensome that most teams cannot maintain them operationally.

The actual compliance map for AI coding tools in 2026

The compliance landscape for AI coding tools is fragmented and frequently misunderstood. Teams assume that "enterprise plan" means compliance. It frequently does not — it means enhanced security controls and data processing agreements, which are not the same as the specific certifications and BAAs that regulated industries require.

AI coding tool compliance status — 2026:

  Tool              | HIPAA BAA | SOC 2     | FedRAMP   | Data residency
  ------------------+-----------+-----------+-----------+----------------
  Cursor            | No        | No        | No        | No
  Claude Code (Pro) | No        | Partial   | No        | No
  Claude Code (API  | Yes (ZDR  | Partial   | No        | No
    + ZDR config)   | only)     |           |           |
  GitHub Copilot    | No        | Yes       | No        | Enterprise only
  Claude Cowork     | No*       | Excluded  | No        | No
                    | (*BAA     | from Audit|           |
                    | doesn't   | Logs      |           |
                    | cover it) |           |           |

  * Cowork activity is explicitly excluded from Audit Logs, Compliance API,
    and Data Exports on all Anthropic plan tiers including Enterprise

The Claude Cowork situation deserves specific attention. As of mid-2026, Cowork activity is explicitly excluded from Anthropic's Audit Logs, Compliance API, and Data Exports on every plan tier, including Enterprise. This means that for SOC 2 audits requiring evidence of what AI accessed and what it returned, Cowork generates no auditable record — not because of a gap that can be configured away, but as an explicit architectural choice by Anthropic. Teams using Cowork in environments where SOC 2 audit coverage is required are operating a tool that their auditors cannot see.

What HIPAA compliance for Claude Code actually requires

The path to a HIPAA-compliant Claude Code deployment exists, but it is narrow and operationally demanding. It requires specific setup that most teams adopting Claude Code have not done, and the BAA does not cover several of Claude Code's own features even when the correct setup is in place.

What "Claude Code with HIPAA BAA" actually requires:

  Required setup:
    1. Anthropic API account (not Pro/Team plan)
    2. HIPAA BAA signed with Anthropic
    3. Zero Data Retention (ZDR) configuration active on the API key
    4. All Claude Code sessions routed through that specific API key
    5. No use of Claude Code Desktop remote mode
    6. No use of Claude Code web interface
    7. No use of Code Review or Code Security features

  What is NOT covered even with BAA + ZDR:
    -> Claude Code Desktop (remote mode)
    -> Claude.ai web interface
    -> Claude Code web
    -> Code Review feature
    -> Code Security feature
    -> Claude Cowork (any mode)

  Teams using any of the uncovered surfaces with PHI-adjacent code:
  HIPAA violation regardless of BAA status

Teams that have signed a BAA with Anthropic and have not configured ZDR on their specific API key are not covered by the BAA. Teams that have correctly configured ZDR but are using Claude Code's Desktop remote mode, web interface, Code Review, or Code Security features are introducing uncovered surfaces. The BAA is not a blanket coverage of everything Claude does — it is a specific agreement covering specific configurations. The surface area of what it does not cover is substantial.

This is not a criticism of Anthropic. It is an accurate description of where compliance coverage exists and does not exist. Healthcare organizations and financial services firms that are making tooling decisions based on "Claude has a BAA" without understanding which surfaces and configurations are actually covered are making assumptions that their compliance officers would not approve if they saw the specifics.

The real problem: compliance requires centralization, these tools are per-developer

The deeper issue is architectural. Compliance in regulated industries requires centralized controls: audit trails, access governance, data handling policies enforced at the infrastructure level rather than trusted at the individual user level. The popular AI coding tools are designed as per-developer tools: individually installed, individually configured, individually authenticated. Per-developer tooling and centralized compliance governance are structurally at odds.

A team of 15 developers each running Claude Code with their own API key, their own ZDR configuration (if they set it up), and their own usage pattern creates 15 independent data flows that a compliance team cannot centrally audit. Some developers may have configured ZDR correctly. Some may not. Some may be using the web interface on days when they find the CLI inconvenient. The compliance team has no visibility into any of this, because per-developer tooling does not generate centralized records by design.

Security engineers who need to govern AI coding access across regulated environments are not looking for per-developer configuration guides. They are looking for a single governed layer where access controls, audit trails, and data handling policies can be enforced consistently — regardless of what any individual developer has or has not configured.

What regulated engineering teams actually need

The productivity gap that regulated industry engineering teams are trying to close is the same one that drives Cursor and Claude Code adoption everywhere else: AI that understands the codebase, answers questions across services, and accelerates development work. The compliance requirement does not eliminate this need. It constrains how it can be satisfied.

What engineering teams in regulated industries actually need from AI:

  They need:
    -> AI that can answer questions about their codebase
    -> AI context that spans multiple services and repos
    -> Non-technical team members (compliance, legal, ops) able to query the system
    -> Audit trails of what AI accessed and what it returned
    -> No raw code transmitting to third-party servers per query

  They do not need:
    -> A local CLI they have to configure per-developer
    -> ZDR key management distributed across the engineering team
    -> Per-developer API keys with no centralized billing or audit
    -> A tool whose BAA doesn't cover half its own features

The right architecture for regulated industries is a managed, centralized codebase intelligence layer: one connection to the repository, indexed server-side under a single governed configuration, accessible to the team through a centrally audited interface. Developers query the index rather than sending raw code to individual AI provider APIs. Non-technical roles — compliance officers, legal teams, operations — can query the system through an interface appropriate to them. Every query generates an auditable record at the infrastructure level, not at the individual developer's machine.

The SOC 2 audit question every engineering team will eventually face

SOC 2 audits are increasingly asking about AI tools. The questions are specific: what AI systems have access to the codebase? What data do they transmit? Where does that data go? What audit logs exist of AI activity? Teams using per-developer Cursor or Claude Code setups with no centralized logging face these questions without answers. "Each developer manages their own tool" is not a SOC 2 answer. It is a gap finding.

The organizations that are ahead of this are building the audit infrastructure now — not because an auditor has already asked, but because the question is coming. A managed codebase intelligence layer with centralized access logs, governed data handling, and a clear vendor security posture is the auditable answer. Per-developer AI tool setups with distributed API keys and no central logging are not.

Final take

Regulated industry engineering teams are not choosing between AI productivity and compliance. They are looking for an architecture that provides both. The popular AI coding tools, in their default configurations, do not provide both. The path to both is a managed codebase intelligence layer: centrally governed, compliant by design, accessible to the whole team without requiring each individual to correctly configure their own compliance posture.

The compliance gap in AI coding tools for regulated industries is not a gap that careful individual setup can close at scale. It requires a different architecture — one where the codebase intelligence is managed centrally, accessed through a governed interface, and auditable in ways that per-developer tool configurations cannot be. That is what managed codebase access exists to provide.