Approval is easy, monitoring is hard: the Joint Commission’s AI guidance and the work after go-live

The week

On September 17, 2025, the Joint Commission, which accredits most U.S. hospitals, and the Coalition for Health AI, known as CHAI, released joint guidance on the responsible use of AI in health care.

By then artificial intelligence had moved well beyond pilot projects in American hospitals. It was drafting replies to patient messages, listening in on appointments to write up clinical notes, flagging patients who might be deteriorating, and helping staff with billing codes and insurance paperwork. What hospitals lacked was a shared sense of what responsible use looked like once those tools were switched on, and the guidance offered one. Accreditation is the seal of approval hospitals need to show that they meet quality and safety standards, and it is closely tied to their standing with payers and the public. When the accreditor speaks, hospital leaders listen.

The guidance set out seven elements. They were AI policies and governance structures; patient privacy and transparency; data security and data use protections; ongoing quality monitoring; voluntary, blinded reporting of AI safety-related events; risk and bias assessment; and education and training. “Blinded” reporting means sharing details of a problem with others outside the organization in a form that does not identify the patients or, often, the hospital involved, so that everyone can learn without anyone being exposed.

The scope was broad. The guidance covered AI used in clinical, operational and administrative settings, including tools bought from vendors. Software that touches diagnosis and treatment was one part of it; a tool that helps with scheduling, coding or prior authorization fell inside it too.

It was voluntary. Both organizations described it as a first step, to be followed by more detailed playbooks and a voluntary certification. Even so, commentators noted that guidance from an accreditor tends to shape what surveyors, boards and vendors expect, even before it carries any formal weight. Surveyors are the inspectors who visit hospitals on the accreditor’s behalf, and their expectations have a way of becoming everyone’s.

The practical question for hospital leaders that week was which parts of the guidance their existing AI committees were already doing, and which parts nobody had yet been asked to do.

Take a nurse on a busy medical ward at a community hospital. A software tool on her screen has started flagging patients it thinks may be developing sepsis, a dangerous reaction to infection. When it was switched on a year ago, the alerts were mostly right. Lately they seem to come more often and to be wrong more often. She has started ignoring some of them. She is not sure whom to tell, or whether anyone is counting.

That scenario is not a failure of approval. The tool was reviewed carefully before it went live. It is a failure of everything that is supposed to happen afterward, and it is exactly where the Joint Commission and CHAI guidance put its weight.

By 2025 most large health systems had an AI committee. Those committees were built around a decision: should this tool be used here? The guidance accepted that decision as necessary and then spent most of its elements on what follows it. Quality monitoring, safety event reporting and periodic bias assessment all happen after go-live, for as long as the tool runs. That is where hospital programs were thinnest, and where the hospital depends most on its vendors.

The work falls into four parts: the approval decision, the evidence after go-live, the supplier’s obligations, and the named owner for each tool. First, though, what hospital AI is and why it can change over time.

What hospital AI is, and why it drifts

“AI” covers a wide range of software. In a hospital, the most common kinds are predictive models and generative tools. A predictive model looks at data, such as vital signs and lab results, and estimates the chance of something happening, such as a patient deteriorating. It is trained on large amounts of past patient data, learning which patterns tended to come before a bad outcome. A generative tool produces new text, such as a draft reply to a patient’s message or a clinical note written from a recorded conversation.

Both kinds share a property that ordinary software does not. A traditional program follows fixed rules, so if it worked correctly yesterday, it will work the same way today. An AI tool learned its behavior from data, and its accuracy depends on today’s patients and today’s records looking like the data it learned from. When they stop looking alike, performance can slip without any error message. Specialists call this drift.

A useful comparison is a new physician who trained at a large city hospital and then moves to a rural practice with older patients and different common conditions. Her skills are real, but some of her instincts will need recalibrating, and a good practice would watch her early cases closely. AI tools need the same watching, except they never notice the change themselves.

Two more terms are worth knowing. Validation is the testing a developer does to show a tool works, usually on a particular group of patients, called the validation population. Bias, in this setting, means a tool performing noticeably better for some groups of patients than others, perhaps because those groups were under-represented in the data it learned from. Neither is a reason to avoid AI, but both are reasons to keep measuring its performance after go-live.

The approval decision

Approval is the part hospitals do reasonably well. Committees review intended use, validation evidence, privacy and security, and clinical workflow fit. The guidance pushed on two edges of that process. It applied to administrative and operational tools as well as clinical ones, so prior authorization automation, coding assistants and patient messaging tools belong in scope. It also expected governance with real authority, able to pause or retire a tool rather than merely advise.

That second point is more significant than it sounds. A committee that can only advise is a discussion group. If the people watching a tool’s performance cannot switch it off when it misbehaves, then monitoring produces reports and nothing else. Boards should confirm in writing who has the authority to pause a tool and how quickly that can happen.

One practical change follows. Approval should end with written monitoring criteria: the measures that will be tracked, the thresholds that trigger review, and the date of the first reassessment. A tool approved without those criteria has nothing to be monitored against later, and at the first annual review nobody can say whether things are going well.

Not every tool needs the same depth. A risk tier set at approval, based on clinical impact and on how much the output is acted on without human review, lets the committee spend monitoring effort where harm is plausible. A scheduling assistant and a deterioration alert should not carry the same reporting burden. Tiering keeps the program affordable and keeps scarce clinical attention on the tools where mistakes could hurt someone.

The evidence after go-live

Three of the seven elements generate evidence over time. Quality monitoring asks whether the tool still performs as it did when approved. Risk and bias assessment asks whether it performs adequately across the hospital’s own patient groups, which may differ from the vendor’s validation population. Event reporting asks clinicians to flag cases where AI output contributed to an error or near miss, and encourages sharing those reports outside the organization in blinded form.

Each needs data the hospital may not have. A sepsis alert can be monitored against outcomes in the electronic health record if someone builds the query. The electronic health record, or EHR, is the hospital’s central digital chart, holding each patient’s history, orders, results and notes. Comparing who was flagged with who actually became ill is possible, but it takes analyst time that has to be planned and paid for.

An ambient documentation tool is harder. These tools listen to the conversation between clinician and patient and draft the visit note. Their quality shows up in note accuracy, which requires sampled human review, and in clinician edits, which only the vendor may log. A message-drafting tool may need patient complaint data linked to drafts. Hospitals should decide, tool by tool, which signals they can collect themselves and which they must obtain from the supplier.

Monitoring also needs to watch the hospital’s own changes. An EHR upgrade, a new documentation template, a revised order set or a shift in patient mix can degrade a tool that the vendor never touched. An order set is a standard bundle of orders for a common situation, such as admitting a patient with pneumonia; changing it changes the data an AI tool sees. Change management for those systems should flag which AI tools consume their data, so the tool owner reviews performance after each change.

Event reporting has a cultural barrier as well. Clinicians report when they believe something will happen. If an AI-related report disappears into a general incident queue, reporting stops. A distinct category in the existing safety reporting system, triaged by someone who understands the tool, keeps it alive. Return to the nurse on the ward: if she could choose “AI tool concern” in the reporting system she already uses, and saw that someone acted on it, the drifting sepsis alert would have been caught much sooner.

The supplier’s obligations

Most hospital AI is bought, and the guidance applied to vendor tools explicitly. That makes the contract the main instrument for the post-deployment work. Standard software agreements rarely provide what monitoring requires.

Four terms matter most. The vendor should provide performance data for the hospital’s own deployment at a defined frequency. It should give advance notice of model changes, with release notes that describe what changed and how it was validated. It should support the hospital’s bias assessment, at minimum by describing its validation populations and known limitations. And data use terms, including business associate agreements where protected health information is involved, should state whether the vendor may use hospital data to train or improve models. Counsel should review each of these.

A business associate agreement is the contract HIPAA requires when an outside company handles identifiable patient information, called protected health information, on a hospital’s behalf. It sets out what the company may and may not do with that data. Whether patient records may be used to improve a vendor’s product is precisely the kind of question patients, regulators and the press care about, and it should never be left to a default clause.

Model changes deserve particular attention. Vendors improve their tools, which is welcome, but an update can change how a tool behaves on a hospital’s patients. Without advance notice and clear release notes, the hospital may find out only when its own measures move, or when a clinician files a report.

Bargaining power is uneven. Large systems can negotiate. Smaller hospitals often accept standard terms, so group purchasing organizations, health information exchanges and state hospital associations may be the practical route to common clauses. Existing contracts can be brought in line at renewal, which makes a renewal calendar for AI tools a governance document.

The named owner for each tool

Committees approve tools; they do not watch them day to day. Each deployed tool needs a named operational owner, usually in the department that uses it, with time allocated to review monitoring reports, triage events and receive vendor notices. That role often goes unfunded because it appears nowhere in the purchase price.

That last point is where many programs fail without anyone noticing. A tool is bought with a license fee and an implementation budget. The hours a physician or nurse leader spends each month reviewing its performance are real costs, but they are absorbed into someone’s already full job. Within a year, the reviews slip. Leaders who want monitoring to happen should budget for it at the time of purchase, as part of the total cost of the tool.

The education and training element supports the owner. Frontline staff should know which tools in their workflow use AI, what each is for, and where to report a concern. A short inventory that pairs each tool with its owner, monitoring measures and contract terms gives the committee, the board and an eventual surveyor the same view. A useful board measure is the share of deployed tools with a current monitoring review on file.

Who answers when a tool drifts

When an AI tool drifts, patients bear the harm first, and the hospital then answers for it to surveyors, payers, its own staff and its lawyers.

Patient safety comes first. A tool that slowly becomes less accurate does not announce itself. Clinicians either over-trust it, acting on wrong suggestions, or under-trust it, ignoring the right ones along with the wrong. Both outcomes can harm patients, and both are invisible without monitoring.

Then there is accreditation and reputation. Commentators were right that an accreditor’s guidance shapes what surveyors and boards expect, even when it is voluntary. A hospital that cannot show who owns its AI tools, how they are watched and what its contracts say will find those questions harder to answer each year. A public story about an AI tool behaving badly on a particular group of patients would be far harder still.

Money is part of it too. AI tools are often bought to save clinician time or reduce administrative cost. If a documentation tool’s notes gradually become less accurate, clinicians spend more time correcting them and the promised savings evaporate. If a coding assistant drifts, billing accuracy can suffer. Monitoring is how a hospital knows whether it is getting what it paid for.

And there is the workforce. Staff who are asked to use AI tools want to know that someone is watching them and that their concerns will be heard. A visible reporting route, and visible action when reports come in, builds the trust that makes adoption work. Its absence breeds unofficial workarounds.

Finally, there is legal exposure. Data use terms that allow a vendor to train on patient records, without the hospital having decided that deliberately, can become a privacy question long after the contract was signed. General counsel should want to know which existing contracts say what, and when each one comes up for renewal.

A program with teeth

In a well-run program, the AI inventory is a living document, not a one-time survey. Every tool on it has a risk tier, a named owner, written monitoring criteria, a date for its next review and a summary of its contract terms on data use and model changes. The committee meets on a schedule, receives short reports from owners, and occasionally pauses a tool, which is a sign that the process has teeth rather than a sign of failure.

Suppose a mid-sized health system adopts an ambient documentation tool across its primary care clinics. At approval, the committee sets a tier, names the clinic medical director as owner, and agrees two measures: a monthly sample of notes reviewed for accuracy, and the share of notes clinicians substantially rewrite, which the contract requires the vendor to report. When the vendor announces a model update, the owner receives notice in advance and schedules an extra sample review the following month. Nothing dramatic happens, which is what the process is for.

Weaker programs look the opposite way. Approval ends with a vote but no monitoring criteria. Administrative tools are left out of scope because they “aren’t clinical.” Contracts are signed on standard terms with no right to performance data or notice of changes. AI concerns are lumped into general incident reports where they are never triaged by anyone who understands the tool. And owners are named without being given the time to do the job.

Inventory, monitoring, contracts and pause authority the board can check

• Do we have a complete inventory of the AI tools in use across clinical, operational and administrative areas, and for each one, a named owner with time set aside to do the job?
• Did each approval end with written monitoring measures, thresholds for review and a first reassessment date, and what share of deployed tools has a current monitoring review on file?
• Which performance signals depend on the vendor, and do our contracts require them, along with advance notice of model changes and clear terms on training with our patient data?
• Can a clinician report an AI-related concern as its own category, and who triages those reports?
• Who has the authority to pause or retire a tool, and how quickly could they do it?

The board does not need to understand how a model works to ask these questions. It needs to insist that the work after go-live is owned, funded and evidenced, in the same way it would for any other tool that touches patient care.

With hindsight

In late May 2026, CHAI released a set of AI governance playbooks covering topics such as organizational structures, risk and impact assessments, lifecycle management, responsible data management and third-party management. CHAI presented them as a framework for the voluntary certification the Joint Commission said it would soon release. Hospitals considering that certification should check its current status and requirements directly with the Joint Commission.

The topics are telling. “Lifecycle management” is the formal name for everything that happens to a tool from purchase to retirement, and “third-party management” is the formal name for overseeing vendors. Two of the playbook topics address the same post-go-live and supplier work that the September 2025 guidance had emphasized.

The 2026 materials kept the emphasis on lifecycle oversight and vendor management. That continuity matters for planning. Hospitals that had treated the 2025 guidance as a signal of direction, rather than waiting for something more formal, found that the direction held.

Hospitals that had written monitoring criteria into approvals and update and data terms into contracts started from evidence. Those whose governance ended at approval had to reconstruct it. Reconstructing evidence is slow and often incomplete: past performance data may not exist, vendor terms cannot be renegotiated until renewal, and the clinicians who noticed problems may not have recorded them anywhere.

Responsible AI in health care is less about a single decision and more about a long, steady habit of watching. Approval is a moment. Monitoring, reporting and vendor oversight continue for as long as the tool runs, and they need owners, budgets and contract terms to match. Whatever form certification eventually takes, the hospitals best placed for it are those already able to show that work on paper. A board that asks for that evidence once a year, tool by tool, will know where it stands.