Designing Healthcare AI Workflows to Minimize BAA Exposure
TL;DR: In-line redaction, de-identification review, and zero-retention configurations can materially reduce how much patient data reaches external AI services. But this is not automatically "BAA-free": the HIPAA outcome still depends on whether the downstream payload remains PHI, what the vendor retains, and whether counsel agrees the design satisfies the de-identification standard.
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
- 45 CFR § 160.103
- 45 CFR § 164.514
- HHS: Guidance on de-identification of PHI
- HHS: Guidance on HIPAA and cloud computing
- HHS OCR FAQ: de-identified information and CSP status
- OpenAI Help Center: API BAA guidance
- Anthropic Help Center: BAA guidance
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 a sprint call to see if the Evidence Pack can help.
Reduce the Surface Area of BAA Review
The Evidence Pack Sprint is designed to give your security team clearer evidence about data flows, retention boundaries, and controls.
Book Your Sprint Call