AI Regulation Tracker  /  Healthcare AI

Singapore Rewrites Its Health AI Rulebook Around Who Is Accountable

In March 2026, Singapore's Ministry of Health and the Health Sciences Authority published Version 2.0 of the Artificial Intelligence in Healthcare Guidelines (AIHGle 2.0), issued to all licensees through MOH Circular MOH-MHC-0024-2026. The refresh splits duties cleanly across AI developers, deployers, and the clinicians who use the tools, and it pulls change management and cybersecurity into HSA's existing GL-04 medical-device lifecycle rules. It is advisory best-practice guidance, not a new statute, but it sits directly on top of Singapore's binding medical-device registration regime.

By Anthony Guerriero  ·  The Leveraged Years Regulatory Research  ·  Published July 20, 2026  ·  Last updated July 20, 2026

Singapore has run a national AI-in-healthcare guideline since 2021, so the news here is not that the country decided to say something about health AI. The news is what the second version does with responsibility. The first version read like a set of principles. This one reads like an org chart. It takes the same ethical goals and hard-wires them into named roles, so that when an AI tool gives a bad recommendation, there is no longer a fog about who was supposed to catch it.

The guideline is deliberately scoped to the harder cases. It notes that while it is broadly applicable to all AI, it is, in its own words, "targeted at the more complex subset of AI solutions that employ ML or DL algorithms, which have amplified risks due to their complexity, opacity, and scalability." That is the regulator telling you where the attention goes: the machine-learning and deep-learning systems, including generative AI, that most of the market is now shipping into clinics.

Three roles, three sets of duties

The spine of AIHGle 2.0 is a clean division of labour. Developers are the healthcare AI manufacturers. Deployers are the healthcare organisations that put the tool into service. Users are the healthcare professionals who rely on it in front of a patient. Each group gets its own chapter and its own list of obligations, and the guideline wants those obligations written down rather than assumed.

On that point it is explicit. Stakeholders, it says, have different responsibilities and levels of involvement across the lifecycle, and so "it is recommended to document and formalise their specific roles and responsibilities." The suggested mechanics are the ones a working professional will recognise: developers and deployers pin their obligations to each other in service level agreements, and deployers document what they expect of clinicians through standard operating procedures. The stated goals of that paperwork are clear accountability across the AI lifecycle, responsibilities assigned to whoever is best equipped to handle them, and mitigation of risk with compliance to the relevant regulations.

Transparency gets the same treatment. The guideline sets an expectation that runs across all three roles: every stakeholder should "provide sufficient relevant information for each stakeholder in the AI lifecycle to support informed decision-making," and users "should be informed of interaction with AI, aligning with the medical principle of autonomy." In practice that means front-end labels flagging where AI is generating a recommendation, disclosure to patients, and enough visibility into datasets and evaluation that a clinician can actually understand what the tool is and is not good at.

Change management and cybersecurity ride on GL-04

The part US vendors should read twice is the technical governance. AIHGle 2.0 does not invent a parallel engineering regime. It tells developers to manage their solutions through what it calls a total product lifecycle, which "encompasses thorough risk assessment, rigorous software verification and validation, change management, and traceability to facilitate transparency and accountability throughout the solution's life cycle." For the registration and cybersecurity detail, it hands you straight to HSA's existing medical-device guideline, noting that developers should refer to the HSA Regulatory Guidelines for Software Medical Devices, A Life Cycle Approach, better known as GL-04, "for information on regulatory requirements for risk management and cybersecurity."

This is where the change-control duty bites. Machine-learning tools do not sit still. The guideline flags that continuous-learning models "update their algorithms based on new data encountered during deployment, potentially improving performance over time," but that this "also presents added risks, like model drift" where performance quietly degrades. So it expects developers to snapshot and document the model before any change, so a change can be reversed, and it expects deployers to treat rollout itself as a discipline, because "successful AI deployment requires comprehensive change management. This encompasses technological adoption, workflow transformation and organisational culture shifts." If you have been building against the US idea of a predetermined change control plan, this is the same instinct expressed through Singapore's lifecycle framework: you plan your changes, you document them, and you stay accountable across versions.

What this is, and what it is not

Be precise about status, because it is easy to oversell. AIHGle 2.0 is guidance. It states responsibilities and recommends how to formalise them. It does not, by itself, create a new fine or a new cause of action. If someone tells you Singapore just passed a health-AI law in March, that is not what happened.

But do not file it under thought leadership either. It went out through an MOH circular to all licensed providers, which is how Singapore signals an operating expectation, not a suggestion. And it explicitly complements binding law. Any AI tool that meets the definition of an AI medical device or Software as a Medical Device still has to be registered with HSA, and the data-protection obligations it references are real. The guideline is the connective tissue that tells developers, deployers, and clinicians how the regulator expects them to behave around those binding rules.

Why a US professional should care

If you build or sell digital-health or AI-diagnostics products, Singapore is a common first stop in Asia, and this changes the diligence a buyer there will run on you. A hospital deploying your tool now has a government guideline telling it to pin down, in writing, who is accountable for what, to run its own risk assessment before go-live, and to manage your model changes over time. That means your Singapore counterparties will push contract terms your way: service level agreements that assign lifecycle responsibilities, documentation of model versions and change control, evidence of cybersecurity practices mapped to GL-04, and transparency artifacts a clinician can actually use.

For US counsel advising these vendors, the practical read is that the accountability split and the change-control expectation are becoming table stakes in the Singapore market, layered on top of the binding HSA device registration you already have to clear. None of it has direct legal force in the United States. The reason to care is that it is a clean, exportable template, close in spirit to how US regulators think about lifecycle change control for AI-enabled devices, and your clients will be asked to meet it the moment they sell into Singapore.

What to do now

Do not tell a client Singapore banned anything, because it did not. Tell them Singapore just published a detailed expectation of who owns what across the health-AI lifecycle, and that it complements binding device rules. If you or your clients ship health AI into Singapore, map your product against the three roles now: what the developer owns, what the deploying hospital owns, and what the clinician owns, and get those splits into your service level agreements and standard operating procedures. Line your change-management and cybersecurity documentation up against GL-04 rather than inventing your own scheme. Build the transparency artifacts, the front-end AI labels and the dataset and evaluation disclosures, because deployers will ask for them. And confirm whether your tool meets the AI medical device definition, because that registration duty is the part that actually binds.

Browse the full AI Regulation News tracker

Informational analysis for working professionals, not legal advice. This briefing summarizes advisory guidance issued by Singapore's MOH and HSA that complements, but does not replace, binding medical-device and data-protection law. Confirm how any development applies to your situation with qualified counsel in the relevant jurisdiction.