Consider a vehicle programme approved this quarter, an infusion pump cleared this year, and a core banking platform being modernised today. The vehicle may take three years to reach production and require another fifteen years of support. The pump may still be in use a decade from now. The banking platform may outlast many of the people approving it. Each creates an obligation extending well beyond the initial implementation.
Now consider the AI components being incorporated into those products. Their supported lives may be measured in months or, at best, a few years. Frontier providers retire models on published schedules, open-weight models lose ecosystem support, and the underlying runtime, libraries and hardware follow their own refresh cycles. The organisation is combining a long-term customer obligation with components whose availability it may control only partially.
Owning the model appears to offer a straightforward answer. It removes the supplier's ability to withdraw the weights, which is useful, but it does considerably less to ensure that the organisation can maintain the working system for the full period it has promised. That distinction needs to be understood before ownership is presented as a solution to the dependency.
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.
The relevant dependency differs across those options, and each needs its own management approach.
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.
The weights remain in your possession, but you may no longer be able to reproduce or rebuild the working system. Ownership of one layer has therefore left the product exposed to the supported lives of all the others.
The cost and authority to change
Long-lived and regulated products can be updated. The practical constraint is that each update requires engineering, testing, evidence and operational coordination, and may also require formal approval. The organisation needs to account for that effort whenever a component changes, including when the change is imposed from outside.
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. Across these regimes, the assurance process depends on an important assumption: the institution can control the component being assured and the timing of changes to it.
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.
Designing the AI component for replacement
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 requirement has four practical implications for the product architecture and the organisation supporting it.
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?
An unanswered question indicates a gap in management of the dependency, even if the system is performing well today. Product and technology leaders should establish the replacement owner, procedure, elapsed time and cost before committing to the support obligation. Long-term durability depends on being able to reproduce the executable stack, replace the component, preserve the protective controls and complete the change within the time available.