6.1 决策者自查清单（引入新AI工具前）
请逐项检查，任一项目为"否"，应先解决再推进：
| # | 检查项 | 是/否 |
|---|---|---|
| 1 | 是否明确了AI工具的定位（流程的一部分/替代品/增强器）？ | |
| 2 | 是否完成了操作分级（L0-L4），并设置了对应的审批机制？ | |
| 3 | 是否完成了权限最小化配置（默认拒绝、临时授予、范围限定）？ | |
| 4 | 是否完成了供应链安全审计（来源+完整性+权限+数据流）？ | |
| 5 | 是否向员工明确了AI的定位（副驾驶，非替代者）？ | |
| 6 | 是否安排了分层培训（只教可落地的场景操作）？ | |
| 7 | 是否建立了AI治理委员会或指定了AI安全负责人？ | |
| 8 | 是否建立了失败容忍机制（失败配额、不追责条款）？ | |
| 9 | 是否保留了人工刹车（一键回滚、物理熔断）？ | |
| 10 | AI Agent数量超过20个时，是否部署了守护智能体？ | |
| 11 | AI替代初级任务超过30%时，是否建立了替代培训通道？（v2.1新增） | |
| 12 | 是否执行过至少一轮反噬压力测试（6.5节五个场景）？（v2.1新增） | |
| 13 | 是否审查了供应商的组织基因（产品理念与盈利模式是否冲突/项目是否背3个以上互斥目标/减负功能是否变管控抓手，1.5.1三条判据）？（v2.2新增） | |
| 14 | 所选AI产品的自主性等级与组织AI成熟度阶段位的落差是否小于2级（1.5.4标尺+5.7.5审计）？（v2.2新增） |
6.2 事故复盘模板
当AI相关事故发生时，使用此模板进行复盘：
## 事故复盘报告
### 基本信息
- 事故时间：
- 发现时间：
- 影响范围：
- 损失估算：
### 反噬层次分析（可多选）
- [ ] 工具层：AI工具本身故障/误操作
- [ ] 团队层：人机冲突/员工抵制/过度依赖
- [ ] 组织层：流程/决策链/激励问题
- [ ] 自主性层：AI Agent抗命/失控
- [ ] 安全层：供应链/权限/数据泄露
### 关系维度分析
- [ ] 人-工具关系：信任/控制问题
- [ ] 人-人关系：认知鸿沟/激励错位
- [ ] 工具-工具关系：兼容性/权限链
- [ ] 工具-流程关系：嵌入深度/替代范围
### 直接原因（触发层）
（发生了什么？）
### 根本原因（深层）
（为什么发生？——至少追问3层）
### 缺失的防御措施
（如果当时有___，事故就不会发生？）
### 对应方法论条款
（本次事故对应方法论中哪个诊断/哪个案例/哪个应对措施？）
### 改进措施
1.
2.
3.
### 方法论更新建议
（是否需要新增案例归类？是否需要调整现有方法论？）
6.3 新案例归类模板
当发现新的AI落地反噬案例时，按此模板归类：
## 新案例归类
### 基本信息
- 案例名称：
- 发生时间：
- 涉及企业/行业：
- 来源链接：
### 反噬层次归属
- 主层次：（工具/团队/组织/自主性/安全）
- 次层次：
- 叠加模式：
### 关系维度归属
- 主要维度：
- 次要维度：
### 症状编号
（对应诊断框架中的S1-S12，或新增症状编号）
### 理论映射
（案例中的现象对应方法论中的哪个概念/公式/洞察？）
### 方法论贡献
（本案例为方法论增加了什么新认知？是否需要调整现有框架？）
6.4 定期审计模板
建议每季度进行一次AI落地反噬审计：
| 审计项 | 当前状态 | 风险等级 | 改进措施 |
|---|---|---|---|
| AI Agent数量 | |||
| AI工具数量 | |||
| 近3个月AI事故次数 | |||
| 事故复盘完成率 | |||
| AI工具使用率 | |||
| 员工AI信任度 | |||
| 供应链审计覆盖率 | |||
| 守护智能体覆盖率 | |||
| 权限最小化执行率 | |||
| 失败容忍机制执行状态 | |||
| 任务替代率>50%的岗位数（v2.1新增） | |||
| 初级/实习岗位数量变化率（v2.1新增） | |||
| 人均AI输出校验量变化（v2.1新增） | |||
| 组织AI成熟度阶段位及阶段位-产品位差（v2.2新增） |
6.5 反噬压力测试模板（v2.1新增）
正如金融行业压力测试在2008年金融危机后成为监管制度，反噬压力测试将在未来2-3年内成为AI时代企业治理的标配。建议每半年对核心AI系统执行一轮以下五个标准场景测试：
6.5.1 五个标准测试场景
| 测试场景 | 触发条件 | 通过标准 | 失败应对 |
|---|---|---|---|
| 智能体链式失控 | 主智能体连续触发3+子操作 | 30步内偏离率<10% | 立即熔断+人工接管 |
| 校验疲劳触发 | AI连续正确输出超过100次 | 强制人工校验未降频 | 引入随机"陷阱任务"检测校验率 |
| 培训带断裂 | 初级岗位减少超过30% | 替代培训通道已建立 | 冻结进一步AI替代 |
| 供应链攻击 | 任一AI供应商被攻破 | 影响范围可控制在1个业务单元 | 立即断开+启动备份流程 |
| 中级塌陷加速 | 中间管理层减少超过40% | 决策效率未下降 | 重建必要管理层级 |
6.5.2 测试场景与五层模型的映射
| 测试场景 | 主要反噬层次 | 对应症状 | 对应防御层 |
|---|---|---|---|
| 智能体链式失控 | 自主性层 | S5 | 第四层：守护智能体 |
| 校验疲劳触发 | 团队层 | S11 | 第二层：团队对齐（5.3.4） |
| 培训带断裂 | 组织层 | S13 | 第五道防线：能力变更审计（5.7） |
| 供应链攻击 | 安全层 | S6/S10 | 第一层：工具刹车（5.2.3） |
| 中级塌陷加速 | 组织层+团队层 | S7/S13 | 第五道防线：能力变更审计（5.7） |
6.5.3 执行要点
- 独立性：压力测试必须由独立于AI项目团队的部门执行（AI治理委员会或外部审计方），防止"既当运动员又当裁判"
- 节奏：每半年一轮全量测试；引入关键新智能体或新供应商时增补专项测试
- 报告：测试结果纳入AI治理委员会季度报告，向决策层明示未通过项
- 整改闭环：任一场景失败且未在30天内完成整改的，相关AI系统应降级运行（如从L2写入降为L1建议级）
- 记录留存：每轮测试的原始记录、整改措施与复测结果归档，作为6.4定期审计的输入