Three products, three timelines.
A vehicle programme approved this quarter reaches production in about three years. It will then be supported for fifteen.
An infusion pump cleared this year may still be on hospital wards a decade from now.
A core banking platform being modernised today will outlast many of the people approving it.
Now the other side of the ledger. The AI components going into all three have supported lives measured in months, or at best a few years. Frontier models are withdrawn on published schedules. Open-weight models quietly lose ecosystem support. The runtime, libraries and silicon underneath them follow hardware and software cycles that were never designed to stretch across a fifteen-year obligation.
Somebody in your organisation has already put the second thing inside the first.
The instinctive response is that this is a procurement problem with a procurement answer: own your models and the dependency disappears. That answer is half right, and the half that is wrong is expensive.
What owning the model actually gets you
Most organisations are heading toward a mix: frontier services for general work, fine-tuned open weights where volume or data sensitivity demands it, and purpose-built models where the domain is narrow enough to justify one. That is sensible. It may be where enterprise AI settles for years.
But the three options fail differently.
If you consume a frontier model, you operate on a vendor's calendar. Notice arrives, the model is retired, and you cannot decline.
If you run open weights, formal deprecation is gone. Nobody can withdraw a file you already possess. What replaces it is quieter: the architecture falls out of fashion, the tooling moves on and the serving stack stops being maintained. There may be no notice because there is no single vendor responsible for sending one.
If you train your own models, you have maximum control over the model and almost none over what runs it.
Weights are a file of numbers. They do nothing alone. To turn them into working behaviour you need a compilation and quantisation toolchain, an inference runtime, vendor mathematics libraries, drivers and a particular accelerator. Every layer has a support window, and someone else decides when it closes.
Picture year nine of a fifteen-year obligation. The accelerator in your control unit is end-of-life. The toolkit that targeted it stopped being maintained. The toolchain that compiled your validated binary will no longer build on an operating system you are permitted to run.
You still own the weights. That was never the problem.
You have lost the ability to reproduce or rebuild the working system.
You can update. It just costs you every time.
It is wrong to say that long-lived or regulated products cannot be updated. They can. The important fact is that each change consumes engineering, testing, evidence, operational coordination and sometimes formal approval.
Automotive software-update rules explicitly permit over-the-air change, but require manufacturers to know which vehicles are affected, control configuration, assess compatibility and determine whether the update affects safety or approval. The FDA's Predetermined Change Control Plan goes further: a manufacturer can define expected modifications, validation methods and impact assessments in advance, then implement changes inside the approved envelope without making a fresh submission each time.
Banking uses different language but follows the same logic. Model-risk frameworks expect lineage, independent challenge, validation and evidence that an examiner can inspect.
Three regimes, three vocabularies, one assumption underneath: the institution controls the thing being assured and decides when it changes.
A supplier deprecation or ecosystem collapse violates that assumption. The cost of assessing one change may not have increased. The number of changes forced on the institution has.
The design fix
If a product carries a decade-long obligation, no AI component should be welded into it. It should be treated as a serviceable part behind a defined interface—the same discipline already applied to any component whose service life is shorter than the assembly around it.
That means four things.
The interface stays fixed. The surrounding system should not depend on every proprietary quirk of the present model.
Degraded behavior is designed. What happens when the component is missing, unavailable, materially changed or replaced should be specified and tested before a customer discovers the answer.
Replacement is a procedure. The owner, sequence, evidence, elapsed time and expected cost should be known. “We can switch models” is not a replacement plan.
Protective properties live outside the model. Put the payment limit in ordinary code. The model can propose a transfer of any size; a deterministic rule refuses anything above the threshold whether the proposal came from a 2026 model or its 2032 replacement. The same pattern applies to a torque ceiling, dosage range, contraindication or keep-out zone.
When the model changes, the limit does not move. The evidence supporting that limit therefore survives.
None of this is new engineering. It is how competent organisations handle a discontinued microcontroller, an expiring cryptographic algorithm or any other short-lived part inside a long-lived system. AI often entered through teams applying ordinary cloud-software habits. Those habits assume that frequent redeployment is cheap. In these environments, redeployment carries an obligation.
Why a mixed approach can compound the problem
A portfolio of models feels like diversification. In this case it may create three additional exposures.
The clocks do not align. A frontier component refreshes on a vendor's timetable. An open-weight component follows an ecosystem's attention span. An internal model refreshes when the institution retrains it—or when its hardware ages out. Owning one synchronises one clock and leaves the others running.
The hardest cases are often rented. Many mixed architectures route routine work to a cheaper controlled model and escalate ambiguous or difficult work to a frontier service. The decisions where error costs the most may therefore be the ones operating on somebody else's lifecycle.
Every extra model creates a new operating mode. Two models require validation of each model, the routing decision, the handoff, and the system's behavior when one component is unavailable or silently changes. Two models are not simply twice the work.
There is a fourth consequence that arrives later. A customer is declined for credit and asks why. “The AI assessed the application” is not an answer. The institution must identify which model, which version, under which policy and on which date—and produce the record.
Which component handled which decision is now part of the audit trail. Instrumenting it at design time is straightforward. Reconstructing it later may be impossible.
The practical test
Ask one question for every consequential AI component:
Who owns the replacement path, how long would it take to exercise, and what would it cost?
If nobody can answer, the dependency is not managed. It has merely not failed yet.
The durable asset is not the model. It is the combination of a replaceable architecture, an executable stack you can reproduce, controls that survive the swap, and an institution capable of completing the change inside the time available.