Change Control When the Supplier Updates the Model

AI systems are updated. Suppliers improve models by retraining on new data, adding features or fixing problems. Your contract must specify how updates happen and what control you have. Without change control terms, suppliers can change your system without your consent, and the changes can degrade performance or introduce new risks.

A bad contract gives the vendor unlimited update authority. The term might state: “The supplier may update the model at any time without notice or approval.” This leaves you vulnerable. An update could break an integration, degrade performance or introduce unwanted behaviours. You would have no notice, no recourse and no ability to prevent it.

A good contract gives you change control. It specifies: what types of updates require approval before deployment, what notice the vendor must provide, how you can defer or refuse updates, and what happens if you refuse an update.

Updates fall into categories. Critical security updates that patch vulnerabilities should probably deploy immediately with notice; you cannot reject a security fix. Performance improvements that you requested might deploy automatically. But major changes like retraining on new data or model architecture changes should require your approval before production deployment.

A good change control clause reads: “The vendor will provide 30 days’ notice of any non-security update. You may request to test the update in a staging environment before production deployment. You may defer non-security updates for up to 60 days. If an update introduces an unacceptable change to performance or behaviour, you may reject the update and continue using the previous version. Security updates may be deployed with 24 hours’ notice.”

This clause does several things. First, it requires notice, so you know changes are coming. Second, it provides a test period, so you can verify the update does not break your system. Third, it allows deferral, so you can delay updates during critical periods. Fourth, it allows rejection if the update causes problems. Fifth, it balances security against control by treating security updates differently.

You should also specify what “performance” means in the context of updates. Does an update that increases accuracy but takes longer to run constitute acceptable change? Does an update that improves accuracy on some customer demographics but worsens it on others constitute acceptable change? Your contract should define this.

An example change control term: “Vendor updates must not degrade accuracy by more than 2 percentage points, must not increase response time by more than 10 percent, and must not introduce new failure modes where the system makes decisions with confidence above 70 percent in cases where a human expert would abstain. You may reject updates that violate these standards.”

This term sets clear boundaries around what changes you will accept.

You should also address rollback. If an update causes problems, can you ask the vendor to revert to the previous version? Your contract might state: “If an update causes problems, you may request the vendor to rollback to the previous version within 24 hours. The vendor will maintain the previous version for 90 days after each update to enable rollback.”

Monitoring is also important. How will you know if an update caused problems? You need visibility into performance metrics over time. Your contract might require: “The vendor will provide weekly performance reports showing accuracy, response time, and error rates for the previous week. Any significant change from the previous week will be flagged for your review.”

Practical example: your customer service team relies on an AI chatbot to handle common inquiries. The system is performing well, handling 70 percent of inquiries without human escalation. The vendor pushes an update without notice. The update retrains the model on new data. After deployment, the chatbot’s accuracy drops to 55 percent. Human escalations increase and wait times triple. Customer satisfaction declines. You contact the vendor and learn: “We deployed an update. It should have improved performance. We will investigate.” This leaves you without a working system while the vendor investigates. If change control was in place, you would have tested the update before deployment and rejected it, preventing the production outage.

A better scenario with change control: the vendor plans an update and provides notice. You download the updated model and test it in a staging environment. During testing, you discover the accuracy drop. You reject the update and continue using the current version. The vendor investigates why accuracy dropped and provides a better version in two weeks.

Change control also matters for maintenance burden. Frequent updates might require you to test constantly. Your contract might limit update frequency: “The vendor will release updates monthly, not more frequently, except for security updates. This allows your team to manage testing workload.”