Model-change notification — the vendor clause procurement teams forget

A security review of an AI vendor assesses specific properties of the system as deployed: the model's capability scope, its known failure modes, its behaviour under adversarial inputs, the data flows through the inference layer, and the alignment characteristics that determine how it responds in edge cases.

These properties are tied to a specific model version. When the vendor changes the model, the properties change. The new model may have capabilities the old model did not — including capabilities that create new risks in the deployment context. It may have different failure modes. Its data handling behaviour may differ if the new model comes from a different provider. Its alignment properties — the rules and boundaries the model was trained to respect — may have shifted.

In assessed systems we have reviewed, the most common failure mode is a disposition record that lists the model version as a condition of the approval, with no mechanism to detect when the model changes. The condition exists on paper; there is no operational process to enforce it.

Not every model update is a material change requiring a full re-assessment. The definition of materiality determines which changes trigger the notification obligation and which can be handled through a lighter-touch update to the review record.

Changes that should be treated as material for re-assessment purposes:

• Base model switch:The vendor changes the underlying model from one provider's model to another — for example, from an Anthropic model to an OpenAI model, or from a public model to a proprietary internally-developed model. The risk profile, data handling terms, and alignment properties are all materially different.
• Major version upgrade: The vendor upgrades from one major version of a model to another — for example, from GPT-4 to GPT-4o or from Claude 2 to Claude 3. Major versions typically have different capability profiles and may have different alignment properties.
• Fine-tuning dataset change: The vendor changes the fine-tuning dataset used to adapt the model for their product. If customer data is used in fine-tuning, or if the new dataset introduces capabilities not present in the original fine-tuned version, this is material.
• Significant capability addition: The vendor adds a capability to the AI product that was not present in the assessed version — such as tool use, web access, code execution, or a new data modality.
• Model provider change: The vendor changes the third-party model provider whose infrastructure powers the inference layer. The new provider has different data handling terms, different retention policies, and different subprocessor status.

Changes that are generally not material: patch-level updates within the same model version, prompt template adjustments that do not change the model's capabilities, and infrastructure updates that do not affect the inference layer or data flows.

Standard vendor contracts do not include a model-change notification clause. The notification obligations in a standard SaaS agreement cover security incidents, data breaches, and service outages. None of these covers a model update — even a material one that changes the risk profile of the product.

The contractual gap is not a vendor oversight — it reflects the fact that most vendor contracts predate the era of AI-powered products. Vendors that have not specifically addressed model-change notification in their agreements have not done so because no one asked. The clause needs to be negotiated.

The practical consequence of this gap: organisations have no contractual right to know when the model they assessed has been replaced. The vendor's obligation is to provide the product as described in the order form. If the product description refers to “AI features” without specifying the model, the vendor has no obligation to notify when the model changes.

The model-change notification clause should be negotiated as part of the initial vendor agreement, or added by amendment when the AI feature is introduced. The clause should address:

Scope: What changes constitute a material model change triggering the notification obligation — at minimum, base model changes, major version upgrades, and model provider changes.

Notice period:The minimum advance notice before a material model change is deployed to the customer's environment. Thirty days is a reasonable minimum for enterprise customers who need time to assess the change.

Content of notice: What information the vendor must provide in the notification — at minimum, the identity of the new model, the reason for the change, a summary of capability differences, and an updated data processing description for any change in how customer data is handled.

Customer options: Whether the customer has a right to delay the model change while conducting a supplemental assessment, or to continue using the prior model version for a defined period.

Re-assessment support:The vendor's obligation to provide updated security documentation — model cards, data processing descriptions, red-team summaries — sufficient to support a supplemental security assessment.

In addition to the contractual clause, the organisation's disposition record for the vendor should include a re-assessment trigger that fires on model change. The trigger connects the contractual notification right to the internal security process.

The trigger entry in the disposition record should specify:

• The event that fires the trigger: vendor notifies of a material model change.
• The review scope when triggered: supplemental assessment focused on the model change and its security implications.
• The responsible party: who initiates the supplemental assessment when the trigger fires.
• The disposition status during assessment: whether the existing approval remains in force during the supplemental assessment, and under what conditions it would be suspended.

Where no contractual notification clause exists, the trigger should include an alternative detection mechanism: periodic review of the vendor's release notes, model card updates, or changelog for material model changes.

The evidence record for the vendor assessment should document the model version in use at assessment time as a specific, verifiable fact — not a general description like “GPT-4 based.” The version number, the provider, and the date of assessment should be captured.

When a model change occurs and a supplemental assessment is conducted, the evidence record should be updated to reflect:

• The previous model version and the date it was in place.
• The new model version and the date it was deployed.
• The supplemental assessment conducted, including scope, findings, and disposition.
• Whether the supplemental assessment resulted in a change to the overall disposition, additional conditions, or confirmation that the existing disposition remains valid.

This creates a traceable history of the vendor's AI system as it has changed over time — and a record that can withstand a regulator or auditor inquiry about whether the organisation maintained current, accurate security review records for its AI vendor relationships. For the broader evidence requirements for the full vendor assessment record, see When to re-assess an AI vendor.