An AI service can change underneath your operating model as vendors implement their changes.
Vendor change control must be treated as a live operational-risk discipline—not a clause reviewed once at procurement.
If your organisation cannot identify affected processes, test a replacement and make a go/no-go decision inside the vendor’s notice period, accountability has been outsourced but risk has not.
The 30-second take
AI vendors retire models, alter capabilities and change subcontracting arrangements. The practical control is a named owner, an inventory linking each external model to business processes, defined notification and objection rights, and a rehearsed migration path. A vendor notice is only the start: internal readiness determines whether the change becomes controlled adaptation or operational disruption.
APRA has highlighted that many Boards rely too heavily on vendor presentations and lack the literacy needed to challenge unpredictable model behaviour and operational impacts. It expects Boards to oversee an AI strategy aligned with risk appetite and supported by reporting, third-party oversight and intervention triggers.
Now is the time to undertake activity to understand your and your vendors AI risk. Tools such as the AI Signal BoxTM provide clear tools to support AI governance assessments, vendor assessments and ogoing monitoring.
Model retirement is an operating event
Microsoft’s Azure AI Foundry lifecycle guidance makes the issue explicit. Models move through availability, deprecation and retirement, while security or compliance concerns can trigger an emergency retirement with shortened notice. That means a team cannot assume every material change will fit its annual review cycle; it needs current dependency records and an escalation route capable of acting quickly.
AWS documents an equally concrete consequence for Amazon Bedrock. When a model reaches end of life, requests to it fail, migration is not automatic and customers may need to update application code to use a replacement.
The operational outcome is clear: without tested compatibility, fallback arrangements and accountable release decisions, a supplier lifecycle event can interrupt a customer-facing process even when the underlying cloud platform remains available.
Contract rights must connect to operational capability
The European Union’s DORA delegated regulation provides a useful benchmark for material changes in technology supply chains. For subcontracting that supports critical or important functions, providers must give notice early enough for the financial entity to assess the effect, with provisions for approval or objection and termination rights in specified circumstances. Even outside DORA’s scope, the principle is useful: notification rights have little value unless the organisation can assess impact and act before the change takes effect.
Put those expectations into one operating model:
- Maintain a register of external models, versions, owners, affected processes and critical data flows.
- Define what counts as a material vendor change, who receives notices, how impact is triaged, what testing evidence is required and who accepts residual risk.
- Track the time from notice to impact assessment and from decision to tested migration; those measures expose whether the control works before a forced change does.
Questions for your organisation
- Can you identify every critical process that depends on a specific third-party AI model or version?
- Do contracts require timely notice of model retirement, capability changes and material subcontracting changes?
- Who decides whether to accept, challenge, defer or exit after a material vendor change?
- Can your teams test a replacement model and its downstream controls within the shortest credible notice period?
- Are fallback arrangements technically viable, documented and rehearsed rather than merely described in a contract?
- Does the board or risk committee receive evidence on unresolved vendor changes and migration readiness?
Turn notice into readiness
Do not wait for a vendor notice or an escalated vendor issue to discover that no one has monitored AI changes in vendors.
Use the Innovation of Risk to test your readiness and turn vendor change controls into an operational capability.