There is no standalone AI compliance regime in United States healthcare. AI tools fall inside obligations that already exist: HIPAA if the tool touches protected health information, FDA device authorities if it diagnoses or recommends, ONC transparency requirements if it lives inside certified health IT, and a growing patchwork of state law. The compliance work is classification, deciding which of those apply to a given tool, not waiting for a new rulebook.
That reframing matters because the most common compliance posture on healthcare AI right now is a holding pattern. Teams describe the environment as unsettled and defer decisions until it clarifies. Meanwhile ambient scribes are recording encounters, the EHR shipped three predictive models in the last upgrade, and clinicians are pasting case details into consumer chatbots. The obligations attached to all of that are already in force. Nothing is pending.
HIPAA Applies Without an AI Amendment
If an AI tool creates, receives, maintains, or transmits protected health information, the Privacy and Security Rules apply exactly as they do to any other system. That includes a Business Associate Agreement with the vendor, and it includes the minimum necessary standard applied to whatever the tool ingests.
Two questions do real work here and are easy to skip. First, what happens to the data after the immediate task, specifically retention period and whether it is used to train or improve models. A BAA permits a business associate to use PHI for its own operations in defined ways, and vendors vary widely in how they characterize model improvement within that. Get the answer in the agreement, not in a sales conversation. Second, where does inference actually run, particularly when the vendor is calling a third-party foundation model, because that is a subcontractor relationship the BAA needs to reach.
FDA Applies Based on Function, Not on Whether It Is Called AI
The FDA regulates software meeting its medical device definition, broadly tools that diagnose, treat, predict, or drive a clinical recommendation. Whether the vendor markets it as artificial intelligence is irrelevant to the analysis. A documentation tool that only drafts a note is generally outside device authorities. The same tool that starts suggesting diagnostic codes or flagging clinical findings has moved toward the line, and vendors frequently ship that expansion as a feature update rather than a new product.
This is the practical compliance trap. A tool cleared for one indication, or correctly outside device scope at purchase, can drift into a different regulatory posture through ordinary product development. That is a reason to re-check classification on material vendor updates rather than only at procurement.
If It Lives in the EHR, Transparency Rules Reach It
ONC's HTI-1 requirements obligate developers of certified health IT to disclose source attributes for predictive decision support built into their systems: how the model was developed, what it was validated against, and how it performs. For a health system, the useful consequence is that this information is supposed to be available for models arriving through the EHR, which is exactly the door that bypasses procurement. Asking for those disclosures is asking for something the developer is already required to produce.
State Law Is Where the Movement Is
The fastest-moving layer is state legislation, and it is genuinely fragmented. Requirements under discussion or enacted across various states include disclosure when AI is used in patient communication, limits on AI-driven utilization review and coverage denial, and consent requirements around AI-assisted encounters. A multi-state health system can face materially different obligations by location for the same deployed tool.
Because this layer changes faster than anything above it, treat any specific state summary as needing verification against current law rather than as settled. The durable point is structural: state obligations attach to where care is delivered, so the compliance question is per-jurisdiction, not per-tool.
The Practical Version
For any AI tool in the building, four classification questions resolve most of the analysis.
- Does it touch PHI, and is there a BAA covering retention, model training, and any downstream model provider
- Does it diagnose, predict, or recommend a clinical action, and if so what is its FDA status for that specific use
- Does it live inside certified health IT, and have we requested the required source attribute disclosures
- Which states do we deliver care in, and do any impose disclosure, consent, or utilization review constraints on this use
None of that requires a new regulation to answer. It requires an inventory of what is actually deployed, which is the thing most organizations discover they do not have the moment they try to run this exercise. The inventory is the compliance project. The rules are the easy part.
Compliance classification should feed a standing hospital AI governance process, while the evidence and accountability tests belong in a separate responsible AI review. One identifies the obligations. The others decide whether the tool should be deployed and how it remains controlled.