Model drift — how models fail quietly

The short answer. Model drift is performance degradation without failure: the model keeps returning answers while the world it was trained on moves — patient mix shifts, clinical practice changes, an upstream field is remapped. Nothing errors, nothing pages anyone, and the accuracy quietly leaves. That is why drift is a monitoring-and-governance problem rather than an uptime problem.

Software fails loudly — errors, timeouts, pages. Models fail quietly: the sepsis predictor still scores every patient, the radiology model still flags studies, and the AUROC that was 0.87 at approval is 0.79 now because the payer mix changed, a documentation template was revised, or the lab swapped analysers.

The operational insight is that drift produces no incident. No system is down, so no ticket exists, so nobody looks — unless looking is someone’s scheduled job. The continuity plan does not catch it either, because that plan is built to detect an outage: a tool that stays up and quietly gets worse trips none of the machinery you already own. That is the entire case for post-deployment monitoring: a locked baseline, a threshold, a cadence, an owner. It is also why serious platforms treat a breached threshold as a status change — HAI-OS automatically suspends a model whose drift crosses its locked threshold, on the argument that a degraded model should have to earn its way back rather than fail silently in production.

Where do you actually stand? The free RUAIH readiness score maps your organisation against the five focus areas in about eight minutes, and the published crosswalk shows how each control lands across RUAIH, CHAI and the NIST AI RMF.

Model drift — how models fail quietly

Keep reading