In this article
Key takeaways
- HIPAA does not regulate AI as a category. It regulates PHI, and an AI system handling PHI inherits every existing obligation.
- AI creates new places for PHI to live: prompts, retrieval indexes, embeddings, model outputs, evaluation sets and logs. Each one needs the same safeguards as your EHR data.
- The Security Rule’s technical safeguards (45 CFR 164.312) map directly to AI engineering work: identity, audit, integrity, authentication and transmission security.
- The proposed Security Rule update from January 2025 is not final, but its direction (required encryption, MFA, asset inventories, regular testing) is where to build now.
- Tools help only inside a design. Choose by category and fit, and confirm every vendor that touches PHI will sign a BAA.
What HIPAA-compliant AI means
HIPAA-compliant AI is an AI system deployed so that the protected health information it touches is used, disclosed and secured as the HIPAA Privacy, Security and Breach Notification Rules require. It needs BAAs with every vendor handling PHI, administrative, physical and technical safeguards, minimum necessary data use, and a documented risk analysis.
Two consequences follow. First, “HIPAA-compliant AI” describes a deployment, not a product. A model provider can offer HIPAA-eligible services and sign a BAA; whether a given use is compliant depends on the organization running it. Second, the AI label does not change which rules apply. The same rules that govern an EHR or a patient portal govern a chatbot, an ambient scribe or a coding agent, as soon as PHI is involved.
If you are evaluating specific products, our comparison of which ChatGPT, Claude and Gemini offerings come with a BAA covers that. This guide is about what any AI system needs around it.
identifiers removed under the Safe Harbor de-identification method
45 CFR 164.514(b)(2)outer limit to notify affected individuals after discovering a breach
45 CFR 164.404(b)retention for required HIPAA documentation, including policies and risk analyses
45 CFR 164.316(b)(2)Which HIPAA rules apply to AI
Three HIPAA rules do most of the work. Two newer federal requirements sit alongside them for specific AI uses.
| Rule | What it governs | What it means for AI |
|---|---|---|
| Privacy Rule45 CFR 164 Subpart E | When PHI may be used or disclosed, minimum necessary, patient rights | Whether a given AI use of PHI is permitted at all, how much data a prompt may carry, and whether training or fine-tuning on PHI is allowed for your purpose |
| Security Rule45 CFR 164 Subpart C | Administrative, physical and technical safeguards for ePHI | Access control, audit logging, integrity, authentication and transmission security for every component that stores or processes ePHI |
| Breach Notification Rule45 CFR 164 Subpart D | Assessing and reporting breaches of unsecured PHI | AI-specific incidents, such as an output exposing another patient’s data or PHI pasted into an uncovered tool, must go through breach assessment |
| Section 155745 CFR 92.210 | Nondiscrimination in patient care decision support tools | Covered entities must make reasonable efforts to identify and mitigate discrimination risks in AI and other decision support tools (in effect since May 2025) |
| ONC HTI-145 CFR 170.315(b)(11) | Transparency for decision support in certified health IT | Applies to certified EHR developers’ AI features. ONC proposed in December 2025 to remove its AI “model card” requirements; that proposal was not final as of October 2026 |
For a closer look at how the first two rules divide responsibilities, see our explainer on the HIPAA Privacy Rule vs Security Rule.
The Security Rule update is proposed, not finalIn January 2025, HHS proposed the largest revision of the Security Rule since 2013. It would remove the distinction between required and addressable specifications, require encryption at rest and in transit and multi-factor authentication with limited exceptions, require an asset inventory and network map at least every 12 months, vulnerability scans every six months and penetration tests every 12 months, and restoration of critical systems within 72 hours. As of October 2026 it has not been finalized; the federal regulatory agenda lists final action for July 2027, and HHS states the current rule remains in effect. We recommend building to the proposal anyway, because most of it is already standard practice for AI systems.
Where PHI lives in an AI system
The first requirement of any risk analysis is knowing where ePHI is. AI systems scatter it into places a traditional application inventory misses.
Prompts and context
Everything sent to the model, including retrieved records and system instructions that embed patient details.
Model outputs
Summaries, drafts and answers are new PHI the moment they describe a patient.
Retrieval stores
Vector databases and their embeddings. Embeddings of PHI should be treated as PHI.
Logs and telemetry
Application logs, traces, error reports and analytics that capture request bodies.
Evaluation and training sets
Test cases, fine-tuning data and annotated examples copied from real conversations.
Vendor-side storage
Provider retention for abuse monitoring, stored conversation state, uploaded files and caches.
De-identification takes data out of HIPAA’s scope when done to the standard. The Safe Harbor method removes 18 categories of identifiers, including names, geographic units smaller than a state, all dates except year, contact details, record and account numbers, device identifiers, URLs, IP addresses, biometrics and full-face photos, and requires that you have no actual knowledge the rest could identify someone. The alternative is Expert Determination. Simply deleting names is neither. Our PHI de-identification team works with both methods.
Administrative, physical and technical safeguards, mapped to AI
The Security Rule organizes its requirements into three families. Here is what each looks like for an AI system rather than a generic application.
- Risk analysis and managementInclude the AI system, its vendors and every data store before go-live.
- Assigned security responsibilityNamed owners for the AI system, not just the platform.
- Workforce trainingWhat may be entered into which tools, and how to report problems.
- Business associate contractsBAAs with model, cloud, voice and logging vendors.
- Contingency planWhat happens when the model or a vendor is unavailable.
- Facility accessUsually inherited from your HIPAA-eligible cloud provider; confirm it is in their attestations.
- Workstation use and securityDevices staff use to access AI tools, including personal phones.
- Device and media controlsDisposal of exported transcripts, datasets and local model files.
- Self-hosted modelsOn-premises GPUs holding PHI need the same physical controls as servers.
- Access controlUnique IDs, emergency access, logoff, encryption.
- Audit controlsRecord activity in systems holding ePHI, including model calls and actions.
- IntegrityProtect ePHI from improper alteration, including by an agent’s writes.
- AuthenticationVerify the person or system behind each request.
- Transmission securityProtect ePHI in transit to and from model providers.
HIPAA technical safeguards for AI, in detail
This is where most engineering effort goes. Under the current rule, some implementation specifications are required and others addressable, which means you implement them if reasonable and appropriate or document an equivalent alternative. Addressable never means optional.
| Standard | Specification | For an AI system |
|---|---|---|
| Access control164.312(a) | Unique user identification Required Emergency access procedure Required Automatic logoff Addressable Encryption and decryption Addressable | Every request tied to one identity. Authorization checked in code before each retrieval and tool call. Encryption of transcripts, vector stores and caches. |
| Audit controls164.312(b) | Record and examine activity Required | Log user, patient record, action, model and prompt version, guardrail outcome and result. Keep message bodies out of general logs. |
| Integrity164.312(c) | Protect from improper alteration Required Authentication mechanism Addressable | Agents write through validated APIs with confirmation; outputs written to records are attributable and reviewable. |
| Person or entity authentication164.312(d) | Verify identity Required | Patients authenticated through the portal, staff through SSO with MFA, services through managed identities, not shared keys. |
| Transmission security164.312(e) | Integrity controls Addressable Encryption Addressable | TLS 1.2+ on every hop, including to the model provider, EHR APIs and between internal services. |
Required and addressable labels reflect the current rule as of October 2026. The 2025 proposed rule would make all specifications required, with limited exceptions.
BAAs and the AI vendor chain
An AI system usually involves more business associates than teams expect. A patient-facing voice assistant might touch a telephony provider, a speech-to-text service, a model provider, a cloud host, an observability tool and a support desk. Each one that receives PHI needs a BAA, and each BAA covers specific products.
Three points that matter specifically for AI:
- Feature-level scope. AI vendors increasingly list covered and excluded features. Live web search, beta tools, connectors and some APIs are common exclusions.
- Retention conditions. Some providers require specific retention arrangements for BAA coverage. Your retention policy has to account for theirs.
- Downstream subcontractors. If a model is accessed through a platform or reseller, find out whose BAA covers it and whether the model developer ever sees the data.
Provider-by-provider details are in part 2, Is ChatGPT, Claude or Gemini HIPAA compliant? To keep the agreements themselves in order, see our BAA and vendor risk management service.
What HIPAA doesn’t spell out, but AI systems need
HIPAA is technology-neutral, so it says nothing about hallucinations, prompt injection or model drift. These controls come from security practice and AI risk frameworks rather than the regulation, but a risk analysis that ignores them is not “accurate and thorough.”
Guardrails
Input screening, grounding checks, PHI leakage checks and tool-call validation around the model. The OWASP Top 10 for LLM Applications is a good threat list to test against.
Human oversight
Defined review points for each kind of output, and deterministic routing of urgent situations to people.
Fairness
For decision-support uses, Section 1557 requires reasonable efforts to identify and mitigate discrimination risk.
Governance framework
The NIST AI Risk Management Framework gives structure for mapping, measuring and managing AI risk beyond privacy. Our post on enterprise AI governance covers how to apply it.
How these fit into an actual build, from the orchestrator that enforces policy to the evaluation suite that runs on every change, is covered in part 1: how to build a HIPAA-compliant AI chatbot or agent.
The HIPAA-compliant AI checklist
Use this for any AI system that will touch PHI, whether you are buying it or building it. Tick items as you confirm them (progress is saved in this browser only), or print it to work through on paper.
HIPAA-compliant AI checklist · Bonami Software · bonamisoftware.com/blog-hipaa-compliant-ai
Governance and risk
Vendors and BAAs
Data and minimum necessary
Identity and access
Encryption and infrastructure
Logging and monitoring
AI model and guardrails
Testing and incident response
A checklist is a summary, not a substitute for the risk analysis it points to. HHS and ONC publish a free Security Risk Assessment Tool for smaller organizations, and NIST SP 800-66 Revision 2 is the detailed implementation guide for the Security Rule. For a structured review of an AI system specifically, our HIPAA risk assessment team can help.
HIPAA-compliant AI tools and technology stack
Lists of “HIPAA-compliant AI tools” usually mix finished apps with infrastructure and say little about how the parts fit. A more useful view is the stack: the categories of technology every compliant AI system needs, with the questions that matter in each. Vendor names are examples, not endorsements, and every vendor that touches PHI still needs a BAA for the specific service.
Identity and accessWho is asking, and what may they touch
Single sign-on with MFA for staff, patient identity from your portal, and fine-grained authorization the AI layer cannot bypass.
Encryption and key managementProtect data at rest and in transit
Managed key services with logged access, TLS everywhere, and encryption for every store an AI system adds.
Cloud infrastructureWhere PHI-handling components run
Use only services on your provider’s HIPAA-eligible list, under its BAA. All three major clouds publish one.
Healthcare APIs and FHIRStandard access to clinical data
FHIR R4 APIs for reads and writes, with US Core profiles, so the AI reads from the record instead of keeping a copy.
EHR integrationConnecting to the systems of record
Vendor FHIR APIs where available, interface engines for HL7 v2 feeds, and monitoring for failed or delayed messages.
AI and LLM layerThe model, hosted where a BAA covers it
Models through a provider API or cloud AI service under BAA, or self-hosted open models on controlled infrastructure.
Guardrails and data protectionChecks before and after the model
PHI detection and redaction, prompt-injection screening, grounding checks and schema validation for agent actions.
Retrieval and storageGrounding data and conversation state
Vector stores and databases on HIPAA-eligible services, with per-patient filtering, encryption and retention jobs.
Logging, monitoring and SIEMAudit trails and detection
Structured audit events for access and actions, PHI-safe application logs, and alerting on unusual patterns.
Testing and evaluationProving it behaves before and after release
Evaluation suites with clinician review, red-team and prompt-injection tests, and conventional security testing.
Compliance operationsKeeping the paperwork true
Risk register, BAA inventory, policy management, training records and evidence collection for audits.
Incident responseWhen something goes wrong
Runbooks that include AI scenarios, breach risk assessment and notification workflows with clear owners.
Layers run from identity (L1) up to compliance operations and incident response (L6). Notice that the model is one tile out of twelve. Our guides to HIPAA cloud infrastructure, FHIR data exchange and LLM evaluation go deeper on individual layers, and our FHIR integration and Epic integration teams build the interoperability layer.
Risk analysis and incident response for AI
A risk analysis for an AI system follows the same method as any other: inventory where ePHI is created, received, maintained or transmitted, identify threats and vulnerabilities, assess likelihood and impact, and document the controls. What changes is the list of threats. Add these to yours:
| AI-specific threat | Example | Primary controls |
|---|---|---|
| Cross-patient exposure | Retrieval returns another patient’s note into an answer | Per-patient filters, authorization before retrieval, leakage checks |
| Prompt injection | Text in an uploaded document instructs the agent to reveal data | Input screening, tool allow-lists, policy checks outside the model |
| Uncovered disclosure | Staff paste PHI into a consumer AI app | Approved tools, policy, training, network or DLP controls |
| Out-of-scope feature | An enabled web search or connector sends PHI outside the BAA | Feature-level BAA review, disable or block exclusions |
| Wrong action | An agent reschedules or messages the wrong patient | Confirmation, idempotent writes, action-level audit, rollback |
| Silent behavior change | A model update changes answers without notice | Version pinning, regression evaluation, monitoring |
When something does go wrong, the Breach Notification Rule applies unchanged. An impermissible use or disclosure of PHI is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI was compromised. Where notification is required, individuals must be told without unreasonable delay and no later than 60 days after discovery, with additional reporting to HHS and, for larger breaches, the media. Make sure your incident response plan names who assesses AI-related incidents and how logs will be used to reconstruct what the system did.
Frequently asked questions about HIPAA-compliant AI
What is HIPAA-compliant AI?
HIPAA-compliant AI is an AI system deployed so that any protected health information it handles is protected as the HIPAA Privacy, Security and Breach Notification Rules require. That means signed Business Associate Agreements with every vendor that touches PHI, administrative, physical and technical safeguards around the system, minimum necessary use of data, and a documented risk analysis. It describes a deployment, not a product.
Is AI prohibited by HIPAA?
No. HIPAA does not prohibit AI or mention it specifically. It regulates how covered entities and business associates use and disclose PHI and how they protect electronic PHI. An AI system that handles PHI must meet the same rules as any other system, including a BAA with the AI vendor and appropriate safeguards.
Which AI tools are HIPAA compliant?
No AI tool is compliant on its own. Several providers offer HIPAA-eligible products with a BAA, including specific OpenAI, Anthropic and Google business offerings and AI services on AWS, Microsoft Azure and Google Cloud. Consumer AI apps generally are not covered. Coverage depends on the exact product, features and configuration.
What are the HIPAA requirements for AI systems?
The core requirements are a BAA with each vendor handling PHI, a risk analysis that includes the AI system, access controls with unique user IDs, audit controls, integrity protections, person or entity authentication, transmission security, encryption where reasonable and appropriate, minimum necessary use, workforce training, and breach notification procedures. AI adds practical requirements around prompts, logs, retrieval stores and model outputs.
Does HIPAA require encryption for AI systems?
Under the current Security Rule, encryption at rest and in transit are addressable implementation specifications: you must implement them if reasonable and appropriate, or document why not and what you do instead. In practice, encryption is expected for AI systems handling ePHI. HHS proposed in January 2025 to make encryption required with limited exceptions, but that rule was not final as of October 2026.
Do AI vendors need to sign a BAA?
Yes, if they create, receive, maintain or transmit PHI on your behalf. That includes model providers, cloud hosts, transcription and voice vendors, and any logging or analytics service that receives PHI. HHS guidance says a cloud provider storing encrypted ePHI is still a business associate even without the encryption key.
Can PHI be used to train or fine-tune an AI model?
Only if the use is permitted under the Privacy Rule for your purpose and your agreements allow it, including the vendor BAA. Many organizations de-identify data first using the Safe Harbor method, which removes 18 identifiers, or Expert Determination. Check that the vendor’s BAA covers fine-tuning before sending PHI to any training endpoint.
How often should a HIPAA risk analysis cover AI?
HIPAA requires an accurate and thorough risk analysis and periodic review. Update it before an AI system goes live with PHI and whenever it changes materially, such as a new model, vendor, data source or capability. The January 2025 proposed rule would set a minimum of every 12 months, but it is not yet final.
The takeaway
HIPAA-compliant AI is not a special category of technology. It is the familiar discipline of protecting PHI, applied to a system with more places for data to hide and more ways to act on it. Find every place PHI lives, put a BAA behind every vendor that touches it, map the safeguards to each component, and test the AI-specific failure modes. The checklist above is a good place to start, and a good thing to revisit every time the system changes.
Need a second pair of eyes on an AI system?
We review and build healthcare AI systems against these requirements: risk analysis, BAA scope, architecture, integrations and testing.
Sources
- eCFR: 45 CFR Part 164, Subpart C (Security Standards)
- eCFR: 45 CFR 164.514 (de-identification)
- eCFR: 45 CFR 164.404 (notification to individuals)
- HHS: HIPAA Security Rule notice of proposed rulemaking
- HHS: Security Rule NPRM fact sheet
- Reginfo.gov: RIN 0945-AA22 regulatory agenda entry
- HHS: Guidance on HIPAA and cloud computing
- eCFR: 45 CFR 92.210 (patient care decision support tools)
- Federal Register: ONC proposed rule, December 29, 2025
- NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule
- NIST AI Risk Management Framework
- OWASP Top 10 for LLM Applications
This article is general guidance, not legal advice. Regulatory status reflects the eCFR, HHS and the Federal Register as of October 5, 2026. Your obligations depend on your role and data flows; involve your privacy and security officers and counsel.
