The December 2025 revision to GL-04 adds machine-learning specific expectations. Most of them are documentation you should already hold, and frequently do not.
HSA revised GL-04, its regulatory guidelines for software medical devices, in December 2025. The revision harmonises definitions, adds clarity on cybersecurity and machine learning, and introduces a streamlined pathway for software changes under a change management programme. For AI specifically, it sets expectations around training and validation dataset documentation, post-market performance monitoring for model drift, controls for models that keep learning after deployment, and explainability documentation for clinical decision support.
HSA updated GL-04, its regulatory guidelines for software medical devices, in December 2025. The headline revisions harmonise definitions with international practice, clarify requirements for cybersecurity and machine learning, and add a streamlined pathway for software changes made under a change management programme.
That last point is the one product teams tend to care about most, because the alternative is a change process that punishes iteration.
The requirement to document what a clinician should do when the model disagrees with them is easy to skim past. It is the most operationally demanding item on the list, because answering it forces a position on where authority sits.
If the answer is that the clinician always overrides, the tool provides less value than the business case assumed. If the answer is that the model should usually win, someone has to defend that in a case review. Most submissions we see avoid the question with language about the tool being decision support rather than decision making, which is true and does not answer it.
Read as a whole, GL-04's AI additions are a demand for evidence that the developer understood their own model. Dataset demographics, drift detection, and interpretation guidance are not regulatory paperwork invented to slow you down. They are the things you would want to know before letting a system near a patient.
The organisations that find this update painful are usually the ones who built first and documented afterwards. The documentation is hard to produce retrospectively because the decisions it describes were never explicitly made.
Our practical advice: if you are a deployer rather than a developer, ask your vendor for these four items directly. A vendor selling into Singapore should already have them. How quickly and completely they answer tells you a great deal about the maturity of what you are buying.