Model Drift: When an AI System No Longer Matches the Business Case

Published: 10 April 2026

Article series: Limits of delegating to AI systems (Part 3)

The earlier articles in this series set out two limits on delegating to AI systems: the board cannot fully know the object of delegation with learning systems (the responsibility gap: Part 1), and it can only check execution indirectly (the oversight paradox: Part 2). Both articles looked at the system at the point it went live.

Part 3 of this series asks a different question: what happens once the system changes after approval, without anyone making a conscious decision to that effect?

Many boards discuss an AI implementation like a project, and a project typically ends at sign-off. Approved. Implemented. Done. With AI systems, that is a mistake, because a system can ‘change’ without anyone changing it. No new code. No new training. No notification. And yet: different results.

A comparison makes the problem tangible: a financial analyst whose market models rest on data from a low-rate period keeps producing professional-looking analyses once rates rise. But the underlying assumptions no longer hold. The difference from an AI system: with the analyst, the board can ask questions, and the analyst can disclose the assumptions. With the AI model, that questionability is missing, as the previous article on the oversight paradox showed.

What model drift means in practice

A model is trained on a given dataset and approved with a performance profile: error rate, scope of use, assumptions about data and process.

In operation, reality shifts:

With data drift, the inputs change: customer behaviour, market conditions, fraud patterns, supply chains or regulatory requirements evolve.
With concept drift, the relationship between input and outcome tips: an indicator that was reliable yesterday loses its predictive power.

The model stays the same. The world keeps moving. Decision quality shifts as a result, often slowly, but steadily.

The governance-relevant signal is the same in both cases: performance drift, the deviation from the approved performance profile. This term belongs in every board report wherever AI systems are used in operation. It gives the board a single, clear category to demand and monitor, regardless of whether the cause is data drift or concept drift.

Why this is a governance problem

Delegation assumes that its object is defined and reasonably stable in effect. When the board approves an AI system, it effectively approves a specific use case, a specific data basis and a specific performance profile.

Model drift means: this performance profile changes without a new board decision. It amounts to a creeping delegation, unauthorised and often unnoticed.

The legal framework points in the right direction, but it sets no threshold. In practice, the Code of Obligations operates with a definable object of delegation. Art. 14 of the EU AI Act requires that high-risk systems can be effectively overseen by natural persons ‘for the period in which they are in use’. Neither norm addresses model drift explicitly, but both imply that oversight does not end with initial approval. The gap: no existing legal framework defines the point at which a deviation from the approved performance profile triggers renewed review and re-approval. The board must set and monitor that threshold itself.

Floridi (2021) names ‘meta-autonomy’ as a condition for human control: delegation must remain overridable, that is, ‘deciding to decide again’. This is more than a quotation. It is a governance requirement: the board needs mechanisms that flag, in time, that there is something to decide. Without such mechanisms, the power to reclaim delegation becomes fiction.

Why drift usually stays invisible

Model drift is neither an outage nor a system fault. The system keeps producing results. Professional. Plausible. And that is exactly the danger.

A human can be asked: ‘What assumption is this based on?’ A model is often not questionable in that sense, and the shift in quality only shows up once it is measured systematically.

For learning systems, Matthias (2004) described the responsibility gap that arises once system behaviour is no longer predictable. Model drift creates a related problem for static models: predictability does not erode through learning. It erodes through a changing environment. The system is often not sufficiently inspectable, and it changes quietly. The board can neither reliably see what the system does, nor recognise that its effect is shifting.

What the board must actually set

Not every AI system needs the same depth of governance. From a board perspective, what matters is materiality: influence on business-critical decisions or processes, potential harm (legal, financial, reputational) and scale. The following measures should accordingly be proportionate, tightly managed for materiality-critical applications, leaner for less critical ones.

Frame approval as a conditional mandate: board-level AI approvals should include conditions that trigger reassessment: thresholds for performance drift (deviation in core metrics such as error rates, recall/precision, false positives/negatives), indicators in the input data, material changes in the process environment or the relevant legal and regulatory framework, and new user groups or risk classes. Approval then becomes not a one-off act, but a mandate with limits and triggers.
Anchor risk-appropriate monitoring as a governance duty: not ‘we monitor’, but which metrics, at what frequency, with which thresholds, and who escalates. For materiality-critical systems, this includes brief standard reporting (trend, deviation, action taken, decision required). A clear owner for drift monitoring is equally essential. Without an owner, monitoring stays a technical exercise with no governance effect.
Introduce periodic revalidation: alongside ongoing monitoring, the board needs regular revalidation of whether the system, use case, data basis and performance profile still match the approved scope. Frequency should be set on a risk basis. Where material deviations exist, a documented reassessment, and if necessary re-approval, is required.
Operationalise withdrawal of delegation: if a system runs outside its approved performance profile or the risk picture shifts, a defined process for graduated intervention is needed: restricting the use case, moving to reinforced human control, or deactivation with rollback. Clear decision authority and response times are part of this, otherwise withdrawal remains possible only on paper.

Successful implementation is not the endpoint

The duty of care for AI does not end with approval and implementation of the system. It begins there. Anyone who approves a system but never checks whether it still matches the approved performance profile loses control without noticing.

Sources

Floridi, L. (2021). Ethics, Governance, and Policies in Artificial Intelligence. Springer.
Matthias, A. (2004). The Responsibility Gap: Ascribing Responsibility for the Actions of Learning Automata. Ethics and Information Technology, 6, 175–183.
Art. 716a, 716b, 717, 754 OR (Swiss Code of Obligations).
Art. 14 EU AI Act (Regulation (EU) 2024/1689).