# P9 Audit Release > AI Native 审计放行 Skill - Skill: `gabrielmoreira/p9-audit-release` (Agent Skill) - Install (CLI): `npx skillmds@latest add gabrielmoreira/p9-audit-release` - Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/p9-audit-release/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/gabrielmoreira/p9-audit-release --- # AI Native 审计放行 Skill ## 使用场景 - 系统构建已完成，需要判断能否进入生产环境 - 需要建立审计放行的证据链和决策机制 - 需要设计 Shadow System 验证系统在真实环境中的表现 ## 核心概念 - **审计放行（Audit）**：把能力、风险、证据和放行条件压缩到同一套判断机制中的阶段 - **go / no-go**：是否允许系统进入真实执行链路的组织级决定 - **放行边界**：允许自动执行的范围、必须人工接管的范围和必须禁用的范围 - **证据链**：从设计、评估、Shadow 到运行准备的连续证据，而不是单点结果 ## 审计放行流程 ``` 设计证据 → 评估证据 → Shadow 证据 → 放行边界判断 → go / no-go → 生产要求下发 ``` 如果没有连续证据链，审计放行就会退化成主观印象或形式化审批。 ## 第一步：设计证据 系统设计是否清晰地定义了： - 能力范围：系统能做什么、不能做什么 - 失败模式：已知的失败类型和处理策略 - 边界条件：什么情况下必须回退或交还给人 - 治理机制：如何监控、如何审计、如何回滚 ## 第二步：评估证据 评估结果是否充分： - 能力评估：样本测试、边界测试、长尾测试 - 安全评估：权限边界、数据保护、渗透测试 - 性能评估：延迟、吞吐、成本、稳定性 ## 第三步：Shadow 证据 Shadow System 是审计放行的关键机制： - 系统在真实环境中运行，但不直接影响用户 - 同时收集系统输出和人工处理结果进行对比 - 证明系统在真实数据上的表现 Shadow 的价值在于：它让系统在不影响用户的情况下接触真实世界。 ## 第四步：放行边界判断 明确三个区域： ### 自动执行区 - 系统可以独立完成的任务 - 失败后果可控、可回退 - 已经过充分验证 ### 人工接管区 - 高风险任务 - 涉及敏感操作 - 系统信心度不足的场景 ### 禁用区 - 超出系统能力范围的任务 - 未经验证的新场景 - 涉及合规或安全红线的操作 ## 第五步：go / no-go 决策 ### go 条件 - 连续证据链完整 - 放行边界清晰 - 回退机制可靠 - 监控体系就绪 - 团队准备就绪 ### no-go 情况 - 证据链中断 - 边界不清晰 - 回退机制不可靠 - 监控体系缺失 - 团队未就绪 ## 审计放行要审的六类问题 1. **可靠性**：回答是否稳定，任务是否真的完成，是否存在幻觉、错误归因或不一致输出 2. **安全与权限**：是否可能泄露敏感信息，是否存在越权读取、越权调用、Prompt 注入、工具滥用 3. **执行边界**：哪些动作允许自动执行，哪些必须审批，哪些高风险动作要彻底禁用 4. **成本与性能**：延迟、令牌消耗、工具链长度、重试策略是否可控，流量放大后是否失稳 5. **可追溯性**：是否能复盘输入、上下文、模型版本、工具调用、人工接管、最终结果 6. **合规与治理**：角色责任是否清晰，审计记录是否保留，异常处理是否有明确流程 ## 输出物：放行方案 1. **证据链汇总**：设计、评估、Shadow 的证据摘要 2. **放行边界图**：自动执行区、人工接管区、禁用区 3. **go/no-go 决策**：明确的放行或拒绝决定 4. **生产要求**：上线后必须持续监控的指标、阈值、应急预案 5. **回滚方案**：如果出现问题如何快速回滚 ## 使用方式 当用户提供系统构建方案时，自动执行： 1. 收集设计证据 2. 收集评估证据 3. 设计 Shadow 方案并收集 Shadow 证据 4. 定义放行边界 5. 执行六类审计检查 6. 做出 go/no-go 决策 7. 如果 go，下发生产要求和回滚方案 8. 输出放行方案 ## 示例 ### 示例：AIOps 系统审计放行 **场景描述**： AIOps 故障分诊系统已完成构建，需要审计是否可进入生产环境。 **用户输入**： "我们的 AIOps 系统已开发完成，准备上线，需要进行审计放行" **Skill 执行流程**： 1. **设计证据收集** | 检查项 | 状态 | 证据 | |--------|------|------| | 能力范围定义 | ✅ | 明确只做分诊建议，不做自动处置 | | 失败模式 | ✅ | 已定义5类失败及回退策略 | | 边界条件 | ✅ | 置信度<70%时必须人工确认 | | 治理机制 | ✅ | 日志审计、监控告警、回滚方案 | 2. **评估证据收集** | 评估类型 | 结果 | 是否满足 | |----------|------|----------| | 能力评估 | 日志解释88%，告警聚类82%，案例召回75% | ✅ 满足 | | 安全评估 | 无越权调用，数据已脱敏 | ✅ 通过 | | 性能评估 | P95延迟<2s，支持100并发 | ✅ 通过 | | 边界测试 | 20个边界案例，18个正确处理 | ✅ 达标 | 3. **Shadow 证据收集** ```yaml Shadow 方案: 运行周期: 2周 数据量: 50次真实故障 对比结果: 系统建议采纳率: 55% 辅助参考价值率: 80% 错误归因数: 2次（均被工程师识别，未造成误判） 平均定位时间: - 纯人工: 45分钟 - 系统辅助: 25分钟 关键发现: - 系统在"看什么"上表现好 - 系统在"怎么做"上仍需人工判断 - 高约束设计有效避免了错误放大 ``` 4. **放行边界定义** | 区域 | 范围 | 控制措施 | |------|------|----------| | 自动执行区 | 无 | 系统不执行任何自动动作 | | 人工接管区 | 全部输出 | 所有建议需工程师确认 | | 禁用区 | 自动修复、自动重启 | 明确禁止的功能 | 5. **六类审计检查** | 审计项 | 检查结果 | 风险等级 | |--------|----------|----------| | 可靠性 | 幻觉率<5%，无错误归因 | 低 | | 安全与权限 | 无越权，已脱敏 | 低 | | 执行边界 | 明确只做建议 | 低 | | 成本与性能 | 单次调用<$0.01 | 低 | | 可追溯性 | 全链路审计日志 | 低 | | 合规与治理 | 责任清晰，流程明确 | 低 | 6. **go/no-go 决策** ```yaml 决策: GO（条件放行） 放行条件: - 仅限值班辅助场景 - 所有输出必须有"供参考"标识 - 不得用于无人值守场景 上线后监控: - 采纳率是否维持>50% - 是否有未识别的错误归因 - 是否有工程师绕过确认直接执行 应急预案: - 发现严重问题可5分钟内关闭AI建议 - 回退到纯人工分诊流程 ``` **输出结果**： ```yaml # 放行方案：AIOps 故障分诊系统 证据链汇总: 设计证据: ✅ 完整 评估证据: ✅ 通过 Shadow证据: ✅ 2周运行，采纳率55% 放行边界: 自动执行区: 无（仅建议模式） 人工接管区: 全部输出 禁用区: [自动修复, 自动重启, 自动切流] go/no-go决策: ✅ GO - 条件放行 生产要求: 必须监控指标: - 采纳率: >50% - 误判率: <5% - 响应时间: P95<2s 必须保留记录: - 每次故障的输入+输出 - 工程师采纳/拒绝行为 - 最终人工处理结果 定期审计: - 每周审查误判案例 - 每月评估是否需调整边界 回滚方案: 触发条件: - 误判导致生产事故 - 采纳率持续低于40% - 安全漏洞 回滚步骤: 1. 关闭AI建议开关（5分钟内） 2. 通知值班团队 3. 启动根因分析 4. 修复后重新走审计流程 风险提示: - 当前系统适用于"辅助判断"，不适用于"自动处置" - 工程师需培训：理解AI建议的局限性 - 建立快速上报通道：异常建议及时反馈 ``` --- ### 示例2：金融风控反欺诈系统审计放行 **场景描述**： 金融风控反欺诈系统已完成构建，需审计决定是否可投入生产环境进行实时交易风险评估。 **用户输入**： "我们的AI反欺诈系统准备好了，需要审计放行" **Skill 执行流程**： 1. **设计证据收集** | 检查项 | 状态 | 证据 | |--------|------|------| | 能力范围定义 | ✅ | 仅限风险评分（0-100），不做拦截决策 | | 失败模式 | ✅ | 定义误杀、漏杀、特征漂移三类失败 | | 边界条件 | ✅ | 高风险交易（>80分）必须人工复核 | | 治理机制 | ✅ | 模型监控、特征监控、审批流 | 2. **评估证据收集** | 评估类型 | 结果 | 是否满足 | |----------|------|----------| | 能力评估 | 欺诈识别率 92%，误报率 8% | ✅ 达标 | | 安全评估 | 模型防攻击测试通过 | ✅ 通过 | | 性能评估 | P99延迟 <50ms，支持10万TPS | ✅ 满足 | | 公平性评估 | 各群体FPR差异 <2% | ✅ 通过 | 3. **Shadow 证据收集** ```yaml Shadow 方案: 运行周期: 4周 数据量: 500万笔真实交易 对比结果: 系统评分与人工规则对比: - 一致性: 87% - 系统识别新增风险: 3.2%（人工规则未覆盖） - 误报增量: +1.5%（可接受范围） 业务指标: - 欺诈损失率: 从0.15%降至0.08% - 误杀投诉: 日均12起（可接受） - 高风险交易人工复核率: 18% ``` 4. **放行边界定义** | 区域 | 范围 | 控制措施 | |------|------|----------| | 自动执行区 | 风险评分计算、低风险标记 | 无需人工干预 | | 人工接管区 | 高风险交易(>80分) | 必须人工复核 | | 禁用区 | 直接拦截、冻结账户 | 系统无权执行 | 5. **六类审计检查** | 审计项 | 检查结果 | 风险等级 | |--------|----------|----------| | 可靠性 | OOD检测、置信度校准到位 | 低 | | 安全与权限 | 模型防投毒、特征防泄露 | 低 | | 执行边界 | 评分与决策分离 | 低 | | 成本与性能 | 单次评分<$0.001，延迟可控 | 低 | | 可追溯性 | 每笔交易评分原因可查 | 低 | | 合规与治理 | 符合金融监管要求 | 中 | 6. **合规特殊审查（金融场景）** | 合规项 | 检查结果 | |--------|----------| | 模型可解释性 | ✅ 提供Top5特征贡献 | | 公平性审计 | ✅ 各 demographics FPR差异<2% | | 人工复核机制 | ✅ 高风险100%人工复核 | | 误杀申诉 | ✅ 建立快速申诉通道 | | 数据隐私 | ✅ 符合GDPR/个人信息保护法 | 7. **go/no-go 决策** ```yaml 决策: GO（条件放行） 放行条件: - 风险评分仅作辅助参考 - 所有拦截决策必须人工确认 - 建立实时监控系统 上线后监控: - 欺诈识别率维持>90% - 误报率维持<10% - 特征漂移监控 - 公平性指标持续监控 应急预案: - 模型异常时切换规则引擎（30秒内） - 误杀激增时启动白名单机制 ``` **输出结果**： ```yaml # 放行方案：金融风控反欺诈系统 证据链汇总: 设计证据: ✅ 完整，评分与决策分离 评估证据: ✅ 通过，92%识别率/8%误报 Shadow证据: ✅ 4周运行，业务指标正向 合规矩阵: ✅ 全部通过 放行边界: 自动执行区: [风险评分计算, 特征工程, 低风险标记] 人工接管区: 高风险交易(>80分) 禁用区: [直接拦截, 冻结账户, 自动拒绝] go/no-go决策: ✅ GO - 条件放行 生产要求: 实时监控: - 欺诈识别率: >90% - 误报率: <10% - P99延迟: <50ms - 特征漂移: 每日检测 - 公平性: 每周审计 人工复核: - 高风险交易(>80分): 100%复核 - 中风险交易(60-80分): 抽样复核10% - 建立复核SOP和时效要求 可解释性: - 每笔评分附带Top5特征 - 提供自然语言解释 - 客服可查评分依据 回滚方案: 触发条件: - 误杀率超过15% - 模型预测分布异常 - 监管合规问题 回滚步骤: 1. 切换至备用规则引擎(30秒) 2. 通知风控团队 3. 冻结模型自动更新 4. 启动根因分析 特别说明: - 反欺诈是持续对抗，需定期模型更新 - 建立黑产情报联动机制 - 误杀投诉处理时效: 4小时内响应 ``` --- ### 示例3：医疗辅助诊断系统审计放行 **场景描述**： 医院AI辅助诊断系统已完成开发，需审计决定是否可投入临床辅助使用。 **用户输入**： "我们的AI影像诊断辅助系统需要审计放行" **Skill 执行流程**： 1. **设计证据收集** | 检查项 | 状态 | 证据 | |--------|------|------| | 能力范围定义 | ✅ | 仅作"第二意见"参考，非诊断结论 | | 失败模式 | ✅ | 定义漏诊、误诊、置信度不足三类 | | 边界条件 | ✅ | 置信度<85%时必须医生确认 | | 治理机制 | ✅ | 临床审计、质控流程、责任界定 | 2. **评估证据收集** | 评估类型 | 结果 | 是否满足 | |----------|------|----------| | 能力评估 | 病灶识别AUC 0.94，敏感度 91% | ✅ 达标 | | 安全评估 | 通过医疗器械软件安全测试 | ✅ 通过 | | 性能评估 | P95延迟 <3s，并发50 | ✅ 满足 | | 鲁棒性 | 不同设备/参数下稳定性>95% | ✅ 通过 | 3. **Shadow 证据收集** ```yaml Shadow 方案: 运行周期: 8周 数据量: 2000例真实患者影像 对比结果: 与专家诊断对比: - 一致性: 89% - 系统发现专家遗漏: 4.2%（经复核确认） - 专家发现系统遗漏: 2.8% 临床价值: - 阅片时间: 从15分钟降至10分钟 - 医生满意度: 82% - 无重大误诊事故 ``` 4. **医疗合规特殊审查** | 合规项 | 检查结果 | |--------|----------| | 医疗器械注册 | ✅ 通过二类医疗器械认证 | | 临床验证 | ✅ 完成多中心临床试验 | | 医生培训 | ✅ 参与科室医生100%培训 | | 知情同意 | ✅ 患者知情同意流程到位 | | 责任界定 | ✅ 明确AI辅助，诊断责任归医生 | 5. **放行边界定义** | 区域 | 范围 | 控制措施 | |------|------|----------| | 自动执行区 | 影像预处理、病灶标记辅助 | 仅处理 | | 人工接管区 | 所有诊断输出 | 医生100%确认 | | 禁用区 | 独立诊断、治疗方案建议 | 系统永远不输出 | 6. **六类审计检查** | 审计项 | 检查结果 | 风险等级 | |--------|----------|----------| | 可靠性 | 鲁棒性验证通过，临床数据支持 | 中 | | 安全与权限 | 数据隐私、访问控制到位 | 低 | | 执行边界 | 仅辅助，不替代医生 | 中 | | 成本与性能 | 单次<$0.05，延迟可接受 | 低 | | 可追溯性 | 病例、影像、输出全记录 | 低 | | 合规与治理 | 医疗器械认证、临床准入 | 中 | 7. **go/no-go 决策** ```yaml 决策: GO（严格条件放行） 放行条件（最严格）: - 仅用于已培训科室 - 所有输出必须有"仅供参考"标识 - 医生对最终诊断负全责 - 建立临床质控委员会 上线后监控（最高标准）: - 每月临床质量评估 - 每季度多科室效果对比 - 持续不良事件监测 - 年度临床试验更新 ``` **输出结果**： ```yaml # 放行方案：医疗AI辅助诊断系统 证据链汇总: 设计证据: ✅ 明确辅助定位 评估证据: ✅ AUC 0.94，临床试验通过 Shadow证据: ✅ 8周运行，无重大事故 医疗准入: ✅ 二类医疗器械认证 放行边界（最保守）: 自动执行区: [影像预处理, 图像增强] 人工接管区: 全部诊断相关输出 禁用区: [独立诊断, 治疗方案, 预后判断] go/no-go决策: ✅ GO - 严格条件放行 生产要求: 使用前必备: - 科室医生完成专项培训 - 患者签署知情同意书 - 质控委员会建立 持续监控: - 敏感性/特异性: 月度统计 - 医生采纳率: 实时监控 - 不良事件: 24小时内上报 - 质控委员会: 季度评审 责任界定: - 系统: 仅提供算法分析 - 医生: 对诊断结论负全部责任 - 医院: 建立投诉处理机制 回滚方案: 触发条件: - 重大漏诊/误诊事故 - 敏感性下降至<85% - 监管合规问题 回滚步骤: 1. 立即暂停系统使用 2. 通知所有使用科室 3. 启动医疗安全事件调查 4. 向监管部门报告 5. 修复后重新临床验证 风险提示（医疗场景）: ⚠️ 医疗风险不可逆，容错率极低 ⚠️ AI只是工具，不能替代医生专业判断 ⚠️ 持续收集临床反馈，迭代优化 ⚠️ 建立快速通道处理医生质疑 ```