2. AI模型生命周期基础

AI模型不是一次训练完成就静止不变的软件资产。它更像一条持续流动的“决策生产线”：数据进入、参数更新、指标验证、服务上线、行为监控，最终因业务变化或风险积累而退役。审计人员若只盯着“上线那一刻”，就会遗漏大量风险。理解模型全生命周期的关键活动与审计切入点，是后续变更与回滚控制审计的基础。

一、核心原理：模型生命周期是一条“证据链”

模型生命周期的本质，是把一个不确定的统计产物，逐步转化为可被组织信任、可被监管解释、可被工程运维的决策组件。每个阶段都在产生证据：开发阶段产生数据来源与实验记录，验证阶段产生评估报告与签字结论，部署阶段产生版本与配置快照，监控阶段产生漂移与性能日志，退役阶段产生下线审批与数据处置记录。审计的核心动作，就是检查这条证据链是否完整、连续、可追溯。

二、五阶段关键活动与审计切入点

三、方法流程：从开发到退役的审计追踪路径

审计人员不必成为算法专家，但必须掌握“追踪路径”。建议按以下顺序建立检查逻辑：

1. 从业务需求出发：确认模型目标、使用场景、影响范围与风险等级，判断其是否属于高风险AI系统。
2. 回溯数据与实验：检查训练数据来源是否合法、特征是否可解释、实验是否可复现，重点关注数据版本与代码版本的对应关系。
3. 审查验证独立性：验证团队是否独立于开发团队？测试集是否与训练集隔离？阈值是否经过业务与合规共同确认？
4. 核对部署一致性：上线模型是否与验证通过的版本完全一致？配置参数、依赖库、运行环境是否被记录？
5. 评估监控有效性：监控指标是否覆盖性能、漂移、公平性与业务KPI？告警后是否有闭环处置？
6. 检查退役完整性：退役是否经过审批？流量是否完全切换？模型文件与相关数据是否按合规要求归档或删除？

四、案例/场景：一次“静默变更”引发的回滚失败

某金融风控模型在监控中发现逾期率异常上升。运维团队决定回滚到上一版本，却发现回滚后效果更差。审计追查发现：上一版本模型文件虽然存在，但其依赖的特征工程脚本已被更新，旧模型在新特征管道上运行，输入分布完全错位。更严重的是，部署记录中只记录了模型文件名，没有记录特征版本与配置快照。

部署记录（不完整）：
model: risk_model_v2.pkl
deploy_time: 2024-06-11 02:00
operator: ops_zhang

缺失信息：
feature_pipeline_version: unknown
config_snapshot: not saved
training_data_version: not linked
rollback_plan: none

这个案例说明：回滚控制不是“把旧文件放回去”，而是恢复一整套可运行、可验证、可解释的模型服务状态。审计切入点应前移到开发与验证阶段，要求版本绑定与配置快照成为上线前置条件。

五、误区与复盘

• 误区一：把模型当普通软件。模型行为依赖数据分布，数据变了，模型即使代码未变也可能“实质变更”。
• 误区二：验证一次就永久有效。业务环境、用户结构、对抗行为都会变化，验证结论有有效期。
• 误区三：监控只看准确率。准确率可能掩盖公平性恶化、漂移累积和长尾失效。
• 误区四：退役等于删除文件。退役涉及依赖排查、流量切换、合规归档与相关方通知，缺一不可。