Model-Version Governance: Pinning, the chat-latest Trap, and the Re-Validation Cadence

If you run a regulated, operationally complex mid-market organization, a behavioral health group under HIPAA, a PE portfolio company answering to a quarterly board, a property manager holding tenant trust funds, a SaaS vendor carrying SOC 2 and now state AI law, you already treat a change to a production system as a controlled event. You do not let a vendor push a new version of your EHR or your general ledger into production on a Tuesday afternoon with no notice, no test, and no rollback. Yet that is exactly what most AI deployments permit today, because the model behind the prompt is often not pinned to a version at all. GPT-5.5 Instant became the ChatGPT default on May 5, 2026, exposed as a floating "chat-latest" alias, a label, not a version. The model underneath that label can change with no notice and no version bump. An unpinned model is an unmanaged change, and the frontier release cadence has made the problem chronic: Anthropic shipped Opus 4.8 on May 28, 2026, just 41 days after 4.7, and the labs are now releasing on a roughly six-week rhythm. Your change-control framework was built for software that changes when you decide it changes. The model market no longer works that way. What changed: the model under your prompt is now a moving target Two facts collide. The first is cadence. Six weeks between frontier releases means that over the life of a single annual audit cycle, the vendor will ship roughly eight new versions of the model your regulated workflow depends on. The second is the alias. When you call a stable id like , you are calling an immutable artifact, the same weights today and next quarter, which is why Anthropic publishes that id and tells you to pin it. When you call , you are calling whatever the vendor has decided "latest" means this morning. The first is a version. The second is a promise the vendor reserves the right to break. The Fable 5 episode this month is the sharp edge of the same problem. Fable 5 launched on June 9, 2026, and was suspended three days later, on June 12, under a US export-control directive. Set the politics aside; the operational lesson is that a model you built a workflow around can not only change behavior behind an alias, it can disappear entirely in 72 hours. If your continuity plan assumed a specific model would simply keep answering, you found out the hard way that a model is a vendor dependency like any other, and undocumented vendor dependencies are how regulated programs fail diligence. Why the old control model misses it Your change-management process almost certainly assumes the buyer initiates the change. A ticket is opened, a test is run, an approver signs, the new version goes live, the old one is the rollback. A floating alias inverts every step. The vendor initiates the change, no ticket is opened, no test is run, no approver signs, and there is no rollback target because you never recorded which version you were on. The eval suite that justified the deployment, the prompt templates tuned to the prior model's quirks, the safety testing you ran for your auditor, all of it was validated against a model the vendor has since replaced underneath you. The validation did not fail. It silently stopped applying. Prompt injection makes this concrete. OWASP mapped prompt injection to 6 of its 10 agentic-AI Top 10 categories on June 11, 2026, it is not an edge case, it is most of the threat surface. Your prompt-injection testing was conducted against a specific model's refusal and tool-use behavior. A new version behind the same alias can respond differently to the same adversarial input, and you will not know until something leaks. This is distinct from the routing and effort question. Our companion briefing on Opus 4.8 routing discipline covers how to pick the right model and effort level among current options; this briefing is about the version itself, the fact that the option you evaluated can be swapped without your consent, which no amount of routing care fixes. What the audit and the board will ask The regulatory frame has already converged on version discipline as a control objective. The US Treasury's Financial Services AI RMF, published February 19, 2026, lays out 230 control objectives across seven domains, and change management is one of them, an examiner reading that framework expects to see which model version was in production on a given date. The EU AI Act's GPAI enforcement powers activate August 2, 2026, with fines up to 3% of global turnover, and they require downstream deployers to collect and retain provider documentation. You cannot collect documentation for a floating alias; "chat-latest as of some Tuesday" is not a record. NIST's preliminary Cyber AI Profile (IR 8596), released December 16, 2025, points the same direction for security teams. Expect three questions, and have the answers written down before they are asked. Which model version handled this regulated workflow on the date of the incident or the reporting period, and where is that recorded? What re-validation was performed before that version was promoted into the workflow, and who approved it? And if the new version had failed, what was the rollback target? If your answer to any of the three is that the vendor manages versions for you, you have just described an unmanaged change to a regulated system, and the finding writes itself. The artifact: a pinned-version register and a re-validation gate The control is two linked pieces. The first is a pinned-version register, one row per regulated AI workflow, recording the immutable model id in production (never an alias), the date that version was promoted, the date of its last re-validation, and the rollback target it would revert to. The second is a re-validation checklist that runs as a promotion gate before any new version is allowed into a regulated workflow. The checklist has four mandatory items: the eval suite re-run against the new version and compared to the incumbent; the prompt-injection and safety tests re-run, because refusal behavior is not stable across versions; output-formatting validation, because a version that quietly changes JSON shape or citation format breaks downstream systems silently; and the cost profile, because token economics shift between versions and a new default can move your bill without moving your output. Per-request attribution now exists to measure that last item, Amazon Bedrock shipped request-level usage attribution on May 20, 2026, and Microsoft Foundry added project-level cost attribution on May 31, so "we could not see the cost change" is no longer a defensible answer. Treat the upgrade itself as a change-control event with a named approver and a documented rollback, exactly as you would a database migration. And for data that genuinely cannot leave your perimeter, note that open weights are now a real pinning strategy: the Gemma 4 open-weight models released May 1, 2026 give you a version you host and freeze yourself, which is the strongest pin there is, the vendor cannot move what runs on your hardware. As open weights mature and accelerator costs keep falling, in-perimeter inference is becoming a more credible option for sensitive workloads; run the payback math for your own environment before you assume it is too expensive. What we recommend Four moves a regulated buyer can make this quarter, the kind we work through in our fixed-scope Diagnostics. First, ban floating aliases in every regulated workflow and pin to immutable model ids; a model that can change underneath you cannot be evaluated, documented, or rolled back. Second, stand up the re-validation gate, evals, prompt-injection tests, output formatting, and cost profile re-run and compared before any new version is promoted. Third, treat every model upgrade as a change-control event with a named approver and a recorded rollback target, and write the pinned version and its re-validation date somewhere an auditor can find without asking you. Fourth, for perimeter-bound data, evaluate a self-hosted open-weight option such as Gemma 4 so the version is one you control outright. The regulatory architecture underneath all of this is mapped in our field guide, The Five-Layer AI Compliance Stack for Regulated Mid-Market (/blog/five-layer-ai-compliance-stack-mid-market-regulated). The vendor will ship the next version on its schedule whether you are ready or not, so pin the one you tested, and decide for yourself when it moves.