Approval is easy, monitoring is hard: the Joint Commission’s AI guidance and the work after go-live
The September 2025 Joint Commission and CHAI guidance read like a governance checklist. Most of its weight fell after go-live, on monitoring and event reporting that depend on vendor contract terms few hospitals had negotiated.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On September 17, 2025, the Joint Commission, which accredits most U.S. hospitals, and the Coalition for Health AI released joint guidance on the responsible use of AI in health care. It set out seven elements: 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. The guidance covered AI used in clinical, operational and administrative settings, including tools bought from vendors. It was voluntary. Both organizations described it as a first step, to be followed by more detailed playbooks and a voluntary certification. Commentators noted that guidance from an accreditor tends to shape what surveyors, boards and vendors expect, even before it carries any formal 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 Joint Commission and CHAI 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.
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 and not only advise.
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.
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.
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. An ambient documentation tool is harder. Its 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. 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.
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.
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.
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.
With hindsight
In late May 2026, CHAI released a set of AI governance playbooks covering topics such as oversight committees, risk and impact assessment, lifecycle management, responsible data use and third-party vendor oversight. The following week the Joint Commission launched a voluntary Responsible Use of AI in Healthcare certification. Coverage at the time described it as certifying organizations rather than individual AI products. Its standards grouped expectations into areas including governance, data management, risk and bias reduction, and monitoring and validation of safety and performance. Hospitals considering the certification should check its current requirements directly. The 2026 materials kept the emphasis on lifecycle oversight and vendor management. 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.