How do I re-review an AI vendor before renewal?

The trigger

The renewal date on an AI vendor contract is sixty days out, or the annual review of an approved AI service falls due. The approval on file was granted against a configuration that has almost certainly moved since, because approval decays after deployment as models, prompts, connectors and permissions change underneath it. Renewal is the one point in the year where declining is a real option, so it is the point where the evidence has to be current.

The inputs

• The original approval record: approved purpose, users, tested configuration, conditions and approver
• The contract, with the material change and notification clauses to hand
• Every vendor release note, change notice and incident notification received since approval
• The service entry in the critical operations register, with its stated tolerance and minimum service level
• The nominated fallback and the date it was last tested end to end
• Dependency evidence: served model family and version, hosting cloud and region, gateway, identity and retrieval services, disclosed fourth parties
• The CPS 234 vendor due diligence checklist used at onboarding

The steps

1. Reconstruct what was actually approved. Pull the approval record and state the tested configuration in one paragraph. If the evidence cannot identify the system that was tested, stop and mark the service due for full revalidation rather than renewal.
2. Rebuild the dependency line. Trace the service back through its foundation model, cloud, region, gateway, identity and retrieval services to its disclosed fourth parties. Label every edge verified, vendor stated, inferred or unknown.
3. List every change event since approval. Sweep release notes, change notices, incidents and complaints into one list, and classify each as record only, targeted test, full revalidation or stop use.
4. Retest the fallback. Compare the nominated substitute against the primary on capability, infrastructure independence, data and control continuity, and executable human activation. A different product name is not independence when three vendors sit on one foundation model.
5. Re-read the clauses that carry clocks. Confirm the notification window, the material change route and the exit terms still match how the service is used, since a vendor breach starts your own clock and contract terms are the CPS 230 control.
6. Put the decision to the named owner. Renew, renew with conditions, or decline. Record the decision, the evidence it rests on and the next expiry date.

The prompts

Using only [APPROVED_SOURCE_PACK], rebuild the dependency line for
[AI_SERVICE_ID]. Return direct vendor, foundation model and version,
hosting cloud and region, gateway, identity, retrieval, monitoring,
fourth parties, evidence source, evidence date and confidence label.
Mark every missing or inferred edge HUMAN REVIEW REQUIRED. Do not
classify the provider as material and do not state that an unknown
dependency is independent.

Compare the approved configuration manifest with the current one for
[AI_SERVICE_ID] over [DATE_BAND]. List every change to model,
instructions, retrieval data, tools, permissions, safety settings,
users and purpose. Map each change to a known failure mode and
recommend record only, targeted test, full revalidation or stop use,
with reasons. Do not authorise renewal and do not infer that an
omitted field is unchanged.

The checks

• Every dependency edge carries a confidence label, and no inferred edge is reported as architecture fact
• Each change event has a classification and a named owner
• The fallback result reads PASS, FAIL or NOT PROVEN against each of the four proofs, with evidence references
• Nothing in the pack identifies a customer, an employee or a specific matter
• The renewal recommendation names the person who decides, not the tool that drafted it

Governance controls

The renewal decision belongs to the accountable service owner, with second line review. AI structures the evidence and challenges the fallback claim, and never approves, classifies materiality or accepts residual risk. De-identify before anything leaves your systems: use banded placeholders such as [VENDOR_ID], [BUSINESS_AREA_BAND] and [DATE_BAND] rather than named customers, staff or open incidents. Keep the source pack, the prompt outputs and the signed decision together, because at the next review that record is the only proof of what was tested. Where the vendor supports a critical operation, reconcile the outcome to the critical operations register and the service provider records before the contract is signed.

The output

A renewal pack: a dependency line with confidence labels, a classified change log since approval, a fallback test result, a clause check, and a dated decision signed by the accountable owner with the next expiry set.

Time it takes

Ninety minutes for one service once the approval record and release notes are gathered. The first one takes longer because the dependency evidence rarely exists in one place.