Selecting an AI Gateway With Native PHI Redaction and BAA Coverage for Digital Health Product Teams

For digital health teams handling PHI, selecting an AI gateway is a compliance architecture decision before it is a performance or routing decision. Teams should start by checking for native PHI redaction before model routing and BAA coverage they can get. Neither makes a deployment HIPAA-compliant by itself, but together they establish the threshold that gateways must meet before latency, provider breadth, and cost become deciding factors.

Why digital health teams face a different gateway decision than other software teams

HIPAA’s technical safeguards apply to every system component that creates, receives, maintains, or transmits PHI. An AI gateway in that request path qualifies. Its role is therefore different from that of a proxy evaluated solely for infrastructure efficiency. The same component that unifies fragmented APIs and enforces fallback logic also becomes part of the architecture responsible for protecting patient information.

That changes the order of the buying decision. Controlling token spend and simplifying model access remain useful, but they cannot establish fitness for a regulated deployment. Teams that choose a gateway for routing and retrofit compliance afterward may discover that its contracts or controls cannot support the intended use. The evaluation must begin with the paths PHI can take, including paths activated only when a provider fails.

The six HIPAA requirements that apply to any gateway carrying PHI

Teams must check that a gateway meets six requirements together. They are a signed BAA with every PHI-touching provider, Zero Data Retention at those providers, encryption in transit and at rest, access controls and audit logging, PHI minimization and de-identification where possible, and a documented breach-notification process. A model-provider BAA addresses only the first requirement. It establishes a contractual relationship, while technical controls to govern each request remain a separate requirement.

Identity deserves particular attention within access controls. HIPAA 164.312(a)(2)(i) requires a unique name or number to track user identity. A shared API credential without a gateway does not show who used it. The evaluation therefore needs to distinguish access to a model from the ability to identify who used it. Audit logging must show who made each request as well as that the request took place.

Gateway redaction reduces PHI sent to models and stored in logs, but redacted traffic must still be treated as PHI under a BAA. Gateway redaction alone does not meet the requirements for Safe Harbor de-identification, which calls for removing all 18 identifier types, including names and all date elements except year. Routing adds another risk to this framework. A fallback that sends PHI to an uncovered provider is a compliance failure, so the evaluation must cover per-key provider allowlists and complete fallback chains.

Which major model providers currently offer BAAs and on what terms

Anthropic offers a BAA for HIPAA-ready Claude API organizations and Claude Enterprise, with specific features and configuration required and not all API features covered. Azure OpenAI has an automatic BAA on EA/MCA/CSP under the Microsoft DPA. Google Cloud Vertex AI offers a BAA at the organization level. These contractual paths each carry distinct terms.

AWS offers BAA coverage under its umbrella for AWS Bedrock and Bedrock AgentCore. The services were added to the AWS HIPAA Eligible Services list effective February 10, 2026. As with the other provider paths, eligibility establishes a starting point for evaluating coverage of the intended use. Teams must check whether the intended service and configuration fall within their coverage.

ChatGPT.com Free, Plus, Pro, and Business and Claude.ai Free, Pro, Max, and Team have no BAA and cannot be used with PHI. BAA-eligible paths include sales-managed products such as ChatGPT for Healthcare, ChatGPT Enterprise with Regulated Workspace, and Claude Enterprise with HIPAA activated. A valid OpenAI API BAA does not extend to a request submitted through ChatGPT.com. The gateway must therefore enforce the approved request path, and teams still need pre-submission redaction and cross-provider audit evidence beyond what provider coverage supplies.

What native PHI redaction at the gateway layer actually means and why placement matters

The gateway is the enforcement point through which every model request should pass. With redaction there, the same policy applies across teams, features, and models without relying on how each application implements it. Free-text prompts make that distinction especially important in digital health. Developers cannot reliably anticipate every piece of PHI a user might submit, and application-level controls cannot cover every surface. A control distributed across those surfaces depends on developer discipline at each one.

“Native” describes the enforcement properties. Redaction must run on every request by policy, be reviewable per request, and resist bypass by an individual caller. A plugin, post-processing step, or caller-selected option is not equivalent to that arrangement. In particular, post-processing cannot reduce the PHI already submitted to a model. The evaluation should focus on where enforcement occurs and who can avoid it.

Clinical text also tests the scope of the control. A production implementation must handle names, dates, geographic subdivisions, MRNs, phone numbers, and email addresses. Its audit evidence must show what was redacted, on which request, under which key, and by which caller. Both are needed to make the policy reviewable.

Redaction must precede routing so that a fallback request has already passed through the same control as the primary request. Coupling redaction with routing protects the minimization step during failover. The provider allowlist remains a separate constraint on where the request may go.

How to evaluate a gateway’s BAA coverage as a selection criterion, not an afterthought

A gateway vendor that processes PHI acts as a business associate of the covered entity or other business associate deploying it. That relationship requires its own BAA, separate from model-provider agreements. The contract must address the gateway’s own processing as well as its forwarding of requests to covered providers. Logs belong in that assessment as well as traffic in transit. Otherwise, the coverage claim leaves a PHI-touching surface unresolved.

Three questions establish the practical value of that coverage. Is a BAA available without an enterprise contract or lengthy procurement process? Does it cover the gateway’s own processing of PHI in transit and in logs? Is Zero Data Retention available at the covered providers to which the gateway routes? For a five-person AI-native healthcare startup, the first question can determine whether the architecture is available at all.

SOC 2 Type II, SSO, and audit logs help support a BAA at audit time, while an agreement without usable access controls or audit evidence leaves risk unresolved. Aptible AI Gateway comes with a BAA as standard, audit logging that uses PHI encryption, and built-in PII/PHI de-identification with re-identification. Aptible has helped digital health startups meet compliance requirements since 2013 and is HITRUST R2 certified and SOC 2 Type 2 audited. It is an option for teams requiring HITRUST coverage or re-identification capability.

Cloudflare’s Trust Hub states that it enters into a BAA with Enterprise-level customers whose use involves PHI. AI Gateway is on its list of HIPAA in-scope services. That makes it relevant to teams already operating in the Cloudflare ecosystem, although access to the BAA is tied to the Enterprise tier. These terms differ from a standard BAA offering and should be evaluated against the team’s procurement capacity.

LiteLLM’s self-hosted OSS path has no vendor BAA because there is no vendor relationship. The operator must maintain the upstream BAA chain and own redaction, audit logging, and access controls. This is a viable architecture for a team with dedicated platform engineering capability. It is also not the default path for a startup without that capacity.

Where the conventional gateway criteria — performance, routing, cost — fit into a compliance-first evaluation

Native PHI redaction and BAA coverage are threshold criteria. A gateway that cannot satisfy both should not enter the performance comparison, regardless of its latency profile or provider count. Once those thresholds are met, conventional criteria distinguish the remaining options. Compliance and operational quality are therefore not competing goals. They occupy different stages of the decision.

A gateway limited to one or two BAA-covered providers constrains model selection, while an up-to-date eligibility matrix across OpenAI API, Anthropic API, Azure OpenAI, AWS Bedrock, and Google Vertex AI preserves more choices for cost, speed, and quality. Those choices must remain subject to per-key or per-team allowlists enforced before routing. General-purpose fallback breadth is not the same as useful fallback coverage. The latter preserves availability without leaving the approved provider set.

Cost visibility then becomes a meaningful differentiator among eligible gateways. Teams need real-time spend tracking by team, project, key, model, and provider. With a managed gateway, the team does not have to deploy, patch, or run the proxy infrastructure, while self-hosting gives it control over those tasks in exchange for vendor-BAA access. Teams must weigh that trade-off against how much platform engineering work they can handle, as well as their preference for managed or self-hosted software.

A practical evaluation sequence for digital health teams selecting a gateway

The practical sequence begins before comparing gateway products. Teams should identify the providers they intend to send PHI to, obtain or verify the relevant provider BAAs, and establish whether Zero Data Retention is available. This preparation gives the evaluation a defined set of destinations with the upstream agreements required alongside a gateway. It also makes the provider terms part of the architecture from the start.

The first gate is BAA accessibility and scope. The team should establish whether the gateway vendor offers an agreement, whether an enterprise contract is required, and whether coverage includes its own processing in transit and in logs. For a self-hosted option, this gate instead exposes the responsibilities retained by the operator. The six-requirement framework remains the baseline in either case, including encryption, identity and audit controls, and a documented breach-notification process.

At the second gate, teams test native PHI redaction in the request path. The team should assess whether policy applies to every request, whether the relevant clinical identifiers are covered, and whether each redaction is reviewable in audit logs. The ordering must also be explicit. Redaction must occur before routing rather than depend on which destination the gateway selects. A feature label alone does not show that these checks are met.

The third gate compares operational fit among qualifying options. Teams should weigh provider coverage, allowlisted failover, real-time spend visibility, and the managed-versus-self-hosted model against their size and how much engineering work they can handle. Failover needs an explicit test. The team should submit a request with a simulated provider failure and confirm that routing stays within its allowlist.

For early-stage teams, a managed gateway with an accessible BAA is the lower-risk default. Self-hosted architectures remain viable when the team can own the controls and upstream agreements from day one. The same evaluation sequence can then be reused as the model mix changes, providers gain BAA eligibility, or new features introduce PHI-touching surfaces.