Standing Up an AI Governance Committee
The sepsis model had been live for eleven months before anyone in the room could say who had approved it. A quality director asked the question in a routine meeting, almost offhand: who owns this tool, who validated it, who is watching it now. The silence that followed was the finding. A vendor had sold it, an enthusiastic service line had turned it on, IT had wired it into the EHR, and no single body had ever looked at the whole thing, weighed the risk, and signed. That silence is what an AI governance committee exists to end. It is the difference between an institution that can answer, in one afternoon, what AI touches its patients and who is accountable for each tool, and an institution that discovers the answer during a lawsuit or a survey.
Why Governance Is Now a Standard, Not a Nicety
For most of the last decade, a hospital could adopt a clinical algorithm the way it adopted a new stapler: a champion liked it, a budget existed, and it appeared in the workflow. That era is closing. On September 17, 2025, the Joint Commission and the Coalition for Health AI (CHAI) released the first guidance on the Responsible Use of AI in Healthcare (RUAIH), the first time a US accrediting body has told health systems, in writing, what responsible AI governance looks like. It is voluntary today. It is the shape of your future survey. When an accreditor publishes seven foundational elements, the prudent reading is not that they are optional forever; it is that they are the rubric your organization will eventually be measured against, and the organizations that build to the rubric now will not scramble later.
The seven foundational elements are worth naming plainly, because your committee is the machine that operationalizes them. First, AI policies and governance structures: written rules for how AI enters, lives in, and leaves your organization. Second, patient safety and quality: the north star that outranks efficiency, cost, and vendor enthusiasm every time. Third, a designated governance structure that keeps leadership genuinely aware of what AI is doing in the building, not a slide that reaches the board once a year. Fourth, evaluation of tools for risk and bias both before and after deployment, because a tool that was safe at go-live can drift into harm. Fifth, a requirement that vendors disclose known risks, limitations, and bias, so you are not buying a black box on trust. Sixth, validation on data that represents your actual population, not the vendor's development cohort. Seventh, workforce training and ongoing monitoring, because a governed tool used by an untrained clinician is still a hazard. A committee is simply the standing human structure that turns those seven abstractions into decisions with names attached.
The phrase that does the most work in RUAIH, for the purpose of this lesson, is the third element: a designated governance structure. An accreditor does not tell you to hold better opinions about AI; it tells you to name the body that owns the risk. Every other element has to live somewhere, and the committee is where they live. The table below maps each of the seven elements to the concrete committee mechanism that carries it, so you can see that the committee is not a parallel activity to the RUAIH elements but the operational form of all seven at once.
| RUAIH foundational element | The committee mechanism that operationalizes it |
|---|---|
| AI policy and governance | The written charter: mandate, scope, decision rights, quorum, escalation path |
| Patient safety and quality | The quality and patient-safety seat, and the rule that safety outranks efficiency in every vote |
| A designated governance structure | The committee itself, with a named executive sponsor and a standing reporting line to the board |
| Risk and bias evaluation before and after deployment | Risk-tiering at intake plus the monitoring cadence and re-review schedule for live tools |
| Vendor disclosure of known risks and limits | The fixed intake questionnaire that forces disclosure before review, backed by the CISO and legal seats |
| Validation on representative data | The local-validation condition attached at approval, owned by informatics and the equity seat |
| Workforce training and ongoing monitoring | Training conditions in the approval, and the monitoring owner named for every high-risk tool |
Read that table as a checklist you can be surveyed against. If a surveyor asks how your organization satisfies any one of the seven elements, the answer is a specific committee artifact: a charter clause, a seat, an intake question, a monitoring log. An element with no corresponding mechanism is an element you are failing in practice, whatever your policy binder says.
What a Committee Actually Is: A Decision Body, Not a Discussion Club
The most common failure mode of AI governance is a committee that meets, discusses, and decides nothing enforceable. It becomes a forum where interesting concerns are aired and then dissolve, while tools continue to be turned on by whoever has the login. A real governance committee has three properties that a discussion club lacks. It has authority: the power to say no, to require conditions, and to pull a live tool. It has a mandate that everyone above and below it recognizes, so that a service line cannot simply route around it. And it produces a record: every tool it reviews, every decision it makes, and every condition it attaches is written down, dated, and retrievable. If your committee cannot stop a deployment, it is not governing; it is commentating.
Think of the committee as the single front door and the single exit for AI in your organization. Nothing clinical that uses AI should enter patient care without passing through it, and nothing should quietly persist after it has stopped being safe without the committee knowing. That framing matters because the danger is rarely the tool your committee reviewed carefully. The danger is the tool that never reached the committee at all: the free browser extension a resident found, the vendor pilot a department started on a handshake, the model a well-meaning informaticist enabled because the vendor said it was already cleared. Governance is only as strong as its ability to see everything, which is why the intake process is the beating heart of the whole enterprise.
A governance committee that cannot say no, cannot attach conditions, and cannot retire a live tool is not governance. It is a meeting that produces minutes while the risk continues unmanaged.
The Charter: Mandate, Scope, and Decision Rights
The authority described above does not exist because people are reasonable. It exists because it is written down in a charter that leadership has ratified, and because the charter says, in plain language, what the committee is allowed to do. A committee without a charter is a group of well-meaning people whose decisions can be overturned by anyone with a bigger title and a project deadline. The charter is the document that converts good intentions into governance, and its anatomy is not decoration. Each clause exists to close a specific hole through which a real tool has, somewhere, escaped oversight.
Start with the mandate: one or two sentences stating that this body has the authority to review, approve, condition, pause, and retire any AI used in patient care across the organization, and that no clinical AI may enter patient use without its review. Then the scope, which is harder than it sounds and is where most charters are quietly gutted. Scope must define what counts as in-scope AI, and it must be written to capture the tools people will argue are exceptions: not only FDA-cleared devices and models embedded in the EHR, but ambient scribes, inbox and patient-message assistants, prior-authorization and operational tools that shape clinical resourcing, vendor pilots, free browser extensions, and any general-purpose model a clinician points at PHI. If scope lists only "clinical decision support software," every ambient scribe and chatbot in the building is out of scope by omission, and the committee is governing a fraction of its actual risk.
Next, decision rights, stated as verbs the committee may perform without asking anyone: approve, approve with conditions, defer pending information, decline, and, for live tools, pause or retire. The right to attach conditions and the right to pause a live tool are the two that timid charters omit, and they are the two that matter most, because a committee that can only approve or reject at the front door has no power over a tool that misbehaves after go-live. Then a quorum: the minimum seats, and critically which seats, that must be present for a binding decision. A useful quorum names the seats that can never be absent for a high-risk vote, typically clinical leadership, quality and safety, informatics, and at least one of legal or compliance, so that a quiet Tuesday meeting cannot approve a diagnostic model with only IT and the vendor's champion in the room. Then a named executive sponsor, a member of the C-suite who owns the committee's standing and defends its authority when a service line tries to route around it. And finally an escalation path to the board: a defined route by which a contested decision, or a decision to pause a tool that a powerful stakeholder wants to keep, reaches the board or a board committee rather than dying in a hallway. The escalation path is what makes the committee's no durable.
| Charter element | What it must specify | Failure if missing |
|---|---|---|
| Mandate | Authority to review, approve, condition, pause, and retire all clinical AI | Decisions are advisory and get overruled by whoever outranks the room |
| Scope | What counts as in-scope AI, written to capture scribes, chatbots, pilots, and browser tools, not just cleared devices | Whole categories of AI are ungoverned by omission and never reach intake |
| Decision rights | The exact verbs allowed, including attach conditions and pause a live tool | The committee can bless a tool but cannot control it after go-live |
| Quorum | Minimum seats and which seats are mandatory for a high-risk vote | A thin meeting approves a dangerous tool without clinical or safety eyes on it |
| Executive sponsor | A named C-suite owner of the committee's standing | Authority is relitigated at every deadline and erodes |
| Escalation path | A defined route for contested decisions to reach the board | A powerful stakeholder overturns a safety decision in a hallway with no record |
A charter you can hold in your hand and read aloud in five minutes is worth more than a forty-page policy no one has ratified. The test of a charter is not its length; it is whether, when a senior physician turns on a tool the committee never saw, the charter already answers the question of who was allowed to do what, and whether the committee can pull the tool without a fight. If the answer is yes, you have a governance structure. If the answer requires a meeting to determine, you have a suggestion.
Who Sits at the Table and Why Each Seat Is Load-Bearing
An AI governance committee fails when it is either too narrow or too diffuse. Too narrow, and it becomes an IT project-approval board that cannot see clinical harm or equity risk. Too diffuse, and it becomes a town hall that never decides. The right composition is a compact set of seats, each of which catches a category of risk that the others would miss. The goal is not representation for its own sake; it is coverage. Every seat exists because there is a failure mode only that person is positioned to see.
Clinical leadership, a CMO or physician executive, anchors the body in the question that outranks all others: does this help or harm the patient in front of us. Clinical informatics, typically a CMIO or CNIO, translates between the vendor's claims and the reality of your EHR and workflow, and knows where a tool will actually land in a clinician's day. Quality and patient safety connects AI risk to your existing event-reporting, root-cause, and harm-review machinery, so an AI failure is triaged like any other safety event rather than as an exotic IT problem. Nursing is not optional and is too often forgotten: nurses touch more AI-mediated workflows than anyone, from early-warning scores to documentation, and a committee without a nursing voice will systematically miss bedside failure modes. Pharmacy owns the medication-related AI that carries some of the sharpest harm potential, from dosing support to interaction alerts.
Legal and risk management hold the questions of liability, standard of care, and disclosure that no clinician is trained to weigh. Compliance and privacy, including the privacy officer, own HIPAA, the business associate agreement, minimum-necessary access, and the state disclosure laws that now vary by jurisdiction. Health equity, whether a dedicated officer or an assigned owner, exists so that disparate performance across the populations you serve is somebody's explicit job rather than an afterthought that surfaces after harm. Information security, the CISO or a delegate, owns the technical integration, data flows, and the attack surface a new AI vendor adds, and is the seat that will object when a tool wants to ship PHI to a vendor with no business associate agreement or an untested data path. And a rotating frontline clinician from the service line proposing a tool grounds every review in the actual work, because the people who will use a tool see risks the executives never will.
Two seats are named last not because they matter least but because they are the two most often forgotten, and forgetting them is expensive. The first is the patient voice: a patient or family advisor, ideally drawn from your existing patient and family advisory council, who sits at the table for the review of any tool that touches patients directly, especially patient-facing communication tools, care-gap outreach, and models that allocate a clinical resource. The patient representative is the only seat whose loyalty is unambiguously to the person the tool acts on, and they routinely surface the question the clinicians and the vendor have stopped being able to hear: would you want this used on you without being told, and would you understand the message this tool just generated in your name. A committee that governs patient-facing AI with no patient in the room is deciding, on behalf of people it never consulted, what those people will accept. The second easily forgotten seat is pharmacy for medication-related AI, already named above, whose absence turns dosing and interaction models into ungoverned risk.
That compact set, roughly ten to twelve seats, is small enough to decide and broad enough to see. The required core that should never be traded away for speed is clinical leadership (CMO or physician executive), informatics (CMIO or CNIO), nursing (CNO or a nursing leader), quality and patient safety, information security (CISO), legal, health equity, a frontline clinician, and the patient voice, with pharmacy, compliance and privacy, and IT as the supporting seats that join by relevance. When you find yourself tempted to drop a seat for the sake of speed, ask which failure mode you are choosing to stop watching for, and which of the seven RUAIH elements you are quietly leaving with no owner in the room.
| Seat | Failure mode it is positioned to catch | Status / RUAIH element it anchors |
|---|---|---|
| CMO or physician executive | A tool that is efficient but harms the patient in front of the clinician | Required; patient safety and quality |
| CMIO or CNIO (informatics) | Vendor claims that do not survive contact with your EHR and real workflow | Required; validation on representative data |
| CNO or nursing leader | Bedside and early-warning-score failure modes that never reach executives | Required; patient safety and quality |
| Quality and patient safety | An AI failure triaged as an IT ticket instead of a safety event | Required; risk and bias evaluation |
| CISO / information security | PHI leaving to a vendor with no BAA, or an unvetted data path or attack surface | Required; vendor disclosure and policy |
| Legal and risk | Liability, standard-of-care, and disclosure exposure no clinician is trained to weigh | Required; AI policy and governance |
| Health equity owner | Disparate performance across the populations you actually serve | Required; risk and bias evaluation |
| Frontline clinician (rotating) | Divergence between the demo and how the tool behaves in the real unit | Required; workforce training and monitoring |
| Patient voice / representative | Undisclosed or unintelligible use of AI on the person it acts upon | Required; patient safety and quality |
| Pharmacy | Dosing, interaction, and medication-model errors with sharp harm potential | Supporting; joins for medication-related AI |
| Compliance and privacy | HIPAA, minimum-necessary, and evolving state disclosure law | Supporting; AI policy and governance |
| IT integration | Broken data flows, downtime, and integration defects | Supporting; designated governance structure |
What the Committee Decides: Intake, Approval, Monitoring, Retirement
A committee is defined by its decisions, and there are four kinds it must own across the full life of every AI tool. Miss any one of the four, and you have a gap that a real tool will eventually fall through.
Intake: the single front door
Intake is the process by which any proposed AI tool, from any corner of the organization, is registered and triaged before it can touch a patient. A good intake asks a fixed set of questions every time: what clinical problem does this solve, what is the intended use and the intended population, is it an FDA-regulated device and if so what is its clearance and intended use, what does the vendor disclose about known risks and bias, what data was it validated on, what happens when it is wrong, and who is the accountable clinical owner. Intake is where you build and maintain the one artifact every governed organization needs and most lack: an inventory of every AI tool in clinical use, with an owner, a risk tier, and a status. If you cannot produce that inventory today, that is your first deliverable, because you cannot govern what you cannot see.
Risk-tiering and approval
Not every tool deserves the same scrutiny, and a committee that reviews an inbox-drafting assistant with the same intensity as an autonomous diagnostic model will exhaust itself and slow the safe tools to a halt. Tier by potential harm, and write the tiers down so tiering is a rule, not a mood. A workable scheme uses three tiers keyed to how much a wrong output can hurt a patient and how much a human stands between the output and the harm. A low-risk tool drafts scheduling or administrative text that a human always reviews before it reaches anyone. A medium-risk tool shapes documentation or surfaces information a clinician still owns, such as an ambient scribe or a summarization assistant, where a confabulated finding is possible but a clinician attests to the final record. A high-risk tool influences diagnosis, triage, dosing, discharge, or the allocation of a clinical resource, where a wrong output can steer care before anyone catches it. The tier sets the depth of review and, just as importantly, the cadence of re-review after go-live.
| Risk tier | Examples | Required review depth at intake | Re-review cadence after go-live |
|---|---|---|---|
| Low | Scheduling-message drafts, administrative text, always human-reviewed | Light-touch registration, intended-use and owner recorded, fast lane in days | Annual attestation that use and risk are unchanged |
| Medium | Ambient scribe, note or inbox summarization, patient-message drafting | Intake questionnaire, disclosure review, workflow and attestation check, a defined error-report path | Every six to twelve months, plus review on any material vendor change |
| High | Diagnosis, triage, dosing, discharge, or resource-allocation models | Local validation, subgroup bias testing, a monitoring plan, a named clinical owner, and often a shadow-mode trial before exposure | At least every six months by the committee, monthly metric reporting by the owner, and immediate re-review on any threshold breach or undisclosed vendor change |
Approval is rarely a clean yes or no; the committee's most useful output is the conditional approval, a yes that carries requirements: validate locally first, run in shadow mode for a defined period such as ninety days, report these specific metrics monthly, disclose to patients per state law, retrain these staff before go-live. A conditional approval that does not name who checks each condition, and by when, is a wish, not a control. The discipline is to write each condition as an assignment with an owner and a date, so that the person who was supposed to run the subgroup analysis cannot later say they thought someone else had it. The conditions, checked, are where governance actually protects patients.
Monitoring, escalation, and retirement
The decision that organizations forget is the last one. A tool approved in 2025 is not approved forever. The committee must assign, for every high-risk tool, a monitoring owner, a set of metrics, thresholds that trigger review, and a schedule. Concretely, a high-risk tool should carry a monitoring plan that says who reports (the named owner), what they report (performance and subgroup metrics, override rates, and safety-event signals), how often (monthly to the committee is a defensible default for high-risk tools), and what number forces action (a stated threshold, for example a drop in performance or a subgroup gap beyond a set margin, that triggers re-review rather than a conversation). The point of a written threshold is that it converts a judgment call under social pressure into a pre-committed rule: when the number crosses the line, the tool comes back to the committee whether or not anyone wants it to.
Escalation is the pressure-release valve that keeps monitoring honest. The charter should name who holds emergency pause authority, so that a serious safety signal does not wait for the next monthly meeting. A workable rule gives the committee chair, together with the quality and patient-safety seat and the executive sponsor, the authority to pause a live tool immediately when a safety signal warrants it, with a mandatory review at the next meeting and a defined route to the board if the pause is contested. That is the difference between a governance structure that can stop harm on the day it is detected and one that can only note it in minutes. When a stakeholder with more power than the committee wants to keep a tool the evidence says should stop, the escalation-to-board path is what prevents the decision from being quietly reversed in a hallway.
And the committee must be willing to retire a tool: to turn off a model that has drifted, whose vendor has changed it without disclosure, or that a newer standard has made unsafe. Retirement is a decision, not a default. A tool that no one ever decided to keep is a tool that is running on institutional inertia, and inertia is not a safety strategy.
It helps to see the four decisions as a single loop rather than four unrelated tasks. Intake feeds approval, approval sets the conditions that monitoring will check, and monitoring produces the evidence that eventually forces either continued operation or retirement. A committee that owns intake but neglects monitoring is like a hospital that credentials a physician once and never looks again; the failure will not announce itself, and by the time it surfaces as harm, the trail of who knew and when is exactly the trail a plaintiff or a surveyor will follow. The whole point of closing the loop is that no tool can quietly outlive the scrutiny that made it safe to turn on. Every high-risk tool should have, at all times, an answer to three questions: who owns it, what are we watching, and what would make us turn it off.
A Worked Example: The Readmission Model That Almost Skipped the Door
Watch how the structure works on a real-shaped case. A population-health team proposes a readmission-risk model to prioritize which discharged patients get an intensive follow-up call, a genuinely useful triage of a scarce nursing resource. Without governance, the story is familiar: the vendor demos beautifully, the service line is excited, IT enables it, and within a month care managers are working a list they trust. With governance, the tool enters through intake, where the committee registers it, assigns it a high-risk tier because it allocates a clinical resource, and names an accountable owner.
Now the seats earn their keep. Informatics asks what population the model was trained on and discovers it was developed at an academic center with a very different payer mix. The equity owner asks the question that turns out to matter most: does the model use prior healthcare utilization or cost as a proxy for need. It does, in part. That is the exact design choice that, in a well-documented real-world case, caused a widely used population-health algorithm to under-refer Black patients, because they had historically generated lower costs at the same level of illness, so the model read them as lower-need. The committee does not reject the tool; it issues a conditional approval. Validate on our population. Test performance across the racial, language, and insurance subgroups we serve. Run in shadow mode against current care-manager judgment for ninety days. Report subgroup performance monthly. Only then go live, and even then, keep monitoring. The tool that would have quietly amplified a disparity becomes a tool that is watched for one. That is not bureaucracy. That is the difference between a committee that produces minutes and a committee that protects patients.
Standing It Up Without Stalling Innovation
The fear every leader raises is that governance becomes the department of no, a bottleneck that pushes clinicians toward the ungoverned browser tools precisely because the official path is too slow. That fear is legitimate and the answer is design, not dilution. Make the low-risk path genuinely fast, so that the safe, human-reviewed, low-harm tools clear in days, not months, and the committee reserves its depth for the tools that can actually hurt someone. Publish the intake form and the criteria, so a service line knows before it starts what a strong proposal looks like. Charter the committee formally, with a named executive sponsor, a defined membership, a decision-making quorum, and a documented escalation path to the board, so its authority is not perpetually relitigated. And keep the record: a living inventory and a decision log that lets you answer, on any given day, what AI touches your patients and who is accountable. An organization that can answer that question calmly during a survey, a lawsuit, or a family meeting has already won the argument that governance is worth its cost. The committee is not the enemy of innovation. It is the thing that lets you say yes to AI without betting the institution on a tool no one ever really examined.
One caution for leaders standing this up for the first time: resist the urge to make the committee perfect before it is useful. The organizations that succeed do not wait for a flawless charter, a complete taxonomy, and a full-time equity officer before they begin. They start with the compact set of seats they can convene next month, a one-page intake form, a spreadsheet inventory, and a decision log, and they let the structure mature as it runs. The alternative, a governance program that spends a year designing itself while ungoverned tools continue to accrete in the building, is not caution; it is the risk it claims to prevent, dressed as diligence. Begin with the front door, insist that everything comes through it, keep the record, and improve from there. A committee that meets, decides, and writes it down, even imperfectly, is protecting patients today, which is the only test that finally matters.
Key Takeaways
- The first accrediting-body AI guidance, Joint Commission and CHAI RUAIH (released September 17, 2025), sets seven foundational elements: AI policy and governance, patient safety and quality, a designated governance structure, risk and bias evaluation before and after deployment, vendor disclosure of risks and limits, validation on representative data, and workforce training with ongoing monitoring. It is voluntary now and is the likely shape of future accreditation.
- A governance committee is the standing human structure that operationalizes those seven elements into decisions with names attached; it needs a written charter specifying its mandate, scope of in-scope AI, decision rights (approve, condition, pause, retire), quorum, executive sponsor, and an escalation path to the board, so its authority is not relitigated at every deadline.
- Treat the committee as the single front door and single exit for clinical AI: the real danger is the tool that never reached it, so a complete, owned, risk-tiered inventory of every AI tool in clinical use is the foundational deliverable.
- Each seat exists to catch a failure mode only that person can see. The required core is clinical leadership (CMO), informatics (CMIO or CNIO), nursing (CNO), quality and safety, information security (CISO), legal, health equity, a rotating frontline clinician, and the patient voice, with pharmacy, compliance and privacy, and IT joining by relevance. Dropping a seat means choosing a risk to stop watching for.
- The committee owns four decisions across the full tool life: intake and registration, risk-tiering and approval, ongoing monitoring, and retirement. Tier tools by potential harm, re-review high-risk tools at least every six months with monthly metric reporting against written thresholds, and name who holds emergency pause authority. Retirement is an active decision; a tool no one decided to keep is running on inertia.
- The most useful output is the conditional approval: yes, with requirements such as local validation, subgroup bias testing, shadow-mode trial, monthly metric reporting, patient disclosure, and staff training. The conditions are where governance actually protects patients.
- Tier scrutiny by potential harm so the low-risk, human-reviewed tools clear fast and the committee reserves depth for tools that influence diagnosis, triage, dosing, or discharge; a slow committee pushes clinicians toward ungoverned tools.
- An organization that can answer calmly, on any day, what AI touches its patients and who is accountable for each tool has already justified the cost of governance to a surveyor, a plaintiff, and a family.
Skill.re