From Pilot to Scale: How Healthcare Organizations in Viet Nam Should Decide Whether Clinical AI Is Ready for Wider Deployment
PRACTICAL FRAMEWORKS & TOOLS
From Pilot to Scale: How Healthcare Organizations in Viet Nam Should Decide Whether Clinical AI Is Ready for Wider Deployment
IMPLEMENTATION & CAPABILITY BUILDING
Last reviewed: 1 October 2026
A clinical AI pilot can go well and still not be ready to scale.
The system may produce promising results. Clinicians may like it, technical integration may work, and no serious safety incident may occur. The vendor may describe the pilot as a success, and the organization may understandably want to move quickly from one department to several sites.
But a pilot answers a narrower question than scale. It usually shows how an AI system performed under a particular set of conditions: a particular patient population, workflow, group of users, technical environment, period of observation and level of implementation support. Wider deployment changes some of those conditions. It may expose more patients, involve users with different levels of experience, connect to different equipment, operate for longer hours, enter different workflows or depend on data of different quality.
The central question is therefore not simply “Did the pilot work?” It is: “Do we have enough evidence, organizational capability and safeguards to expect this AI system to remain useful and safe when the conditions of use become broader and less controlled?”
That distinction matters increasingly in Viet Nam. The Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, Decree No. 142/2026/NĐ-CP since 1 May 2026, and Decision No. 33/2026/QĐ-TTg establishing the list of high-risk AI systems since 15 August 2026.[1–3] Viet Nam’s framework takes a risk-based, lifecycle approach. Among other requirements, a deployer must coordinate with the provider to review and reclassify an AI system where deployment, modification, integration or changes in function or intended purpose create new or higher risks than those reflected in the existing classification.[2]
International work is moving in the same direction. A September 2026 WHO/Europe Knowledge Community report emphasized governance, validation, workforce capacity and participation as priorities for responsible AI adoption in health, although WHO expressly notes that the report reflects the perspectives of participants and does not necessarily represent a formal WHO position.[8] NIST has also highlighted the importance and practical difficulty of post-deployment monitoring, while IMDRF’s work on AI-enabled medical devices increasingly reflects a total-lifecycle approach.[12–14]
For healthcare organizations, scaling should therefore be treated as another governance decision, not as the automatic next step after a successful pilot.
A successful pilot is evidence, not permission to scale
Pilots are useful because they reduce uncertainty. They can show whether an AI system integrates into a local workflow, whether clinicians understand its outputs, whether performance appears acceptable, whether technical problems emerge and whether the expected clinical or operational benefit is realistic.
Pilots can also create unusually favorable conditions that may not survive expansion. The vendor may provide intensive technical support. Project leaders may personally monitor every problem. Users may be highly motivated early adopters. The pilot department may have better data quality, newer equipment or more protected training time than other departments.
Even the absence of safety events needs careful interpretation. A pilot involving 500 patients with no serious incident cannot establish that a rare problem will remain insignificant when tens of thousands of patients are exposed.
The purpose of a pilot is therefore not to prove that an AI system is “safe.” No realistic pilot can eliminate that uncertainty. Its purpose is to generate enough relevant evidence to support the next decision. Sometimes that next decision should be expansion. Sometimes it should be modification, additional validation, a narrower use case, another stage of piloting or stopping the project.
“Pilot” is not automatically Viet Nam’s formal controlled-testing mechanism
The word pilot needs an important clarification in the Vietnamese context.
In this article, a pilot means a limited organizational implementation or evaluation conducted under defined conditions. It should not automatically be interpreted as participation in the formal controlled-testing mechanism established under Article 21 of the AI Law and Chapter IV of Decree No. 142/2026/NĐ-CP.
Participation in that statutory mechanism is voluntary and involves its own application, approval, scope, limits, risk controls and regulatory oversight. Decree No. 142 also distinguishes research, development or testing conducted in a simulated, closed or internal environment without real-world test participants and without creating effects outside the organization from activities falling within the formal controlled-testing mechanism.[2]
Where an organization does participate in that mechanism, the approval defines matters such as the scope, location, duration, scale and limits of the trial, along with relevant safety, data-protection and risk-management requirements. Authorization to participate in the controlled test applies within the approved scope; it should not be treated as authorization for routine or wider deployment beyond that scope.[2]
Calling a hospital project a “pilot” therefore does not create a regulatory exemption. An organizational pilot remains subject to the legal requirements that otherwise apply to the AI system, personal data, cybersecurity, medical devices and healthcare activity.
First define what “scale” actually means
Healthcare organizations often use scale to mean installing the same system in more hospitals. That is only one form of expansion.
Clinical AI can scale across sites, users, patient volumes, operating hours, technical environments, data sources, integrations or levels of clinical reliance. An algorithm piloted with five radiologists and then made available to fifty radiologists has scaled even if it remains in the same hospital. A system expanded from one hospital to several hospitals within the same intended clinical use has also scaled even if the model itself has not changed.
Some expansions, however, may be more than simple scale. Extending an AI system to a materially different patient population, clinical indication or purpose may change the intended use or operating context enough to require separate evidence and regulatory review.
The organization should therefore define the proposed future state before asking whether the technology is “ready to scale.” Which sites will be added? Which users? Which patients? Which devices and integrations? What case volume and operating hours? What degree of clinical reliance?
A scale decision cannot be evaluated properly until the organization knows what it is scaling into.
Scale criteria should ideally be defined before the pilot begins
One of the easiest ways to overestimate pilot success is to decide what “success” means after seeing the results.
If the original goal was to reduce missed findings but the pilot mainly demonstrates faster reporting, it may be tempting to redefine the project as a productivity success. That efficiency benefit may be real, but it is different from demonstrating the outcome that originally justified the project.
Before the pilot begins, the organization should therefore define what evidence would make wider deployment reasonable. This does not require a formal research protocol for every implementation. It does require enough discipline to agree on the intended benefit, important safety concerns, relevant performance measures, workflow outcomes, operational requirements and circumstances that would prevent or delay expansion.
The same principle applies to safety. The organization should know what events, trends or deterioration in performance would trigger investigation, restriction or reconsideration. Predetermined criteria reduce the risk that enthusiasm for a technology gradually lowers the threshold for scale.
The first scale question is whether the AI created meaningful value
A pilot can demonstrate technical success without demonstrating meaningful healthcare value.
A model may perform accurately but add little because clinicians already identify the same cases quickly. An AI system may increase detection while generating enough false-positive work to make its overall clinical benefit uncertain. A documentation tool may save typing time while requiring substantial verification and correction.
The scale decision should therefore return to the healthcare problem that justified the pilot. Did the AI improve something that matters?
Depending on the intended use, that may mean earlier detection, reduced diagnostic delay, improved consistency, fewer missed findings, shorter turnaround time, better prioritization, lower workload, improved access or another clinically or operationally meaningful result.
Not every AI implementation needs to demonstrate reduced mortality or another major clinical endpoint before it can be used. The outcome should nevertheless be relevant to the system’s intended purpose and the reason the organization adopted it.
A technically impressive AI system that produces little meaningful improvement should not be scaled simply because the pilot ran successfully.
Safety evidence should include more than reported incidents
A pilot with no serious incident is reassuring, but it is not the same as a complete safety assessment.
Healthcare organizations should examine a broader set of signals: incorrect outputs that clinicians caught before harm occurred, near misses, unexpected recommendations, repeated overrides, user confusion, inappropriate reliance, technical failures, delayed results and cases in which the AI behaved differently from what users expected.
These weaker signals matter because scale increases exposure. A failure occurring once in every 2,000 examinations may never appear in a small pilot but can become important when the technology processes hundreds of thousands of cases.
For high-risk AI, Decree No. 142 requires deployers to manage risks during operation, monitor deviations, risks and incidents, maintain human oversight and intervention, implement controls within their authority and coordinate with the provider when significant changes or incidents occur.[2]
Even when those specific high-risk obligations do not apply, the patient-safety principle remains useful. The scale decision should ask not only “Did anyone get harmed?” but also “What safety signals did the pilot reveal, including problems that clinicians successfully intercepted?”
Real-world performance should be examined, not assumed from pre-deployment evidence
Vendor validation evidence remains important, but implementation generates another layer of evidence.
Did sensitivity, specificity, positive predictive value, calibration or another clinically relevant metric remain acceptable in actual use? Did false-positive and false-negative patterns resemble what was expected? Did performance vary across equipment, locations or clinical conditions?
The answer does not always require a large prospective research study. The depth of local evaluation should be proportionate to the potential patient harm, degree of clinical influence and remaining uncertainty.
Healthcare organizations should also distinguish between model performance and system performance. An algorithm may generate excellent predictions but fail operationally because outputs arrive too late, users misunderstand the interface, input data quality is poor or technical integration causes cases to be missed.
Scale decisions therefore need evidence about the AI as actually used, not merely the underlying model.
IMDRF’s final 2025 Good Machine Learning Practice principles support this lifecycle perspective. They address, among other issues, intended use, representative datasets, human–AI interaction, performance of the human–AI team and monitoring of deployed models across the total product lifecycle.[13]
Performance in one population does not automatically transfer to another
Scaling frequently broadens the conditions in which AI is used.
A tertiary hospital may have a different case mix from a smaller hospital. An outpatient center may have different disease prevalence from an emergency department. Imaging equipment, acquisition protocols, documentation patterns, referral pathways and workflow conventions may vary between sites.
These differences matter even if the AI model itself remains unchanged. For classification systems, differences in prevalence can change predictive values. Different equipment or preprocessing can alter input characteristics. Language, documentation practices and workflow differences can affect natural-language or generative AI systems.
Important patient subgroups should also be reviewed where clinically relevant. A strong average performance figure can conceal weaker performance in a smaller subgroup.
A 2026 WHO/Europe scoping review found that equity considerations remain inconsistently integrated into digital-health regulation, implementation and evaluation, and that standardized equity metrics and robust bias auditing for AI-driven technologies remain underdeveloped.[9] That evidence comes from the WHO European Region and should be used as an international implementation reference rather than assumed to describe Vietnamese populations directly.
A practical scale question is therefore: Are the people, settings and technical environments we plan to add sufficiently represented by the evidence we already have?
If not, expansion may still be reasonable, but it should generally involve additional validation and stronger monitoring.
Human factors often change when early adopters are no longer the only users
Pilots frequently begin with motivated clinicians who are particularly interested in the technology. Scale brings the system into routine work.
That can expose usability and human-factor problems that were not obvious during the pilot. Some clinicians may rely on the AI too heavily. Others may routinely ignore it. Some may misunderstand the confidence, limitations or appropriate scope of the output. Users working under heavier workload may interact with the technology differently from carefully supported pilot participants.
The organization should therefore examine whether the AI fits normal work, not simply whether early adopters liked it. Does it add clicks or cognitive load? Does it interrupt established workflows? Does it create alert fatigue? Are users able to recognize inappropriate outputs? Is the result available at the point when it can actually affect care?
Human oversight deserves particular attention. An oversight model that works with ten extensively trained clinicians may become weak when several hundred users are involved. If responsible use depends on unusually intensive supervision or manual checking that cannot realistically be maintained at scale, the organization may need to redesign the workflow or strengthen controls before wider deployment.
Workforce competency must also be scalable
Training should not be treated as a one-time implementation event.
Users need to understand not only how to operate the software but also the system’s intended purpose, limitations, important failure modes, appropriate response to disagreement, escalation pathway and circumstances in which the AI output should not be relied upon.
The organization should ask whether this competency can be maintained across the wider user base. Who will train employees who join six months later? How will competency be verified? How will users be informed when a model update changes functionality or limitations?
If the pilot depended on the project team personally teaching and supporting every user, that model may not survive scale.
WHO/Europe’s September 2026 Knowledge Community report identified AI-literacy gaps, unclear accountability and weaknesses in institutional governance among persistent barriers described by participants, and workforce capacity was one of the priorities identified for responsible implementation.[8] As noted earlier, these findings reflect participant perspectives rather than a formal WHO policy position.
Scale readiness therefore includes workforce readiness, not simply software readiness.
Operational and technical capacity should be tested against scale volume
A system that works with 100 cases per day may behave differently when handling several thousand.
Technical scaling can create problems involving load, latency, storage, interfaces, simultaneous users and service availability. Connections that were stable during a small pilot may become more fragile when more devices or facilities are involved.
Healthcare organizations should assess whether infrastructure can support the expected volume and complexity of the wider deployment. What happens during downtime? Can clinical care continue safely? Can the AI component be isolated without disabling the underlying HIS, EMR, PACS, LIS or medical device? Are backup and recovery procedures realistic at the larger scale?
Vendor support also needs to scale. An engineer who responds personally to every pilot problem may not be able to support a multi-site implementation in the same way.
The scale decision should therefore test the operating model behind the technology, not only the technical capacity of the model itself.
Data governance, privacy and cybersecurity should be revisited when the footprint changes
Scaling frequently changes data flows. Additional facilities may connect to the platform, new patient groups may be included, more staff may receive access, and data may begin flowing through additional interfaces, servers, cloud services or subprocessors.
Those changes can invalidate assumptions made during the original privacy and data-governance review.
Viet Nam’s Personal Data Protection Law No. 91/2025/QH15 has been effective since 1 January 2026, with Decree No. 356/2025/NĐ-CP providing implementing requirements.[4,5] Healthcare organizations should therefore consider whether expansion changes the purposes, categories, recipients, processing arrangements or cross-border flows of personal data rather than assuming that an assessment performed for one pilot configuration automatically covers every future configuration.
Cybersecurity should also be reconsidered. More users, sites, interfaces and remote connections generally increase both the attack surface and operational complexity. Viet Nam’s Cybersecurity Law No. 116/2025/QH15 has been effective since 1 July 2026, and the applicable obligations depend on the system and deployment context.[6]
The relevant scale question is therefore not simply whether privacy and cybersecurity were reviewed once. It is: Is the architecture we are about to scale still the architecture that was assessed?
Vendor capability and contractual arrangements must support the proposed scale
Scaling also increases dependency on the vendor.
A provider that supported one pilot site successfully may not have the local personnel, technical capacity, incident-response arrangements or service infrastructure needed to support a large network.
Before expansion, the organization should revisit the vendor relationship. Can the provider meet service levels at the larger volume? Can it support multiple sites? Will all facilities use the same model version? How will updates be coordinated? Can relevant logs be preserved across locations? Will additional cloud providers or subprocessors be introduced?
The contract may also need to change. Licensing, support, personal-data arrangements, cybersecurity responsibilities, incident support, change notification, version control and termination arrangements should reflect the future deployment rather than the original pilot.
A pilot contract should not quietly become an enterprise AI agreement simply because the pilot was successful.
Scaling may require regulatory review even when the algorithm has not changed
Expansion does not automatically mean that every AI system needs to be reclassified.
However, Article 5 of Decree No. 142 requires the deployer to coordinate with the provider to review and reclassify an AI system where deployment, modification, integration or changes in function or intended purpose create new or higher risks than those reflected in the existing classification.[2]
A move from one site to multiple sites should therefore trigger a regulatory question rather than an automatic conclusion. Has the intended purpose changed? Is the system being used in a materially different population or environment? Have integration, data sources or technical dependencies changed? Has the degree of automation or clinical reliance increased? Does the new deployment create risks that were not part of the original assessment?
For high-risk AI systems, Article 13 of Decree No. 142 is more specific. The provider must reassess conformity when a significant change affects the basis of the original conformity assessment. Relevant examples include changes to principal functions, intended purpose or scope of application; architecture, model or major technical configuration; major input-data sources or processing methods; or integration into a new system or operating environment that may generate new or different risks.[2]
This does not mean that every routine update requires a complete reassessment. The question is whether the change is significant enough to affect the assumptions or findings on which the previous classification or conformity assessment rested.
Where the AI-enabled product is also regulated as a medical device, the organization should separately consider whether wider deployment or associated changes affect obligations under Viet Nam’s medical-device framework. Circular No. 24/2026/TT-BYT, effective since 1 July 2026, addresses determination of risk levels and management measures for medical devices and amends parts of the framework implementing Decree No. 98/2021/NĐ-CP.[7]
Regulatory status should therefore be reconsidered at material change points, not only when the AI is first purchased.
Monitoring capacity should be assessed before exposure increases
A small pilot may be monitored manually by a project team. Wider deployment cannot depend indefinitely on that model.
Before scaling, the organization should know what will continue to be monitored, where the information will come from, who reviews it and what thresholds trigger action.
Relevant measures may include clinically meaningful performance, false-positive and false-negative patterns, subgroup performance, user overrides, unexpected outputs, safety incidents and near misses, downtime, data-quality indicators, workflow effects and significant vendor changes.
Monitoring also needs escalation rules. When does an unusual pattern become an investigation? When is additional validation required? Who can restrict the system? When must the vendor become involved?
The NIST AI Risk Management Framework provides useful general, non-healthcare-specific guidance on third-party AI risk, ongoing monitoring, incidents, change management and decommissioning.[11] NIST’s March 2026 AI 800-4 report, also not specific to healthcare, describes challenges including performance degradation, fragmented logging, human–AI feedback loops and the difficulty of scaling human-driven monitoring alongside rapid rollout.[12]
A healthcare organization should therefore not expand faster than its ability to observe what expansion is doing.
Economic value should be reassessed under routine conditions
Pilots often receive resources that disappear after launch.
Extra vendor support, project staff, protected training time, manual data reconciliation and senior leadership attention may make the pilot look more efficient than routine deployment will actually be.
The scale decision should therefore consider total operating cost, not just software licensing. Will the organization need more integration work, storage, technical support, cybersecurity resources, monitoring, training or staff time? Will multiple sites require additional interfaces or hardware?
The organization should also return to the expected benefit. Did the pilot create enough clinical or operational value to justify those ongoing costs?
A statistically significant improvement does not automatically establish economic sustainability. Scale needs to work under normal organizational conditions.
Organizational governance must also be able to scale
Some pilots succeed because one enthusiastic project leader personally holds everything together. That is not an enterprise governance model.
Once AI expands, ownership, decision rights, monitoring, escalation and documentation need to remain functional even when individual project champions are no longer closely involved.
Who owns the system after the pilot team dissolves? Who approves updates? Who reviews monitoring? Who decides whether another facility may join? Who coordinates with the provider? Who can restrict or temporarily suspend use?
The AI should remain visible within the organization’s AI inventory and connected with existing quality, patient-safety, data, cybersecurity and clinical-governance systems.
A July 2026 statement from the WHO Regional Director for Europe similarly warned about the gap between AI deployment and governance capacity in health systems and called for governance, accountability and workforce preparedness to keep pace with adoption.[10]
An organization that can manage one closely supervised pilot but cannot sustain these governance functions is not yet ready to manage the same technology at scale.
A practical Scale Readiness Gate
Healthcare organizations do not need to turn every scale decision into a major research program. They do need a structured decision.
A practical Scale Readiness Gate can examine whether sufficient evidence and capability exist across several connected domains: clinical value; patient safety; real-world performance; applicability to the wider patient population and technical environment; equity; workflow and human factors; workforce competency; operational and technical readiness; data protection and cybersecurity; regulatory status; vendor capability; monitoring and incident response; economic sustainability; and organizational governance.
This is an organizational governance framework, not a statutory checklist under Vietnamese law.
Its purpose is to prevent one favorable result, such as high accuracy, positive user feedback or reduced turnaround time, from dominating a decision that actually depends on multiple conditions.
The evidence does not need to be perfect in every domain. It does need to be sufficient for the level of risk and uncertainty the organization is proposing to accept. Where uncertainty remains, the next question should be whether it can be safely managed through a controlled stage of expansion.
The result should not be a binary “scale or fail” decision
A pilot does not have to end in either enterprise deployment or abandonment. A more realistic governance framework has four possible outcomes.
Stop means that evidence of value is insufficient, risk is unacceptable or the AI no longer fits the organization’s needs.
Modify and re-pilot means that the use case remains promising but changes in workflow, technology, safeguards, training or implementation are required before further expansion.
Limited expansion means that evidence is strong enough to broaden exposure gradually while additional evidence is collected—for example, moving from one department to a second site rather than immediately deploying across an entire hospital network.
Scale means that the organization has enough evidence, infrastructure, workforce capability and governance to support the proposed wider deployment while maintaining appropriate monitoring and controls.
None of these decisions should automatically be described as failure. Stopping an AI system that does not justify wider exposure can be a successful patient-safety and governance decision.
Multi-site scaling should often happen in waves
For hospital systems, progressive expansion can provide valuable evidence about transferability.
A second site becomes more than another installation. It tests whether the AI remains useful with different users, equipment, patient mix, data quality and operational conditions. It also tests whether the implementation approach works when the original project team is less directly involved.
Each wave can therefore inform the next, while progressive deployment reduces the chance that the organization discovers the same integration, training or workflow problem simultaneously across multiple facilities.
This does not mean that every AI application must scale slowly. Lower-risk technologies with strong evidence and limited implementation complexity may reasonably be expanded more quickly.
The principle is proportionality: the greater the potential harm and the greater the uncertainty, the stronger the case for staged expansion.
Scale should remain reversible
Healthcare organizations sometimes treat scale as the end of evaluation. It should instead be another stage in lifecycle management.
After wider deployment, performance may drift, new safety information may emerge, clinical practice may change or a provider may introduce a significant update. A better alternative may also become available.
Wider deployment therefore needs mechanisms for restriction, rollback and retirement. The hospital should understand whether it can disable the AI at one site without disrupting other facilities, how clinicians return to a safe fallback workflow and how users are informed when access or permitted use changes.
The ability to scale safely includes the ability to scale back safely. Reversibility is not evidence that implementation has failed; it is part of responsible lifecycle governance.
From successful pilot to sustainable clinical capability
The goal of scaling clinical AI is not to maximize the number of installations. It is to turn a promising technology into a sustainable clinical capability.
That requires more than evidence that the algorithm can work. The healthcare organization needs confidence that the AI can work with its patients, clinicians, data, infrastructure and workflows; that meaningful human oversight can be maintained; that safety signals can be detected; that the provider can support wider deployment; and that governance continues to function as exposure increases.
The question for healthcare leaders is therefore not simply “Was our pilot successful?” It is:
“What did the pilot actually establish, what will change when we expand, and do we have enough evidence and capability to manage those changes safely?”
If those questions have clear answers, wider deployment may be justified. If they do not, another stage of learning may be more responsible than immediate scale.
In responsible clinical AI, scale is not the reward for completing a pilot. It is a new decision that must earn its own evidence.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical device, cybersecurity, personal-data or conformity-assessment advice.
The Scale Readiness Gate, staged-expansion approach and four decision outcomes described in this article are practical organizational governance recommendations. They are not statutory requirements under Viet Nam’s AI Law unless a particular obligation is otherwise imposed by applicable law, regulation, technical regulation, contract or specialized regulatory framework.
The term pilot in this article generally refers to a limited organizational implementation or evaluation. It should not automatically be interpreted as participation in the formal controlled-testing mechanism established under Article 21 of the Law on Artificial Intelligence and Chapter IV of Decree No. 142/2026/NĐ-CP.
Scaling an AI system does not automatically require statutory reclassification. Organizations should assess whether the proposed expansion or associated changes create new or higher risks or materially alter the intended purpose, function, data, integration, deployment environment or other relevant conditions. High-risk AI systems may also require conformity reassessment where significant changes affect the basis of the original assessment.
Where an AI-enabled product is also subject to personal-data, cybersecurity, medical-device or other sector-specific requirements, those obligations should be reconsidered based on the actual expanded deployment.
References
National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
Government of Viet Nam. Decree No. 142/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Artificial Intelligence. 30 April 2026; effective 1 May 2026.
Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. 30 June 2026; effective 15 August 2026.
National Assembly of Viet Nam. Law No. 91/2025/QH15 on Personal Data Protection. Adopted 26 June 2025; effective 1 January 2026.
Government of Viet Nam. Decree No. 356/2025/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Personal Data Protection. 31 December 2025; effective 1 January 2026.
National Assembly of Viet Nam. Law No. 116/2025/QH15 on Cybersecurity. Adopted 10 December 2025; effective 1 July 2026.
Ministry of Health of Viet Nam. Circular No. 24/2026/TT-BYT on Determining Risk Levels and Management Measures for Products and Goods That Are Medical Devices and Amending Certain Provisions of Circular No. 05/2022/TT-BYT. 30 June 2026; effective 1 July 2026.
World Health Organization Regional Office for Europe. Report of the Knowledge Community on Responsible Artificial Intelligence in Health. 1 September 2026. WHO/EURO:2026-13381-53155-83077.
World Health Organization Regional Office for Europe. Equity Across the Regulation, Implementation and Evaluation of Digital Health: Scoping Review. 17 March 2026. WHO/EURO:2026-13153-52927-82472.
World Health Organization Regional Office for Europe. Statement – Govern AI in Health Before the Gaps Become Irreversible. 15 July 2026.
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1; 2023.
National Institute of Standards and Technology. Challenges to the Monitoring of Deployed AI Systems. NIST AI 800-4; March 2026.
International Medical Device Regulators Forum. Good Machine Learning Practice for Medical Device Development: Guiding Principles. IMDRF/AIML WG/N88 FINAL:2025; published 29 January 2025.
International Medical Device Regulators Forum. N93: Technical Framework for Artificial Intelligence Life Cycle Management. Proposed document; public consultation closed 10 July 2026.