Designing Healthcare AI Workflows to Minimize BAA Exposure

The problem: BAA review slows HealthCare AI

A recurring implementation pattern is straightforward: the engineering team builds a promising AI workflow, then procurement and privacy review slow the rollout while the organization evaluates the vendor's HIPAA posture, data retention, and contracting path.

Here is the current contracting landscape:

Consumer tiers are not HIPAA-ready and should be treated as out of scope for PHI.
OpenAI and Anthropic now offer BAAs for certain commercial configurations, subject to case-by-case review and HIPAA-ready service scope.
Azure OpenAI may be a simpler contracting path for organizations already operating inside Microsoft enterprise terms and healthcare compliance programs.
The real bottleneck is still diligence—data flows, retention, logging, and scope need to be nailed down before PHI touches an external model.

The commercial point is still real: if your architecture can safely reduce or eliminate PHI disclosure to third parties, you shorten the review surface. But that is very different from assuming the BAA question disappears by default.

The insight: what if PHI never leaves?

HIPAA's definition of a Business Associate requires that the vendor "creates, receives, maintains, or transmits" Protected Health Information on behalf of a covered entity.

The key word is "transmits."

If the downstream service never receives PHI because the transmitted payload has been de-identified before disclosure, the legal analysis changes materially. But tokenization or redaction is not enough on its own. You still need to test whether the payload remains identifiable in context and whether any retained mapping makes the data effectively re-identifiable.

The legal insight: The stronger HIPAA argument is usually not the conduit exception. It is whether the downstream disclosure is still PHI after redaction, de-identification review, retention controls, and feature scoping.

The implementation: four steps

Note: This example shows GLACIS sidecar mode deployment for Kubernetes-based PHI redaction. GLACIS also supports proxy mode for simpler architectures with a single chokepoint to external AI services.

Step 1: intercept

Deploy a sidecar proxy in your Kubernetes cluster that intercepts all outbound LLM API calls:

# Route OpenAI traffic through GLACIS sidecar
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: glacis-sidecar

Step 2: detect & redact

The sidecar runs a RegexSet-based PHI detector that identifies and replaces sensitive data with tokens:

// Before redaction
"Patient John Smith (DOB 03/15/1985) presents with..."

// After redaction
"Patient [PHI_NAME_1] (DOB [PHI_DATE_1]) presents with..."

Step 3: ephemeral vault

Original PHI values are stored in a memory-only vault with a TTL matching the request timeout. After the response returns, values are cryptographically zeroed.

Step 4: cryptographic attestation

Every request generates a signed attestation proving what was redacted, when, and that PHI never left the trust boundary:

{
  "attestation_id": "att_7x9k2mNp...",
  "phi_detected": 3,
  "phi_transmitted": 0,
  "timestamp": "2025-12-01T14:32:00Z",
  "signature": "ed25519:..."
}

The legal analysis

The key question is whether a vendor that never receives PHI qualifies as a Business Associate. Under 45 CFR § 160.103, a Business Associate is defined as a person or entity that "creates, receives, maintains, or transmits" PHI on behalf of a covered entity.

If PHI is stripped before transmission and the downstream service only ever sees data that no longer qualifies as PHI, the argument improves. But it is not automatic:

HIPAA turns on the data actually disclosed — if the external vendor receives PHI, the BAA analysis is unavoidable.
De-identification is the stronger framework — HHS guidance under 45 CFR § 164.514 matters more here than the conduit exception.
HHS treats the conduit exception narrowly — OCR's cloud-computing guidance says it applies only to pure transmission services with no storage other than temporary storage incident to transmission.
A de-identified downstream payload changes the analysis — OCR separately says a cloud service provider is not a business associate if it receives and maintains only information that has been de-identified in accordance with the Privacy Rule.
Vendor configuration matters — OpenAI and Anthropic now provide BAAs for certain HIPAA-ready services, which may be cleaner than trying to force a non-covered workflow into a narrow legal theory.

Primary sources reviewed: 45 CFR § 160.103, 45 CFR § 164.514, HHS de-identification guidance, HHS cloud-computing guidance, OpenAI’s API BAA guidance, and Anthropic’s commercial BAA guidance.

This is not legal advice. This analysis is for informational purposes only. Every deployment is different, and you should consult qualified healthcare legal counsel before implementing this or any architecture involving patient data.

Primary sources

What this enables

With this architecture in production, healthcare organizations can now deploy:

Clinical documentation assistants that summarize patient encounters
Prior authorization automation that drafts appeals
Patient messaging copilots that help clinicians respond faster
Quality improvement analytics that identify care gaps

Potentially with less PHI disclosure, tighter retention boundaries, and clearer evidence for internal review.

Try it yourself

GLACIS is currently working with select healthcare AI vendors. If you're building AI features that touch patient data and deals are stuck in security review, book the Agent Runtime Security & Evidence Sprint: 10 business days to harden one workflow locally and produce signed evidence receipts your reviewers can verify.

Reduce the surface area of BAA review

The Agent Runtime Security & Evidence Sprint hardens one AI workflow locally, keeps sensitive data inside your stack, and produces signed evidence receipts about data flows, retention boundaries, and controls.

Book the Sprint

Designing HealthCare AI workflows to minimize BAA exposure