In June, The Joint Commission announced what it calls a first-of-its-kind voluntary certification, the Responsible Use of AI in Healthcare (RUAIH) Certification, designed exclusively for healthcare organizations in the United States. The most important detail was that the program “does not validate or certify individual AI products or tools.”
That boundary is appropriate and precise. The certification looks at whether a hospital or health system has the governance, data management, risk controls, monitoring, validation processes, transparency, and training needed to use AI responsibly. Those capabilities matter now that organizations are adopting AI faster than many can build the structures to oversee it. Interviews with 27 health-system leaders by the Center for Connected Medicine and KLAS Research, conducted in May and June, found that 25 had deployed third-party AI. Of those 25, 23 said the tools were tested and validated before deployment, but only 11 had a dedicated platform or environment in which to do it.
Hackensack Meridian Health announced on July 29 that it had become the first health system to earn the certification. By its own account, the assessment took three weeks, building on governance work done in the years before. That is what an organization-level certificate recognizes: a capability that takes years to build, not a verdict on any single tool the hospital runs.
The problem begins when that precise assurance is shortened to a much broader claim: “our AI is certified.”
The word “certified” is doing too much
Healthcare buyers now encounter certificates, conformity marks, clinical safety standards, security assessments, and governance frameworks. They can sound interchangeable in a procurement meeting, but they assess different things. ISO/IEC 42001 examines whether an organization has repeatable processes for managing AI. HITRUST’s AI Security Assessment and Certification tests security controls on a defined, operational AI system. In the NHS, DCB0129 places clinical risk management requirements on developers of health IT, while DCB0160 requires the deploying organization to manage the risks of its local use.
Each adds assurance to a different layer. A hospital can have mature AI governance while a particular model performs poorly for one patient group. An AI system can pass a security assessment without establishing its clinical effectiveness. The scope is the substance. Remove it, and a useful certificate becomes a misleading shorthand.
Healthcare has plenty of principles and far less proof
A 2026 scoping review by researchers at Macquarie University examined 77 healthcare AI governance frameworks. Only 10, or 13%, combined four basic elements: guiding principles, an assessment method, coverage of lifecycle stages, and an organizational oversight mechanism. Among the ten most comprehensive, four had been implemented in a healthcare organization. Across all 77 frameworks, the reviewers did not find evidence that any had been evaluated for its effectiveness in facilitating safe and responsible AI. Their review was not designed specifically to find every effectiveness evaluation, so this is not proof that none exists. It is still a warning about how rarely governance is connected to evidence of what it achieves.
That is why an organization-level certification matters, and why it is not enough. Certification can test whether the machinery of governance exists. It cannot replace the evidence required for the system being governed. The FUTURE-AI consensus guideline, developed by 117 experts from 50 countries, lists controls that only exist at the point of use: local clinical validation, drift detection, logging, and named responsibility after deployment. They depend on the model version, patient population, and workflow, and a certificate held by the hospital or supplier cannot make those variables disappear.
Put an assurance map beside every certificate
Whenever a supplier or healthcare organization says an AI system is certified, the supporting record should identify who holds the certificate; the exact product, service, or deployment in scope; the version and intended use examined; what was independently tested and what was self-declared; the claims expressly left outside scope; the expiry date or changes that trigger reassessment; and who owns the remaining risk locally.
That short map would prevent several different claims from collapsing into one label. If the organization is certified but the product has not been locally validated, the gap is visible. If security controls were tested but clinical performance was not, the distinction survives procurement. If the model or workflow changes, the original assurance can be revisited instead of quietly carried forward.
The Joint Commission has been unusually clear about the boundary of the RUAIH certification. Healthcare organizations should preserve that clarity when they describe it. The certificate is evidence that an organization has built a system for responsible AI governance. Whether a particular AI system is safe and effective for a particular patient population, workflow, and moment remains a separate question, and it still needs its own evidence.
Author:
Dr. Mahé Pereira is a Product Manager at Videolab.
