Shipping Under Model Drift

Software behaves the same until someone changes it. An AI product does not: the world moves and the inputs shift, the model provider updates behind a stable name, and a retraining pipeline emits a new model on a schedule nobody watches. The product changes without a release, which breaks assumptions that product management is built on.

What moves

The world. Language, slang, entities and topics change, so a model trained on last year's data becomes progressively less current. The rate is domain-dependent and is fast in anything touching news, culture or fast-moving software.

The inputs. As users learn what the product does well, their inputs shift toward that, which changes the distribution the model sees and is usually beneficial. New user segments shift it in less predictable directions.

The model. A hosted model updated behind a stable identifier changes behaviour with no deployment on your side. Pinning to dated versions where the provider offers them converts this from a surprise into a scheduled migration, at the cost of eventually being forced to move anyway.

Everything around the model. Prompts, retrieval corpora, tool definitions and thresholds change frequently and are edited by people who do not think of themselves as shipping.

What it does to commitments

A capability demonstrated today may not hold in three months, so promising a specific behaviour indefinitely is a commitment the system cannot keep on its own. The practices that make it keepable are a fixed evaluation set run continuously so a regression is detected rather than reported, a behavioural regression suite covering the specific promises, and version pinning so change is deliberate.

Roadmaps need a maintenance allocation that conventional software does not, because a substantial share of the work is keeping existing behaviour working rather than adding new behaviour. Teams that plan only new features discover the maintenance load as a slipped roadmap.

When it breaks

Regressions are found by users. Without a continuously run evaluation set, a provider-side change or a retrain that degraded a specific capability is discovered through complaints. The detection lag is the entire cost.

Prompt edits are releases and are not treated as one. A change to a system prompt alters behaviour across every user, and if it is not versioned, reviewed and evaluated, it is an unreviewed production change. This is the single most common source of an unexplained behaviour change.

Deprecation forces unplanned work. Providers retire model versions, and a product pinned to one gets a migration on the provider's schedule. Budgeting for it, and keeping the evaluation harness ready to compare candidates, turns a scramble into a task.

Improvements are also changes. A better model can break a prompt tuned around the old one's quirks, change output formatting that downstream code parses, or alter refusal behaviour. Upgrades need the same evaluation as any other change, and the assumption that better cannot break is how upgrades cause incidents.