HIPAA and AI: How HIPAA Applies to Building, Buying, and Using AI
HIPAA has no AI-specific provisions, so it governs AI through the rules that already apply to protected health information (PHI) at each stage of an AI system's life. Building or tuning a model on PHI needs a permitted purpose: health care operations, research under an authorization or waiver, or de-identification under 45 CFR 164.514. Buying an AI tool that receives PHI makes the vendor a business associate, and the business associate agreement (BAA) decides whether the vendor may train on that data, how long it keeps it, and which subcontractors see it. Using the tool brings it inside the Security Rule's risk analysis, access controls, and audit controls. Beside HIPAA sit rules written with algorithms in mind, including the Section 1557 rule on patient care decision support tools, ONC's HTI-1 criterion for certified health IT, and state AI laws.
Which rules sit beside HIPAA for health care AI?
HIPAA governs the data. The rules below govern what an algorithm may do with it, who must be told, and who makes the final decision. Each row reflects the rule's status as of October 23, 2026.
| Rule | Who it covers | What it requires for AI | Status |
|---|---|---|---|
| Section 1557, 45 CFR 92.210 | Health programs receiving federal financial assistance, HHS, and ACA exchanges | No discrimination through patient care decision support tools; reasonable efforts to identify tools that use race, color, national origin, sex, age, or disability as inputs and to mitigate the risk | Identification and mitigation duties have applied since May 1, 2025 |
| ONC HTI-1, 45 CFR 170.315(b)(11) | Developers of certified health IT | Source attributes users can review for decision support interventions; risk management for predictive ones the developer supplies | In the eCFR as of October 2026 |
| FTC Health Breach Notification Rule, 16 CFR Part 318 | Vendors of personal health records and related entities outside HIPAA, including apps | Notice to individuals within 60 days of discovering a breach, which includes an unauthorized disclosure, plus notice to the FTC | Amended in 2024 |
| Medicare Advantage, 42 CFR 422.101(c) | Medicare Advantage organizations | Medical necessity decisions based on the enrollee's medical history, physician recommendations, and clinical notes | In effect |
| FDA device rules | Software that analyzes medical images or signals, or whose basis clinicians cannot independently review | Device regulation unless the software meets all four non-device criteria in FD&C Act section 520(o)(1)(E) | Current CDS guidance issued January 2026 |
| State AI laws | Providers, health plans, and utilization review agents in California, Texas, and Illinois, among others | Patient disclosures, physician medical necessity decisions, limits on automated denials and on AI in therapy | Effective dates from 2025 to 2027; details below |
Can you use PHI to build or tune an AI model?
Yes, when the use fits a permitted purpose, and the purpose decides the conditions. Training a model to support your own organization's care or operations can fall under health care operations, which 45 CFR 164.501 defines to include quality assessment and improvement activities, outcomes evaluation, and the development of clinical guidelines, provided that obtaining generalizable knowledge is not the primary purpose. Once the goal is generalizable knowledge, such as a model you plan to publish or license to others, the project meets the definition of research: "a systematic investigation, including research development, testing, and evaluation, designed to develop or contribute to generalizable knowledge." Research use needs each individual's authorization under 164.508 or a waiver or alteration approved by an institutional review board or privacy board under 164.512(i).
Two data options reduce the burden. De-identified data under 164.514(b) is not PHI at all, whether it meets Safe Harbor's removal of 18 identifiers or an expert's documented determination that the risk of identification is very small. A limited data set under 164.514(e) strips 16 direct identifiers but may keep dates, city, state, and ZIP code, so it remains PHI and may be used only for research, public health, or health care operations under a data use agreement that bars re-identifying or contacting the individuals. The minimum necessary standard applies to operations uses, so a tuning project should take only the fields the model needs. Whether a project is operations or research is a call for your privacy officer and counsel, and it should be recorded before training starts.
Can an AI vendor train its own models on your PHI?
Only to the extent the BAA allows, and the BAA cannot allow more than the covered entity could do itself. Under 45 CFR 164.504(e)(2)(i), a BAA may not authorize the business associate to use or disclose PHI in a way that would violate the Privacy Rule if the covered entity did it, with two exceptions: the vendor's own proper management and administration under 164.504(e)(4), and data aggregation services relating to the covered entity's health care operations. The business associate also may not use or disclose PHI other than as the contract permits or the law requires. Training a general-purpose model the vendor sells to other customers is hard to fit inside either exception, so treat any BAA clause that allows model training or product improvement with PHI as a question for counsel before you sign.
De-identification is the mechanism that could make vendor training permissible, and HHS's de-identification guidance says a business associate may de-identify PHI only to the extent its BAA authorizes it. A clause permitting de-identification for product improvement is therefore a decision the covered entity makes when it signs. Vendor policies help, and the contract still governs. OpenAI states that it does not train on business data by default and that content shared with ChatGPT for Healthcare is not used to train models, and Microsoft states that Azure OpenAI prompts and completions are not used to train the base models. Put the same commitment in the BAA or the underlying agreement, with retention and deletion terms that let you test it. Our article on whether ChatGPT is HIPAA compliant compares which AI vendors sign BAAs and for which products.
What should a BAA with an AI vendor cover?
The required terms in 164.504(e) apply to AI vendors like any other business associate, and six of them carry extra weight when the vendor runs a model.
| BAA term | Why it matters for AI | What to ask for |
|---|---|---|
| Permitted uses, 164.504(e)(2)(i) | Model training and product improvement are uses that need a lawful basis | An express prohibition on training with PHI, or a de-identification clause the covered entity approves |
| Retention, return, and destruction, 164.504(e)(2)(ii)(J) | Prompts, outputs, logs, and fine-tuning files persist where users never see them; OpenAI's API keeps abuse monitoring logs up to 30 days unless it approves zero data retention | A retention period for each data type and evidence of deletion at termination |
| Subcontractors, 164.504(e)(2)(ii)(D) | Model hosts, cloud providers, and annotation contractors may handle PHI | A current subcontractor list and the same restrictions flowed down to each |
| Breach and incident reporting, 164.410 | The rule allows up to 60 days after discovery for breach notice to the covered entity | A shorter notice period and a defined format for security incident reports, which HHS says a BAA may set |
| Data location | HHS permits storing ePHI outside the United States under a BAA and expects the risk analysis to account for the location | The regions where prompts are processed and data is stored |
| Feature scope | Vendors exclude features such as live web search from BAA coverage | A written list of covered and excluded features |
HHS's cloud computing guidance adds one more point: a cloud provider that stores only encrypted ePHI without the key is still a business associate, so an AI vendor cannot avoid a BAA by encrypting what it holds.
How does the Security Rule apply to AI systems?
The Security Rule applies to any AI system that creates, receives, maintains, or transmits electronic PHI, and four standards do most of the work. The risk analysis in 164.308(a)(1)(ii)(A) must cover the model, the prompts and outputs, the logs, any retrieval index built from PHI, and the integrations that move data in and out. Access control under 164.312(a)(1) requires unique user identification and limits on which roles and service accounts can query the tool. Audit controls under 164.312(b) require mechanisms that record and examine activity, which for AI means logging who prompted what, which records the tool retrieved, and what it wrote back. Integrity under 164.312(c)(1) requires protecting ePHI from improper alteration or destruction, which matters once an AI scribe or coding tool writes into the medical record.
The January 2025 proposal would make the inventory explicit. The notice of proposed rulemaking, published January 6, 2025 at 90 FR 898, would require a written technology asset inventory and network map reviewed at least every 12 months, and its preamble includes a request for information on artificial intelligence. Health law summaries of that section report HHS's view that ePHI in AI training data, prediction models, and algorithm data maintained by a regulated entity is protected by the Security Rule, and that AI software interacting with ePHI would belong in the inventory and the risk analysis. As of October 23, 2026 the proposal is not final: HHS says the current Security Rule remains in effect, and the Unified Agenda lists the rule among long-term actions with a final action date of July 2027. Our article on the HIPAA Security Rule update covers the full proposal.
Do patients have rights to AI outputs in their records?
Yes, once an output becomes part of the designated record set. The right of access in 164.524 and the right to request amendment in 164.526 reach the designated record set, which 164.501 defines as a provider's medical and billing records, a health plan's enrollment, payment, claims adjudication, and case or medical management records, and other records "used, in whole or in part, by or for the covered entity to make decisions about individuals." An AI-drafted note filed in the chart, a summary a clinician relied on, and a risk score used to manage a patient's care all fit that definition. Model weights, training sets, and aggregate analytics fall outside it unless they are used to make decisions about individuals. Decide in advance where AI outputs are stored and which become part of the record, because the first access or amendment request will test that decision.
What do Section 1557 and HTI-1 require for AI tools?
The Section 1557 rule at 45 CFR 92.210 applies to any "patient care decision support tool," which 92.4 defines as "any automated or non-automated tool, mechanism, method, technology, or combination thereof used by a covered entity to support clinical decision-making in its health programs or activities." The definition reaches non-automated tools as well as AI models. Covered entities may not discriminate on the basis of race, color, national origin, sex, age, or disability through these tools, must make reasonable efforts to identify uses of tools whose input variables measure those characteristics, and must make reasonable efforts to mitigate the risk of discrimination from each one. The final rule took effect July 5, 2024 and gave covered entities 300 days to meet the identification and mitigation duties, which have applied since May 1, 2025.
HTI-1 works from the vendor side. ONC's criterion at 45 CFR 170.315(b)(11) requires certified health IT to let a limited set of identified users review plain-language source attributes for evidence-based and predictive decision support interventions, including how inputs such as race, ethnicity, sex, and social determinants of health data are used, and requires developers to apply risk analysis, risk mitigation, and governance practices to the predictive interventions they supply. A health system can use those source attributes as the starting evidence for its 92.210 inventory. Neither rule decides whether software is a medical device; the FDA does, and its January 2026 clinical decision support guidance keeps software that analyzes medical images or signals within device regulation.
Which state AI laws apply to health care organizations?
State laws now add duties that apply whatever a vendor's HIPAA status. California's AB 3030, at Health and Safety Code 1339.75 since January 1, 2025, requires a disclaimer and instructions for reaching a human on generative AI patient communications about clinical information, unless a licensed or certified provider reads and reviews them. California's SB 1120 amended Health and Safety Code 1367.01 so that a health plan's AI or algorithm used in utilization review must base decisions on the enrollee's own clinical history and circumstances, may not rest solely on a group dataset, and may not deny, delay, or modify care for medical necessity; only a licensed physician or health care professional may make that determination.
Texas's H.B. 149 requires providers to disclose the use of AI in relation to a health care service or treatment by the date of service, effective January 1, 2026, and Texas's S.B. 815 bars utilization review agents from using an automated decision system to make an adverse determination for plans issued or renewed on or after January 1, 2026. Illinois's 225 ILCS 155 bars AI from therapeutic communication and independent therapeutic decisions in therapy services. Colorado's 2024 AI Act, SB 24-205, treated decisions about health care services and insurance as consequential decisions; according to the Colorado Attorney General, SB 26-189, signed in May 2026, repealed and reenacted it as a law on automated decision-making technology used in consequential decisions, effective January 1, 2027, so confirm with counsel how it will reach your tools. For consumer health apps outside HIPAA, the FTC's Health Breach Notification Rule treats an unauthorized disclosure as a breach that triggers notice.
How do the rules map to common health care AI uses?
Intake reviews go faster when each request starts from a map of the rules that usually apply. The figure gives that first pass for seven common uses.
Two patterns stand out. Every use that touches PHI needs a BAA, so the vendor contract is the first gate. The AI-specific rules cluster around tools that inform clinical or coverage decisions, such as imaging triage, predictive risk scores, and payer prior authorization tools. Coding assistance looks quiet on the map, yet the False Claims Act and the 60-day overpayment rule reach every claim it touches.
How do you govern AI under HIPAA in practice?
Governance turns these rules into one path from request to retirement. Six practices cover most of it, and each maps to the NIST AI Risk Management Framework's Govern, Map, Measure, and Manage functions and to ISO/IEC 42001's requirements for an AI management system.
- Keep an AI inventory of every model, feature, and vendor tool that touches PHI, including AI that vendors switch on inside software you already own and tools staff adopt on their own.
- Run intake and approval through one path, with risk tiers based on the data involved, the tool's role in care or coverage decisions, and its autonomy.
- Review the vendor and the BAA before PHI flows, using the six terms above.
- Update the HIPAA risk analysis for each approved tool, and record the Section 1557 identification and mitigation work for any tool that supports clinical decisions.
- Monitor and audit by sampling outputs for accuracy, reviewing access and audit logs, and tracking overrides, complaints, and incidents.
- Train the workforce on approved tools and data rules, and apply the sanction policy when people go around them.
Our guide to building an AI governance framework covers the sequence in more depth, and our comparison of ISO 42001 and the NIST AI RMF explains when a certifiable management system is worth the effort.
How BD Emerson helps
BD Emerson's healthcare AI governance team builds the AI inventory, reviews AI vendors and their BAAs, updates the HIPAA risk analysis for each tool, and maps each use to Section 1557, HTI-1, the FTC rule, CMS rules, and the state laws that reach it. For organizations that want a certifiable management system, our ISO 42001 consulting practice implements ISO/IEC 42001 and performs internal audits, and an accredited certification body issues the certificate. Your counsel makes the legal determinations and your clinical leaders make the clinical ones; we do not validate the clinical accuracy of models. Our healthcare cybersecurity guide covers the security program that AI governance depends on.
Frequently asked questions
Does HIPAA apply to AI? Yes, whenever an AI system creates, receives, maintains, or transmits protected health information for a covered entity or business associate. HIPAA has no AI-specific provisions, so the Privacy Rule governs permitted uses of PHI for training and operation, the business associate rules govern AI vendors, and the Security Rule requires the risk analysis, access controls, and audit controls to cover the AI system.
Is an AI vendor a business associate? Usually. A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate, and HHS guidance says a cloud provider remains one even if it stores only encrypted data without the key. The vendor needs a BAA before PHI flows, and its own subcontractors, such as model hosts, must accept the same restrictions.
Can we use patient data to train an AI model? Yes, with a permitted basis. Training for your own quality improvement or operations can qualify as health care operations if generalizable knowledge is not the primary purpose. Research use needs patient authorization or an IRB or privacy board waiver. De-identified data is not PHI, and a limited data set can be used under a data use agreement for research, public health, or operations. Document the basis before training starts.
What makes an AI tool HIPAA compliant? No vendor can make a tool compliant on its own, and HHS does not certify HIPAA compliance. A tool can be used compliantly when the vendor signs a BAA that covers the features you use, the tool appears in your risk analysis, access and audit controls are configured, and staff follow the minimum necessary standard. Ask each vendor in writing which features its BAA covers and which it excludes.
What does Section 1557 require for AI tools? The rule at 45 CFR 92.210 bars covered entities from discriminating on the basis of race, color, national origin, sex, age, or disability through patient care decision support tools, a term that covers AI models and non-automated tools. Since May 1, 2025, covered entities must make reasonable efforts to identify tools that use those characteristics as inputs and to mitigate the risk of discrimination from each one.
Does the HIPAA Security Rule update cover AI? The January 2025 proposed amendments were not final as of October 2026, and HHS says the current Security Rule remains in effect. The current rule already reaches AI systems that handle electronic PHI through the risk analysis, access control, audit control, and integrity standards. The proposal would add a written technology asset inventory, and summaries of its preamble say AI tools that touch ePHI would belong in it.
If you are approving AI tools that touch PHI or preparing for a regulator's or customer's questions about them, our healthcare AI governance team can build the inventory, review the vendors and their BAAs, and map each use to HIPAA and the rules beside it.
