HIPAA-Compliant AI Tools for US Healthcare: AWS Bedrock, Azure OpenAI, Vertex AI, OpenAI Enterprise, Anthropic, Hippocratic AI — Real BAA Terms, Real Trade-offs (2026)

Before comparing vendors, get the terminology straight. A **Business Associate Agreement (BAA)** is the contract HHS requires between a Covered Entity (your hospital, clinic, payer, or clearinghouse) and any Business Associate that creates, receives, maintains, or transmits Protected Health Information on your behalf. The legal basis is 45 CFR 160 and 164 — full statutory text linked from https://www.hhs.gov/hipaa/. The BAA must contractually obligate the Business Associate to safeguard PHI, report breaches, ensure sub-processors meet the same standards, and return or destroy PHI at contract end. No BAA means the vendor is not legally permitted to process your PHI, full stop.

**Protected Health Information (PHI)** is individually identifiable health information held or transmitted by a Covered Entity or Business Associate in any form — electronic, paper, or oral. The 18 HIPAA identifiers include names, dates, addresses, phone numbers, email, SSN, MRN, account numbers, biometric identifiers, full-face photos, and IP addresses tied to a person. If you pipe any of those into a model prompt without a BAA covering the endpoint, you have just committed a HIPAA violation regardless of how the model behaved. Vendors love to advertise that they are 'HIPAA-ready' or 'HIPAA-friendly' — those phrases are meaningless. The question is binary: do they sign a BAA, and is the specific service you are using on their HIPAA-eligible services list.

**De-identification** is the safe harbor that lets you process former PHI without a BAA. HHS recognizes two methods. **Safe Harbor de-identification** requires removing all 18 specified identifiers and having no actual knowledge that the remaining information could re-identify the individual. **Expert Determination** requires a qualified statistician to certify, in writing, that the risk of re-identification is very small. Both methods are documented at https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/. Google's Cloud Healthcare API ships presets for both methods. AWS Comprehend Medical handles PHI entity detection that maps to the Safe Harbor list. Microsoft's Azure AI Language PII detection includes health-specific entities. OpenAI ships no native de-identification tooling — you must pre-process upstream.

**Audit logging is not optional.** HIPAA Security Rule §164.312(b) requires implementation of 'hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.' Translated: every read, write, modify, and delete of PHI must be logged, the logs must be tamper-evident, and they must be retained long enough to support OCR investigation. HHS does not name a specific retention period in §164.312, but the related §164.530(j) document-retention requirement is six years from creation or last effective date. Most health-system CISOs set six-year minimums for AI inference logs that touched PHI. AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs all support multi-year retention; OpenAI's audit log retention defaults to 30 days and requires export to extend.

**Breach notification under HIPAA is unambiguous.** 45 CFR 164.404 requires Covered Entities to notify affected individuals of a breach of unsecured PHI without unreasonable delay and no later than **60 calendar days** after discovery. Breaches affecting 500 or more individuals also require notice to HHS and to prominent media outlets in the affected state. Your vendor's job under the BAA is to give you prompt notice — typically within hours to days of discovery — so you have time to investigate, contain, and meet the 60-day patient notification deadline. The OCR fines schedule under the HITECH Act ranges from $137 per violation at the lowest culpability tier to $2,067,813 annual maximum per identical violation at the willful-neglect-uncorrected tier (2024 inflation-adjusted figures per 45 CFR 102). The penalty math is what makes the BAA review serious.

Finally, **sub-processor pass-through** is the question that traps most healthcare buyers. When you sign a BAA with Microsoft for Azure OpenAI, you are accepting that Microsoft's sub-processors (Azure infrastructure, data center contractors, security tooling vendors) are also bound to HIPAA terms by Microsoft. AWS, Google, and Microsoft all publish sub-processor lists and warrant pass-through for in-scope services. OpenAI's sub-processor pass-through is more limited and is part of the negotiated enterprise contract, not a standard term. Hippocratic AI markets a single-tenant deployment option specifically to shrink the sub-processor surface area to near zero. Read every sub-processor list before signing — that is where novel infrastructure dependencies hide.

**AWS Bedrock** is the simplest path in 2026. The standard AWS BAA — available at https://aws.amazon.com/compliance/hipaa-compliance/ — automatically covers Amazon Bedrock invocations of all included foundation models (Claude, Llama, Titan, Mistral, Cohere Command, Jamba) in HIPAA-eligible regions. You sign one BAA with AWS and you get coverage across the full Bedrock model catalog, HealthLake, Comprehend Medical, Transcribe Medical, S3, Lambda, and roughly 175 other HIPAA-eligible AWS services. The current list is maintained at the same compliance URL — verify your specific services are listed before go-live. AWS explicitly does not require a separate BAA per Bedrock model; the umbrella covers everything that runs through the Bedrock invocation API in an in-scope region.

**Azure OpenAI** is covered under the Microsoft enterprise BAA per https://learn.microsoft.com/en-us/compliance/regulatory/offering-hipaa-hitech. Microsoft lists Azure OpenAI Service explicitly as HIPAA-eligible, along with the broader Azure AI Foundry, AI Health Bot, AI Document Intelligence, Cognitive Services, Synapse, and Cosmos DB. The critical detail: the BAA covers data sent to Microsoft's enterprise tenant of OpenAI's models — it does not cover data sent directly to openai.com or to a personal ChatGPT account. The 'enterprise' qualifier in Microsoft's BAA language matters; Microsoft 365 Copilot is HIPAA-eligible only when deployed through the qualifying enterprise SKUs, not the consumer ChatGPT-style products. Also negotiate the abuse-monitoring opt-out if you do not want Microsoft to retain prompt content for 30 days for safety review.

**Google Vertex AI** is covered under the Google Cloud BAA per https://cloud.google.com/security/compliance/hipaa. Once the BAA is executed at the Cloud organization level, Vertex AI Gemini models, Med-PaLM 2, MedLM, the Healthcare API (FHIR, HL7v2, DICOM stores), Document AI, BigQuery, and Cloud Storage are all in-scope when invoked in HIPAA-eligible regions. Google's HIPAA-eligible services list is at the same compliance URL and is broader than most healthcare buyers expect — almost every Vertex AI sub-service is covered. The exception worth flagging: third-party model partnerships marketed inside Vertex (e.g., some Anthropic or Mistral models surfaced through Vertex Model Garden) may have separate BAA implications. Confirm coverage on the specific model endpoint before sending PHI.

**OpenAI Enterprise** signs BAAs per https://openai.com/enterprise-privacy/, but the BAA is negotiated rather than standard. Only Enterprise-tier customers qualify; ChatGPT Team customers can request a BAA on contract. The BAA scope covers ChatGPT Enterprise (web + mobile), the Assistants API, and the model endpoints invoked through the Enterprise admin console with ZDR (Zero Data Retention) enabled. OpenAI does not yet publish a standalone HIPAA compliance page comparable to AWS or Google; the privacy posture is documented in the Enterprise Privacy page plus the negotiated DPA and BAA. Real-world implication: expect a 30- to 60-day procurement cycle and a six-figure annual commit minimum before OpenAI will sign.

**Anthropic** does not sign direct BAAs in 2026. There is no path to processing PHI through anthropic.com's first-party API while staying HIPAA-compliant. The only HIPAA-eligible route to Claude is via Amazon Bedrock — where the AWS BAA covers the Claude invocations the same way it covers Llama or Titan. Claude is also available on Google Vertex AI Model Garden in some regions, but BAA coverage there should be confirmed in writing with Google before sending PHI. The practical implication: if you want Claude's reasoning on PHI workloads in 2026, you are running it on Bedrock. Anthropic's enterprise security posture is documented at https://www.anthropic.com/trust, but the BAA path itself remains AWS-mediated.

**Hippocratic AI** ships a BAA in its standard master services agreement per https://www.hippocraticai.com/. This is the healthcare-native architecture: their Polaris model is trained for clinical and operational healthcare workflows, their agent runtime is purpose-built for patient-facing conversations, and the BAA is non-negotiable boilerplate rather than a procurement battle. The pricing model is per-conversation or per-seat with annual commits, and most deployments include a single-tenant or virtual-private-cloud option that minimizes sub-processor exposure. Same caveat applies to other healthcare-native vendors on this list — Nabla at https://www.nabla.com/, Abridge at https://www.abridge.com/, Suki AI, DeepScribe, and Microsoft DAX Copilot — all ship BAAs in their standard healthcare agreements because the entire business model assumes PHI workloads.

The technical question behind 'is it HIPAA-eligible' is what happens to your prompt the instant you call the model endpoint. On **AWS Bedrock**, your prompt goes from your VPC to a Bedrock invocation endpoint inside an AWS region you control. Per the Bedrock data privacy FAQ, prompts and completions are not stored by AWS, not used to train base models, not shared with third-party model providers (including Anthropic, Meta, Mistral), and processed only in the region you invoked. This isolation is what makes Bedrock the dominant HIPAA path for Claude, Llama, and Mistral on PHI workloads in 2026.

On **Azure OpenAI**, the model endpoint sits inside your Azure tenant in your chosen region. Microsoft documents that customer prompts and completions are not sent to OpenAI itself, are not used to train OpenAI's base models, and are processed only within the Azure region you target. The wrinkle is abuse monitoring: by default Azure OpenAI retains prompts and completions for up to 30 days for safety review by Microsoft staff. For PHI workloads this is a non-starter, so apply for the abuse-monitoring opt-out, which Microsoft grants on a case-by-case basis for HIPAA customers per https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/abuse-monitoring. Without that opt-out, abuse-monitoring storage of PHI inside Microsoft's review pipeline becomes its own compliance question.

On **Google Vertex AI**, the prompt goes to a Vertex endpoint inside the Google Cloud region you specified. Google's stated policy at https://cloud.google.com/vertex-ai/docs/generative-ai/data-governance is that Vertex AI customer data is not used to train Google's foundation models, is not logged for human review by default, and is processed only in the region you invoked. Med-PaLM 2 and MedLM run under the same posture. Vertex's CMEK (Customer-Managed Encryption Keys) support lets you bring your own KMS keys for additional control, which is useful for systems that want crypto-shredding as part of the breach-response playbook.

On **OpenAI Enterprise**, the data flow goes directly to OpenAI's infrastructure — there is no hyperscaler in between. The ZDR (Zero Data Retention) setting, which must be turned on for the workspace per https://openai.com/enterprise-privacy/, means prompts and completions are not persisted past the inference request and are never used to train OpenAI's models. The trade-off versus Bedrock or Azure is that OpenAI itself is the sub-processor, not Microsoft or AWS — your BAA pass-through chain runs directly through OpenAI's vendors. For some healthcare buyers this is fine; for others, the lack of an intermediating hyperscaler is a deal-breaker. Get the sub-processor list and verify against your existing BAA inventory.

On **Anthropic via AWS**, the data flow is identical to any other Bedrock model: prompt enters Bedrock in your region, the Anthropic-developed model weights serve the response inside AWS infrastructure, completions return, nothing leaves AWS to Anthropic's first-party systems. This is the architectural reason the AWS BAA can cover Claude even though Anthropic does not sign direct BAAs. Anthropic does not see your prompt content.

On **Hippocratic AI**, the data flow is purpose-built. Patient conversations route through Hippocratic's agent runtime, PHI guardrails filter both inputs and outputs to scope what the agent can disclose, and the underlying Polaris model is hosted in a HIPAA-compliant environment with single-tenant deployment options. Hippocratic publishes the architecture overview at https://www.hippocraticai.com/safety. The same architectural pattern holds for Nabla (https://www.nabla.com/), Abridge (https://www.abridge.com/), Suki, DeepScribe, and Microsoft DAX Copilot — these vendors built the data plane around PHI from day one rather than retrofitting compliance on top of a general-purpose API.

HIPAA Security Rule §164.312(b) requires implementation of audit controls — full text at https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/. The control is technology-agnostic: the rule does not name CloudTrail, Azure Monitor, or any specific tool. What it requires is mechanisms that record and examine activity in systems containing electronic PHI. For LLM workloads the practical translation is: log every model invocation that touched PHI, who initiated it, when, what region, what model endpoint, and ideally the prompt-and-completion hash for tamper evidence. Plain-text prompt logging is risky because the audit log itself becomes a PHI store subject to the same controls — most CISOs hash the prompt and store the plaintext in a separate, encrypted, access-restricted bucket.

**AWS Bedrock** logs invocations through CloudTrail by default — control-plane events are free, data-plane events (the actual InvokeModel calls) require enabling Bedrock model invocation logging to CloudWatch Logs or S3. Retention is customer-controlled; the default CloudWatch retention is configurable from 1 day to 10 years or never expire. Most healthcare customers set six-year retention to match the §164.530(j) document-retention requirement and write logs to an S3 bucket with Object Lock for write-once-read-many tamper resistance. The reference architecture is documented at https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html.

**Azure OpenAI** logs through Azure Monitor and Diagnostic Settings. Retention in a Log Analytics workspace can be set up to 12 years, and archived logs in storage accounts can be retained indefinitely with immutability policies. The integration with Microsoft Sentinel makes the logs query-able alongside the rest of your Azure security telemetry. For HIPAA workloads, configure Diagnostic Settings to capture all categories — RequestResponse, Trace, and AuditLogs — and route them to both a Log Analytics workspace for query and an immutable storage account for long-term retention.

**Google Vertex AI** logs through Cloud Audit Logs. Admin Activity logs are retained for 400 days at no charge. Data Access logs — which include Vertex AI prediction requests — are not enabled by default and must be turned on explicitly; retention is customer-configured. The full reference is at https://cloud.google.com/vertex-ai/docs/general/audit-logging. For HIPAA workloads, enable Data Access logs on Vertex AI, route to BigQuery for long-term retention and analytics, and apply Bucket Lock to any GCS archives for tamper resistance.

**OpenAI Enterprise** ships audit logs through the Enterprise admin console and the audit-log API. Default retention is roughly 30 days inside the console; for longer retention, export to your own SIEM. The audit log granularity is per-workspace events (user invites, role changes, ZDR setting changes) plus per-API audit events for completion calls. This is leaner than AWS or Azure's audit infrastructure and is often the area that requires the most customization for healthcare procurement. Confirm in writing what events are logged and what the maximum export retention is before signing.

On breach notification: the AWS, Microsoft, and Google BAAs all commit to notifying the customer 'without unreasonable delay' upon discovery of a breach — they do not commit to a specific hour-count SLA in their standard contracts. OpenAI's negotiated BAA terms are similar. The HIPAA Breach Notification Rule at 45 CFR 164.404 puts the **60-day patient notification clock on you, the Covered Entity**, not the vendor. The vendor's job is to give you enough information fast enough that you can investigate, contain, and notify within 60 days. For breaches affecting 500 or more individuals, you also must notify HHS and prominent media outlets in the state. OCR's enforcement page at https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/ documents recent penalty actions — 2024 saw multiple settlements in the multi-million-dollar range, and the inflation-adjusted maximum per identical violation reached $2,067,813 annually.

HIPAA Safe Harbor de-identification requires removing all 18 specified identifiers — names, dates other than year, addresses smaller than state, phone numbers, fax numbers, email addresses, SSNs, MRNs, account numbers, health plan numbers, certificate or license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number, characteristic, or code — and having no actual knowledge that the remaining information could re-identify the individual. HHS documents the method at https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/. Once data is Safe Harbor de-identified, it is no longer PHI and can be processed by any vendor without a BAA.

Expert Determination requires a qualified statistician — typically with formal training in re-identification risk — to apply generally accepted statistical and scientific principles and certify in writing that the risk of re-identification is very small. The advantage is that Expert Determination can leave more analytical signal in the data (for example, exact dates of service) than Safe Harbor allows. The disadvantage is the ongoing cost of expert review and the documentation burden. Most large health systems maintain a small bench of statisticians or contract with firms like Privacy Analytics for this work.

**Google Cloud Healthcare API** ships the most mature de-identification tooling on this list. The DICOM and FHIR de-identification operations support both Safe Harbor and Expert Determination presets and let you customize per-field transforms (suppress, replace, generalize, date-shift, crypto-hash). The reference is at https://cloud.google.com/healthcare-api/docs/concepts/de-identification. For research datasets going from a clinical FHIR store to a non-PHI analytics environment, this is the cleanest pipeline available across the three hyperscalers.

**AWS Comprehend Medical** ships a PHI detection and redaction API that identifies all 18 HIPAA identifiers in unstructured text. The output is a structured list of detected entities with offsets, which you can use to redact, replace, or hash before passing the cleaned text into a model. AWS HealthLake adds a FHIR-native de-identification pipeline that handles structured records. Together these cover the Safe Harbor path well. For Expert Determination you still need a statistician to design and certify the transformation logic.

**Azure AI Language** PII detection includes health-specific entity categories and is suitable for Safe Harbor identifier removal in unstructured clinical text. The Azure AI Health Bot SDK includes redaction utilities for conversational PHI scrubbing. Microsoft does not ship a first-party Expert Determination toolkit comparable to Google's Healthcare API, so Azure customers building research pipelines often pre-process in Spark or Databricks before landing data in Synapse for analytics.

**OpenAI Enterprise** and **Anthropic via AWS** do not ship first-party de-identification tooling. The recommended pattern is to use AWS Comprehend Medical, Azure AI Language, or Google Cloud Healthcare API upstream — depending on which cloud you live on — and feed the de-identified result into the model. **Hippocratic AI** ships PHI guardrails inside the agent runtime rather than as a separate de-identification toolkit, because the use case is patient-facing operational workflows where PHI is intentionally in scope under the BAA. Match the tool to the use case: research pipelines benefit from Google's de-id presets; agent-driven patient outreach benefits from in-runtime guardrails.

Start with the BAA itself. Ask the vendor to send the **current standard BAA** (not a marketing summary) before you take a demo. Read it. Specifically check: (1) is the AI model endpoint you want to use named on the HIPAA-eligible services list referenced by the BAA; (2) what is the breach notification timeline the vendor commits to; (3) what are the sub-processor list and the pass-through warranty language; (4) what is the data-return-or-destruction obligation at contract end. If any of these four are absent or hedged, you have a procurement red flag, not a contract. AWS, Microsoft, and Google standard BAAs all answer these clearly. OpenAI's negotiated BAA varies — be ready to mark up.

Next, **pin down the in-scope model and region**. The AWS BAA covers Bedrock invocations of HIPAA-eligible foundation models in HIPAA-eligible regions. If you call a model that is not on the eligible list, or invoke in a region that is not HIPAA-eligible, the BAA does not apply to that invocation — and you have a breach. The same logic holds for Azure OpenAI region selection and Vertex AI region selection. Build your runtime to fail-closed on region: reject any invocation routed outside the configured allowlist of HIPAA-eligible regions. Do not rely on developers to remember.

Get the **audit log architecture documented end-to-end** before go-live. Spell out which events are logged, where logs are written, what the retention is, how integrity is enforced (Object Lock for AWS, immutability policies for Azure, Bucket Lock for GCP), and who can access them. Have your CISO sign off on the architecture diagram before you let the first production prompt with PHI run through the model. The cost of bolting audit logging on after an OCR investigation starts is many multiples of the cost of building it correctly upfront.

**Get the sub-processor list in writing and review it.** The hyperscalers publish their sub-processor lists at stable URLs — AWS at https://aws.amazon.com/compliance/sub-processors/, Microsoft at https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum, Google at https://cloud.google.com/terms/subprocessors. OpenAI publishes its sub-processor list inside the Enterprise privacy page. Healthcare-native vendors typically publish on request. Review the list with your privacy officer, flag any sub-processor that processes data outside the US if data residency is in scope, and confirm the pass-through warranty language covers them. New sub-processors should require advance notice under the BAA — typically 30 days.

**Pressure-test the breach response process.** Ask the vendor what their internal breach response runbook looks like, what the typical time from detection to customer notification has been historically, and how they handle multi-customer breach scenarios (where the same incident affects many BAAs simultaneously). Ask for references from health-system customers who have actually been through a vendor-side incident with them. The marketing answer is always 'within hours'; the operational reality varies. You want a vendor whose actual past performance matches their contractual SLA.

Finally, **negotiate the termination terms before the pilot starts, not after**. Standard terms typically give the Covered Entity the right to terminate if the Business Associate materially breaches the BAA, but the timelines, cure periods, and data-return obligations vary significantly. For high-risk PHI workloads, push for: a 30-day notice termination right for material breach without cure, a 90-day data-return-or-destruction obligation, and an audit-rights clause that lets you (or your auditor) inspect the vendor's HIPAA controls annually. The hyperscalers will resist the audit-rights clause and offer their SOC 2 reports as a substitute — that is usually acceptable, but get the substitution documented in the BAA itself.

Some health-system CISOs ask whether they can sidestep vendor BAAs entirely by self-hosting an open-weights model — Llama 3.x, Mistral, or Mixtral — on their own HITRUST-certified infrastructure. The answer is yes, technically, and for some workloads it is the right architecture. If you already operate a HITRUST CSF-certified data center or VPC, your existing HIPAA controls extend to whatever workloads you run there, including LLM inference. No vendor BAA is required because you are not handing PHI to a vendor — you are processing it inside infrastructure you already own and audit.

The trade-offs are real. Self-hosted Llama 3 70B requires roughly 140 GB of GPU memory in fp16 — two A100 80GB cards or one H100, plus the orchestration around them. Operating cost is in the $30,000-$80,000 per year range per inference node depending on utilization, before headcount for ML platform engineering, model evaluation, prompt-injection defense, and ongoing security review. For a system with 5,000 daily PHI inferences across 50 use cases, the math against Bedrock or Azure OpenAI is rarely favorable. For a system with 5 million daily inferences in a tight set of repeatable workflows, the math flips fast.

The hybrid pattern that works in 2026: **buy** Azure OpenAI or AWS Bedrock for the broad portfolio of clinical and administrative AI use cases where flexibility matters, and **build** self-hosted Llama or Mistral for the one or two highest-volume, lowest-variability workflows — clinical documentation summarization, claims adjudication assistance, FHIR query routing — where economics justify the operational burden. Run the inference cost model honestly using the OpenAI API cost calculator and the RAG cost per query calculator to compare the per-inference cost at your projected volume.

Where self-hosting genuinely wins on compliance grounds: extremely sensitive workflows where the residual risk of any third-party touching PHI — even under BAA — is unacceptable to your board or general counsel. Behavioral health, substance abuse records subject to 42 CFR Part 2, certain reproductive health workflows in post-Dobbs jurisdictions, and certain pediatric workflows all carry elevated sensitivity that some health systems handle by self-hosting. The HHS guidance at https://www.hhs.gov/ acknowledges that some Covered Entities will choose this path; the regulatory bar is the same — you must implement the Security Rule technical, physical, and administrative safeguards regardless of whether the inference runs in your data center or your vendor's.

Where self-hosting loses: you do not get Claude 4-class or GPT-4o-class reasoning quality from open-weights models in 2026, full stop. The gap on complex clinical reasoning is material. If your use case genuinely needs the frontier model — for example, a clinician-facing decision support tool — you should be on Bedrock Claude, Azure OpenAI GPT-4o, or Vertex AI Gemini Ultra under a BAA, not on self-hosted Llama. Open-weights quality is closing for narrow tasks (summarization, extraction, structured output) but the gap on multi-step clinical reasoning remains.

If you do go the self-hosted route, the cost calculator at vector database cost per 1M embeddings is helpful for sizing the RAG layer that almost always accompanies an LLM workload. Forgetting that the embeddings store, the vector database, and the retrieval pipeline all need their own HIPAA controls is the most common architectural error in self-hosted healthcare AI deployments. Every component touching PHI is in scope for §164.312 audit controls, encryption in transit and at rest, and access controls — not just the model endpoint.

For a 1,000-bed academic medical center already standardized on AWS, the answer is **AWS Bedrock + HealthLake + Comprehend Medical** as the foundation, with Claude 4.x as the default reasoning model and Llama 3.x for high-volume cheap inference. Single BAA covers the stack, single audit trail through CloudTrail, single sub-processor list to review. Add Hippocratic AI on top for patient-facing outreach and chronic-care check-ins where the conversational quality and operational packaging are best-in-class. Verify the current Bedrock HIPAA-eligible model list at https://aws.amazon.com/compliance/hipaa-compliance/ before procurement.

For a system standardized on Microsoft (Epic on Azure, Microsoft 365 Copilot deployed, Dynamics-based revenue cycle), the answer is **Azure OpenAI with the Microsoft enterprise BAA**, plus Microsoft DAX Copilot for ambient clinical documentation. The bundle math is hard to beat when you are already an Azure enterprise customer, and the Epic GPT integrations announced in 2024-2025 are deeply tied to Azure OpenAI's privacy posture. Apply for the abuse-monitoring opt-out and get it in writing. Verify the current Azure OpenAI HIPAA-eligible status at https://learn.microsoft.com/en-us/compliance/regulatory/offering-hipaa-hitech before go-live.

For a research-heavy academic system that needs Med-PaLM 2 or MedLM, the answer is **Google Vertex AI** with the Cloud Healthcare API for FHIR de-identification of research datasets. Google's de-identification toolchain is the most mature on the market, and Med-PaLM's healthcare-specific tuning is genuinely useful for medical question answering and literature synthesis. Verify the current Vertex AI HIPAA scope at https://cloud.google.com/security/compliance/hipaa. For clinical reasoning workloads, pair with Gemini Ultra; for de-identified research analytics, BigQuery plus Vertex AI is the cleanest pipeline.

For a health-tech startup that needs ChatGPT-grade UX with a real BAA and minimal infrastructure, the answer is **OpenAI Enterprise with ZDR**. The procurement cycle is real (plan on 60-90 days) and the commit is meaningful (typically six figures annually minimum), but the developer experience is best-in-class and the BAA is genuinely on offer per https://openai.com/enterprise-privacy/. For the same use case at a hospital-system buyer scale, Azure OpenAI is usually the better choice because the Microsoft BAA is already in place.

For ambient clinical documentation specifically — the highest-ROI healthcare AI workflow in 2026 — the answer is a healthcare-native specialist, not a hyperscaler. **Abridge** at https://www.abridge.com/, **Nabla** at https://www.nabla.com/, **Suki AI**, **DeepScribe**, and **Microsoft DAX Copilot** are all purpose-built for the workflow. Abridge has the deepest Epic integration as of 2026; DAX Copilot is the right pick for systems heavily invested in Microsoft; Nabla is strong internationally and on Android; Suki and DeepScribe are EHR-agnostic. All ship BAAs in standard terms. Per-encounter pricing has dropped meaningfully — 2026 ranges land in the $200-$400 per clinician per month band depending on volume and specialty.

The one thing not to do in 2026 is **process PHI through a vendor with no BAA**. ChatGPT consumer accounts, Claude.ai personal subscriptions, Gemini consumer accounts, and any LLM API not explicitly listed as HIPAA-eligible by the vendor are out of scope, period. The risk is not theoretical — OCR has settled multiple cases involving employees using consumer AI tools on PHI. Lock down access at the network layer, deploy DLP rules that catch PHI-in-prompt attempts to non-eligible endpoints, and train staff explicitly that personal AI accounts are off-limits for any work data. The OCR enforcement bulletin at https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/ documents the trend.