The AI Governance Committee That Ships Decisions Instead of Blocking Them

Almost every hospital that has stood one up describes the same failure. The committee meets monthly, hears three presentations, asks good questions, and adjourns without deciding anything. Six months later the clinical teams have stopped bringing requests, and the tools that reach production are the ones that never went through the committee at all.

The cause is structural rather than personal. A body with no decision rule, no clock and no scope boundary defaults to caution, because caution is the only position nobody gets blamed for. Deferring a decision feels like diligence, and there is no meeting artifact that records the cost of the delay.

The fix is not to weaken oversight. It is to define, in writing, three things: what the committee decides, what it merely notes, and how long it has to do either. Everything else in this playbook is downstream of those three answers. A committee that publishes a target turnaround and hits it will see requests routed to it voluntarily, which is the only way governance ever reaches the shadow deployments that matter.

If you are earlier than this and still deciding whether the organisation is ready to deploy anything, the AI readiness assessment is a better first stop than a charter.

Keep it to two pages. A charter that runs to fifteen pages is a document nobody consults, which means the committee is governed by whoever remembers the most.

1. Purpose. One paragraph. What the committee exists to protect and what it exists to enable, in that order.
2. Scope. Which systems are in and which are out. State plainly whether the committee covers only new procurements or also existing tools, whether it covers vendor features shipped inside the EHR, and whether it covers research use.
3. Decision rights. Which decisions the committee makes itself, which it recommends to an executive owner, and which it delegates. Name the roles, not the people.
4. Quorum and voting. The minimum attendance for a binding decision, and what happens when the committee splits.
5. Escalation. Who breaks a tie, and who can overrule the committee. Somebody can, so write down who.
6. Turnaround commitments. A target number of working days per risk tier, published and measured.
7. Review cycle. When the charter itself gets revisited, which should be at least annually while the technology moves this fast.

The scope clause is the one that gets skipped and then causes the most argument. Say explicitly whether an ambient documentation feature that your EHR vendor enables by default is in scope. Most hospitals discover the answer matters only after the feature is live. The HTI-1 rule gives you a useful hook here, since certified health IT developers now have transparency obligations for decision support interventions that you can require your own teams to collect.

Nine to eleven voting members. Below seven the committee lacks the standing to bind anyone. Above twelve it stops deciding.

• Chair. A clinical leader with operational authority, usually a CMIO or an associate chief medical officer. Not the CIO, because the committee needs to be able to say no to IT.
• Clinical practice. Two or three practising clinicians from the specialties with the highest documentation and inbox load. They should still be seeing patients.
• Nursing. One nursing informatics leader. Nursing workflow is where most administrative agents actually land.
• Information security. The CISO or a delegate with signing authority on risk acceptance.
• Privacy and compliance. The privacy officer, who owns the HIPAA analysis and the business associate agreement position.
• Legal. One counsel, present for tiering and contract questions rather than every item.
• Data and analytics. Someone who can read a validation report and say whether the evaluation was any good.
• Health equity. A named owner for subgroup performance questions, which nobody raises unless it is somebody's job.
• Operations or revenue cycle. Whoever owns the workflows most likely to be automated, such as prior authorization and denial management.

Add a non voting coordinator who owns the queue, the agenda and the minutes. This role is the difference between a committee that functions and one that does not, and it is the one most often left unfunded.

One page, submitted before anything reaches an agenda. If a requester cannot fill it in, the request is not ready, and that filter alone removes a large share of the committee's load.

1. What problem is this solving, and what is the current baseline, measured?
2. Which workflow does it sit in, and who performs that workflow today?
3. Does the system touch protected health information? If yes, which categories?
4. Does the output reach a patient without a human reading it first?
5. Does the system suggest, order or influence a clinical decision, or does it only draft, summarise or route?
6. Which vendor, which underlying model providers, and is there a signed business associate agreement?
7. Is the vendor's product regulated as a medical device, and if so under what clearance? See FDA oversight of AI enabled devices for the boundary.
8. What is the failure mode, and who notices when it fails?
9. Who is the accountable operational owner after go live, by name?
10. What would make you turn it off?

Question ten is the most useful one on the form. A requester who has a shutdown criterion has thought about the risk. One who has not will usually go and think about it, which is the point.

Question five is the tiering question. It separates a documentation drafting tool from something that changes clinical decisions, and those two things should never receive the same review. We unpack that distinction in the difference between automation, copilots and agents.

Three tiers. Four is defensible, five is a taxonomy nobody applies consistently. Tier on what the system can affect if it is wrong, not on how sophisticated the technology is.

Publish the turnaround targets and report against them at every meeting. A committee that reports it hit fourteen of sixteen commitments last quarter has a very different standing in the organisation from one that reports nothing.

Note that tier is a property of the deployment, not the product. The same ambient documentation tool is Tier 2 when a clinician signs every note and Tier 3 if anyone proposes auto filing. Retier on any material configuration change.

Fortnightly, sixty minutes, with a standing agenda and a queue published two working days ahead. Monthly is too slow for a fifteen day commitment on Tier 2, and weekly cannot be sustained by people with clinics.

A workable agenda:

• Five minutes. Queue status and turnaround performance since the last meeting.
• Ten minutes. Monitoring exceptions on systems already in production. This slot comes before new business deliberately, because a committee that only reviews new requests is an approval body, not a governance body.
• Thirty minutes. Two or three Tier 2 or Tier 3 items, ten to fifteen minutes each, decided in the meeting.
• Ten minutes. Tier 1 items noted in a batch, no discussion unless a member objects.
• Five minutes. Actions, owners, dates.

Two rules make this hold. First, no item reaches the agenda without a completed intake form and a written recommendation from the coordinator, so the meeting is spent deciding rather than discovering. Second, every item ends in one of four outcomes recorded in the minutes: approved, approved with conditions, declined with reasons, or deferred with a specific question and a date. Deferral without a named question is how committees drift, and banning it costs nothing.

Keep the minutes properly. Six months after a decision, when somebody asks why a tool was approved, the minutes are the answer, and they are also what a regulator or an auditor will ask to see.

The NIST AI Risk Management Framework 1.0, released in January 2023, organises AI risk work into four functions: Govern, Map, Measure and Manage. It is voluntary, not a regulation, but it is the most widely recognised structure available and mapping to it means your governance work is legible to auditors, insurers and enterprise customers without a separate exercise. NIST added a Generative AI Profile, NIST AI 600-1, in July 2024, which is the more useful companion document for language model deployments.

The production register is the artifact most hospitals are missing. It is a single list of every AI system in live use, with its tier, its accountable owner, the date of its last review and its shutdown criterion. Building it is usually the committee's hardest first task, because nobody knows what is already running. That discovery exercise is a large part of what our AI governance and compliance work delivers.

Three things, and writing them into the charter prevents most of the scope creep that kills these bodies.

It should not select vendors. Governance sets the constraints and reviews the evidence. A committee that runs the bake off cannot then impartially review its own choice, and it will spend its meetings on feature comparison. Keep vendor selection in a separate process with separate people, and let the committee approve the constraints that process must respect.

It should not run the pilots. The operational owner runs the pilot. The committee specifies what must be measured and reviews the result. Committees that run pilots become invested in the outcome.

It should not review every prompt. Staff use of general purpose tools is a policy question, handled by an acceptable use policy and training rather than a case by case review. Our AI acceptable use policy guide covers what that policy needs to say. If your committee is reviewing individual chatbot queries, it has run out of governance work and started performing it.

The corollary is that the committee must have somewhere to send things. A governance body with no operational counterpart becomes the default owner of everything, which is how it ends up with a queue it cannot clear.

A realistic sequence, assuming an executive sponsor is already in place.

• Weeks 1 to 2. Draft the charter, name the chair and the coordinator, and get the sponsor to sign. Do not consult widely on the charter yet, because a committee that spends its first month negotiating its own remit never recovers the momentum.
• Weeks 3 to 6. Build the production register. Ask every department what AI tools they are using, including features inside existing systems and anything bought on a departmental card. Expect the answer to be larger than the CIO's list.
• Weeks 5 to 8. Publish the intake form and the tier definitions, and route the backlog through them. Meet fortnightly from week five, even if the first two meetings are mostly triage.
• Weeks 9 to 12. Retro fit tiering to everything on the register, set monitoring for the Tier 2 and Tier 3 items, and report turnaround performance to the sponsor for the first time.

Ninety days is enough to have a functioning committee with a real register and a published turnaround record. It is not enough to have reviewed everything, and a charter that promises otherwise sets the committee up to fail in its first quarter.

If you want the register, the tiering and the charter built alongside your team rather than from scratch, that is precisely the scope of our governance engagement, and it usually starts with the same discovery pass as an AI readiness audit. Hospitals working through this at scale may also find the segment specific notes for hospitals and health systems useful, along with the screening questions in our HIPAA compliant AI tools review.