Can you put patient data into that AI tool?

There is no HIPAA AI rule, and that is the whole point

The most common question in health care compliance right now is some version of whether a given AI product is HIPAA compliant. The question has no answer, because it is asking about the wrong object. HIPAA does not certify software. There is no approved-vendor list, no federal seal, no accreditation body that reviews a model and blesses it. A vendor page that says HIPAA compliant is a marketing statement about which nobody at HHS was consulted.

What HIPAA has instead is a set of definitions that were written in 2000 and amended in 2013, and they turn out to handle AI without much strain. The question is not what the technology is. The question is what it receives, who receives it, and on whose behalf. Answer those three and the obligations fall out mechanically.

That is genuinely good news for anyone trying to make a decision this quarter. You are not waiting for a regulator to tell you what the rules are. The rules are already written, and they already reach this.

Question one: is it protected health information at all

Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate, in any form or medium. If the tool never receives it, HIPAA has nothing to attach to and the analysis stops. Drafting a job posting, summarizing a vendor contract, generating marketing copy, or writing code against synthetic data is ordinary software use.

The trap is not the initial decision, which most organizations get right. The trap is drift. A tool approved for general administrative work is the tool people reach for when they are busy, and the appeal letter, the screenshot of tomorrow's schedule, and the spreadsheet with a free-text complaint column each turn an out-of-scope tool into a disclosure. The boundary has to be written down and trained on, because it will be tested weekly by people who are not thinking about the Privacy Rule.

The other exit is de-identification. Health information de-identified in accordance with 45 CFR 164.514(b) is not protected health information, and under 164.502(d)(2) the Privacy Rule's use and disclosure restrictions do not apply to it. No business associate agreement is required to send de-identified data to a model. This route is real, and it is also where teams overestimate themselves: OCR's guidance draws no distinction between structured fields and free text, and clinical narrative is dense with names of relatives and employers, dates, and identifying detail. A pipeline that clears columns and leaves the notes has not de-identified anything. Our de-identification checker walks the eighteen categories if you want to test a specific extract.

Question two: is the vendor a business associate

45 CFR 160.103 defines a business associate as a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information for a function or activity regulated by the rules. Nothing in that sentence cares about architecture. An ambient scribe that hears a room, a chatbot that reads a message thread, a coding assistant that ingests a chart, and an API call that sends a note for summarization all create, receive, or transmit PHI on behalf of a covered entity.

Once that is true, 45 CFR 164.502(e)(1)(i) sets the condition: a covered entity may disclose protected health information to a business associate only if it first obtains satisfactory assurances, in the form of a written contract, that the business associate will appropriately safeguard the information. 164.504(e)(2) specifies what that contract must contain. The word first is doing work there. A pilot on real charts, conducted while procurement catches up, is a disclosure that already happened.

Two arguments get raised at this point, and both usually fail. The first is that the vendor is a mere conduit. HHS guidance keeps that exception narrow: it covers entities acting as transmission channels, like the postal service, certain private couriers, and their electronic equivalents, where any storage is transient and incidental to the transmission. A service that runs inference over the content is not transmitting it. It is processing it. The second is that the data is encrypted or not retained. Both are safeguards, and safeguards are what the agreement is supposed to require. Neither removes the relationship.

The scope trap: the agreement you signed may not cover what you are running

This is the failure this checker was built around, because it is invisible from the inside. Vendors scope business associate agreements to a named service, a plan tier, a region, sometimes a specific model endpoint. Meanwhile the same company ships a consumer app, a free tier, a browser extension, and a stream of preview features. Staff reasonably assume that having a BAA with a company means having a BAA with everything the company makes. That assumption is wrong often enough to be the default thing to check.

Get the answer in writing, naming the product, the tier, and the endpoints. Then check it again when the vendor ships something new that your team starts using, because a feature released into preview is exactly the kind of thing that sits outside the executed agreement while feeling like part of the same product.

Model training on your inputs, and why it is usually a hard stop

A business associate may use or disclose protected health information only as its agreement permits or as required by law, under 45 CFR 164.504(e)(2)(i). The rule then carves out a short list of uses a business associate may make for its own purposes, at 164.504(e)(4): the proper management and administration of the business associate, carrying out its legal responsibilities, and data aggregation services relating to the health care operations of the covered entities it serves.

Training a general-purpose model that will then serve other customers is not on that list. It is a use for the vendor's own commercial benefit, and it is exactly the use that consumer terms of service reserve by default. If the vendor wants your patient data for model improvement, the lawful routes are de-identification under 164.514(b), which takes the data outside the Privacy Rule, or individual authorization under 164.508, which is impractical at scale. What you want in the contract is a plain statement that customer inputs and outputs are not used to train or improve models served to other customers, and you want it in the agreement rather than in a help center article that can be edited on a Tuesday.

The chain past your vendor

Most AI applications in health care are a thin layer over a model somebody else built, running on a cloud somebody else operates. That matters legally. Under 45 CFR 164.502(e)(2) a business associate must obtain satisfactory assurances, in writing, from any subcontractor that creates, receives, maintains, or transmits protected health information on its behalf, and 164.308(b)(2) says the same for the Security Rule. The subcontractor is itself a business associate under 160.103, with direct liability.

You are not required to hold agreements with your vendor's subcontractors. You are well advised to know who they are. Ask for the list in writing, ask whether each is under a written agreement covering PHI, and ask what happens if the vendor swaps model providers. That last question is where the honest answers get interesting, because model providers get swapped for cost and capability reasons on timelines that have nothing to do with your procurement cycle.

What changes if you run the model yourself, and what does not

Self-hosting is having a moment, and for the disclosure question it works. Members of the workforce are excluded from the business associate definition at 45 CFR 160.103. A model your own staff operate on infrastructure you control involves no disclosure to an outside party, so no business associate agreement is required.

Every other obligation stays exactly where it was, and a few get heavier. The risk analysis at 164.308(a)(1)(ii)(A) has to cover the new system. Access control at 164.312(a) and audit controls at 164.312(b) apply to it. The information system activity review at 164.308(a)(1)(ii)(D) should include it. And there is no vendor security team, no vendor patching schedule, and no vendor incident response. Teams that self-host to avoid the paperwork frequently discover they have traded a contract negotiation for an operational security program.

The five obligations that never transfer

This is the part that shows up in enforcement, because it is the part only you can produce. Signing a business associate agreement moves risk; it moves none of the following.

The risk analysis, at 164.308(a)(1)(ii)(A), requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all the electronic protected health information you create, receive, maintain, or transmit, followed by risk management under 164.308(a)(1)(ii)(B). Adding a system that processes charts and not reassessing is the most consistently cited failure in OCR enforcement. New tool, new analysis, at go-live rather than at the next annual cycle.

Minimum necessary, at 164.502(b) and 164.514(d), requires reasonable efforts to limit PHI to the minimum necessary to accomplish the purpose. Whole-record access is the fastest integration to configure and the hardest to defend afterward. Scope the connection to the encounters and fields the task needs.

Audit controls, at 164.312(b), require mechanisms that record and examine activity in systems containing electronic PHI. Without them you cannot investigate a report that someone pasted a chart into a browser tab, which means you cannot scope a breach risk assessment, which means you cannot demonstrate low probability of compromise when 164.414(b) puts the burden on you.

Workforce training, at 164.530(b)(1), and the security awareness program at 164.308(a)(5)(i), reach every member of the workforce as necessary and appropriate for their functions. If your policies now address AI tools, training on those policies is already required.

Sanctions, at 164.530(e)(1), require appropriate sanctions against workforce members who fail to comply with your policies. This is the one people skip, and it is the one that makes the policy mean anything. A written policy nobody was trained on and nobody enforces is a document, not a control.

Shadow AI is the failure that is actually happening

Every incident pattern described so far is a governance problem. The incident pattern that keeps occurring is simpler and more human. A nurse pastes a note into a free chatbot to turn it into plain language for a patient. A biller drops a denial letter in to draft an appeal. A manager summarizes a complaint thread. Nobody is being careless in their own mind. They are doing good work faster with the best tool available to them, which happens to be one nobody approved.

Under 45 CFR 164.402 an impermissible use or disclosure of PHI is presumed to be a breach unless you demonstrate a low probability of compromise through a four-factor risk assessment covering the nature and extent of the PHI, who received it, whether it was actually acquired or viewed, and the extent of mitigation. Documented either way.

The response that works has three parts and only one of them is a policy. Name the approved tools in writing. Train the workforce on the distinction, because a policy filed in a binder does not reach the person deciding at 4pm on a Friday. And provide a sanctioned tool that actually helps with the work people were trying to do, because prohibition without a substitute reliably produces the next shadow tool. Organizations that ban and stop there tend to find the behavior again six months later, in a different application.

What the AI writes becomes part of the record

A point that gets very little attention: once model output is adopted into the medical record, it is protected health information in your designated record set like anything else. The patient has a right of access to it under 45 CFR 164.524 and a right to request amendment under 164.526. A machine having drafted it changes neither.

This is a quality and safety issue wearing a privacy costume. Generated text can be fluent and wrong, and a hallucinated detail that a clinician signs is now a record entry a patient can read, dispute, and ask you to amend, and that travels with the patient through releases and referrals. Clinician review before adoption is the control. Whether clinicians actually perform it under time pressure is a training and culture question, which is where most of the real risk in ambient documentation currently sits.

The rule that is not HIPAA

If the tool informs decisions about patient care, a second obligation applies from a different statute. The Section 1557 final rule issued in May 2024 added 45 CFR 92.210, which requires covered entities to make reasonable efforts to identify uses of patient care decision support tools that employ race, color, national origin, sex, age, or disability as an input variable, and reasonable efforts to mitigate the risk of discrimination resulting from their use. The compliance date for that provision was May 1, 2025. The definition is deliberately broad and reaches automated and non-automated tools alike, from flowcharts to machine learning models.

For practical purposes this means that if you deploy a triage assistant, a risk score, or anything that shapes a care pathway, you should be able to show what diligence you did on its inputs and what you concluded. That is a separate file from your HIPAA documentation, and it is worth keeping deliberately rather than reconstructing later.

What is coming, and how much to weight it

On January 6, 2025, HHS OCR published a notice of proposed rulemaking to strengthen the Security Rule, the first substantial proposed overhaul in about twenty years, with a comment period that closed on March 7, 2025. The proposal would remove the distinction between required and addressable implementation specifications, and add explicit expectations around technology asset inventories, encryption, multi-factor authentication, and restoration timelines after an incident.

As of this writing it remains a proposal. HHS has stated that the current Security Rule remains in effect during the rulemaking, and the target date for final action has moved more than once on the regulatory agenda. A final rule, if issued, may differ substantially from what was proposed. Treat the proposal as a signal about direction rather than a compliance deadline, and note that an organization already maintaining a current asset inventory and a real risk analysis has most of what the proposal would formalize. Those are also the two things an AI deployment most often skips.

A note on what training proves

Because this page sits on a site that sells HIPAA training, the distinction should be stated rather than implied. Completing a course proves that named individuals received instruction on a stated date, and the certificate is documentation of that, useful for the training records the rules expect you to keep at 164.530(b)(2) and 164.308(a)(5). Organizational compliance is a different and larger thing: risk analysis, safeguards, agreements, policies, and what people actually do. No course, tool, or vendor can certify an organization as compliant, and no federal accreditation for that exists.

What training does do is decide whether the rest of it survives contact with a busy week. Agreements and policies govern behavior only through people who know they exist. The whole shadow AI problem is a training problem with a technology label on it.

Primary sources

Read the sources rather than taking this page's word for any of it. Each link goes to the government text.

• 45 CFR 160.103 , the definitions of business associate, protected health information, and workforce.
• 45 CFR 164.502 , the general use and disclosure rules, minimum necessary at (b), the business associate condition at (e), and de-identified information at (d).
• 45 CFR 164.504(e) , the required content of a business associate agreement and the narrow uses a business associate may make for its own purposes.
• 45 CFR 164.514 , de-identification under Safe Harbor and expert determination, and the limited data set.
• 45 CFR 164.308 , administrative safeguards, including risk analysis, security awareness and training, and business associate contracts.
• 45 CFR 164.312 , technical safeguards, including access control and audit controls.
• 45 CFR 164.402 , the definition of breach and the four-factor risk assessment.
• HHS guidance on business associates , including the scope of the conduit exception.
• HHS de-identification guidance , including the treatment of free text and the actual knowledge condition.
• HHS page on the Security Rule notice of proposed rulemaking , which states that the current Security Rule remains in effect during the rulemaking.
• 45 CFR 92.210 , the Section 1557 requirement on patient care decision support tools.