AI governance

You don't need an AI governance framework. You need your compliance program.

Brandon Goulter, MHA 8 min read

Ambient scribes are in the exam room. Coding assistants are in the revenue cycle. Something is drafting the first pass of patient messages. And somewhere in the organization, a committee is being formed to select an AI governance framework. That committee is usually solving a problem the organization already solved, in 2023, when it built a compliance program.

AI is a new risk surface, not a new kind of risk. Every question that matters about an AI deployment (who approved it, what data it touches, who is accountable for the output, how you would find out if it went wrong) is a question the OIG's seven elements of an effective compliance program already asks. The General Compliance Program Guidance published in November 2023 did not anticipate ambient scribes, but it did not need to. It describes a machine for governing risk, and AI is risk.

The benefit shows up immediately: you can start Monday. An organization that goes shopping for an AI governance framework spends two quarters selecting one and another two mapping it onto controls it already runs; an organization that treats AI as a new risk area inside its existing program starts by adding a line to the risk assessment.

The mapping

Here is each element against the AI question it answers. Nothing in the right column requires a new governance structure. All of it requires you to actually apply the one you have.

Element

Applied to AI

01Standards, policies, procedures

A written AI use policy naming approved tools, prohibited data, and the rule that AI output is never final clinical documentation without review. Two pages, not twenty. The question it settles: may a nurse paste a note into a chatbot to reword it? Right now, most organizations cannot answer that in writing.

02Compliance leadership and oversight

A named owner and an approval gate that sits between "a service line wants this" and deployment, with compliance and privacy at the table. Plus AI as a standing board item. If AI decisions are made entirely inside IT or a clinical department, compliance learns about them after the data has moved.

03Training and education

Training that names the approved tools and the prohibited inputs. Generic annual privacy training does not tell anyone whether the tool on their desktop is allowed, which is the one thing they actually need to know.

04Effective lines of communication

The existing hotline, with one communication saying it covers AI concerns and a reporting category so you can trend them. The concerns worth hearing are specific: a wrong output nobody escalated, a tool nobody approved, pressure to accept AI drafts unreviewed.

05Enforcing standards, consequences and incentives

Entering PHI into an unapproved tool is a privacy violation under the policy you already have. The work here is confirming your disciplinary language reaches it, and then applying it the same way regardless of who did it.

06Risk assessment, auditing and monitoring

AI as a named category in the 45 CFR §164.308(a)(1)(ii)(A) risk analysis, with its own threat set. Then ongoing monitoring: sampling AI-generated clinical content against the source, watching coding distributions after an AI coder goes live, re-checking model performance across patient subpopulations.

07Responding to detected offenses and corrective action

An incident response plan that contemplates AI failure modes, because they do not map onto the standard breach workflow. PHI sitting in a vendor's prompt log. A model trained on data it should never have seen. A fabricated clinical detail that reached a patient.

The organizations that will handle AI badly are not the ones without a framework. They are the ones that never put AI inside the program they already run.

Where the fit is genuinely imperfect

The framework has five limits. In each, the seven elements need something added rather than simply applied.

1. The contract is the control

Most compliance risks are governed by what your workforce does. A large part of AI risk is governed by what a vendor's contract permits, and standard business associate agreements predate the questions that now matter. A BAA drafted in 2019 is almost certainly silent on whether the vendor may train a model on your PHI, how long prompts are retained, and whether "return or destroy all PHI" reaches a set of fine-tuned model weights.

Silence is the exposure. A vendor reading general "improve the service" language as permission to train is not behaving unreasonably; the contract simply never addressed it. This is why the AI-specific terms have to be negotiated in rather than assumed, and why the vendor's answer to the training question tells you a great deal about the vendor.

2. De-identification claims need testing, not accepting

"De-identified" is used as a marketing adjective far more often than as a regulatory status. When a vendor says data is de-identified, the useful follow-up is which pathway: Safe Harbor under 45 CFR §164.514(b)(2), or Expert Determination under §164.514(b)(1). Then ask for the documentation.

The place this usually falls apart is free text. Safe Harbor requires removing all 18 identifiers, and clinical narrative carries names, dates, and locations inside prose. Automated scrubbing of narrative is imperfect in ways that structured-field de-identification is not. Reading twenty scrubbed samples yourself will tell you more than any vendor attestation.

3. California wrote AI-specific law, and some of it lands on the developer

The seven elements are a federal program framework. They do not tell you that AB 3030 requires a disclaimer and human-contact instructions when generative AI drafts a clinical patient communication, with civil penalties attached, unless a licensed provider reviews it first. Or that AB 489 restricts AI tools from using terms, titles, or persona design implying the patient is talking to a licensed clinician, with the obligation running to the developer. Or that SB 1120 requires a human to make the final medical-necessity call.

Two of these deserve emphasis because they are commonly missed. The AB 3030 human-review exemption is only worth relying on if the review is a logged workflow step rather than an assumption about what clinicians do with the inbox: an exemption you cannot evidence is not an exemption. And ambient scribes raise a question HIPAA does not answer at all, which is California's two-party consent recording law at Penal Code §632. Notice of privacy practices does not resolve it.

4. Monitoring has to be continuous, because the thing changes

A traditional control, once validated, tends to stay validated. A model does not. The vendor updates it, clinical practice shifts, your patient mix changes, and accuracy drifts without any change on your side. A validation performed at procurement is evidence about a system that no longer exists.

This is the element-six obligation applied honestly: re-baseline after vendor model updates, sample on a cadence, and check performance across subpopulations rather than in aggregate. Ambient scribes in particular fail quietly, which is the failure mode monitoring exists to catch.

5. Federal civil-rights law now reaches your algorithms

The seven elements govern risk, but they do not tell you that a specific federal civil-rights rule now sits on top of your clinical tools. The 2024 Section 1557 final rule, at 45 CFR §92.210, requires a covered entity to make reasonable efforts to identify any patient care decision support tool that uses race, color, national origin, sex, age, or disability as an input variable, and then to mitigate the risk of discrimination from it. This is not the Security Rule risk analysis wearing a different hat. It is an affirmative duty aimed at the fairness of your own decisions, and it reaches well beyond AI: a race-adjusted eGFR equation or a risk score that stratifies by sex is squarely in scope.

Two things make this easy to miss. It runs to the entity's own use of the tool, not the vendor's contract, so it does not surface in a procurement review. And its compliance date, May 1, 2025, has already passed, which means an organization that has not done the identify-and-mitigate work is not early, it is late. The mitigation can be as concrete as discontinuing a race-adjusted equation or adding a documented human-review step; what OCR expects is a reasoned, written effort sized to your organization. This is also where the accessibility and language-access pieces of Section 1557 land on patient-facing AI: a chatbot that only works in English, or that a screen reader cannot use, is a nondiscrimination problem before it is a usability one.

What to actually do this quarter

In rough order of value per hour spent:

Inventory what you have. Pull the vendor list from accounts payable, ask each clinical and revenue-cycle leader what they are using, and check the EHR app marketplace for what has been enabled. You cannot govern what nobody has enumerated.
Go looking for shadow AI. Review expense reports for consumer AI subscriptions and send one amnesty-framed message inviting staff to disclose what they adopted on their own. People answer that message honestly when it does not lead with discipline. Free-tier chatbots pasted with patient details are the most common real AI privacy incident, and they never appear in a procurement record.
Read one contract properly. Take your highest-volume AI vendor and check three things: does it prohibit training on your PHI, how long are prompts and outputs retained, and does it name the foundation model provider behind the product.
Add AI to the risk assessment. One named category, its own threats, feeding the audit plan.
Write the two-page policy. Approved tools, prohibited data, and the documentation rule. Publish it where staff already look.

None of this requires a framework purchase or a new committee. It requires treating AI as a risk area that belongs inside the program you already built, assessed with the same rigor you would apply to a new service line or a new billing arrangement. The organizations that get this wrong will mostly be the ones where AI arrived through a dozen separate departmental decisions and compliance found out afterward.

Work through it against your own tools

The AI Risk Assessment runs 81 items across six lanes: contract and vendor controls, clinical safety, nondiscrimination, fraud and abuse, research and development, and governance. It is free, and your answers stay on your machine.

Run the AI risk assessment →

This article is general information, not legal advice. Brandon Goulter is not an attorney, and reading it creates no professional advisory relationship. AI regulation is moving quickly and unevenly across jurisdictions, and obligations vary by organization and circumstance; confirm current requirements with a licensed attorney before acting. Nothing here addresses FDA medical device regulation, which may independently apply to clinical AI tools.