Google Cloud Model Armor在2026年8月31日把v3提升为Stable稳定过滤版本。此前的v1和v2同日进入Legacy阶段，并计划在2026年11月29日退役，留给用户约90天迁移时间。
Model Armor用于在请求进入生成式AI模型前以及响应返回应用前执行安全检查。版本变化可能影响过滤结果和误报表现，因此生产模板是否会自动跟随Stable别名，是这次升级首先需要确认的问题。
v3从今天开始接管Stable别名
官方版本时间表显示，v3在8月31日晋升为Stable，并覆盖亚洲、欧洲、北美以及us、eu等多区域位置。
没有指定过滤版本的模板默认使用Stable版本。显式选择Stable别名的模板也会随着别名指向变化自动使用v3，不需要修改模板资源。
无需改配置不等于无需验证。过滤器版本已经在服务端变化，应用即使没有发布代码，也可能观察到拦截率或告警分布改变。
固定v1和v2的模板进入Legacy阶段
v1与v2在同一天转为Legacy。使用具体版本号固定模板的用户，在Legacy期间仍可执行sanitize操作，现有行为不会立即停止。
Google为Legacy版本提供90天迁移窗口，时间表显示两者将在11月29日退役。进入Retired阶段后，用户必须把模板迁移到Latest或Stable版本。
新配置不能把过滤版本设置为Legacy或Retired。换句话说，旧模板可以在窗口期继续运行，但不能把Legacy当成长久锁定策略。
自动跟随与固定版本各有运维代价
使用Stable别名的优点是能自动获得当前稳定过滤器，减少追踪版本生命周期的工作。代价是别名升级时，过滤结果可能在没有模板变更的情况下发生变化。
固定具体版本更利于复现和分阶段验证，但团队必须主动关注Legacy和退役日期，并在窗口结束前完成迁移。
生产环境可以采用分层方式：测试模板跟随Latest观察变化，预发布环境使用Stable完成回归，关键生产模板在验证后再切换具体版本或Stable别名。
迁移测试应覆盖拦截和误报两端
升级验证不能只测试明显恶意输入。还要从真实业务中抽取正常请求、边界表达、多语言内容和模型输出，比较v3与旧版本的处理结果。
重点指标包括拦截率、误报率、漏报样本、处理延迟和失败率。对于会直接阻断用户请求的策略，应先在观察模式或小比例流量中运行，再逐步扩大范围。
测试样本需要脱敏并遵守数据管理要求。安全团队还应记录规则变化对客服、内容审核和开发排障流程的影响，避免只完成技术切换却没有更新处置流程。
区域和模板版本需要逐项盘点
v3的支持区域广于单个旧版本，但不同项目可能把模板分散在多个位置。迁移前应导出模板清单，确认每个模板的区域、版本选择、调用方和负责人。
对于没有显式版本的模板，要把它视为已经切换到v3，而不是等待11月再处理。固定v1或v2的模板则应设置早于11月29日的内部迁移截止日期。
完成升级后还要持续查看安全命中和应用错误。Model Armor v3成为稳定版本只是平台时间点，只有模板盘点、回归测试、分批切换和监控都完成后，业务侧迁移才算真正结束。
