AI capability is now table stakes. AI deployment in regulated industries is still complicated. The capability that makes AI useful in healthcare, financial services, and government settings is the same capability that triggers compliance review, vendor risk assessment, and data residency questions. Most off-the-shelf AI offerings were designed for a consumer or general-business audience. The compliance answers are often “yes, but” or “in some cases” rather than the unambiguous “yes” that regulated buyers need.
This guide is for compliance officers, CTOs, and IT leaders at HIPAA-regulated organizations evaluating AI deployment options. It covers what HIPAA actually requires of an AI system, the four deployment architectures available in 2026, and the trade-offs of each.
What HIPAA Actually Requires of AI
HIPAA does not contain a chapter titled “AI.” It contains rules about Protected Health Information (PHI). Any AI system that processes PHI is subject to those rules. The relevant requirements:
- Business Associate Agreement (BAA). Any vendor that handles PHI on behalf of a covered entity must sign a BAA. This includes AI vendors whose systems process patient data.
- Administrative, physical, and technical safeguards. The Security Rule requires that PHI be protected at rest, in transit, and in processing. AI systems are processing.
- Minimum necessary use. Only the PHI required for the specific task should be processed. Sending entire patient records to a general-purpose AI service for a narrow question is a minimum-necessary violation.
- Audit controls. Logging of who accessed what PHI, when, and for what purpose. AI processing counts as access.
- Breach notification. If an AI service is compromised or improperly accesses PHI, the covered entity has breach notification obligations.
None of these are exotic. Healthcare IT teams already navigate them for every other system. The question is whether a given AI deployment can satisfy them, and at what cost in capability and complexity.
The Four Deployment Architectures
Architecture 1: Public cloud AI services with BAAs
The major cloud providers (AWS, Google Cloud, Microsoft Azure) all offer AI services with available BAAs. Microsoft offers Azure OpenAI Service with BAA coverage. Google offers Vertex AI with BAA. AWS Bedrock has BAA coverage.
Pros: Capability is current. Models are frequently updated. Infrastructure scales without effort. The compliance answer is “yes, with BAA.”
Cons: PHI leaves the covered entity’s environment and enters the cloud provider’s. The BAA covers liability and obligations, but data is still in motion. For organizations with strict data residency requirements (some state Medicaid programs, some federal contractors), this architecture is not available even with a BAA.
Where it fits: Mid-sized healthcare organizations comfortable with cloud-resident PHI under BAA terms. Most common architecture in 2026.
Architecture 2: Private cloud AI with dedicated infrastructure
Customer-dedicated cloud infrastructure (AWS GovCloud, Azure Government, dedicated Google Cloud regions) running AI workloads in environments isolated from general public cloud. Often required for federal customers and state Medicaid programs.
Pros: Stronger isolation. Compliance acceptance is easier with federal customers and security-sensitive state agencies. BAAs apply.
Cons: Higher cost. Smaller selection of available AI models, since not every model the provider offers is available in the dedicated environment. Slower to receive new model versions.
Where it fits: Federal healthcare contractors, state Medicaid programs with strict residency requirements, organizations with FedRAMP requirements.
Architecture 3: On-premise AI with locally-hosted models
AI models running on customer-owned infrastructure inside the customer’s data center. The model files are deployed on customer hardware. Inference happens on customer-controlled GPUs or specialized accelerators. Nothing leaves the network.
Pros: Strongest data control. No PHI ever transits a third-party network. Compliance review is simpler because the AI system is treated as an internal application. No BAA is needed because no vendor is processing PHI.
Cons: Significant infrastructure investment. Customer is responsible for hosting, scaling, updating, and maintaining the models. Model selection is constrained to what can be deployed locally. Operating costs include power, cooling, and hardware refresh cycles.
Where it fits: Large healthcare organizations with existing on-premise infrastructure investments. Research hospitals running computationally intensive workloads. Organizations whose risk tolerance does not accept any cloud transit of PHI regardless of BAA coverage.
Architecture 4: Air-gapped AI with locally-hosted models
The same architecture as on-premise, with the additional constraint that the environment has no internet connectivity at all. AI models are deployed via physical media. Updates are scheduled and controlled.
Pros: Maximum security posture. Used by classified workloads, defense contractors, and the most security-sensitive healthcare workloads. No possibility of data exfiltration via network.
Cons: Most operationally complex. Model updates require coordinated downtime windows. New model versions cannot be evaluated quickly. Highest cost. Smallest set of available models.
Where it fits: Defense health systems. Classified medical research. Highest-sensitivity workloads.
The Hybrid Pattern
In practice, most enterprise deployments end up hybrid. Different AI workloads have different sensitivity profiles. The same organization might run:
- Public cloud AI with BAA for de-identified analytics and administrative workflows where PHI is masked or absent
- Private cloud AI for general clinical workflows handling PHI under BAA terms
- On-premise AI for high-sensitivity research workloads or workflows that touch PHI from multiple sources
- Air-gapped AI for any classified or maximum-sensitivity work
The architectural decision is workload-by-workload, not organization-wide. A blanket policy (“all AI must run on-premise”) is usually overcorrected. A blanket policy (“we’ll use whatever cloud AI is convenient”) is usually under-protected.
The Model-Agnostic Argument
A platform that supports multiple model backends (Claude, OpenAI, Gemini, locally-hosted open weights) preserves flexibility as the regulatory and capability landscape shifts. Three patterns where this matters:
- A new model is released that better serves a specific workload. Without model-agnostic architecture, switching is an integration project. With it, switching is a configuration change.
- A model provider changes terms. BAA terms, pricing, residency commitments, or data handling commitments can change. Model-agnostic architecture preserves the ability to migrate.
- Different workloads require different models. Some workloads need cutting-edge capability and can use cloud-hosted models. Others need air-gapped deployment and require locally-runnable open-weights models. A unified platform that handles both is more cost-effective than separate stacks.
What to Look for in an AI Vendor
For HIPAA-regulated organizations, the vendor evaluation questions worth asking:
- Does the vendor offer a BAA, and what is the scope?
- What deployment architectures are supported (public cloud, private cloud, on-premise, air-gapped)?
- What model backends are supported, and can the customer choose?
- What audit logging is built in?
- What is the data retention policy for inputs and outputs?
- If models are hosted, do they ever train on customer data?
- What happens to PHI in flight, in process, and at rest?
- What is the breach notification process and timeline?
- What certifications does the vendor or platform hold (SOC 2, HITRUST, FedRAMP)?
A vendor that cannot answer these questions directly and in writing is not ready for HIPAA-regulated deployment regardless of how good the AI capability is.
QuantaPath AI and Healthcare Workflows
QuantaPath AI is Golden Path Digital’s HIPAA-compliant AI platform for CRM, portal, and workflow automation. The platform is model-agnostic and supports all four deployment architectures: public cloud with BAA, private cloud, on-premise, and air-gapped. Customer data residency choice is a first-class concern, not an afterthought.
Use cases in current deployment include patient communication workflows, prior authorization automation, claims processing assistance, and intake form processing. Each workflow can be deployed at the architecture that matches its specific sensitivity profile.
What to Do Next
If your organization is evaluating AI deployment options under HIPAA constraints, the next step is an architecture conversation that maps your specific workloads to the appropriate deployment patterns. Golden Path Digital offers initial scoping conversations for healthcare organizations and regulated enterprises.
Visit goldenpathdigital.com/qantapath-ai/ or reach out via the contact form for a discovery call.
Golden Path Digital is an enterprise software and AI modernization company headquartered in Hot Springs Village, Arkansas. AS/Forward modernizes IBM i and RPG codebases. Laravel Ascend automates Laravel application upgrades. QuantaPath AI delivers HIPAA-compliant CRM and workflow automation. Serving enterprises nationwide with US-based delivery and air-gapped deployment options. 1 US patent pending.