A Procurement Guide to Private AI for Healthcare

Private AI for healthcare is a deployment model in which the model, the inference workload, and the patient data it touches are kept inside a boundary the health system controls, so that protected health information (PHI) does not flow to a vendor’s shared infrastructure. It is the procurement answer to a regulatory reality: PHI is restricted by HIPAA, and the organization that holds it cannot point an AI tool at the records without assuming compliance responsibility for where the data lands.

Why PHI changes the rules

When an AI system reads, writes, or reasons over records that contain individually identifiable health information, it is operating on PHI. The federal framework that governs PHI is the Health Insurance Portability and Accountability Act (HIPAA) — specifically the Privacy Rule, the Security Rule, and the Breach Notification Rule. Two facts about this framework drive most procurement decisions.

The covered entity remains responsible. HIPAA places its compliance obligations on covered entities, which include health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with covered transactions. A hospital that bills electronically is a covered entity. When it engages a vendor that creates, receives, maintains, or transmits PHI, that vendor is generally a business associate, and the covered entity must put a business associate agreement (BAA) in place before disclosing PHI to it. HHS makes this explicit: a covered entity may disclose PHI to a business associate only if it obtains satisfactory assurances, in the form of a contract or other written arrangement, that the business associate will appropriately safeguard the information. The obligation is contractual, but the accountability is not transferred.

A BAA is not optional. The requirement is codified at 45 CFR 164.502(e) and 164.308(b)(1). HHS is direct that a covered entity that uses a cloud service provider to process or store ePHI without a BAA is in violation of the HIPAA Rules, and it has entered resolution agreements with covered entities that stored the ePHI of over 3,000 individuals on a cloud server without first executing a BAA. This is the point where “HIPAA-compliant cloud” and “private AI” diverge: with a BAA, the vendor is contractually bound; without one, the hospital carries the full regulatory exposure alone.

Business associates are directly liable, but that is not a shield for the hospital. The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted in 2009 and implemented by OCR’s 2013 final rule, made business associates directly liable for certain provisions of the HIPAA Rules, including the Security Rule, impermissible uses and disclosures of PHI, breach notification to the covered entity, and failure to enter into BAAs with their own subcontractors. HHS lists as examples of business associates a cloud service provider that processes or stores ePHI, a third-party vendor AI chatbot on a patient portal that handles PHI, and an EHR vendor whose support work requires access to ePHI. Direct liability is meaningful leverage in a negotiation, but it does not relieve the covered entity of its own duties.

Breach exposure is the cost center. Under the Breach Notification Rule, 45 CFR 164.400–414, a covered entity and its business associates must notify affected individuals, the Secretary of HHS, and in some cases the media, after a breach of unsecured PHI. Individual notification must be provided without unreasonable delay and in no case later than 60 days from discovery; breaches affecting fewer than 500 individuals may be reported to the Secretary annually, due within 60 days of the end of the calendar year. A breach is an impermissible use or disclosure that compromises the security or privacy of the PHI, and it is presumed to be a breach unless a risk assessment demonstrates a low probability of compromise. For a procurement decision, this is the line item that turns a software purchase into a balance-sheet risk: the notification duty, the corrective action plan, and any resolution agreement all land on the covered entity.

Where the realistic risk sits is the deciding factor. In a shared-infrastructure SaaS, PHI is processed on the vendor’s systems; the protection is the BAA, vendor attestations such as SOC 2 and HITRUST, and the vendor’s own Security Rule compliance. The residual risk is that the hospital cannot inspect the environment or control where the data resides. In an on-prem or air-gapped deployment, the data never leaves the hospital’s boundary, so residency, the attack surface, and the logging are directly controlled, at the cost of speed and capital.

The deployment options ranked for healthcare

Three models cover nearly every hospital AI decision, and they are not mutually exclusive. The ranking runs from fastest to deploy down to most controlled.

Option 1 — HIPAA-eligible cloud SaaS with a BAA. The vendor operates the model and the infrastructure, the hospital signs a BAA, and PHI is processed in the vendor’s environment. It is the fastest path to value and the cheapest upfront, but the hospital gives up direct control of the environment and the data’s physical location. The standard mitigation is a BAA plus a strong vendor compliance posture. This is the correct starting point where the PHI is already in the EHR and the benefit is immediate, such as ambient clinical documentation.

Option 2 — Private cloud or dedicated VPC. The workload runs in an isolated tenant or a dedicated virtual private cloud, under the hospital’s own credentials. The BAA is still required because the vendor remains a business associate. The trade: isolation reduces cross-tenant exposure and can satisfy residency constraints, but the platform is still vendor-operated and slower to stand up than a shared SaaS.

Option 3 — Fully on-prem or air-gapped. The model and the inference stack run on hardware the hospital owns, inside its network; in the air-gapped case, on a network with no external connectivity. This is the model for the most sensitive workloads: PHI at rest, the full longitudinal record, research datasets, and any workflow where leaving the boundary is not acceptable. The trade: it is the slowest to deploy and the most expensive to run, because the hospital carries the hardware, the licensing, and the machine learning operations. For the broader sovereign and on-premise models and where each fits, see on-premise AI and what is sovereign AI; the general architecture for running AI inside regulated boundaries is in the regulated AI guide.

A pragmatic pattern is staged adoption: start with a BAA-backed cloud SaaS for a low-sensitivity, high-return workflow, then move the most data-intensive workloads to private cloud, and reserve on-prem or air-gapped capacity for the subset where residency or connectivity constraints are absolute.

The use cases hospitals buy first

Hospitals do not buy “AI”; they buy workflow relief. The use cases that reach funded status first map to a measurable pain and the record the hospital already holds.

Clinical documentation and ambient scribes. This is the current entry point. Ambient AI tools capture the clinician-patient conversation and produce a structured note for the chart. Adoption is broad: a 2026 study of US hospitals using Epic found that 62.6% of those hospitals had adopted ambient AI by June 2025, with uptake higher in larger, nonprofit, higher-margin, and higher-workload systems. The benefit is immediate (documentation time, after-hours work, administrative burden), the data lives in the EHR, and the ROI is measurable in clinician hours. It is also a natural fit for streamlining electronic health records.

Coding and revenue cycle. AI-assisted medical coding, charge capture, and denial management target the revenue side, where payback is direct and quantifiable. These workloads touch the full claim and encounter history, so they sit at the center of the PHI boundary question.

Prior authorization. Automated prior-authorization handling is high-friction and high-volume, and a strong candidate for a private deployment because generating and submitting requests requires access to the patient’s record.

Patient communications. AI triage, scheduling, symptom assessment, and patient messaging on the portal are explicitly called out by HHS as business associate activities when they involve PHI, which makes the BAA requirement unavoidable and pushes the conversation toward a compliant vendor or a private stack.

Research and data science. De-identified and longitudinal research workloads are where the air-gapped model earns its keep, because the dataset is the most sensitive and the regulatory posture is the strictest.

For the broader landscape of how healthcare organizations deploy AI across clinical and operational workflows, see the healthcare and life sciences guide.

The TCO frame for a CFO

A cloud SaaS quote is the floor, not the total. A defensible total cost of ownership has six components, and the mix shifts with the level of control.

1. Licensing and usage. Cloud SaaS is subscription or per-usage; on-prem is a capital or amortized license plus usage. The per-unit economics of inference compound with volume and are easy to understate at scale.
2. Integration and EHR touchpoints. Every workflow that reads or writes the chart needs interface work. This is a one-time cost that recurs with each new use case, and it is often the largest hidden line in the first year.
3. Compliance and contracting. BAA negotiation, security review, SOC 2 / HITRUST review, and the hospital’s own risk analysis under the Security Rule are labor that lands before go-live. In a private deployment, this expands to validating the vendor’s controls inside the boundary.
4. Infrastructure and MLOps. On-prem and air-gapped add hardware, networking, storage, and the staffing to operate a model in production, including monitoring, updates, and the failure handling a public cloud vendor otherwise absorbs.
5. Breach and liability exposure. This is a tail risk, not a line item. The 60-day notification duty, a potential corrective action plan, and an OCR resolution agreement are the downside scenario a BAA-backed or private deployment is meant to reduce.
6. Exit and re-procurement cost. The cost of leaving a vendor, migrating the data, and re-establishing the BAA or the on-prem stack. A contract without a clean exit path converts a vendor decision into a dependency.

The rule of thumb: cloud SaaS has the lowest first-year cost and the highest vendor dependence; on-prem the reverse. The decision is whether the sensitivity of the data and the frequency of the workload justify carrying the infrastructure, or whether a BAA plus a strong vendor posture is sufficient.

The vendor checklist

Run this checklist during due diligence. Each item maps to a requirement or risk identified above, and each should be answered in writing before signature.

• BAA. Does the vendor sign a BAA that meets 45 CFR 164.504(e) before PHI is disclosed? Is the vendor willing to flow the BAA down to its own subcontractors, as it is required to do?
• Data residency and location. Where does the data physically reside, and can the hospital require a specific region or its own boundary?
• Model data residency and training. Is the hospital’s data used to train or fine-tune shared models? What is the contractually committed answer, and how is it verified?
• PHI in inference logs. Are prompts, outputs, and intermediate PHI captured in logs or telemetry, and for how long are they retained?
• Audit logs. Can the hospital access a complete, exportable audit trail of access to and processing of PHI?
• Security Rule controls. What administrative, physical, and technical safeguards does the vendor maintain, and can it produce the evidence (SOC 2 Type II, HITRUST) on request?
• Breach notification. What is the vendor’s contractual commitment to notify the hospital of a suspected breach, and does it meet the hospital’s own 60-day duty to individuals and HHS?
• Access control. Who can access the data and the model, and how are roles, privileges, and workforce access managed and reviewed?
• Subprocessor transparency. What is the current list of subprocessors, and what is the notice and consent process if the list changes?
• De-identification and minimization. Can the hospital enforce minimum necessary use, and are de-identification options available for non-clinical workloads?
• Exit path. What is the process for returning or destroying PHI at termination, and what is the migration assistance and data portability commitment?

A vendor that can answer every item in writing, with evidence, has thought about the boundary. A vendor that deflects any of them is pricing the hospital’s compliance risk as a free option.

For a live walkthrough of how a private or sovereign AI stack is put in front of a hospital’s own data boundary, see a demo.

Last verified: 2026-09-05