Healthcare is not waiting for an AI statute, and neither should its compliance programs. Seven authorities already reach AI, three frameworks converge on what to do about it, and the risks land squarely inside the program you already run. The question is no longer whether AI governance is required. It is whether yours would hold up if someone asked to see it.

How common is AI use in healthcare today?

Adoption is no longer a forecast. In a 2026 American Medical Association survey of 1,342 physicians, 81 percent reported using AI in clinical practice, up from 66 percent in 2024 and 38 percent in 2023. Most organizations are already running several AI tools. Ambient documentation listens in the exam room and drafts the note. Coding and claims scrubbing tools suggest codes and flag claims before submission. Prior authorization support assembles and reviews requests. Generative assistants draft, summarize, and answer staff questions. These arrived department by department, often as a vendor feature update rather than a procurement decision, and usually without compliance in the room.

The useful opening question for your own organization is not whether you use AI. It is which tools are in use today, who approved them, and what data they touch. If that question cannot be answered from a document, the governance gap is already the finding.

Start Here: Four Fields Per Inventory Entry
  What it does
  What data it touches
  Who approved it
  Who monitors it
Include vendor-embedded AI, the category most often missed, because it arrives as a feature update rather than a purchase. A spreadsheet qualifies. What matters is that the record is current and complete.
Takeaway
When a governance question has no documented answer, the gap is the finding.

Who regulates AI in healthcare?

The regulatory environment for AI in healthcare continues to evolve rapidly, and that movement cuts both ways. It creates obligations that arrive faster than most policy cycles accommodate, and it rewards organizations that build governance early enough to adopt new tools with confidence.

How do HIPAA and HITECH apply to AI?

Seven regulatory authorities shape that environment, and every one rests on ground you already stand on. The most operationally relevant are the Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health Act (HITECH), which set the privacy, security, and breach notification obligations an AI system inherits the moment it touches PHI, and extend them to business associates. Proposed Security Rule modifications would reach further still, extending risk analysis to training data governance, model drift, and diligence on AI subcontractors. For most compliance officers this is where the near-term work sits.

What do OIG and CMS expect?

OIG’s newest Corporate Integrity Agreement template is the first to explicitly define generative AI, requiring organizations under a CIA to disclose whether it was used, how, and how output accuracy was verified. Everyone else should read it as a signal of where voluntary General Compliance Program Guidance is heading. CMS has drawn a firmer line, cautioning Medicare Advantage organizations against coverage determinations driven solely by algorithms. AI can inform clinical judgment. It cannot replace it.

What are states requiring?

State law moves fastest and tracks hardest. In 2025 alone, lawmakers in 47 states introduced more than 250 bills regulating AI in healthcare, and 21 states enacted 33 of them, producing a patchwork of disclosure, transparency, and human-review requirements that varies by jurisdiction.

A few states set the pace. Texas SB 1188 lets practitioners use AI for diagnostic purposes only if they review all AI-generated records against Texas Medical Board standards, and it requires disclosing that use to the patient. California’s AB 316 removes the defense that an AI system acted autonomously, so an organization cannot point to the tool to escape responsibility for what the tool did, and SB 1120 bars health plans from basing medical necessity determinations solely on an algorithm. Illinois HB 1806 bars AI from making independent therapeutic decisions without licensed review, and Utah governs generative AI disclosure and mental health chatbots. Several states, among them Arizona, Maryland, Nebraska, and Connecticut, now prohibit insurers from using AI as the sole basis to deny care, making human clinical review statutory. For multi-state organizations, the answer is one framework built to the most demanding requirement rather than a process per state.

One enforcement action shows how little of this depends on a new statute. In September 2024 the Texas Attorney General settled with Pieces Technologies, a generative AI documentation vendor used by at least four major Texas hospitals, over marketing claims about its hallucination rate. The authority invoked was the state’s Deceptive Trade Practices Act. A vendor’s accuracy claim becomes your claim the moment you rely on it with patients.

What does the Joint Commission require for AI?

The newest voice belongs to accreditors. The Joint Commission and the Coalition for Health AI published Guidance on Responsible Use of AI in Healthcare in September 2025, organized around seven elements: governance structures, patient privacy and transparency, data security, quality monitoring, blinded reporting of AI safety events, risk and bias assessment, and education and training. The Responsible Use of AI in Healthcare (RUAIH) certification followed in June 2026. Any organization may apply, accredited or not, and it assesses governance rather than validating individual products.

How do FDA rules and Section 1557 apply?

Two authorities round out the list. FDA oversight can reach software that diagnoses, treats, or monitors disease regardless of what the vendor calls it, so compliance should know which tools carry that risk. And HHS Section 1557 nondiscrimination requirements now reach AI-enabled decision support, making algorithmic bias a civil rights question rather than only a technical one.

Takeaway
No single statute governs healthcare AI. Seven existing authorities do, layered on top of each other and still forming.

Which AI framework should you use?

When three frameworks are named, the natural first move is to pick one. That choice is not really on the table, because each answers a different question, and an organization that treats them as competing options ends up building to the narrowest of the three.

The OIG seven elements cover what the law requires of a compliance program. They are the legal architecture, and AI does not change them; it becomes a new subject matter running through each one. The NIST AI Risk Management Framework covers how to run AI risk day to day, built as a cycle rather than a project: Govern sets policy, roles, and third-party risk; Map establishes context before deployment; Measure tests performance, drift, privacy, and fairness; Manage acts on what Measure found, including the documented authority to turn a tool off. The Joint Commission and CHAI guidance describes what good practice looks like in a healthcare setting, now backed by a voluntary certification. Non-binding is easy to read as permission to wait. In practice, surveyors, boards, carriers, and enterprise customers reach for a published framework well before anything becomes mandatory.

Building to the Joint Commission’s elements, structured through NIST, satisfies most of what HIPAA, HITECH, and OIG ask for, inside the seven elements you already report against.

The conclusion holds in either direction. Building to the Joint Commission’s seven elements, structured through NIST, satisfies most of what HIPAA, HITECH, and OIG are asking for, and it does so inside the seven elements you already report against.

Takeaway
Build to one framework deliberately and you advance the other two by default.

What is the compliance department’s role in AI governance?

Ownership of AI risk can sit with the compliance officer, the CISO, a cross-functional committee, or a dedicated AI governance lead. Right-size it to the organization. The only arrangement that fails is an owner nobody can name, because the role calls for someone tracking what the requirements are today and where they are heading.

That makes compliance the bridge between the pace of AI adoption and the pace of regulatory change: close enough to the business to know what is being piloted before it deploys, and close enough to the authorities to know which requirement it lands against. It is also the seat with the earliest view of trouble. Audit logs, incident reports, denial patterns, and vendor change notices surface the first signals, a rise in overridden recommendations, a shift in coding after a model update, a subprocessor added without notice, well before they reach a board report or a regulator.

Which risks require governance oversight?

In healthcare the exposure concentrates in five familiar places: privacy, patient rights and safety, bias, billing, and vendors. AI does not create new categories so much as it accelerates these, then adds failure modes the register has never held, including model drift, training data provenance, and bias embedded in a tool nobody built in house.

Data privacy and PHI exposure

 PHI touches an AI system in five places: training data, prompts, outputs, logging, and vendor-side retention. The gaps appear at the last two. HIPAA, HITECH · NIST Govern 6, Measure 2.7 · RUAIH 3

Patient rights, safety, and clinical decisions

 A tool that diagnoses, treats, or monitors disease may fall under FDA authority regardless of what the vendor calls it. Document who can override an output, and monitor most closely where a tool sits nearest a clinical decision. FDA, CMS · NIST Manage 2 · RUAIH 4, 5

Bias and disparate impact

Nondiscrimination requirements now reach AI-enabled decision support, making bias a civil rights matter rather than only a technical one. Verify the tool is tuned to the populations you serve, then test, audit, and retain the results. HHS Section 1557 · NIST Measure 2.11, Map 5 · RUAIH 6

Billing and fraud exposure

An AI tool that codes a procedure incorrectly creates the same overpayment and False Claims Act exposure as a person who does. Keep AI-generated claims inside the audit sample. OIG, CMS · NIST Measure 2.3, Manage 4 · RUAIH 4

Vendor and third-party risk

Most BAAs were signed before the AI feature shipped. Address training use of your PHI, retention of prompts and outputs, and which subprocessors sit behind the vendor. HIPAA, HITECH, OIG · NIST Govern 6, Map 4 · RUAIH 3, 4

What makes an AI governance framework defensible?

A framework is defensible when someone outside the organization can follow it on paper: what you use, how each tool was approved, what happens when one fails, and who has been watching. Eight components carry that weight, and each maps to an element you already report against within your compliance program.

It begins with policy and structure, a written AI use policy tied to the code of conduct that names the accountable owner of AI risk. That policy governs an inventory and register of every AI tool in use, vendor-embedded functionality included, recording what each does, what data it touches, who approved it, and who monitors it. Risk assessment and classification tiers those entries by PHI exposure, proximity to a clinical or coverage decision, and degree of autonomy, so oversight scales to consequence.

Decisions then need a forum and a gate. A cross-functional governance committee brings legal, IT and security, clinical, compliance, and business to one table under a written charter, and approval workflows require a pre-deployment impact assessment before any tool touching PHI goes live, with defined sign-off authority.

The last three run continuously. Monitoring and oversight means scheduled testing for drift, bias, and performance, with documented human override for anything influencing a clinical decision. Incident response adds AI failure modes to the existing plan, with root cause, correction, and verification that the fix held. Board reporting and cadence puts inventory status, incidents, and regulatory developments inside the report the board already receives, with reassessment at least annually.

Training runs through all eight, with attestations on file and a confidential channel for AI concerns. Two boundaries also matter. Compliance does not validate model performance, which is a technical and clinical function; it confirms that validation happened, by whom, and on what schedule. Nor does oversight replace in-house counsel, who should review litigation exposure and confirm that BAAs address breach notification and any newly added AI features.

Takeaway
Governance is not a posture. It is eight components, each producing a record, applied to five familiar risks inside the program you already run.

The bottom line for compliance leaders

Accountability does not shift to the model. Whether an error originates with a person, a legacy system, or an AI tool, the organization still has to detect it, correct it, and document what it did about it. That principle has not moved in thirty years of healthcare compliance, and it is why AI governance belongs inside the program rather than beside it.

What has moved is the pace. AI is already embedded in most organizations, usually adopted department by department. Seven authorities now reach it, from HIPAA and HITECH through OIG, CMS, FDA, Section 1557, state law, and now accreditors, and not one of them is settled. Waiting for that to change is itself a decision, with its own consequences.

The work is more familiar than it looks. Three frameworks answer three different questions and stack rather than compete. The exposure concentrates in five places compliance already watches: privacy, patient rights and safety, bias, billing, and vendors. Eight components make a framework defensible, each producing a record and each mapping to an element already in the program. Build while the rules are forming and you gain what the rule-followers will not have: the confidence to adopt a tool, because you can already say what it does, who approved it, and who is watching it.

The organizations that handle the next wave well will not be the ones with the most AI, or the ones that waited longest to touch it. They will be the ones whose compliance officers can hand over a single document and let it speak for the program.

Frequently Asked Questions

No. No single federal statute governs AI in healthcare. Seven existing authorities reach it instead, layered on top of each other: HIPAA and HITECH, OIG compliance program expectations, CMS, FDA, HHS Section 1557, state law, and accreditors. The obligations underneath AI already apply even though the governance is not mandated as a package.

Yes. An AI system inherits HIPAA privacy, security, and breach notification obligations the moment it touches PHI, and HITECH extends those obligations to business associates. PHI reaches an AI system in five places: training data where applicable, prompts and inputs, outputs, logging, and vendor-side storage and retention. Each stage needs its own safeguard.

You need the function, and the form scales. A large health system runs a standing multidisciplinary committee. A small practice can meet the same expectation with a recurring meeting of three people, as long as an owner of AI risk is named and the oversight is recorded. What does not scale down is having no named owner.

In most cases yes, because most Business Associate Agreements were signed before the vendor’s AI feature shipped and say nothing about it. Update the language to address whether your PHI can train the vendor’s models, what is sent to the model and how long prompts and outputs are retained, which subprocessors sit behind the vendor, and how breach notification works. Settle monitoring responsibility in the contract and reserve audit rights.

No. The Responsible Use of AI in Healthcare certification is voluntary, and any healthcare organization may apply whether or not it is Joint Commission accredited. It assesses the organization’s governance rather than validating individual AI products. Even organizations that never pursue it should read the seven elements, because surveyors, boards, and enterprise customers will.

Name an owner of AI risk, then build the inventory. Everything else depends on those two. Capture every AI tool in use, including vendor-embedded features, and record four fields for each: what it does, what data it touches, who approved it, and who monitors it. From there the sequence is an AI use policy, a pre-deployment risk impact assessment, role-based training with attestation, oversight reporting, and a reassessment cadence.