Most AI governance programs get the front door right — intake, risk tiering, approval gates — and then treat approval as permanent. But an internal summarizer quietly becomes a customer-facing feature; a tool that read public documents starts ingesting contracts; a drafting assistant gets wired to send without review. Each step seemed small to the team making it. The fix is a published list of re-review triggers: changes that automatically reopen governance, no matter how long ago the original approval was granted or how well the system has behaved since.
The trigger list
| Trigger | Why it reopens review |
|---|---|
| New data types entering prompts | The privacy gate approved specific classification tiers; adding personal, financial, or confidential data invalidates that analysis |
| Expanded user audience | Internal-only was likely a condition of the risk tier; exposure to customers or the public changes accuracy, disclosure, and brand stakes |
| Changed output destination | Output that once informed a human reader now feeding a downstream system — or being sent automatically — changes autonomy and reversibility |
| Reduced human oversight | Removing or sampling down a review step is a risk-tier change even if nothing else moved |
| Model version change | Behavior, token accounting, and even eligibility rules differ between versions (details below) |
| Platform or feature change | Moving between the Claude API, Bedrock, Vertex AI, or Foundry changes who processes data; enabling stateful features changes retention posture |
| Material system-prompt or retrieval-source change | The system's instructions and knowledge are part of what was validated — see change management |
The re-review need not repeat the full original process — scope it to the gates the change touches. A new data type reopens privacy; a new audience reopens business and legal; a model swap reopens validation. What must never happen is the change shipping first and the review happening retroactively.
Why model changes are on the list
Swapping the model string looks like a configuration tweak; the documentation says otherwise. Anthropic's migration guide records genuine behavior changes between versions — for example, moving from Claude Sonnet 4.6 to Claude Sonnet 5, manual extended thinking and non-default sampling parameters return errors, adaptive thinking is on by default, and a newer tokenizer produces roughly 30% more tokens for the same text, which re-baselines both cost and how much fits in context. Some migrations even change governance eligibility outright: Claude Fable 5 requires 30-day data retention and is not available under a zero-data-retention arrangement — so an organization that approved a use case partly because of ZDR cannot treat an upgrade to Fable 5 as routine maintenance. A model change should therefore trigger at minimum a re-run of your evaluation suite and a check of retention and privacy conditions against the new model's documented requirements.
Why feature and platform changes are on the list
Retention posture is feature-by-feature, not just account-level. Anthropic documents several capabilities — the Batch API, Files API, code execution, skills, the MCP connector, Managed Agents — as fundamentally stateful and ZDR-ineligible; using one is described as a choice to step outside your ZDR arrangement for that specific data. So a team that "just enabled" file uploads on an approved ZDR-scoped use case has materially changed its data posture without touching a line of policy. Similarly, moving a workload between platforms changes the data processor: on Amazon Bedrock and Google Cloud, the cloud provider processes the data under its own retention and compliance terms. Data-residency settings are another quiet one — the inference_geo control (Claude API and Claude Platform on AWS) determines whether inference runs globally or only on US infrastructure, and changing it can matter to commitments made at approval time.
Time is also a trigger
Even with no reported changes, schedule periodic re-checks by risk tier — high-risk annually, lower tiers less often. Drift is often the accumulation of changes each too small to report; a calendar catches what self-reporting misses.
Where to go next
This article is the maintenance counterpart to the intake process and approval gates. For version-level discipline on prompts and models, see managing changes to production AI models; for retiring a use case entirely, see the decommissioning checklist.