A supplier can keep your subscription running while retiring the AI model behind an important workflow. Restoring access with a replacement does not establish that the service still gives the right prices, handles Norwegian customer messages correctly or stops before making an unsupported promise.
For Norwegian management teams, a material model replacement is a change to the service. The technical owner must make the integration work. The person responsible for the business process must establish what the replacement is allowed to do and what evidence is needed before ordinary use resumes.
The practical decision is whether to approve the replacement, restrict the workflow or temporarily use another tested method. Leaving that choice until the old model disappears creates pressure to accept whatever works technically.
A shutdown date is different from a product announcement
OpenAI's deprecation notice says access to a group of older API models ended on 23 October 2026. The retirement was announced on 22 April. The list includes gpt-4.1-nano and the specific snapshot gpt-4o-2024-05-13. This concerns the listed API models, not a statement that every GPT-4o version or a company's ChatGPT subscription has stopped.
Other suppliers also manage model lifecycles. Anthropic's documentation distinguishes a deprecated model, which still functions, from a retired model, for which requests fail. It currently lists 30 November 2026 as the tentative retirement date for claude-sonnet-4-5-20250929. Dates for partner-operated platforms can differ. Check the platform that actually supplies your service.
Automatic replacement is a different case. Google's Gemini API documentation says requests to gemini-3.7-flash automatically route to gemini-3.8-flash, without shutting down that endpoint. A working connection therefore does not, by itself, show that the underlying model is unchanged. These are provider-specific examples, not one lifecycle policy shared by all AI products.
The first task is to establish which situation applies to your company. A Norwegian AS buying a finished customer-service tool may never see a model identifier. Ask its supplier which important functions depend on changing models, how changes are communicated and what testing the customer can see. A public API notice does not establish whether that particular purchased service is affected.
Keep the customer promise stable while the model changes
Consider a hypothetical Norwegian equipment-rental company. Its approved assistant prepares replies about availability, deposits and delivery. Staff review the drafts before sending them. Availability comes from the booking system; prices and conditions come from approved company material.
The supplier replaces the underlying model. In a test, the new version writes more natural Bokmål but offers free transport when the company's conditions require a separate quotation. The connection works, the reply is fluent and the customer would like the offer. The service has still failed its business requirement. This is an invented test case, not a reported incident.
The old answer is not automatically the correct answer either. Assess both versions against the booking records, approved terms and the limits of the assistant's role. A replacement that corrects an old mistake is an improvement, even when its output differs. The purpose is to preserve valid requirements, not every habit of the old model.
There is a real opportunity here. A better replacement may reduce correction work, handle more useful cases or make an awkward workflow easier to operate. Demonstrate those gains on the company's work. Do not equate a newer release or a higher benchmark score with better performance on your rental conditions.
Test the service, not just a conversation with the new model
OpenAI's text-generation guidance notes that different models, including snapshots in the same family, can produce different results and need different prompting. A fixed snapshot helps control change, but it does not make that model available indefinitely. The retirement schedule still matters.
The technical team should record the actual replacement, instructions, information sources, tools and settings used in the test. Keep the business requirements fixed while adjusting the implementation. If the integration or instructions must change, evaluate the resulting service rather than presenting an isolated model comparison as release evidence.
Use approved, appropriately protected examples of normal work and difficult cases. Include Bokmål, Nynorsk or English according to the messages your customers actually send. Test Norwegian dates, amounts, rental periods and industry terminology where they affect the answer. A good English demonstration is not a Norwegian acceptance test.
OpenAI's evaluation guidance recommends defining objectives, suitable data and metrics, comparing results and continuing evaluation as systems change. This is vendor guidance, not an independent finding that a particular replacement is suitable for your company.
My recommendation is to turn the rental company's obligations into a short acceptance record:
| Business requirement | Evidence to examine | Release consequence |
|---|---|---|
| Do not invent availability | Draft agrees with the booking result, including unavailable equipment | Restrict the workflow if it promises equipment without support |
| Preserve price and delivery conditions | Reply follows the approved terms and asks for a quotation when required | An unsupported discount or transport promise blocks ordinary release |
| Refer unresolved cases to staff | Missing information leads to a clear handoff, with the original request retained | Keep staff handling until escalation reliably delivers the request to its owner |
| Work within the agreed service capacity | Measure completed cases, review effort, response time and actual usage cost | Narrow scope or change the implementation if the service is not workable |
This is a proposed management tool, not a validated scoring scheme or a prescribed number of tests. Choose the examples and acceptance criteria from the consequences of failure. Repeat consequential cases where variation matters and retain separate examples that were not used to tune the instructions. No finite test set proves that every future reply will be correct.
Staff with knowledge of the work should examine whether the result meets the requirement. AI can help organise comparisons and identify differences, but an automated preference score alone is a weak basis for approving a new customer promise. Keep data access and permitted actions within the existing approved boundaries during the trial.
The old model may no longer be a fallback
Before retirement, returning to a supported old version may be a practical response to a failed rollout. After retirement, a configuration switch cannot restore access that the provider has removed. A plan that says only “roll back the model” is incomplete.
For the rental company, the fallback could be staff preparing replies from the booking system and approved terms. Another option is to retain the assistant for a narrow task that passed evaluation while staff handle quotations. Each option needs a capacity check and a way to reconcile requests already in progress. Do not promise normal response times if the manual route cannot meet them.
A second model is a fallback only after its service configuration, information handling and task quality have been checked. Sending confidential customer requests to an unapproved free account is not a continuity plan. The broader supplier exit guide addresses leaving a provider; here the immediate issue is maintaining an acceptable service through a model change, possibly with the same supplier.
If a retired model has already interrupted work, restore a tested minimum service first. Preserve unfinished requests, establish the scope of the interruption and communicate realistic times to affected customers. Do not let urgent restoration quietly expand the assistant's permissions or turn unchecked drafts into automatic customer replies.
Decide before the provider's deadline decides for you
The service owner should bring one explicit recommendation: approve the tested replacement within stated limits, reduce its role until specific defects are corrected, or pause the affected function and use the tested alternative. Record the evidence, unresolved problems, responsible person and follow-up date. For a low-consequence writing aid, the review can be brief. A workflow that changes orders or commits the company needs stronger evidence.
The decision should also account for benefits. Delaying a useful replacement indefinitely consumes staff time and may leave the business dependent on a version approaching retirement. A bounded release with additional review is often more informative than either an unchecked company-wide switch or an open-ended postponement. Use the pilot-to-production guide when the replacement substantially changes the way the workflow operates.
Management owns this implementation and supplier follow-up. Where the dependency is material, the board should ask which critical services face a model change, whether the replacement and fallback have been demonstrated, and what cost or interruption remains unresolved. Directors should not approve individual prompts or run the test cases themselves.
Bring one important AI-supported service to the next management meeting. Ask the owner to show its model-change notice, acceptance evidence and workable alternative. The provider sets the availability deadline. The company must still decide what it is prepared to deliver to customers.
Sources checked on 24 October 2026. Model identifiers, lifecycle states and dates are time-sensitive and platform-specific. The rental company, test failure and acceptance record are hypothetical. Recommendations are the author's analysis, not legal requirements or a guarantee of a particular model's performance. The illustration is AI-generated.