AI 项目上线前检查清单：安全、权限、成本、监控和回滚

AI 项目可以上线的最低条件是：任务与失败边界明确，模型输出经过校验，权限由服务端控制，敏感数据有治理，成本有硬预算，质量与系统指标可观测，并且能停止、降级和回滚。只证明 Demo 能回答问题，不等于具备生产就绪度。

先说结论

上线评审应基于证据，而不是口头确认“已经考虑过”。每一项门禁都要有负责人和可验证产物，例如测试报告、数据流图、告警规则、演练记录或回滚命令。

下列任一情况存在时，建议阻止发布：

• 模型可以绕过服务端权限直接调用高风险工具；
• 没有定义可接受输出，也没有回归评估集；
• 敏感数据会进入未经批准的模型、日志或缓存；
• 请求、重试或 Agent 循环没有硬上限；
• 无法识别当前 Prompt、模型、Schema 与数据版本；
• 发生质量事故时只能重新部署全部系统，不能停止或回退 AI 路径。

适合谁，不适合谁

本文适合通用 LLM、RAG、Agent、抽取、分类和 AI 辅助工作流的上线评审。

它不是某个行业的合规认证，也不能替代组织的安全、法务、隐私和变更流程。医疗、金融、公共安全等高风险场景需要额外的专业审查。RAG 特有的数据导入、切片和检索门禁，应使用独立的 RAG 生产检查清单补充。

先确定发布等级

等级	典型行为	最低控制
只读建议	生成草稿、摘要、候选答案	标识 AI 输出、引用/校验、用户可拒绝
可逆写入	创建草稿工单、暂存配置	鉴权、Schema、幂等、撤销
外部通信	发消息、发邮件、提交内容	明确确认、收件人校验、审计
高风险操作	权限、资金、删除、生产变更	默认禁止自动执行，多方审批与专用控制

风险等级越高，越不能依赖模型的自我判断。即使模型说“用户已授权”，工具服务也必须通过可信身份和策略重新验证。

上线门禁决策表

领域	必须回答的问题	可接受证据	不通过时
需求	成功、失败和非目标是什么	验收标准与失败样例	缩小范围
质量	候选版本是否优于或不劣于基线	固定评估集与人工复核	阻止切流
安全	输入、检索内容和工具如何隔离	威胁模型、对抗样例	关闭高风险能力
权限	谁能访问什么、执行什么	服务端策略与审计记录	改为只读或人工
数据	数据去向、保留和删除机制是什么	数据流图与脱敏规则	停止发送敏感数据
成本	单请求和租户上限是什么	预算守卫与告警	限流、降级
监控	如何发现系统和质量退化	指标、日志、追踪、反馈	不扩大流量
回滚	多久、如何、回到哪个兼容版本	演练记录与操作手册	保持灰度

安全与数据检查

• [ ] 对用户输入、检索文档和工具结果标注信任等级
• [ ] 外部内容不能覆盖系统规则或伪造授权
• [ ] Prompt、日志、追踪、缓存和评估数据均执行敏感信息治理
• [ ] 密钥只在服务端安全存储，不进入 Prompt 和客户端
• [ ] 输出进入 HTML、SQL、Shell 或模板前使用对应的安全编码与参数化机制
• [ ] 有内容拦截、滥用限流和安全事件上报路径
• [ ] 明确保留期限、删除流程、数据地域和第三方处理边界

提示注入无法只靠一句“忽略恶意指令”解决。系统要从架构上隔离数据与指令，并让工具层执行确定性权限检查。

权限与工具检查

• [ ] 工具使用 allowlist，参数有运行时 Schema
• [ ] 工具调用携带可信用户身份与租户上下文
• [ ] 服务端重新鉴权，不接受模型生成的权限结论
• [ ] 写操作有幂等键，重复请求不会重复执行
• [ ] 外部通信、高风险写入和不可逆操作需要明确审批
• [ ] 工具超时、失败和部分成功有补偿或人工处理路径
• [ ] 审计记录包含发起者、模型建议、最终参数、审批者和结果

质量与评估检查

• [ ] 定义事实性、完整性、相关性、格式与安全等验收维度
• [ ] 评估集覆盖正常、边界、对抗和历史线上故障
• [ ] 结构化输出执行语法、Schema 和业务规则校验
• [ ] RAG 回答能关联证据，并有“无可靠答案”策略
• [ ] Prompt、模型、Schema、检索和工具变更都会触发回归
• [ ] 高风险样例由具备业务知识的人复核
• [ ] 线上反馈可以回流，但不会未经审核直接污染评估基线

成本与容量检查

• [ ] 请求前限制输入、输出、重试、工具和 Agent 循环
• [ ] 按功能、租户和实际路由记录用量
• [ ] 设置单请求、周期配额和全局熔断
• [ ] 缓存包含权限、版本和时效边界
• [ ] 降级模型已通过对应任务评估
• [ ] 供应商限流或不可用时有排队、降级或拒绝策略
• [ ] 压力测试覆盖长上下文、慢工具和流式断开

成本门禁使用组织核验后的真实费率或账单，不在代码和文档中复制未经维护的固定价格。

监控与告警检查

至少建立两类指标：

系统指标：请求量、错误类别、首片段时间、总耗时、取消、重试、限流、工具失败和资源饱和。

质量指标：Schema 失败、无答案、引用缺失、人工驳回、用户负反馈、安全拦截和版本间评估变化。

• [ ] request ID 能贯穿网关、模型、检索、工具和提交
• [ ] 日志能识别 Prompt、Schema、模型、路由和数据版本
• [ ] 敏感正文默认不进入日志，必要采样有审批与脱敏
• [ ] 告警有负责人、阈值依据和处理动作
• [ ] 仪表盘能按租户、功能、版本和 Provider 切分
• [ ] 未知用量和未知结束原因被单独统计，而不是记为零

灰度、降级与回滚

发布顺序建议是：

离线评估通过
→ 内部/影子流量验证
→ 小范围灰度
→ 观察系统与质量指标
→ 分阶段扩大

每个阶段都要定义停止条件。回滚单位应是兼容组合，包括应用、Prompt、Schema、模型路由、检索配置和工具版本。

• [ ] 有一键停止新 AI 请求或高风险工具的开关
• [ ] 客户端取消与总超时能传播到上游
• [ ] 降级可切到只读、搜索、模板或人工队列
• [ ] 回滚不会让新旧 Schema、缓存或数据互不兼容
• [ ] 已演练 Provider 不可用、流式中断、工具部分成功和错误版本发布
• [ ] 回滚后仍保留事故所需审计证据

常见误区与失败边界

1. Demo 通过几个样例就上线：没有边界样例，无法知道失败分布。
2. 只监控 5xx：很多质量事故以成功响应返回。
3. 模型负责自审与授权：同一概率组件不能成为唯一控制边界。
4. 备用模型能调用就算降级完成：能力、Schema 和质量可能不兼容。
5. 回滚只切应用版本：Prompt、路由、缓存和数据配置仍可能保持错误状态。
6. 把清单全部勾选当作永久安全：上线后仍要根据事故、反馈和依赖变化复核。

若团队无法为某项提供证据，应将它视为未完成，而不是“默认没问题”。对于无法接受的残余风险，应保留人工流程或不上线。

可执行检查清单

发布负责人最终确认：

• [ ] 需求、非目标、风险等级和验收标准已签字确认
• [ ] 安全、隐私、权限与工具边界有验证证据
• [ ] 候选版本完成离线评估和必要人工复核
• [ ] 请求、成本、重试和循环均有硬上限
• [ ] 系统指标与质量指标均可观测并有告警负责人
• [ ] 灰度比例、停止条件和扩大条件明确
• [ ] 降级与回滚已演练，操作人员有权限执行
• [ ] 当前所有版本可追溯，审计记录可查询
• [ ] 上线后复核时间与负责人已安排

下一步

先回到 AI 工程化专题 检查是否遗漏请求生命周期、结构化输出或成本治理。通过通用上线门禁后，下一步进入 AI 项目需求与验收，把检查项转化为项目角色、验收证据和发布责任。