Building HIPAA-Compliant AI Systems: What You Need to Know

Three rules govern HIPAA compliance for AI: the Privacy Rule (minimum necessary ePHI access), the Security Rule (encryption, MFA, audit logging, access controls), and the Breach Notification Rule (disclosure within 60 days). A signed Business Associate Agreement is a legal prerequisite, not a compliance mechanism. It does not prevent ePHI from transiting third-party inference infrastructure or being used in model training. Architectural controls do that.

This guide covers the decisions that healthcare technology buyers actually face: what a BAA covers and what it does not, what the 2025 HIPAA Security Rule update changed, and when self-hosted infrastructure becomes the only defensible option. Skip the definitions. You already know what HIPAA is.

what HIPAA actually requires from an AI system#

the three rules that apply: privacy, security, breach notification#

Privacy Rule: Covered entities and business associates must use and disclose ePHI only as necessary for the intended purpose. For AI systems, that means the model receives the minimum ePHI required for its task. An AI system performing appointment scheduling does not need access to clinical notes. An AI system doing clinical documentation does. Scoping access correctly is both a compliance requirement and a security practice.

Security Rule: Covered entities must implement administrative, physical, and technical safeguards for ePHI. The 2025 NPRM (published January 6, 2025) eliminated the "required vs. addressable" distinction. All implementation specifications are now mandatory: MFA for all systems accessing ePHI, AES-256 encryption at rest, TLS 1.3 in transit, vulnerability scanning every six months, and penetration testing annually (HHS Federal Register, January 2025).

Breach Notification Rule: If a breach of ePHI occurs, affected individuals must be notified within 60 days. HHS OCR must be notified for breaches affecting 500 or more individuals within 60 days; smaller breaches are reported annually. The definition of breach includes unauthorized access by third parties, including an AI vendor whose infrastructure processes your ePHI without appropriate controls.

ePHI defined: what counts and what the AI is touching#

Electronic Protected Health Information is any individually identifiable health information that is created, received, maintained, or transmitted electronically. For AI systems in healthcare settings, ePHI appears in:

• Patient names, dates, contact information linked to health conditions or treatment
• Appointment records that reveal conditions (a cardiology appointment, an oncology follow-up)
• Insurance information linked to a patient
• Clinical notes, lab results, imaging reports
• Billing records that associate a person with a procedure or diagnosis
• Call recordings that contain any of the above

An AI receptionist that books appointments may process ePHI: the caller's name, their insurance information, the type of appointment. Whether it does depends on what data the system collects and whether it connects to records that make it identifiable health information.

the minimum necessary standard and why AI systems struggle with it#

HIPAA's minimum necessary standard requires that covered entities limit ePHI access to what a given task actually requires. AI systems are architecturally prone to violating this because they are designed to use context to improve output quality. An LLM with access to a patient's full medical history gives better-contextualized responses than one with access only to the appointment record, but the former may violate the standard.

This means defining explicit data access scopes before deployment, not after. The model gets the data it needs for the specific task. Not the full record.

no AI tool is "HIPAA certified": what that means in practice#

HIPAA certification does not exist. There is no government certification for HIPAA compliance. When a vendor says their tool is "HIPAA certified," they mean they have implemented controls consistent with HIPAA requirements, typically verified through an internal audit, a third-party assessment, or SOC 2 certification.

What matters is whether the specific AI system's deployment in your environment satisfies the regulatory requirements. A vendor that is HIPAA-eligible (willing to sign a BAA) is not the same as a deployment that is HIPAA-compliant. The distinction is important and widely misunderstood.

the BAA problem: what it covers and what it does not#

what a Business Associate Agreement legally does#

A BAA is a legal contract between a covered entity and a business associate, meaning any vendor that handles ePHI on the covered entity's behalf. The BAA defines what the business associate is permitted to do with ePHI, requires them to implement appropriate safeguards, establishes liability if something goes wrong, and specifies breach reporting requirements.

A BAA is required. Using an AI vendor that handles ePHI without one is a direct HIPAA violation regardless of what else you have done correctly.

what a BAA does not prevent: ePHI in transit through inference endpoints#

Here is the thing most organizations miss about BAAs: they do not change the architecture of how data is processed.

A BAA does not prevent ePHI from transiting the vendor's inference infrastructure. It does not prevent the vendor's model serving layer from processing your prompts. It establishes contractual accountability for what happens, but the data still goes where it goes.

If your AI system sends patient data to a third-party cloud API for inference, that data transits the provider's network, gets processed by their inference infrastructure, and may be logged at various points in their system. The BAA makes the provider contractually responsible for protecting it. It does not make the transfer not happen. For workloads where the architectural requirement is that ePHI never reaches a third-party system, a BAA is insufficient. Full stop.

88% of healthcare organizations have adopted cloud-based generative AI, but 96% use tools that leverage user data for training. That is a direct conflict with HIPAA's minimum necessary standard (Sprypt, 2025). A lot of those organizations have BAAs.

the model training gap: does your vendor's BAA address fine-tuning on your data?#

Read the BAA for explicit language about whether ePHI can be used for model training or fine-tuning, whether it is retained in any form after processing, whether it is logged for debugging or monitoring, and what data retention policies and deletion procedures look like.

Many BAAs prohibit training but are silent on retention and logging. "Not used for training" is not the same as "not retained." Logs that persist your ePHI for 90 days for debugging create an exposure window that the BAA may not address.

the right questions to ask any AI vendor before sending patient data#

1. Does your BAA cover all environments where our data is processed, including inference endpoints, logging systems, and monitoring infrastructure?
2. Is our ePHI used for model training, fine-tuning, or evaluation? Under what circumstances?
3. Where is our data retained after processing, and for how long?
4. Does our data transit any subcontractor infrastructure not covered by the BAA?
5. How do you handle a breach notification under HIPAA's 60-day requirement?
6. What encryption standards apply to our data at rest and in transit?

Get specific answers in writing. Vague assurances do not survive an OCR audit.

the 2025 HIPAA Security Rule update: what changed#

the NPRM published January 6, 2025: removing "required" vs. "addressable"#

On January 6, 2025, HHS OCR published a Notice of Proposed Rulemaking that changes the Security Rule's implementation structure fundamentally. The existing Rule divides specifications into "required" (must implement) and "addressable" (implement or document why not). The NPRM eliminates this distinction. All specifications become mandatory.

The final rule is expected in late 2025 or 2026. Treat the NPRM's requirements as the upcoming compliance floor.

MFA is now mandatory for all systems accessing ePHI, internal and remote#

Previously, MFA was required for remote access but "addressable" for internal access. Under the proposed update, MFA is required for all workforce members accessing ePHI, whether they are connecting remotely or from within the facility network.

For AI systems, this affects any administrative interface, developer access, or operational tool that touches ePHI. Your self hosted inference server, your n8n workflow automation, your monitoring dashboard: if it touches ePHI, MFA on every access path is now mandatory.

encryption standards: AES-256 at rest, TLS 1.3 in transit#

The proposed rule specifies AES-256 for data at rest and TLS 1.3 for data in transit. These replace the previously addressable encryption specifications with defined standards.

Model weights and data stored locally must be encrypted at rest. API calls between components (voice agent to workflow automation to EHR) must use TLS 1.3. Older TLS versions are not compliant.

vulnerability scanning every six months; penetration testing annually#

Both were previously addressable. Both become mandatory under the proposed update. Vulnerability scanning covers all systems that create, receive, maintain, or transmit ePHI, every six months. Penetration testing is annual, with remediation of identified vulnerabilities required.

For AI system deployments, your inference infrastructure, workflow automation layer, EHR integration points, and any supporting systems that handle ePHI are in scope for both.

penalty exposure: up to $2 million per year per violation category#

HIPAA violation penalties as of 2025 range from $13,785 per unknowing violation to $63,973 per willful neglect violation not corrected, with an annual cap of $2 million per violation category (HHS, 2025). A breach affecting thousands of patients is a realistic scenario for any AI system touching appointment data or clinical records, and the resulting penalties can easily exceed the cost of compliant architecture.

2024 was the worst year on record for healthcare data breaches: 276.8 million records, a 64.1% increase over 2023 (HIPAA Journal, 2024). That is a lot of records from organizations that presumably thought they had adequate controls.

cloud AI vs. self-hosted AI: the architectural decision#

where cloud AI creates HIPAA risk even with a signed BAA#

When your AI system sends ePHI to a cloud API for processing, you have created a data exposure event regardless of the contractual protections in place. The data transited the provider's network. Their infrastructure processed it. Logs may have retained it. Subcontractors (model providers, infrastructure vendors) may have touched it.

The BAA assigns liability for these exposures. It does not prevent them. For organizations where the audit standard is "ePHI never left our environment," cloud AI with a BAA does not satisfy that standard. Not in theory, and not in practice.

what self-hosted inference actually means: Ollama, vLLM, and the inference layer#

Self-hosted AI inference means running the language model on your own infrastructure, inside your network perimeter. The model runs on hardware you control. The ePHI in the prompt and the generated output never leave your environment.

A production-ready self-hosted AI stack typically uses:

• Ollama: for single-user, small-team, or local development deployments
• vLLM: for high-throughput production inference with concurrent users
• Open WebUI: for user-facing interfaces with access controls and conversation history

A self-hosted stack starting at $8,000-$15,000 compares to $50,000+ annually in per-seat cloud AI licensing for comparable capacity at many healthcare organizations (Petronella Tech / premai.io, 2025).

For regulated healthcare deployments, self-hosted infrastructure is the only architecturally defensible option when your compliance requirement is that ePHI stays inside your environment. Cloud AI with a BAA cannot satisfy that requirement. That is a structural limitation, not a vendor-specific one.

when cloud AI with a BAA is defensible, and when it is not#

Cloud AI with a proper BAA is defensible when your AI workload touches de-identified data (HIPAA Safe Harbor or Expert Determination), the BAA explicitly addresses inference endpoint data handling, training exclusions, and log retention, and you have documented a risk analysis that identifies and accepts the residual exposure.

It is not defensible when your auditors require architectural proof that ePHI did not leave your network, when your BAA is silent on inference endpoint logging and data retention, when your AI vendor is using subcontractors whose data handling the primary BAA does not cover, or when you are processing highly sensitive clinical data subject to additional protection requirements beyond base HIPAA: mental health records, HIV status, substance use treatment.

the 44% enterprise privacy barrier: why organizations choose on-premise#

44% of enterprises cite data privacy and security as the top barrier to LLM adoption (Kong Enterprise AI Report, 2025). In healthcare, that barrier is regulatory, not philosophical. Self-hosted AI deployment grew 38% year over year between 2024 and 2025, driven by data sovereignty and regulatory requirements (IDC, 2025). Organizations that have been through an OCR audit tend to make different architecture decisions than ones that have not.

how to build a HIPAA-compliant AI system: the technical stack#

start by mapping every AI touchpoint that processes ePHI#

Before you can fix anything, you need to know where ePHI enters, moves through, and exits your AI systems. That means mapping voice AI agents that collect patient information, workflow automation systems that receive and process call transcripts, integration middleware between the AI layer and the EHR, monitoring and logging systems that capture execution data, and any LLM APIs that receive prompts containing ePHI.

For each touchpoint: what data does it process, who controls the infrastructure, what BAA coverage exists, and what is the data retention policy. Write this down. It is your evidence base.

audit BAA coverage: what each vendor explicitly excludes#

Read every BAA line by line. Note what is explicitly excluded or silent. Common exclusions include data used for model improvement (often listed outside the BAA's scope), logging and monitoring systems operated by subcontractors, inference infrastructure shared with other customers, and data retained for debugging purposes.

Where your BAA is silent, assume no protection. Ask your vendor for explicit clarification in writing before treating the coverage as complete.

apply the mandatory 2025 Security Rule controls#

For every system that processes ePHI: AES-256 encryption at rest on all stored data including model outputs, logs, and cached responses; TLS 1.3 on all network communication between components; MFA on all access paths including developer access, administrative interfaces, and operational dashboards; and immutable audit logs of all ePHI access events with six-year retention.

These are no longer advisory. Under the proposed NPRM, they are mandatory.

implement role-based access#

Access to ePHI should follow the principle of least privilege. The voice agent has access to scheduling data. It does not have access to clinical notes. The workflow automation layer has access to call transcripts. It does not have access to billing records. The inference layer processes prompts. It does not retain them.

Audit logs must capture who accessed what data, when, what actions were taken, and what system component executed the access. Logs must be immutable, not modifiable or deletable by the systems they monitor. If the system that generates a log can also delete it, the log is worthless in an audit.

network segmentation and inference layer isolation#

For self-hosted inference, the model inference layer should be network-segmented from other systems. Inference requests come from authorized internal systems only. The inference server has no public network exposure.

For cloud AI deployments with BAAs: review the network path. If your ePHI traverses the public internet before reaching a HIPAA-eligible endpoint, that transit is a compliance gap regardless of the destination's BAA status.

document your risk analysis for each AI system#

HIPAA requires documented risk analysis. For AI systems, this means documenting what ePHI the system processes and in what volume, what threats and vulnerabilities it creates, what controls address those threats, what residual risk remains after controls are applied, and whether that residual risk is acceptable.

This documentation is what survives an OCR audit. The architecture you built matters, but the documentation that proves it is what actually gets evaluated.

the use cases that carry the most risk#

clinical documentation and ambient note-taking#

AI ambient documentation systems process everything said in a clinical encounter. That is the most sensitive ePHI that exists. These systems require the most rigorous architecture: self-hosted inference, explicit exclusions from any training pipeline, minimum retention, and strict access controls. There is no version of this use case where a cloud API with a BAA is the right answer.

prior authorization workflows that read and write to the EHR#

Prior authorization AI reads clinical records, insurance eligibility data, and treatment plans. It writes authorization requests and decisions back to the EHR. Every read and write is an ePHI access event. The integration surface is large, the data sensitivity is high, and the audit trail requirements are strict.

voice AI for patient scheduling and triage#

A voice AI agent that books appointments touches ePHI in the demographic and insurance data it collects. A triage agent that assesses symptoms touches highly sensitive clinical ePHI. The compliance architecture for these two use cases differs considerably: the triage agent requires more rigorous controls on data retention, access, and inference layer isolation.

For more on voice AI for healthcare, see Voice AI Agents for Healthcare.

medical coding and NLP-assisted billing#

AI that processes clinical documentation to generate billing codes touches the full clinical record. Errors carry both compliance risk (incorrect billing is a separate regulatory exposure) and HIPAA risk (broad access to clinical records creates a large attack surface).

how to audit your current AI setup for HIPAA gaps#

Work through these questions for each AI system in your environment:

1. Does this system create, receive, maintain, or transmit ePHI? If yes, it is in scope for HIPAA.
2. Is there a signed BAA with every vendor whose infrastructure processes this ePHI?
3. Does the BAA explicitly address inference endpoint data handling, training exclusions, and log retention?
4. Is AES-256 encryption applied to all ePHI at rest in this system?
5. Is TLS 1.3 applied to all ePHI in transit between components?
6. Is MFA required for all access to this system?
7. Are audit logs implemented and retained for six years?
8. Has this system been included in your last vulnerability scan?
9. Has this system been in scope for your last penetration test?
10. Does the system documentation support a defensible risk analysis?

67% of healthcare organizations reported being unprepared for the stricter security standards in the 2025 HIPAA Security Rule update (Sprypt, 2025). Working through this list for your current AI systems will surface the gaps before an audit or incident does.

FAQ#

Does a signed BAA make an AI tool HIPAA compliant? No. A BAA assigns liability. It does not implement technical safeguards, and it does not stop your data from transiting a vendor's inference infrastructure. Many BAAs cover the vendor's infrastructure without restricting how your data moves through their model inference endpoints or whether it can be used in training pipelines. You must audit the BAA language, not just confirm it exists.

Can you use cloud-based AI tools with patient data if the vendor signs a BAA? It depends on what the BAA specifies about data retention, model training, and inference routing. If ePHI transits a shared inference endpoint or is retained for model improvement without explicit scope restrictions, a signed BAA does not prevent a Security Rule violation. The safest configuration routes ePHI only through dedicated, isolated instances with zero data retention and explicit training exclusions.

What is the difference between HIPAA eligible and HIPAA compliant for AI? HIPAA eligible means the vendor will sign a BAA. HIPAA compliant means the AI system's architecture, access controls, encryption, and audit logging satisfy the Security Rule's technical safeguards. Eligibility is a legal agreement. Compliance is an architectural and operational state. Vendors can be eligible without your deployment being compliant.

Do self-hosted AI models need to comply with HIPAA? Yes. Self-hosting eliminates third-party data transfer risk, but the system itself must still satisfy HIPAA's Security Rule: encryption at rest and in transit, MFA, access controls, audit logging, and network segmentation. Self-hosting is the prerequisite for HIPAA compliance in high-risk AI workloads, not a substitute for the compliance controls themselves.

What changed in the 2025 HIPAA Security Rule update? On January 6, 2025, HHS OCR published a Notice of Proposed Rulemaking eliminating the "required vs. addressable" distinction from the Security Rule. All implementation specifications become mandatory: MFA for all systems accessing ePHI, AES-256 encryption at rest, TLS 1.3 in transit, vulnerability scanning every six months, and annual penetration testing. The final rule is expected late 2025 or 2026.

What HIPAA penalties apply to AI-related breaches? As of 2025, HIPAA violation penalties range from $13,785 per violation for unknowing violations to $63,973 per violation for willful neglect not corrected, with an annual cap of $2 million per violation category (HHS, 2025). A breach affecting thousands of patients can result in penalties that far exceed the cost of compliant architecture, which is usually the point that gets attention after the fact.

Not sure if your current AI setup is HIPAA-defensible? Silverthread Labs audits healthcare AI stacks and gives you a clear picture of what needs to change: BAA coverage gaps, infrastructure configuration issues, and security controls that do not meet the 2025 standard.

Book a Free Audit