← Back to Articles
The short answer

Model drift is the degradation of an AI system's performance after deployment, caused by changes in the patient population, documentation practices, upstream systems or clinical workflows that make live data differ from the data the model was trained and validated on. It is gradual and produces no error message, so it is invisible without deliberate monitoring. HSA's December 2025 GL-04 update requires documented post-market performance monitoring processes covering drift, distribution shift and degradation in prediction quality.

What causes it

A model learns relationships in the data it was trained on. It keeps applying those relationships regardless of whether they still hold.

  • Population shift. Your case mix changes. A new service opens, a referral pattern changes, demographics move.
  • Documentation shift. Clinicians change how they record things. A new template, a new coding practice, a new EHR module.
  • Upstream change. A lab changes assay, an imaging device is replaced, an integration is upgraded and a field starts arriving in a different format.
  • Feedback effects. The model changes clinician behaviour, which changes the data, which changes what the model sees.

That last one is specific to deployed clinical AI and is the least appreciated. A tool that flags high-risk patients causes those patients to be treated differently, which alters the outcomes the model was predicting.

Why it is noticed late

Drift produces no error. The system continues returning confident, plausible outputs. It is simply wrong more often than it used to be, and the increase is gradual enough that no individual clinician encounters a moment that feels like a system failure.

By the time it is visible without monitoring, it is usually visible as an incident.

What the regulator now expects

HSA's December 2025 GL-04 revision requires documented post-market performance monitoring processes that include detecting model drift, distribution shift and degradation in prediction quality over time, plus documented controls for models that update based on post-deployment data.

AIHGle 2.0 places the deployer responsibility for AI in service with the healthcare organisation, which means the monitoring question is yours whether or not your vendor performs the monitoring.

Our view

Drift monitoring is the item most often assumed by both parties in a contract and owned by neither. The vendor assumes the institution is watching clinical outcomes. The institution assumes the vendor is watching model performance. Both assumptions are reasonable and they do not add up to coverage.

Make it explicit at contract stage. Who computes what, how often, against which threshold, and who receives the alert. If the answer involves anyone reviewing a dashboard voluntarily, it will not happen after month three.

The harder point: monitoring requires ground truth, and in clinical settings the true answer often arrives months later or never. A model predicting deterioration can only be evaluated against what actually happened, which means your monitoring lags your exposure. Organisations that have thought about this build proxy measures and accept they are proxies. Organisations that have not tend to discover the problem when someone asks how they know the model still works.

Sources

  1. Health Sciences Authority, GL-04 Regulatory Guidelines for Software Medical Devices, revised December 2025. hsa.gov.sg
  2. Ministry of Health Singapore, AIHGle 2.0, deployer responsibilities. go.gov.sg/aihgle

Asking About Monitoring Before You Buy

We train teams to make this a procurement question, not an incident finding.

Start a Conversation →