AI implementation does not end at go-live. It ends, if it ends at all, somewhere in the second year: when the model you built on is retired, when the system it reads from changes shape, or when the one person who understood it takes another job. Almost nobody asks me about that year. The proposals I am asked to quote cover the build, and most of the risk lives in what comes after it.
Why does nobody ask what happens after go-live?
By now I have sat through several hundred first conversations with Dutch and Flemish business owners, and the questions are remarkably consistent. What can it do. How long will it take. What does it cost. Who else have you built this for. Those are good questions and I would ask them too. But in roughly one conversation in ten, someone asks what the thing looks like eighteen months from now, and whose desk it sits on.
That is not a failure of intelligence. It is how all of us were taught to buy software: as a capital item with a delivery date, a go-live and a small celebration. The project has an end, so the thing must have an end. There is also a quieter reason on my side of the table, which I should admit plainly. Raising year two complicates a proposal. It adds a line nobody budgeted for and a conversation about who is going to do the work. For the first stretch of running Crux Digits I did not raise it either unless the client did. That was a mistake, and the systems that went quiet on me are what taught me so.
Your AI model has a retirement date, and it is published
Here is the part that surprises almost every buyer, and it is checkable in ten seconds. The large model your system calls has a published end of life.
Anthropic keeps a model deprecation page with a status table in which every active model carries a "not sooner than" retirement date, and the company commits to at least 60 days' notice before retiring a publicly released model. Those dates are not hypothetical. Claude Opus 4.1 was announced for retirement on 5 June 2026 and stopped accepting requests on 5 August 2026, sixty-one days later. Claude Sonnet 3.7 and Claude Haiku 3.5 both went dark on 19 February 2026. Once a retirement date passes, requests to that model on the provider's own API simply fail.
OpenAI publishes its own notice periods, tiered by model type: at least six months for generally available models, at least three months for specialised variants, and as little as two weeks for preview models, with the explicit advice not to use preview models for business-critical production work unless you can migrate at short notice.
I want to be careful here, because this is not a scandal and it is not an argument against using hosted models. Published dates and notification emails are more transparency than most enterprise software offers; plenty of on-premise packages die without so much as a letter. The point is narrower and more practical. Nobody on the buying side of an AI project has ever had to think in these terms. Your accounting package does not stop answering on a Thursday in August. A model does, and the date was sitting on a public web page the whole time.
Which produces exactly two requirements, both of them boring. The model name has to live in one place in your system, a single configuration value rather than something scattered through code and a dozen saved prompts. And a named person at your company, not only at your supplier, has to be on the account that receives the notification. I have written before about why I build against consultant lock-in; this is that same principle at the scale of one line of configuration. It is also the first thing people raise when they ask about running an open-weight model themselves, which moves the problem rather than removing it. You keep the weights and you inherit the hosting, the patching and the security updates. Both deprecation policies quoted here were read on the providers' own pages in September 2026, and both are revised from time to time, which is itself part of the point.
What actually breaks in year two?
Four things, in the order I see them. The model is on this list. It is not at the top of it.
1. The systems it reads from
An AI system almost never sees the world directly. It sees the world through somebody else's data structure: an export from Exact or AFAS, an order line out of a WMS, a PDF layout that a supplier decided to redesign, an API version with a sunset note buried in release notes. This is the most common cause of a system that has quietly become wrong, and nothing about the AI changed at all. A field was renamed, or a supplier moved the invoice total two centimetres to the left, and an extraction that was almost always right is now wrong often enough to matter, and nobody has looked.
2. The assumptions written into it
Every automation carries a snapshot of the business on the day it was built. Then comes a new product line, a different VAT treatment, a customer type that did not exist last year, a rule the sales team changed in a meeting nobody minuted. The system does not object. It carries on producing confident, well-formatted output for a company that has moved on. Confidence without correctness is the specific failure mode of language models, and it is more dangerous in year two than in week one, because by then everyone has stopped checking. If what you run is your own trained model rather than a hosted one, the same thing arrives through drift in the data itself.
3. The person
Within a few months of go-live, one person becomes the one who knows the AI thing. They are usually not from IT. They are the person who understood both the process and the tool, and they carry the system in their head rather than in a document. Then they get promoted, or take the job at the bigger firm down the road, and the thing keeps running unattended until it is either irrelevant or wrong. This is the organisational failure mode I keep coming back to, and documentation alone does not fix it. Two people does.
4. The model
And then the model, which after those three is close to a relief. It is a date, published in advance, with a recommended replacement and a migration guide attached. If the model name lives in one place and somebody tests the replacement before the deadline, it is an afternoon of work. If it does not, it is an outage you hear about from a customer.
Who owns the system in year two?
The honest answer is that ownership is usually left unstated, and anything left unstated defaults to nobody.
My position, argued with more clients than have immediately agreed with it: the system belongs to the department whose numbers change, not to IT. IT operates it, in the way IT operates the mail server. But the person accountable for whether the output is any good has to be the person whose own work gets easier or harder because of it. When the finance team owns invoice extraction, somebody notices in week one that a new supplier's layout has broken it. When IT owns it, the same break becomes a ticket that nobody raises, because the people who can see the bad data do not know that it is bad.
In practice that ownership needs a name and a cadence, and both belong in writing before go-live rather than after it. Weekly for the first month and monthly after that is usually enough for a small system: someone opens twenty outputs and asks whether they would have put their own name to them. It is unglamorous and it takes half an hour. It is also the whole difference between a system that is still trusted in year two and one that has quietly been routed around while everybody kept saying it was live.
The country that already understands maintenance
There is something faintly absurd about explaining maintenance to a Dutch audience.
The Unie van Waterschappen calls the waterschappen the oldest democratic institutions in the Netherlands. They have been running since the thirteenth century and are named separately in the Constitution alongside the state, the provinces and the municipalities. There are twenty-one of them. Every year the algemeen bestuur of each one sets the waterschapsbelasting and decides what that money will be spent on. Nobody in this country regards a dike as a finished project. Nobody pays for one and expects never to hear about it again. The bill arrives annually, for as long as anyone plans to live here, and it is not treated as evidence that the original construction failed. It is treated as the condition of having dry feet.
And then the same business owner buys software as though it were a one-off purchase, and experiences the second year's attention as a cost overrun rather than as the thing itself. The gap is not knowledge. It is that a dike has a bestuur and a levy attached to it by law, while your AI system has neither unless somebody deliberately gives it both.
The three questions I now put in every proposal
None of these is clever. They are simply the three absences that I have watched cause the most expensive silence.
Which model, and where is its name written down?
Named explicitly, held in one configuration value, with the provider's deprecation page linked in the handover document and a person at the client on the notification list. If a supplier cannot answer this in one sentence, you are buying something you will not be able to maintain without them, which was probably not what you thought you were buying.
Which upstream systems does it read, and who tells us when they change?
List them by name. Then decide who subscribes to each one's release notes: your ERP partner's, your WMS vendor's, the supplier whose document layout you parse. In most of the year-two failures I have been called into, the answer to "why did it stop working" was sitting in release notes that nobody at either company had read.
Who looks at the output, how often, and what may they change without a ticket?
A name, a frequency and a boundary. The last part matters more than people expect. If the person using the system cannot adjust a rule or a phrase without raising a ticket, the system will drift out of date and no one will fix it, because the fix costs more attention than the error does. Some of that work you can carry in-house; some of it is worth handing back to whoever built it. Either way, what it costs to keep something running belongs in the cost conversation at proposal stage, not in a surprising invoice in month fourteen.
What this should change about how you buy AI
Mostly, it should make you build smaller. A system whose second year is affordable in attention as well as in money is a system that will still be running when it actually matters. The projects I have watched survive were rarely the ambitious ones. They were the ones narrow enough that a single person could still hold the whole thing in their head eighteen months later, and explain it to a colleague in a corridor.
It should also change one question in the first meeting. The most useful thing a prospective client can ask me is not what the system will do. It is: what happens if we want to switch this off? A supplier with a clean answer has thought about year two. The data is yours, here is the export, here is what stops and here is what carries on. A supplier who looks uncomfortable has just told you the most important thing you were going to learn that day, and has done it before you signed anything.
AI implementation is not a delivery date. It is the first year of something you now own, and the second year is where you find out whether you own it or whether it owns you.
