When to re-assess an AI vendor

The case for AI vendor reassessment is straightforward: the risk profile of the vendor's AI system is not static, and the assessment that justified the initial approval will become stale if the system changes. What matters is not just that the system changes — it is whether those changes alter the risk in ways the original assessment did not account for.

Reassessment is not always a full re-run of the original assessment. Most trigger events call for a scoped supplemental review focused on what changed and whether the change materially alters the risk or control requirements. Full re-assessments are warranted only when the nature of the vendor's AI system has changed substantially.

Five categories of events should trigger a reassessment evaluation for an AI vendor:

1. Model updates — the vendor changes the underlying model
2. New AI features — new AI capabilities are introduced to the product
3. Changed data handling terms — the DPA is updated in ways that affect AI processing
4. Vendor incidents — the vendor has a security or AI-related incident
5. Expanding use cases — the organisation uses the vendor's AI for new purposes

Each trigger requires an evaluation — not automatically a full reassessment. The evaluation determines whether the trigger is material: whether it changes the risk profile in ways the existing assessment did not address. If it is not material, the assessment record is updated with a note documenting the trigger, the evaluation, and the conclusion. If it is material, a scoped or full reassessment is initiated.

The model update trigger fires when the vendor changes the underlying model powering the AI feature. This includes base model changes, major version upgrades, model provider changes, and significant fine-tuning changes.

When this trigger fires, the reassessment scope focuses on: what changed in the model, whether the new model has different capability boundaries, whether the data handling terms changed as a result of the model change (particularly if the model provider changed), and whether the original assessment's controls remain appropriate for the new model. The model version in the assessment record must be updated.

The new AI features trigger fires when the vendor introduces AI capabilities that were not present in the assessed version of the product. This includes new AI-powered features added to an existing product, new modalities (the product gains image understanding or document analysis capabilities), and new integrations (the AI feature gains access to additional data sources).

The reassessment scope for new AI features focuses on: what data the new feature accesses, whether the new feature changes the subprocessor chain, what capability boundaries the new feature introduces, and whether the existing controls are sufficient for the new capability.

A new AI feature in an existing product is functionally a new AI system embedded in a trusted relationship. It requires the same assessment discipline as an initial vendor review — scoped to the specific feature rather than the full vendor.

The changed terms trigger fires when the vendor updates its data processing agreement, terms of service, or privacy policy in ways that affect how AI-related data is handled. Trigger conditions include: changes to training data use policies, changes to inference data retention periods, changes to the subprocessor list, and changes to data residency or transfer mechanisms.

Most enterprise SaaS vendors provide advance notice of DPA changes — typically 30 days. The challenge is identifying which DPA changes are relevant to the AI component. A change to the vendor's infrastructure subprocessors may not require reassessment; a change to the model provider subprocessor always does.

The vendor incident trigger fires when the vendor has a security incident, an AI behaviour incident, or a regulatory action related to its AI product. Incident types that warrant a reassessment evaluation: data breaches that affected customer data processed by the AI feature, model behaviour incidents that produced harmful or unexpected outputs, regulatory enforcement actions related to data processing, and third-party model provider incidents that affected the vendor's product.

The reassessment scope following an incident depends on the incident type. A data breach requires reviewing whether the incident affects the assessment's data handling conclusions. A model behaviour incident requires reviewing whether the incident reflects a systemic risk that the original assessment should have identified or that requires additional controls.

The expanding use cases trigger fires when the organisation begins using the vendor's AI for purposes not covered by the original assessment scope. Common expansions: using the AI feature with sensitive data classes (PII, regulated data) that were not in scope at initial assessment; enabling the AI feature for new user populations (customer-facing rather than internal); integrating the AI feature with systems not considered in the original assessment.

This trigger is under-monitored because it is driven by internal changes rather than vendor actions. The organisation's vendor governance process must include a mechanism for teams to declare when they are expanding their use of an approved AI vendor feature in ways that go beyond the original assessment scope.

The governance record for an AI vendor should track the full history of trigger events and their disposition — not just the most recent assessment. This allows an auditor or regulator to trace when trigger events occurred, how they were evaluated, and what the outcome was.

The record should include for each trigger event: the date the trigger was identified, the nature of the triggering change, the evaluation of materiality, the scope of reassessment if one was conducted, the updated disposition, and any new conditions or re-assessment triggers added as a result.

For organisations managing a portfolio of AI vendors, the trigger evaluation process is where most of the ongoing governance work sits. The initial assessments are one-time efforts; the trigger monitoring and evaluation is the continuous discipline that keeps the governance record accurate.