advanta

HomeGlossaryTechnology

Risk Class

Technology

P4

Model drift

Audience

GC / CLORisk & ComplianceLegal OperationsCIO / CISO

DEFINITION

Risk class 3 of the Risk Taxonomy 2026: the vendor's underlying model changes behaviour between versions without proportionate notice to the deployer, causing the same inputs to produce materially different outputs across time. Addressed by requiring vendors to publish change logs and model upgrade notices with customer-impact assessments, and by versioning methodology against the model version in use.

Detailed Explanation

Summary: Model Drift (Risk Taxonomy 2026)

Model drift is the gradual divergence of an AI model’s behaviour from the conditions under which it was originally tested, validated, and approved. It is treated as a risk class, not a defect: all deployed models drift; the governance question is whether that drift is detected, characterised, and responded to on the record.

Forms of Drift

  • Input drift – The distribution of real-world inputs shifts away from the validation-set distribution.
  • Concept drift – The underlying relationships the model approximates change (e.g., user behaviour, market conditions, regulations).
  • Provider-side updates – The vendor silently or explicitly updates a hosted / foundation model, causing a step-change in behaviour.
  • Use-context (workflow) drift – The way humans and systems use the model changes (e.g., new prompts, new downstream processes), altering effective behaviour.

Why Drift Is a Distinct Risk Class

Under Risk Taxonomy 2026, Model drift is separated from other risks because:

  1. It is silent.
    • Outputs often remain superficially reasonable while quality, fairness, and accuracy degrade.
    • There may be no single, obvious failure event.
  2. It is universal.
    • Even static models drift because the world moves (data, norms, user behaviour, regulations).
  3. It is provider-mediated for hosted models.
    • When a vendor updates a foundation model, all customers experience a behavioural shift they did not initiate.
  4. It requires named telemetry.
    • Generic “monitor performance” guidance is insufficient.
    • Mitigation requires a specific control family:
      • Input-distribution monitoring
      • Output-quality sampling
      • Ground-truth re-evaluation
      • Provider-change watch
      • ROAI (Return on AI) re-baselining

Canonical Drift Telemetry

A defensible programme treats Model drift with named, repeating measurements and clear ownership:

  1. Input drift telemetry
    • Statistical comparison of current inputs to the validation-set distribution.
    • Detects shifts in user population, content mix, languages, formats, etc.
  2. Output quality sampling
    • Human-graded sampling of a defined fraction of outputs against a stable rubric.
    • Tracks quality, safety, fairness, and policy adherence over time.
  3. Ground-truth re-evaluation
    • Periodic re-running of a held-out evaluation set with known answers.
    • Provides an anchored, comparable metric across time and model versions.
  4. Provider-change watch
    • Subscription to provider release notes and change logs.
    • Documented re-evaluation trigger whenever the underlying model, safety stack, or major configuration changes.
  5. Workflow telemetry
    • Rate of human override (how often humans reject or substantially change the AI’s output).
    • Edit distance between AI draft and final output.
    • Time-to-final-output (cycle time from AI suggestion to approved result).

Each telemetry feed:

  • Has a named owner under the Governance pillar.
  • Has an escalation threshold defined in the AI Governance Charter (GOV-01).

Drift Across the AI Lifecycle

  • Build stage
    • Drift is anticipated.
    • A re-evaluation cadence (e.g., monthly, quarterly) is committed in the Use Case design.
  • Deploy stage
    • Baseline measurements are captured for all key metrics and telemetry streams.
    • These baselines become the reference for future drift detection.
  • Operate stage
    • Drift telemetry runs continuously or on a defined schedule.
    • Threshold breaches trigger:
      • Updates to the Risk Register.
      • AI Council or equivalent governance body review.
  • Sunset stage
    • Terminal drift (the model can no longer be operated within tolerance, or remediation is uneconomic) is an explicit Sunset criterion.
    • May trigger model retirement, replacement, or major redesign.

Distinction from Adjacent Risks

  • Hallucination vs. Model drift
    • Hallucination is a per-output failure mode (an individual response is wrong or fabricated).
    • Model drift is a population-level shift in behaviour or performance over time.
    • A system that only tracks hallucinations can miss a slow, systemic erosion of quality.
  • Reduced supervisory capacity vs. Model drift
    • Reduced supervisory capacity is a programme-level issue: insufficient human oversight, expertise, or time.
    • Model drift is a model-behaviour issue that exposes and amplifies reduced supervisory capacity (drift goes unnoticed when oversight is weak).
  • Vendor lock-in vs. Model drift
    • Vendor lock-in is a structural dependency on a provider (costs and friction of switching).
    • Model drift is a behavioural change of the provider’s model over time.

A defensible AI governance programme:

  • Monitors both hallucination and drift.
  • Treats drift as a first-class, named risk with explicit telemetry, thresholds, and governance responses.

image pending

Diagram showing model drift telemetry feeds (input drift, output sampling, ground-truth re-evaluation, provider-change watch, workflow telemetry) feeding into governance and lifecycle stages.

Model Drift as a governed risk class: telemetry feeds (input, output, ground-truth, provider-change, workflow) continuously inform Build, Deploy, Operate, and Sunset decisions.

Treat Model drift as inevitable and governable: define explicit telemetry, owners, thresholds, and lifecycle triggers so that behavioural change is detected, characterised, and acted on before it becomes a sharp failure event.

Quick Facts

Term Type

Risk Class

Category

Technology

Related Pillar

P4 · Governance

Governance

Methodology
v2026.1

Explore Glossary

← All Terms