The quote ended at go-live. The model your AI depends on will be retired within eighteen months. Who owns it then?
The build is finished. The supplier has demonstrated it, the invoice has been paid, and the handover pack is a shared drive folder with a diagram in it. The people who built it have moved on to their next client. The system is yours now.
Somebody should ask what "yours" means.
The software you replaced was allowed to sit still
The spreadsheet, the macro, the ten-year-old line-of-business tool this AI replaced had one great virtue. It did not change unless you changed it. You could leave it alone for three years and it would do on the last day exactly what it did on the first. The maintenance question was real, but it was slow, and you could put it off.
An AI system is not allowed to sit still, because the most important component in it is not yours. The model at the centre belongs to a vendor, runs on their servers, and changes on their schedule. Your supplier chose a model, wrote prompts that work against that model's particular habits, and tested the whole thing against that model's outputs. Then the vendor retires the model, and every one of those decisions has to be made again by somebody. The quote you signed ended at go-live. It did not say who that somebody is.
How long does an AI model stay available?
Roughly a year to eighteen months, and then it is withdrawn. OpenAI's published deprecation policy promises at least six months' notice for generally available models, at least three months for specialised variants and as little as two weeks for previews; in practice GPT-4.5 was given three months in 2025, the GPT-4o chat model three months in late 2025, and the GPT-5 snapshot released in August 2025 was scheduled for shutdown in December 2026. Google's Gemini lifecycle page shows the same shape: Gemini 2.0 Flash released in February 2025 and retired on 1 June 2026, sixteen months later, with the listed dates described as the earliest possible shutdown.
Read that as a buyer rather than a developer. A system built in the spring on the current best model will have to be moved to a different model before it is two years old, and possibly before it is one. The move is not optional and it is not a click. The prompts were written for the old model, the tests were passed by the old model, and whether the new one behaves the same is a question nobody can answer without doing the work.
It changes even when nothing has been announced
The retirement notice is the polite version. The other version is that the model behind a fixed name quietly stops behaving the way it did.
A paper from NTNU in April 2026 on governing updates in the LLM supply chain collects the documented cases. The best known is GPT-4's success rate on a code-execution task falling from 52% to 10% inside three months in 2023, with no version change announced. The authors' own tests found a backend function that passed every test against one model and failed a safe-encoding test the next day. Their framing is worth keeping:
Updates may introduce instance-level regressions despite aggregate performance improvements.
In plain terms, the vendor's benchmark went up and your particular use case went down, and the vendor's release notes will only mention the first half. A separate 2025 study of an enterprise search application found that the reliability lost to model drift could be fully recovered, but only through a structured process of migrating the prompts. Somebody had to notice, diagnose and rewrite. That is a job, and it recurs.
We have written about why monitoring uptime is not monitoring your AI. This is the sequel. Even if you are watching the outputs properly, watching tells you that something has changed. It does not tell you who is going to fix it.
The three answers you will be offered, and what is wrong with each
"The supplier will do it on a retainer." This is the usual answer and it has a flaw nobody says out loud. The firm that built the system is now the only party able to judge whether the system is still working, and it is paid whether it is or not. Every model migration is a change request. Every regression is a fresh piece of billable work, discovered, scoped and priced by the people whose work is being questioned. That is not dishonesty; it is an arrangement with no independent voice in it. We set out how to tell whether a supplier is doing a good job precisely because most buyers cannot, and a retainer does not change that.
"We'll handle it in-house." With whom? Deloitte's State of AI in the Enterprise 2026, a survey of 3,235 senior leaders, found insufficient worker skills to be the single biggest barrier to integrating AI into existing workflows, and only 21% of organisations reporting mature governance for the agentic systems three-quarters of them intend to deploy. A UK government survey of AI firms published in January 2026 found 57% reporting a technical skills gap, though it had only 119 respondents, so treat it as a signal rather than a census. Either way: if the firms selling this struggle to staff it, the odds that your IT manager can re-test a model migration in their spare time are not good.
"Nothing will change for a while." Gartner's June 2026 guidance predicts that at least half of generative AI initiatives will overrun their budgets by 2028, naming poor architectural choices and a lack of operational expertise as the causes. Operational expertise is the ability to run the thing after it is built. Gartner is saying, in its way, that half of buyers do not have it and are going to pay for that.
What ownership looks like when it is real
From our own work, the systems that have survived their first model migration share a few unglamorous features. None of them is a piece of technology.
A named owner inside the business. Not the supplier, and not "IT". A person whose job includes knowing which model the system runs on, when that model is due for retirement, and what "working" means in numbers they can check. They do not need to be technical. In our experience an operations manager does this well, because the job is mostly asking the right questions on a schedule.
A test set that belongs to you. Fifty to a few hundred real inputs with the outputs you agreed were correct, kept outside the supplier's repository. When the model changes, you run the set and compare. Without it, "does it still work" is a matter of opinion, and the only opinion in the room is the supplier's.
A migration path written down before go-live. Which model is next, what it costs, who runs the test set, who signs off. This is the single most useful page in a handover pack and it is almost never in one. We have covered the running cost separately; a model migration is where that cost changes without anyone deciding it should.
An independent voice. Someone who did not build it, is not paid to maintain it, and can read a supplier's change request and say whether it is reasonable. That is the part most buyers skip, and it is the part that makes the other three work.
The question to ask this week
If your system is live, or about to be, ask the supplier one question: which model does this run on, and when is that model scheduled for retirement? If the answer is a date, you have a supplier who has thought about it. If the answer is a pause, you have found the gap in your handover before it finds you.
Then ask who is going to re-test it when that date arrives. It should not be the same person who answers the first question.
That second role is what our design authority service is: an independent technical voice on a build somebody else did, from £1,500 a month for a day or two of work, and it stands on its own. You do not need to have started with us, and you do not need a proof of concept first. You need somebody in the room who knows what the last model did, can tell you what the next one broke, and has nothing to gain from the answer.