AI Video Model Drift: Version Pinning, a Regression Set, and a Migration Gate

The engine under your pipeline has a published expiry date

AI video model drift begins with a fact most production plans never record: the model you generate on has a documented end-of-life, and it is not on your calendar. Google Cloud publishes a Veo lifecycle in which stable builds are supported for at least twelve months after release. veo-3.1-generate-001, released on 17 November 2025, is listed as available through 17 November 2026 or later. The two versions it replaced, veo-3.0-generate-001 and veo-2.0-generate-001, both reached retirement on 30 June 2026. Those are not rumours from a changelog thread; they are dates in the vendor's own lifecycle table, published well in advance.

Preview endpoints are a shorter and more dangerous bet. Google's deprecation page shows veo-3.0-generate-preview available only from 31 July 2025 to 12 November 2025 - roughly fifteen weeks of production life. Several current preview identifiers, including veo-3.1-generate-preview and veo-3.1-lite-generate-preview, carry no announced shutdown date at all, which reads like reassurance but is in fact the absence of a commitment. Where a model sits in the short-term availability tier, the published rule is blunter still: it retires 45 days after its replacement ships.

That is why the first decision in choosing a video generation model is not only which engine wins the bake-off today, but which engine will still answer an API call when the campaign that depends on it is still running. A model is a dependency with a maintenance window, and that window belongs in the schedule alongside talent availability and media flight dates.

AI video model drift versus regression: one symptom, two causes

Two failures look identical in dailies. Last month's reliable prompt now returns morphing faces, a product that changes shape mid-shot, or a camera move that is simply ignored. One of those failures is regression and the other is drift, and the difference decides what you do next. Regression is degraded output caused by a change you made: a prompt edit, a swapped reference image, a new aspect ratio, a parameter someone adjusted and did not log. The evidence is in your own version history, and the fix is a code review.

Drift is degraded output when you changed nothing at all. The provider updated weights behind a floating alias, patched a preview endpoint without a version bump, or shifted a default such as the resolution tier, the audio toggle, or safety filtering. Drift shows up first in whatever you worked hardest to lock down, which is why a reference-first workflow for character consistency is usually the earliest casualty. Prompts tuned against one generation of a model also transfer badly to the next generation in the same product family: the wording is unchanged, but the model's reading of it is not.

Keeping the two apart matters because the remedies have nothing in common. Regression is your problem and you can revert it in minutes. Drift is a vendor change you never approved, and the only way to catch it early is to test against a fixed set on a schedule, rather than trusting your recollection of how last quarter's output looked.

Pin the version you ship, then record which one it was

The highest-leverage control is also the dullest: stop calling floating aliases and request an explicit, dated or numbered endpoint on every generation. Asking for veo-3.1-generate-001 rather than a moving latest tag means no provider can swap the engine under you without a deliberate change on your side. Pinning buys time, not immunity. The pinned version still meets its published retirement date, so what you have actually bought is a scheduled maintenance obligation rather than a permanent guarantee.

Pinning is only worth anything if you can later prove what produced a given shot. For every delivered clip, capture the exact model identifier, the full prompt text, hashes of the input references, the seed, the resolution and audio settings, and the generation date. Those values belong as first-class fields in your asset metadata schema, not buried in a chat thread or encoded into a filename. Without that record, the post-mortem on a drifted batch is guesswork, and you cannot reproduce the one usable take when a client comes back wanting a matching insert.

There is a commercial argument here as well as a technical one. When an engine is retired, this record is what lets you show a client that a delivered asset met the agreed spec on the day it shipped - which is a useful thing to hold when they ask why a re-run of the same prompt no longer matches the approved cut.

Build a regression set, not just a checklist for finished cuts

A pre-delivery QC gate judges one finished cut. A regression set judges the engine itself, and it has to run before any upgrade goes near live work. Assemble a fixed set of roughly ten prompts that genuinely represent what you ship: a hero product move, a tight close-up, a fast-motion beat, a shot carrying on-screen text or packaging, a character take driven by references, a locked-off camera, and at least one known failure case from your own history. Store the exact prompt, input assets, settings and model identifier with each entry so the set is reproducible by someone who did not build it.

Score every output against fixed axes rather than impressions: prompt adherence, temporal coherence, reference fidelity, camera control, artifact load, and retries needed per usable clip. Score blind wherever you can, because reviewers reliably flatter whichever version they know is newer. Keep the failures - a rejected take is the evidence of what an upgrade broke, and preserving it is what makes the next comparison meaningful rather than anecdotal.

This is the concrete form of a governance expectation that already exists. NIST's AI Risk Management Framework asks that pre-trained models used in development be monitored as part of regular monitoring and maintenance, and that post-deployment monitoring plans explicitly cover change management. A documented test set with documented metrics is precisely what that language describes, translated into something a production team can actually run on a Tuesday morning.

Gate the migration: make it a go/no-go, not a quiet swap

Moving to a new model version is a deployment decision, so run it as one. When a new build lands, generate the full regression set on the old and new versions in parallel - same settings, same references, same day - and compare the actual clips side by side. Never compare a new version against your memory of the old one, and never against numbers gathered weeks earlier on different inputs. A stochastic system will happily produce one flattering example on demand; only the whole set tells you anything.

Set the pass criteria before you look at the results. A sensible default: no quality axis regresses beyond a threshold you agreed in advance, retries per usable clip stay flat or improve, and every live campaign remains pinned to the old version until it delivers. A model that scores marginally higher on craft but needs twice as many attempts is more expensive in practice, so cost per usable clip belongs on the scorecard next to the creative axes rather than in a separate finance conversation.

Keep the rollback real. NIST's framework expects a defined mechanism to supersede, disengage, or deactivate a system whose performance is inconsistent with its intended use, and in a video pipeline that simply means the old pinned endpoint stays wired up and tested until the new one has shipped a full campaign without incident. Migrating mid-flight, between two rounds of client revisions, is how a manageable upgrade turns into a re-shoot.

Put model changes on the production calendar

None of this survives contact with a busy quarter unless somebody owns it. Name a person who reads the provider's release notes and deprecation pages monthly and reports the deltas to production. The 45-day short-term retirement rule means a replacement announcement starts a six-week clock, not a vague future concern, and a team that finds out through a failing render job has already lost most of that window.

Run two cadences. A full regression pass every quarter catches slow degradation across a model family. On top of that, run an event-triggered pass whenever a release note touches anything that changes interpretation or motion: prompt understanding, camera control, reference handling, duration limits, seed behaviour, safety filtering, default settings, or pricing. Pricing counts because it changes your retry economics even when the pixels are identical, and retry economics is what determines whether a model is viable for a given job.

The teams that stay stable through a model transition are not the ones with better prompts. They are the ones who treat the engine like any other production dependency: explicitly versioned, tested against a fixed set, owned by a named person, and given a sunset date in the plan before anyone commits a campaign to it.