An AI service can change after initial approval. New models, features, data practices, permissions, retention terms, integrations, or safety controls can alter the assumptions behind an earlier review.
Define material change
Establish which vendor or internal changes require reassessment. Examples can include a new model family, materially different outputs, expanded data use, changed hosting or subprocessors, new autonomous actions, broader permissions, altered retention, or a significant change in the business use case.
Compare against the approved baseline
Keep enough information about the approved version and use to identify what changed. Review purpose, users, data, integrations, human oversight, known limitations, testing, security controls, and contractual or policy conditions.
Retest what the change can affect
Do not assume a previous test result automatically applies to a new model or feature. Use proportionate testing for the actual use case, including important failure modes and human-review paths, and document the version or configuration assessed.
Revisit affected reviewers
A material change may require renewed security, privacy, legal, compliance, accessibility, safety, procurement, or other specialist review. The operational governance process should route the issue to qualified decision-makers rather than declare compliance on their behalf.
Record the decision
Link the change notice, assessment, testing, conditions, approvers, residual concerns, and effective date to the AI use-case record. If the change is not acceptable, document whether the service is restricted, rolled back, replaced, or paused.
Related knowledge
Use this guide with AI Governance Evidence, AI Use-Case Approval Records, AI Change Management, and AI Incident Escalation.
References
This resource supports operational governance and does not replace qualified legal, regulatory, clinical, financial, employment, safety, procurement, or other professional review.