The exposure in one paragraph
Your institution has spent years building an apparatus for overseeing models: documented lineage, independent validation, periodic review and evidence an examiner or assessor can inspect. That apparatus works. It was also designed around an assumption that does not always hold—that the institution controls the model and decides when it changes.
A growing share of models inside consequential workflows are commercial services or ecosystem-dependent components with lives shorter than the surrounding platform or device. When the supplier withdraws one, or the serving stack becomes unsupported, the institution does not get to decline.
Why existing controls may not catch this
Three gaps sit in blind spots rather than obvious weaknesses.
Validation tests the model, not the dependency lifecycle. Independent validation asks whether a model is fit for purpose, conceptually sound and performing within tolerance. It may not ask how long the exact component will be supported, who controls that timetable or what happens to the validated state when it is replaced. A model can pass validation and still be scheduled for withdrawal.
Change control assumes the institution initiates the change. Banking model-risk management and clinical software change management are designed around a change the institution proposes, assesses and approves. A vendor deprecation is a change nobody inside proposed, on a timetable nobody inside selected.
Ownership can be reported as control. Institutions running fine-tuned open-weight or internally trained models may report the dependency as resolved. Owning weights removes direct withdrawal of the file. It moves obsolescence down to the inference runtime, libraries, toolchain and hardware. The assertion can be true as stated and misleading as understood.
The three exposures worth naming
Continuity. A component central to a decisioning or clinical workflow is withdrawn, and validating a replacement takes longer than the notice period. The fallback becomes a degraded manual process or an insufficiently validated substitute.
Evidence. A customer is declined, or a clinical recommendation is contested, and the question is why. “The model assessed it” is not enough. The record should identify the model, version, applicable policy and date. Where workflows route among several models, many institutions cannot produce that record without investigation.
Reproducibility. Assurance depends on being able to reconstruct how a decision or build was produced. If the tool or serving stack has been withdrawn, exact reconstruction may be impossible. The problem emerges years later during an examination or incident review rather than when the dependency was introduced.
Seven questions for management
- Which models in consequential workflows are supplied rather than fully controlled, and what is the contractual and practical notice period for each?
- For each, what is the measured elapsed time from a deprecation notice to a validated replacement in production? If that exceeds the notice period, the exposure exists now.
- Where the institution runs its own models, what is the supported life of the inference stack—runtime, libraries, toolchain and hardware—and who tracks it? Ownership of weights is not ownership of the executable stack.
- Can the institution produce, for any decision in the last twelve months, the specific model and version that produced it? If the answer requires a special investigation, the operational answer is no.
- What is the defined behavior when a model component is unavailable or materially changed? Is degraded mode specified, tested and validated as an operating state, or left undefined?
- Which controls protecting customers or patients are enforced outside the model? Limits, thresholds, contraindication checks and segregation of duties belong in deterministic mechanisms that survive model replacement.
- Who owns the replacement path for each dependency, and has the path been exercised? An untested recovery path is an assumption.
What good looks like
Institutions handling this well can adapt disciplines they already possess.
They extend the model inventory to record supported life, supplier, notice period, serving-stack dependencies and replacement owner alongside validation fields. This is initially a schema change, not a new governance empire.
They treat replacement as a tested procedure, exercise it and record elapsed time. The first production replacement should not occur when the institution is forced to complete it.
They move protective controls outside the model. Where a limit, threshold or exclusion protects a customer or patient, deterministic code or policy enforcement makes the protection stable across model changes and easier to evidence.
They instrument decision provenance prospectively. Recording which model and version handled a decision is inexpensive as a design choice and expensive as a retrofit.
The reframe for the committee
The instinct is to treat this as technology-selection risk and route it to the team choosing models. That is where it may be least visible.
The exposure is created by the gap between a component's supported life and the institution's obligation. That gap is visible to the owner of continuity, customer or patient duty, model risk, product support or regulatory evidence—not only to procurement or data science.
The necessary disciplines already exist: supplier concentration risk, business-continuity planning, end-of-life management, model inventories and change control. They have simply not always been pointed at this component layer.
Adding lifecycle and replacement to the existing register is a smaller intervention than discovering the gap during an examination, product incident or supplier withdrawal.
Notes
Banking. In the United States, the Federal Reserve issued revised model-risk-management guidance in SR 26-2 in April 2026. In Canada, OSFI published the final Guideline E-23 in September 2025; it takes effect for federally regulated financial institutions on May 1, 2027. The details differ, but the direction reinforces inventory, governance, validation and ongoing oversight.
Healthcare and medical devices. IEC 62304 establishes medical-device software lifecycle processes. The FDA's 2025 final guidance on Predetermined Change Control Plans permits specified AI-enabled device modifications to be reviewed in advance when the modifications and methods are defined and verifiable. That is valuable for planned change and less complete for a change forced by an external component reaching end of support.
Full argument. The technical foundation is set out in The Model Will Be Gone Before the Product Is.