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. It is 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 practical benefit of this framing is not philosophical. It is that 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 only question they actually have.

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

Intellectual honesty matters more than a clean thesis. There are four places where the seven elements need something added rather than just applied, and pretending otherwise is how organizations get surprised.

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.

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 what it is: 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 not be the ones that picked the wrong framework. They will be the ones where AI arrived through a dozen separate departmental decisions and compliance found out afterward.

Work through it against your own vendors

The AI Vendor Risk Assessment runs 47 items across three lanes: the BAA terms that decide whether your PHI trains someone else's model, the California rules for AI that touches patients, and the governance controls that map AI onto the seven elements. Free, and nothing you enter leaves your browser.

Run the AI vendor 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.