A health system stood up an ambient documentation assistant that drafted after-visit summaries for patients, and the project team declared it compliant because legal had confirmed the vendor was "not a medical device." They were right about that one fact and wrong about almost everything that mattered. The tool touched protected health information with no signed agreement in place, it generated patient-facing clinical communications in a state that now requires a disclaimer on exactly that, and nobody had asked whether it was surfaced inside a certified electronic health record as a predictive intervention with transparency obligations. One tool, four regulatory regimes, and the team had checked one. This lesson is about the discipline that would have caught the other three: mapping a single deployment against every regime that touches it, so nothing is missed.

One Deployment, Many Regimes, Miss None

The most common compliance failure in clinical AI is not ignorance of a rule. It is the quiet assumption that clearing one gate clears the field. A leader hears "FDA cleared" and stops asking questions, or a compliance officer confirms a signed agreement and considers the deployment blessed. Each of these regimes governs a different thing, and each is silent on what the others cover. The FDA cares whether the software is a regulated device and whether it is being used for its authorized purpose. The Office of the National Coordinator, now within the Assistant Secretary for Technology Policy, cares about transparency inside certified health IT. The Health Insurance Portability and Accountability Act cares about who touches patient data and under what terms. A growing patchwork of state laws cares whether patients are told when a machine is involved in their care.

These four regimes overlap, and none substitutes for another. A device clearance from the FDA does nothing to satisfy your data-protection obligations. A signed agreement with a vendor does not tell a patient in Texas that artificial intelligence was involved in their diagnosis. Transparency disclosures inside your electronic health record do not make an unregulated tool into a cleared device, nor do they exempt it from anything. The right mental model is not a single checkpoint but a matrix: one row for the deployment, one column for each regime, and a named owner and evidence in every cell. The core move of this lesson is to teach you to build that matrix for any tool, so that the question is never "did we check compliance" but "did we check every regime that applies, and can we prove each answer."

One deployment answers to many regimes at once, and satisfying one is never a defense against missing another.

Before we walk the four regimes, fix the sequence in your mind. First, characterize the tool: what does it do, whose data does it touch, where does it run, and who are the patients affected. Second, run it against each regime and record the specific obligation, the current status, the evidence, and the accountable owner. Third, treat any missing cell as an open risk, not a rounding error. The regimes below are ordered the way a governance committee should ask them, but in practice you ask all four of every tool, every time.

The table below is the skeleton of that matrix. Keep it in front of the committee for every tool, and refuse to mark a deployment ready until each row has a named owner and evidence you could hand to an auditor.

FDA: Is It a Device, and For What Intended Use

The first FDA question is not "is it cleared" but "is it a device at all." Software qualifies as a medical device, and specifically as Software as a Medical Device (SaMD), when it is intended for a medical purpose such as diagnosis, treatment, or prevention. Many clinical AI tools are not devices. Certain administrative tools, and note-drafting assistants that merely reformat clinician-authored content, often fall outside the definition. Tools that meet the statutory criteria for non-device Clinical Decision Support, where the clinician can independently review the basis for the recommendation and is not being asked to rely on it as the primary source of a decision, are also outside FDA device regulation. Determining device status is therefore the first FDA task, because everything downstream depends on the answer.

If the tool is a device, the relevant fact is that it has an authorization for a defined intended use. By early 2026 the FDA had authorized more than 1,350 AI and machine-learning-enabled devices, roughly double the count from 2022 and up from about 1,250 as of July 2025, and radiology dominates the list, accounting for roughly 74 percent of 2024 authorizations. That volume can lull a committee into treating clearance as a general blessing. It is not. A clearance or authorization is a statement about a specific intended use in a specific population under specific conditions. It is emphatically not a promise that the tool is safe in your workflow or your patient mix. Deploying a cleared tool outside its intended use, on a population it was never validated against, or for a purpose adjacent to but not covered by the clearance, is an off-label deployment that carries the risk back to you.

The PCCP: how a cleared model is allowed to change

AI models are not static, and the FDA anticipated this with the Predetermined Change Control Plan (PCCP). A PCCP is the mechanism by which a manufacturer can update a model within pre-authorized bounds without returning for a new clearance each time. Why you care: a tool with a PCCP can change under your feet, in ways the manufacturer already has permission to make, so you must know whether the tool has a PCCP and exactly what it permits. If the model can be retrained or its thresholds adjusted within the plan, your local monitoring has to be alive to that. A tool without a PCCP that is nonetheless being updated is a different and more serious problem. The FDA questions to record for any device tool are therefore: what is the intended use, what is the clearance or authorization number, and is there a PCCP and what does it allow.

ONC HTI-1: Transparency for Predictive Interventions

The ONC HTI-1 rule reshaped what certified health IT must reveal about the algorithms running inside it. Certified health IT had to meet the Decision Support Intervention (DSI) certification criteria by December 31, 2024, with ongoing maintenance obligations from January 1, 2025, and a United States Core Data for Interoperability version 3 (USCDI v3) baseline required by January 1, 2026. The rule renamed the old category of Clinical Decision Support to Decision Support Intervention, and it created a distinct category for artificial intelligence and machine learning: the predictive DSI (PDSI). A predictive DSI is an intervention that produces an output, such as a risk score, by applying a model to patient data, and it carries the heaviest transparency load.

The centerpiece is source attribute transparency. Think of source attributes as a nutrition label for the intervention: a defined set of facts a deployer can inspect, covering what data the model used, how it was developed and validated, its intended use, and information bearing on its fairness and validity. Why you care: as a deployer, you can now demand to see the source attributes for any predictive DSI in a certified electronic health record, which turns vendor opacity from an accepted cost of doing business into a contract failure. Alongside source attributes, HTI-1 requires intervention risk management (IRM) practices, meaning the developer must analyze and mitigate risks across validity, reliability, robustness, fairness, and security, and it requires real-world testing so that performance is not just a claim from the development lab.

What HTI-1 does not do

HTI-1 governs transparency inside certified health IT. It does not make a predictive tool into an FDA device, and it does not exempt a device tool from FDA obligations. It does not touch your data-protection duties. A predictive DSI with beautifully complete source attributes can still be an unauthorized device used off-label, still be moving PHI to a vendor with no agreement, and still be triggering a state disclosure law. HTI-2 is in development and will extend this framework further, but the durable lesson is that transparency is necessary and never sufficient. The ONC question to record is: is this tool a predictive DSI in a certified EHR, and if so, have we obtained and reviewed its source attributes, IRM documentation, and real-world testing results.

HIPAA: Protecting PHI Wherever the Tool Sends It

HIPAA is the regime most likely to be violated quietly, because it is violated by data flows rather than by decisions. The rule is simple to state. Any AI vendor whose product touches protected health information (PHI) is acting as a business associate, and a business associate must be bound by a signed Business Associate Agreement (BAA) before any PHI reaches it. Why you care: the BAA is what obligates the vendor to safeguard the data, restrict its use, and report breaches. Without it, you have handed patient data to an outside party with no enforceable protections, which is itself a compliance failure regardless of whether anything bad has yet happened.

The second HIPAA principle is minimum necessary: a tool should receive only the PHI the task actually requires, not the whole chart because it was convenient to send. A summarization tool that needs the visit note does not need the patient's full history, and a model that scores readmission risk does not need free-text fields that leak identifiers it will never use. Applying minimum necessary shrinks both your breach surface and your exposure if the vendor's security fails.

The consumer-tool trap and data-use terms

The sharpest HIPAA failure in the AI era is mundane: a clinician pastes PHI into a consumer chatbot that has no BAA in place. That single act is a breach, full stop, and it happens constantly because the tool feels like a private assistant rather than an outside vendor. Governance has to name this explicitly and provide a sanctioned alternative. Beyond the BAA, examine the data flows: where does the PHI physically go, how long is it retained, who at the vendor can access it, and critically, does the vendor use your data to train its models. A vendor that trains on your patient data may be exposing that data in ways a BAA alone does not resolve, and the training question belongs in every AI vendor review. The HIPAA questions to record are: is a BAA signed, is minimum necessary enforced in the data feed, and what do the data-use and retention terms actually permit.

State Disclosure Laws: You Comply Where the Care Happens

The state layer is an evolving patchwork, and the correct posture is precision, not panic. Do not overstate what these laws require, and do not assume one state's rule travels. The governing principle is jurisdictional: you comply with the law of the place where the patient is and the care is delivered. Three examples show the range.

California AB 3030

In force since January 1, 2025, California's AB 3030 requires that when a health facility, clinic, or physician office uses generative AI to produce patient clinical communications, the communication must carry a prominent disclaimer that it was generated by AI and instructions for how to contact a human. There is a meaningful exemption: communications that are read and reviewed by a licensed provider before they reach the patient are exempt. That exemption is a design lever. If your workflow routes AI-drafted messages through a clinician who genuinely reviews them, the disclaimer obligation falls away; if it does not, the disclaimer is mandatory.

Texas TRAIGA (HB 149)

The Texas Responsible Artificial Intelligence Governance Act, HB 149, is effective January 1, 2026. It requires that health care providers disclose the use of AI in a patient's diagnosis or treatment to the patient or the patient's representative. The disclosure must be clear and conspicuous, in plain language, and free of dark patterns, meaning interface tricks that obscure or discourage understanding. Enforcement sits with the Texas Attorney General, and penalties run from $10,000 to $200,000 per violation. The Texas question is concrete: if AI touched the diagnosis or treatment of a Texas patient, was a plain-language disclosure made.

Colorado

Colorado illustrates how fast this ground shifts. The earlier SB24-205 was replaced by SB 26-189, signed May 14, 2026, and effective January 1, 2027. Under the revised framework, entities already covered by HIPAA are largely exempt from the developer and deployer duties that apply to others, but they must still provide notice and specified disclosures when they use covered automated decision-making technology (ADMT). The lesson from Colorado is not the specific date but the pattern: statutes are drafted, replaced, and refined, and a compliance map built on last year's version of the law is a liability. Track the law where your patients are, and refresh it.

Worked Example: One Tool, All Four Regimes

Return to the ambient documentation assistant that drafts patient-facing after-visit summaries, and walk it through the matrix as a governance committee should. A team that checked only one regime would have shipped a tool with three unaddressed exposures.

FDA. The team's instinct was that a summary-drafting tool is not a device, and for a tool that merely reformats clinician-authored content into patient-friendly language with clinician review, that is likely correct. But the committee still records the reasoning: intended use is patient communication, not diagnosis or treatment, and the clinician independently reviews and edits the output, supporting a non-device characterization. If the tool ever began generating clinical recommendations, that answer would change. Owner: regulatory affairs.

ONC HTI-1. Is the assistant surfaced inside a certified electronic health record as a predictive DSI? A pure drafting tool that does not produce a predictive output such as a risk score is probably not a predictive DSI, but if it is embedded in certified health IT and does anything predictive, the committee must obtain its source attributes. The team originally never asked this question at all. Owner: clinical informatics.

HIPAA. The tool ingests the visit note, which is PHI, and sends it to the vendor's cloud. This is the exposure the team missed entirely. A BAA must be signed before go-live, the feed must be scoped to minimum necessary rather than the full chart, and the contract must state whether the vendor retains or trains on the data. Owner: privacy officer.

State disclosure. The tool generates patient-facing clinical communications. In California, unless a licensed provider reviews each summary before it reaches the patient, AB 3030's disclaimer and human-contact instructions are mandatory. If the same tool is used in Texas and any AI-influenced diagnosis or treatment content reaches the patient, TRAIGA's plain-language disclosure applies. The team's single "not a device" finding said nothing about either. Owner: compliance and legal, by jurisdiction.

Four regimes, four owners, four pieces of evidence. The tool that looked compliant on one axis was exposed on three. The matrix is what converts a comfortable assumption into a defensible record, and it is the deliverable a regulator, an auditor, or a plaintiff's attorney will ask you to produce.

Now change one fact and watch the map redraw. Suppose the same organization instead deploys a predictive readmission model embedded in its certified electronic health record, one that scores every discharged patient and flags high-risk cases for a care-management outreach. The FDA question sharpens: a model that scores clinical risk to drive an intervention may or may not be a device depending on its intended use and whether clinicians can independently review its basis, so regulatory affairs must characterize it carefully rather than assume. The ONC question becomes central: this is almost certainly a predictive DSI, so the deployer should demand the source attributes, the intervention risk management documentation, and the real-world testing evidence, and validate the model on its own population before trusting the score. HIPAA still applies to every record the model consumes. The state layer may be quieter here, because a back-end risk score that never surfaces to the patient as an AI-generated communication or an AI-driven diagnosis may not trigger AB 3030 or TRAIGA, though notice obligations under laws like Colorado's ADMT framework can still reach automated decisions about individuals. Same discipline, different answers. That is the point: the matrix is fixed, the contents are tool-specific, and you fill it in every time.

Key Takeaways

• Map one deployment against every regime that touches it. FDA, ONC HTI-1, HIPAA, and state disclosure law each govern a different thing, they overlap, and satisfying one is never a defense against missing another.
• The first FDA question is device status, not clearance. Many tools are not devices, including non-device Clinical Decision Support and pure administrative or note-drafting tools; if a tool is a device, its clearance is for a defined intended use, not a promise of safety in your workflow or population.
• Know whether a device tool has a PCCP and what it permits, because a Predetermined Change Control Plan lets the model change under your feet within pre-authorized bounds.
• Under HTI-1, you can demand source attributes for any predictive DSI in a certified EHR: a nutrition-label set of facts on data, validation, intended use, and fairness, backed by intervention risk management and real-world testing.
• HIPAA is violated by data flows: any vendor touching PHI is a business associate needing a signed BAA, apply minimum necessary, and always ask whether the vendor uses your data to train its models. Pasting PHI into a consumer tool with no BAA is a breach.
• State disclosure law is jurisdictional and evolving: California AB 3030 (in force January 1, 2025) requires a disclaimer on GenAI patient clinical communications unless a provider reviews them; Texas TRAIGA (effective January 1, 2026) requires plain-language disclosure of AI in diagnosis or treatment, penalties $10,000 to $200,000; Colorado's SB 26-189 (effective January 1, 2027) largely exempts HIPAA-covered entities but requires notice for covered ADMT.
• Assign an owner and record evidence for every cell of the matrix. "We checked compliance" is not the standard; "we checked every regime that applies and can prove each answer" is.
• Transparency, clearance, and a BAA are each necessary and none is sufficient. Refresh the map as tools change and as the law where your patients are continues to shift.