Re-acceptance after AI updates: what your vendor tests, what you check
Leave to the vendor the changes its tests can judge, and re-accept in-house only those that need your business know-how.
Key points
- Split AI changes in two by vendor tests
- Re-accept in-house what needs know-how
- List tested behaviours in the contract
- Add a log and rollback to delegated work
Contents
Split AI changes in two by whether vendor tests can judge them
A&A perspective
Split the changes your vendor makes to the AI into two kinds: those the vendor's own tests can judge, and those they cannot. Re-acceptance here means you, the buyer, checking pass or fail again for a change made after delivery.
A&A perspective
The size of a change is no guide. Moving to a newer model version can leave every behaviour the vendor checks passing as before. Rewording a single word in a prompt can make the AI miss one field it used to read. A behaviour here means the answer or action the AI returns for a given input.
From the sources
On 9 January 2026 Anthropic published an explainer on evaluating AI agents. It describes a regression test as one that asks whether the agent still handles all the tasks it used to. Such a test should hold a pass rate of nearly 100%, and a drop signals that something has broken.
From the sources
The same explainer sorts grading into three kinds: grading by code, grading by an AI model, and grading by people. It calls human grading the gold standard, the one that matches expert users' judgement, but notes that it is expensive and slow.
A&A perspective
Automate & Augment (A&A), which writes this article, reads this as a clue to where the line goes. Code and model grading can run on the vendor's side. The experts that human grading calls for are, from the buyer's seat, usually the people in your own operations.
Re-accept in-house the changes that need business know-how
A&A perspective
Re-accept in-house only the changes that touch behaviours whose quality takes your business knowledge to judge. Whether a summary has the level of detail your staff can use, or whether the rule for which documents go to a person still fits, is not something the vendor can judge.
From the sources
On 25 April 2025 OpenAI shipped an update to GPT-4o in ChatGPT. OpenAI reports that responses then shifted noticeably toward flattering users, and that it began rolling back to the earlier version on 28 April.
From the sources
According to the report, the automated evaluations run before the update, including those testing behaviour, generally looked good. A/B tests with a small number of users also seemed to show that people liked the new version.
From the sources
Even so, some of the internal experts who try each new version before launch had said the model's behaviour felt slightly off, the report says.
A&A perspective
A&A reads this as a case of a change that passes the numeric tests and still shows up only when a person uses it. With an outsourced AI, that person is your own staff. Passing every vendor test does not prove that the system is still good enough for your work.
A&A perspective
On the other hand, checking every change yourself makes the checking load grow regardless of real risk. Once checks become a formality, the changes that truly need a look slip through with the rest. You narrow what you check so that time is left for what matters.
| Example change the vendor makes | Who can judge the behaviour that might break | Treatment in the maintenance contract |
|---|---|---|
| Rewriting internals to speed up responses (same output) | The vendor. Output match and time can be measured in code | Leave to the vendor. Keep it in the log |
| Tidying the wording of the reading prompt (same targets) | The vendor. Matches against correct answers on past documents can be measured | Leave to the vendor. Receive results in the monthly report |
| Moving to a newer model version | The vendor for behaviours its tests check; you for those they do not | Leave to the vendor inside the tested behaviours. Re-accept if it touches anything outside |
| Changing the style or level of detail of summaries | You. Only the reader's standard decides | Re-accept. Agree by looking at samples |
| Changing the rule for what goes to a person, to widen what is processed automatically | You. You decide how many misses are acceptable | Re-accept |
| Adding a new kind of document to cover | You. Your business decides what is correct for that document | Re-accept. Have the vendor quote it separately as added scope |
List tested behaviours in the maintenance contract
A&A perspective
What goes into the maintenance contract is not a list of change types but a list of the behaviours the vendor's tests check. Agree in advance that changes explained entirely inside the list are left to the vendor, and changes that touch anything outside it are re-accepted in-house.
A&A perspective
Three columns are enough: the behaviour, how it is judged, and whether the vendor or you judge it.
Hypothetical example
Say a company had a vendor build invoice reading for it and puts four rows in the list. This is a hypothetical example. Row 1 is reading the amount, date and supplier name, which the vendor judges in code by matching the correct answers for past invoices. Row 2, the digits and currency format of amounts, is also judged by the vendor in code.
Hypothetical example
Row 3 is whether entries the AI cannot read are passed to a person by the agreed rule. The vendor grades it with an AI model, and four times a year your staff review the grading results to check that the AI's grading has not drifted from your own judgement. Row 4, whether the attached summary is usable by your staff, is judged by you.
Hypothetical example
With this list, you re-accept only the changes that touch row 4 or a behaviour not on the list.
From the sources
Anthropic's explainer names, as the first material for evaluations, turning failures reported by users into test cases. It says this keeps the test suite in line with actual use.
A&A perspective
For a buyer, that means handing the defects you find to the vendor and having them added to the vendor's tests. Each addition gives the vendor one more row to judge and narrows what you check yourself.
A&A perspective
Keeping the list up takes work. Before signing, confirm with the vendor that the maintenance fee covers that work. A list the fee does not cover ends up unmaintained, leaving only a line in the contract saying the system is tested.
Add a log and rollback to delegated changes too
A&A perspective
Changes you leave to the vendor still need a change log and a contact for asking to go back to the previous behaviour. You can skip your own checks only when there is a way for you to notice and reverse a delegated change that made things worse.
From the sources
The US National Institute of Standards and Technology (NIST) publishes a framework for managing AI risk. Item 4.1 in its Manage section lists plans for monitoring an AI system after it goes into use. Those plans include ways to collect and evaluate input from users, appeal and override, recovery and change management.
From the sources
On the GPT-4o case, OpenAI writes that it expected the update to be subtle and did not announce it in advance. It says it will now announce updates whether they are subtle or not. It reports that the full rollback to the earlier version took around 24 hours.
A&A perspective
Three additions to the contract are enough: a place where you can see the change log at any time, an address for objections with a reply deadline, and a period during which the vendor will return to the previous behaviour on request. Ask for small changes to be logged too.
A&A perspective
Note that older versions of the outside models a vendor uses do not necessarily stay available. If the vendor cannot promise a rollback period, writing "top priority on bringing behaviour close to the previous one" instead of "return to the previous version" makes a promise that can be kept.
A&A perspective
The NIST framework is voluntary. Check the clause wording with your own legal adviser.
Summary
A&A perspective
Split AI changes in two by whether the vendor's tests can judge them. Re-accept in-house only the changes whose quality needs your business knowledge to judge, such as summary detail. Put a list of the behaviours the vendor's tests check in the maintenance contract. Give delegated changes a log and a contact for going back to the previous behaviour too.
You do not need to check every change that goes into your vendor's AI. Leave the changes its tests can judge to the vendor, and re-accept in-house only those that need your business knowledge, such as summary detail. Write that boundary into the maintenance contract as a list of the behaviours the vendor checks, and give delegated changes a log and a route back to the previous behaviour. For a small system that changes a few times a year, having the vendor tell you about each change and checking it yourself is cheaper.
FAQ
Do small systems need this list too?
Not always. If changes come a few times a year and checking takes one email, it is cheaper to write that the vendor tells you about every change and you check it yourself.
If the vendor's tests pass, can we say the change is fine for us?
No. The tests check whether behaviour matches what it was before, not whether that behaviour still helps your work.
How far does this list reach?
It covers changes that come from the vendor's side. Acceptance criteria for the first delivery are covered in "AI deliverable acceptance criteria: 4 terms for output that varies". How to update the AI when your own company rules change is covered in "When your company rules change, who updates the AI? 3 vendor clauses".
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Demystifying evals for AI agents
Anthropic · 2026-01-09
Accessed 2026-10-23 - AI RMF Core — Manage (NIST AI Risk Management Framework 1.0)
NIST AI Resource Center · NIST AI RMF 1.0 (2023), per the page
Accessed 2026-10-23 - Expanding on what we missed with sycophancy
OpenAI · 2025-05-02
Accessed 2026-10-23