On October 2, 2026, xAI’s release notes recorded that grok-voice-transcribe-1.0 had reached end of life, and that “all requests to that slug are routed to grok-voice-transcribe-2.0 at the same price, with higher accuracy.” AI model deprecation usually looks like this. Nothing broke for customers who had pinned the old name. That is the problem. A company that tested version 1.0 is now running version 2.0 under the same model string, and in a federally regulated financial institution, that swap is the kind of change OSFI’s model risk guideline expects to be recorded.
What xAI’s notice says
The notice says three things: the old model is deprecated and reached end of life on October 2, requests sent to its name now go to the newer model, and the price is unchanged. It does not say the customer must take any action, and for a working integration none is technically required.
The automatic routing is a courtesy. A pinned version string normally exists so that the model you validated is the model you run, and here the vendor has decided, for good reasons, that the newer model should answer instead. The same release notes list similar moves: on November 2, requests to grok-imagine-image-quality will be served by a newer image model. Our reading is not that xAI did anything improper. It is that AI model deprecation now routinely happens by redirection, and most contracts and inventories were written for a world where it happened by switch-off.
What OSFI’s Guideline E-23 asks for
Guideline E-23, Model Risk Management takes effect on May 1, 2027, for banks, insurers, and trust and loan companies regulated by OSFI. Principle 2.1 says institutions “should identify and track all models in use or recently decommissioned,” including “vendor and third-party models.” The model inventory is to be “updated in a timely manner, including model modifications and changes in model use, risk rating, or performance status.” Seat pricing moves without notice too, as Cursor pricing showed when the seller behind the seats changed.
Read against the xAI notice, the text is fairly direct. A transcription model that a bank uses to summarize client calls is a vendor model. The swap from 1.0 to 2.0 is a model modification, and “higher accuracy” is a change in performance status, even if a welcome one. E-23 also asks model owners to give a rationale “for model modifications,” explaining “the need for such changes.” Under a silent redirect, the institution did not make the change and may not know it happened.
The rationale is hard to write for a decision you did not take.
The other reading
A reasonable compliance officer could say this is a non-event. The vendor published the change in advance, the price held, accuracy improved, and E-23 is principles-based and proportionate: it ties lifecycle requirements to inherent model risk, so a low-risk transcription tool may sit near the bottom of the risk rating and need little more than an inventory note. On that view, the guideline already handles the case, and nothing needs to change.
We agree with the proportionality point and part of the conclusion. Where we differ is on detection. Proportionate treatment still assumes the institution knows a modification occurred. An inventory can only be “accurate, evergreen,” as E-23 puts it, if someone is reading vendor release notes or if the contract obliges the vendor to send notice. Many AI service agreements do neither in any formal way. Our earlier piece on ChatGPT for Financial Services and E-23 flagged version changes as the open question; this notice is a working example of it.
Fine Print
- Instrument: OSFI Guideline E-23, Model Risk Management (2027), with vendor models also covered through Guideline B-10 on third-party risk.
- Status and effective date: Final guideline published September 11, 2025; takes effect May 1, 2027.
- Who enforces: The Office of the Superintendent of Financial Institutions, through supervision.
- Who it applies to: Federally regulated banks, foreign bank branches, life and property and casualty insurers, and trust and loan companies.
- What changes: Vendor AI models belong in the inventory, and vendor-initiated version changes need a recorded entry and a rationale.
- Still undecided: Unknown whether OSFI will publish expectations specific to automatic version routing by AI vendors.
The contract clause that closes the gap
For any AI service a regulated institution relies on, the procurement file should contain a model-change clause with three parts: written notice to a named contact a set number of days before any deprecation, redirect or alias change; the identifier of the replacement model; and a right to keep the prior version for a defined validation window, or to suspend use without penalty. Where a vendor will not sign that, the inventory entry should say so, and the model owner should be assigned to read the vendor’s change log on a schedule. Firms outside OSFI’s perimeter have no obligation here, but the same clause protects any business whose results depend on a model behaving the way it did when tested.
More policy analysis is in AI Policy in Canada. This is general information, not legal or regulatory advice. Recorded calls raise the same question, since AI call recording in Canada has outgrown the old consent scripts.
Before the next renewal
The next decision point is each AI vendor contract’s renewal date, and the latest practical deadline is May 1, 2027. Before either arrives, the model risk function should list every vendor model in use, record its exact version string, and check whether that string still points to the model that was validated.
FAQ
What is AI model deprecation?
It is when a vendor retires a model version. Increasingly, the vendor routes requests for the old version to a newer model automatically, as xAI did with grok-voice-transcribe-1.0 on October 2, 2026.
Does OSFI E-23 cover vendor AI models?
Yes. Principle 2.1 asks institutions to identify and track all models in use, including vendor and third-party models, and to update the inventory for model modifications.
What should a contract say about AI model changes?
It should require advance written notice of deprecations and redirects, name the replacement model, and give the customer time to validate it or stop using the service without penalty.
