HIPAA and AI: What Providers Have to Get Right

It covers the data, not the technology. There is no AI clause and no AI exemption. If a tool creates, receives, maintains or transmits protected health information on your behalf, the vendor is a business associate and the existing rules apply exactly as they would to a billing company.

That is good news, because it means you already know the framework. It is also why the phrase HIPAA compliant on a vendor website means very little on its own. No product is compliant. A deployment is compliant, and you are the one who has to make it so, whether the tool is an AI medical scribe or an intake agent.

HHS publishes sample provisions, and any vendor agreement should be read against them rather than accepted as a form. The clauses that matter most for AI tools are the ones the sample does not anticipate.

• Permitted uses. Does the agreement permit use of your data to improve or train the vendor's models? If it is silent, assume the answer is one you would not have agreed to.
• Subcontractors. Which model providers and cloud services sit behind the product, and are they flowed down?
• Retention and destruction. How long is raw audio kept, and what happens at termination?
• Breach notification timing. Vendor timelines are often longer than the ones you have to meet.
• Audit rights. What can you actually inspect.

We work through the same list on every readiness audit, and the procurement checklist turns it into questions you can send before booking a demo.

Four more clauses that AI vendors' standard agreements often leave thin. First, a statement of the specific services covered, so that a BAA signed for the scribe does not silently cover a new analytics feature the vendor switches on later. Second, return or destruction at termination in a form you can verify, including audio, transcripts and any derived data, with a certificate. Third, the location of processing, because a subprocessor in another jurisdiction is a Security Rule question and, for some state laws, a disclosure question. Fourth, a right to be told when the subprocessor list changes, before it changes. None of these are exotic. All of them are missing from at least one of the standard BAAs we have read from vendors on the comparison page.

This is the question that most often has a different answer to the one a buyer assumed. Some vendors do not train on customer data at all. Some do, with de-identification. Some offer it as a contractual option. All three can be workable, and only one of them is a surprise.

Ask three things. Is my data used to train shared models. If de-identification is claimed, by which method and who verified it. Can I decline without losing product function. Get the answers in the agreement rather than in an email from a sales engineer, because the sales engineer will have moved on before your first audit.

Only when it meets one of two standards in the Privacy Rule at 45 CFR 164.514, and an AI vendor's use of the word "de-identified" tells you nothing about which, or whether either was met.

Safe Harbor removes eighteen enumerated identifiers, including names, all geographic subdivisions smaller than a state, all elements of dates other than year, telephone numbers, medical record numbers and full face photographs, and requires that the entity has no actual knowledge the remaining information could identify the individual. It is a checklist, and on structured data it is achievable. On free text clinical notes and on audio it is very hard, because a transcript of a consultation contains identifiers the list does not anticipate: the name of the patient's employer, the town where the accident happened, the daughter who always calls on a Thursday.

Expert Determination is a documented opinion from a person with appropriate statistical knowledge that the risk of re-identification is very small, with the methods and results recorded. It is more flexible and more expensive, and it is the only realistic route for clinical text. The output is a document you can ask to see.

So when a vendor says it trains on de-identified data, ask which standard, ask who performed it, and ask for the determination if it is the second. A vendor that cannot answer is describing an aspiration. HHS publishes guidance on both methods, cited in the sources, and it is the reference against which any vendor claim should be read. The point for procurement is simple: until de-identification is demonstrated, the data is PHI, the BAA governs it, and model training on it is a permitted use only if the agreement says so.

A risk analysis, then safeguards proportionate to what that analysis found, then documentation of both. The rule is deliberately not a checklist, which frustrates buyers who want one, and is the reason two organisations can reach different defensible answers.

For AI tools, the risk analysis has to consider things the rule's authors were not imagining: audio recordings of clinical conversations, prompt and response logs that may contain PHI, and third party model providers in the chain. None of that is exotic under the rule. It just has to be written down and controlled like anything else, and it has to appear in the same register as the rest of your estate rather than in a spreadsheet the project team keeps.

Our approach to that documentation is set out under AI governance and compliance.

Awkwardly, and it is worth thinking through rather than waving past. The Privacy Rule requires that uses and disclosures of PHI be limited to the minimum necessary for the purpose, with an exception for disclosures to or requests by a provider for treatment. An ambient scribe records everything said in the room, including the parts that have nothing to do with the note, and sends all of it to a business associate. The treatment exception covers the clinician's use of the note. It does not obviously cover retaining a full audio recording for ninety days on a vendor's server after the note has been signed.

The defensible position has three parts. The purpose of the recording is documentation, so the vendor's retention of audio should be limited to what documentation needs: long enough to draft the note and for the clinician to check it, and then deleted. Set audio retention to the shortest period the product allows, and put the period in the BAA. Second, the vendor's access to the audio should be role based and logged, so that a support engineer cannot listen to recordings at will. Third, patients and visitors who are in the room but are not the patient, a parent, a partner, an interpreter, are being recorded too, and a script that tells everyone present is the minimum.

Minimum necessary also applies to what the AI tool is given by the EHR. A scribe that reads the entire chart when it needs the problem list and the medication list is taking more than the purpose requires, and the integration scope your Epic or other EHR team approves is where that is controlled. Ask the vendor which FHIR resources it requests and why, and refuse the ones it cannot justify.

HIPAA generally permits use of PHI for treatment, payment and health care operations without additional authorisation, so a documentation tool used in treatment usually does not need a separate HIPAA authorisation. That is not the whole answer.

Recording is governed by state law, and consent requirements for recording a conversation vary. Substance use disorder records under 42 CFR Part 2 carry their own consent rules. And beyond the law there is the practical point: patients who discover a recording tool they were not told about respond badly, and rightly. Tell them, always, in plain words.

HIPAA and state recording law answer different questions and both have to be satisfied. HIPAA asks whether the use of PHI is permitted, and for a documentation tool used in treatment it usually is without a separate authorisation. State law asks whether the conversation may be recorded at all, and in a number of states every party to a private conversation must consent before it is recorded. California, Florida, Illinois, Maryland, Massachusetts, Pennsylvania and Washington are among the states generally described as all party consent states; the list and its exceptions change, so verify with counsel for each state you operate in rather than relying on any summary, including this one.

The practical consequences are these. In an all party state, a notice on the wall is not consent from the patient, and it is certainly not consent from the relative in the corner. A spoken notification at the start of the visit, with a spoken yes, recorded in the note, is the minimum. In a one party state, the clinician's own consent is legally sufficient for the recording, and telling the patient anyway is still the right practice, because patients who discover a recording tool they were not told about respond badly and the complaint lands with you rather than the vendor. Telehealth crosses state lines, so the patient's location governs, not yours.

Two overlays sit on top. Substance use disorder records under 42 CFR Part 2 carry their own written consent regime that a scribe processing the encounter has to respect. And the new state AI laws in Texas and California add disclosure duties for AI in care that a clinician reviewed note usually keeps you clear of, and that a skipped review step does not. One notification script, set to the strictest state you serve, with an opt out that does not degrade care, is the way multi state organisations run this. The AI policy template includes the script and the opt out.

It is still a proposal. HHS Office for Civil Rights announced the notice of proposed rulemaking on 27 December 2024, it was published in the Federal Register on 6 January 2025 and the comment period closed on 7 March 2025. As of September 2026 HHS's own page lists it as a proposed rule, no final rule has been published, and trade reporting of the federal regulatory agenda places final action in 2027. Check the HHS page cited in the sources before relying on this paragraph, because that is the only source that will be current on the day you read it.

What the proposal would do, in outline, is remove the distinction between required and addressable specifications, require a written technology asset inventory and network map, require encryption of ePHI at rest and in transit with limited exceptions, require multi factor authentication, require annual compliance audits and more frequent testing, and tighten the obligations of business associates, including a requirement that they verify their safeguards to the covered entity. Several of those bear directly on AI vendors: a network map that shows where audio goes, verified encryption, and a business associate attestation you can rely on.

Does it change anything now? Not as law. As practice, yes, in two ways. First, the proposals describe what OCR already considers reasonable and appropriate under the current rule, so a vendor review that asks for an asset inventory, encryption evidence and MFA is not running ahead of the law, it is reading OCR's mind. Second, contracts signed today will still be in force if the rule is finalised, so a BAA that already requires the vendor to verify its safeguards annually is a BAA you will not need to renegotiate. We write the proposed requirements into vendor questionnaires now for that reason, and the governance and compliance engagement tracks the rule's status for clients so nobody has to re-read the Federal Register.

Your clock starts when the vendor's does, and the notification duty to patients is yours. Under the Breach Notification Rule, a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery, and the covered entity must then notify affected individuals without unreasonable delay and no later than 60 days after the breach is treated as discovered. A breach is treated as discovered by the covered entity when it is known, or should reasonably have been known, to any person who is an agent of the entity, and depending on the agency relationship that can mean the vendor's knowledge is imputed to you on day one.

Three consequences for the contract. First, the BAA's notification timing should be much shorter than the regulatory maximum, measured in days rather than weeks, so that you have time to investigate and notify inside your own deadline. Second, the BAA should require the vendor to give you what you need to notify: the list of individuals, the data elements involved and the date range, in a form you can use. Third, the vendor's own cyber insurance and indemnity should be sized to the number of records it holds for you, which for an ambient scribe with long audio retention is every patient seen since go live.

Breaches affecting 500 or more individuals must be reported to HHS within 60 days of discovery and to prominent media, and they appear on the public breach portal. Breaches of fewer than 500 are reported to HHS annually. The scale of exposure from a vendor incident is usually larger than buyers expect, because the vendor holds records for every clinician using it rather than one clinic's worth; the AI vendor breach exposure tool estimates the number of individuals, the notification cost and the reporting thresholds for your own volumes.

Published resolutions have long clustered around unglamorous failures: no current risk analysis, weak access control, unencrypted devices, and slow breach response. Model behaviour has not been the theme.

The practical reading is that an AI deployment is far more likely to be judged on the basics wrapped around it than on anything novel. Get the risk analysis current, get access control right, log everything, and be able to show the paperwork. That is also the least interesting advice in this field, which is probably why it keeps needing repeating.

If you are shortlisting vendors, our comparison page records what each one publicly documents about agreements and data handling, and says plainly where we could not verify a claim.

Read the resolution agreements and civil monetary penalty notices OCR publishes and the same findings recur: no current, accurate and thorough risk analysis; no risk management plan acting on it; access that was never reviewed or revoked; unencrypted devices and media; audit logs that existed but were never read; and slow or absent breach notification. In 2024 and 2025 OCR ran an explicit risk analysis enforcement initiative and announced a series of settlements whose common thread was the absence of a risk analysis, and it has continued to publish ransomware related settlements where the entry point was ordinary hygiene.

Nothing in the published record turns on the behaviour of a model. That is not a prediction that it never will, but it tells you where the exposure is today: an AI deployment will be judged on the basics wrapped around it. For a practical order of work, that means the risk analysis is updated to include the AI vendor, the audio, the prompt and response logs and the subprocessors before go live; the vendor's access to your systems is provisioned by role and reviewed on a schedule; the vendor's audit logs are collected and someone reads them; and the breach plan names the vendor and the person who calls them.

OCR also publishes right of access enforcement, which is worth a moment: an ambient scribe's audio and transcript are, arguably, part of the designated record set if you retain them, and a patient may ask for them. Decide now whether you retain audio at all, because the simplest answer to the access question is that there is nothing to produce. The governance committee playbook sets out how larger organisations assign these responsibilities so that they are somebody's job.

Twelve items, each of which should produce a document rather than a reassurance. If a vendor cannot produce the document, the answer is no until it can.

1. An executed BAA covering the specific service and configuration, with the clauses above.
2. A subprocessor list naming the model providers and cloud regions, with flow down confirmed.
3. A written statement on model training: whether your PHI is used, under which de-identification standard, and how to decline.
4. Retention periods for audio, transcripts, prompts and outputs, and the deletion method at termination.
5. Current SOC 2 Type II or HITRUST report, read rather than filed, with exceptions noted.
6. Encryption evidence at rest and in transit, and the key management arrangement.
7. Access control model, MFA for vendor staff, and the review cadence.
8. Audit log availability and export, and the retention of those logs.
9. Breach notification timing, contents and contact, tested by asking who you would call today.
10. A recent penetration test summary and the remediation status of its findings.
11. The FHIR resources or data elements requested from the EHR, with a justification for each.
12. Cyber insurance evidence sized to the records held.

Run the list before the demo, not after the pilot, and keep the answers in the same register as the rest of your vendor risk documentation rather than in the project team's folder. The questions to ask AI vendors about HIPAA gives the wording for each item in a form you can paste into an email, and the HIPAA compliant AI tools comparison records what each vendor we track has published against them.

An increasing number, and HIPAA does not pre-empt a state law that is more protective of the individual, so the state rule is the floor wherever it is stricter. Four states have laws that a healthcare AI buyer needs to read now.

• Texas. The Texas Responsible Artificial Intelligence Governance Act, in effect from 1 January 2026, requires healthcare providers to disclose to patients when AI is used in their care, and creates prohibited uses and an enforcement role for the Attorney General.
• California. A cluster of laws: AB 3030 requires disclosure when generative AI produces patient communications without clinician review, SB 1120 limits how health plans use AI in utilisation review, and the CCPA and CPRA add rights for data outside HIPAA's scope. California is also an all party consent state for recording.
• Colorado. The Colorado AI Act regulates high risk AI systems that make or substantially influence consequential decisions, healthcare included, with duties on both developers and deployers. Its effective date was pushed back by the legislature; check the current date on the page.
• Utah. The Artificial Intelligence Policy Act requires regulated occupations, including licensed health professionals, to disclose prominently when a person is interacting with generative AI.

A clinician reviewed ambient note usually sits comfortably under all four, because the AI drafts and a licensed person decides. An intake agent that talks to patients directly, or a tool whose output reaches a patient without review, does not, and the disclosure duty is triggered. For a multi state footprint, the state AI laws in healthcare map is kept current, and the healthcare AI law checker tells you which rules apply to the states you serve. Where the map changes faster than a policy can be rewritten, one policy set to the strictest state is the workable answer.

A vendor's HIPAA page tells you what the vendor is willing to say. An independent review tells you what the contract actually commits it to, what the risk analysis has to contain to include the tool, and which state duties your footprint triggers, in a document you can hand to an auditor rather than describe. It also tells you, sometimes, that the cheapest compliant path is to switch a feature off.

That is the work of our AI governance and compliance engagement for organisations with tools in production or about to be, and of the AI readiness audit for those still deciding. We take no vendor commissions and we do not resell anything, so the BAA read is on your side of the table. Book a call before the agreement is signed rather than after.