> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/ai_security_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/ai_security_guide/di-si-bu-fen-zhi-li-yu-zhan-wang/11_governance/11.7_compliance_operational.md).

# 11.7 AI 安全合规的可操作性指南

本节将合规要求转化为可直接使用的模板、流程和检查清单，帮助组织从“了解法规”跨越到“有效执行”。

这些模板更适合作为起点，而不是一套放之四海而皆准的统一答案。不同法域、行业和业务风险级别对应的义务并不完全相同，落地时仍需由法务、合规和安全团队结合实际部署形态做二次裁剪。

## 11.7.1 AI 安全合规检查清单（可直接使用的模板）

### 风险评估阶段

```markdown
# AI 系统风险评估检查清单

系统信息
□ 系统名称: ____________
□ 系统类型（LLM/Vision/Audio/Multimodal）: ____________
□ 部署地域（欧盟/美国/中国/其他）: ____________
□ 负责人: ____________
□ 评估日期: ____________

## 第一部分：系统分类与风险等级

### 1.1 功能性风险评估

□ 系统用途描述:
  ___________________________________________________________

□ 系统可否影响以下领域？（勾选适用）
  □ 就业与工资决策（高风险）
  □ 教育考试与入学（高风险）
  □ 执法司法决策（高风险）
  □ 医疗诊断（高风险）
  □ 金融信贷评估（高风险）
  □ 通用内容生成（低/中风险）
  □ 其他: ___________

□ 根据上述影响，初步风险分类:
  □ 高风险系统（EU AI Act Annex III）
  □ 中风险系统
  □ 低风险系统

### 1.2 数据与隐私风险评估

□ 系统是否处理以下类型数据？（勾选适用）
  □ 个人敏感数据（健康、种族、性取向等）
  □ 财务信息
  □ 生物特征数据
  □ 地理位置数据
  □ 儿童数据（<13岁）
  □ 不处理个人数据

□ 数据来源：
  □ 完全由用户输入（风险：内部）
  □ 从第三方数据库检索（风险：外部）
  □ 混合来源

□ 数据处理规模：
  □ < 1000 用户
  □ 1000 - 100,000 用户
  □ > 100,000 用户

### 1.3 安全威胁评估

□ 系统是否容易被以下攻击？
  □ 提示注入攻击
  □ 越狱攻击
  □ 数据投毒
  □ 模型窃取
  □ 隐私泄露
  □ 多模态攻击

□ 被成功攻击的潜在影响:
  □ 财务损失（金额: ___________）
  □ 声誉损害
  □ 法律责任
  □ 用户数据泄露
  □ 服务不可用

## 第二部分：合规需求确定

### 2.1 适用法规（根据部署地域）

**欧盟（EU AI Act）**
□ 是否在欧盟市场投放、在欧盟投入使用、在欧盟使用，或其输出将用于欧盟？
  □ 是 → 需评估是否落入 EU AI Act 范围，并按风险等级履行相应义务
  □ 否 → 通常不直接落入 AI Act，但如适用 GDPR 等其他法规仍需合规

□ 如需合规，以下哪些类型适用？
  □ 禁止类AI（第5条）- 必须禁用
  □ 高风险系统（Annex III）- 需要风险管理体系
  □ 有限风险系统（第50条）- 需要透明度披露
  □ 最小风险系统 - 最少要求

**美国**
□ 是否在美国部署？
    □ 是 → 检查适用的州法规
    □ 加州现行 AI 透明性/深度伪造相关法律（不要把 SB 1047 视为已生效要求）
    □ 科罗拉多 SB 26-189（2026 年 5 月签署，废止重写 SB 24-205；核心 ADMT 披露/透明度义务自 2027-01-01 适用，需核对适用范围与执法细则）
    □ 其他州: ___________

□ 是否涉及特定行业监管？
  □ 医疗（FDA）
  □ 金融（SEC/OCC/CFPB）
  □ 教育
  □ 其他: ___________

**中国**
□ 是否面向中国用户或处理中国数据？
  □ 是 → 需结合服务类型、是否向公众提供生成式 AI 服务、是否触发备案或安全评估等具体要求判断：
    □ 《生成式AI服务管理暂行办法》
    □ 《数据安全法》
    □ 《个人信息保护法》
    □ 备案 / 安全评估等配套要求（按服务形态判断）

  □ 否 → 如与中资企业合作需注意跨境数据传输

### 2.2 具体合规要求

**EU AI Act 高风险系统要求清单**
□ 风险管理体系
  □ 建立并文档化风险管理流程
  □ 识别已知与可预见的风险
  □ 制定风险缓解措施
  □ 评估缓解措施的有效性

□ 数据与数据治理
  □ 训练数据集的文档化
  □ 数据治理流程的建立
  □ 数据质量评估

□ 技术文档
  □ 系统架构文档
  □ 安全评估报告
  □ 测试报告

□ 记录保存与自动日志
  □ 设计能够记录高风险系统运行事件的日志能力
  □ 明确日志留存、访问控制、完整性保护和导出流程
  □ 支持风险识别、运行追踪和上市后监控

□ 质量管理体系（QMS）
  □ 覆盖设计、开发、测试、验证、数据治理、风险管理和变更控制
  □ 纳入上市后监控、严重事件报告、监管沟通和文档留存流程
  □ 明确职责、供应商管理、资源管理和内部问责

□ 透明度与用户告知
  □ 向用户披露AI系统的使用
  □ 提供适当的信息说明
  □ 确保用户知晓其与AI交互

□ 人工监督
  □ 建立有效的人工监督机制
  □ 培训监督人员
  □ 文档化监督流程

□ 准确性、鲁棒性与网络安全
  □ 实施安全措施防止对抗攻击
  □ 测试鲁棒性和准确性
  □ 定期检查已知漏洞

□ 合格评定与市场准入
  □ 判断是否需要内部控制或第三方 notified body 合格评定
  □ 准备 EU declaration of conformity 与 CE marking 所需证据
  □ 按要求完成 EU database 注册（适用时）

□ 上市后监控与严重事件报告
  □ 建立持续监控计划，收集真实使用中的性能、安全和基本权利风险证据
  □ 定义严重事件识别、升级、证据保全和监管报告流程
  □ 建立纠正措施、召回/下线、用户通知和复盘机制

## 第三部分：实施与验证

### 3.1 技术控制措施

□ 输入安全
  □ 实施输入验证
  □ 提示注入防护
  □ 内容过滤

□ 模型安全
  □ 安全微调与对齐
  □ 对抗训练
  □ 定期安全评估

□ 输出安全
  □ 内容审核
  □ 敏感信息过滤
  □ 事实性验证

□ 系统安全
  □ 访问控制
  □ 日志与审计
  □ 入侵检测

### 3.2 组织与管理控制

□ 治理
  □ 任命AI安全负责人
  □ 建立AI治理委员会
  □ 制定AI安全政策

□ 培训
  □ 对开发人员的安全培训
  □ 对运营人员的培训
  □ 对用户的安全意识提升

□ 文档
  □ 系统卡（System Card）
  □ 模型卡（Model Card）
  □ 威胁建模文档
  □ 安全事件响应计划

### 3.3 持续监控与改进

□ 监控
  □ 建立安全监控体系
  □ 实施异常检测
  □ 定期审查日志

□ 审计
  □ 定期安全审计
  □ 第三方审计
  □ 合规检查

□ 更新
  □ 及时应对新威胁
  □ 更新防御措施
  □ 版本控制与变更管理

## 第四部分：评估结论

### 综合风险评分

____ / 100

### 推荐行动优先级

优先级1（立即执行）:
- ___________________________________________________________

优先级2（30天内）:
- ___________________________________________________________

优先级3（90天内）:
- ___________________________________________________________

### 签署与确认

评估者: ________________  日期: ____________
负责人: ________________  日期: ____________
法务审查: ________________  日期: ____________
```

### 数据治理阶段

```markdown
# AI 系统数据治理合规检查清单

## 第一部分：数据来源与采集

### 1.1 数据合法性

□ 数据采集是否符合法律？
  □ 获得了必要的许可与同意
  □ 数据采集符合当地法规（GDPR/CCPA/PIPL等）
  □ 第三方数据源的使用协议已审查
  □ 开源数据的使用符合许可证要求

□ 版权与知识产权
  □ 培训数据不包含未授权的受版权保护内容
  □ 已评估使用文本、代码、图像数据的IP风险
  □ 拥有或获得了必要的使用权

### 1.2 数据来源记录

□ 数据来源文档
  □ 记录了所有数据源
  □ 说明了采集时间和方式
  □ 评估了数据来源的质量与可信度
  □ 标记了已知的数据局限性

## 第二部分：数据清洁与处理

### 2.1 敏感信息处理

□ 个人数据识别与脱敏
  □ 识别了数据中的个人可识别信息（PII）
  □ 实施了脱敏措施（加密/删除/匿名化）
  □ 验证脱敏的有效性
  □ 保持了脱敏映射的安全性

□ 敏感类别数据
  □ 识别了受特殊保护的数据类别（种族、宗教、健康等）
  □ 评估了是否有合法基础处理这些数据
  □ 如无合法基础，已将其删除或脱敏

### 2.2 数据质量保证

□ 数据清洁流程
  □ 移除了重复数据
  □ 纠正了格式不一致
  □ 移除了明显的错误与噪声
  □ 文档化了数据清洁流程

□ 偏见与平衡性评估
  □ 评估了数据中的已知偏见
  □ 检查了不同群体的代表性
  □ 采取措施平衡不足代表的群体
  □ 文档化了残余偏见及其影响

## 第三部分：模型训练的合规性

### 3.1 训练过程

□ 训练数据与模型性能
  □ 记录了训练数据大小与组成
  □ 进行了训练数据的审计
  □ 评估了数据对性能的影响
  □ 识别了训练数据的限制

□ 安全对齐
  □ 进行了RLHF或其他安全微调
  □ 使用了安全标注的示例
  □ 测试了常见的越狱攻击
  □ 评估了对齐的有效性

### 3.2 隐私保护

□ 差分隐私
  □ 评估了是否使用差分隐私
  □ 如使用，验证了DP参数的充分性
  □ 记录了应用的DP机制

□ 数据保留与删除
  □ 定义了数据保留期限
  □ 建立了数据删除流程
□ 建立删除请求处理与证据保留流程
□ 说明模型层删除的技术限制；machine unlearning、重训练、检索层隔离等都只是候选手段，不自动等同于满足 GDPR 等法域要求

## 第四部分：持续合规

### 4.1 模型更新

□ 版本管理
  □ 维护了所有模型版本的记录
  □ 保存了每个版本的训练配置
  □ 可追溯每个版本的更改

□ 再训练周期
  □ 定义了再训练频率
  □ 再训练前进行了新数据的审计
  □ 再训练后重新评估了合规性

### 4.2 审计与报告

□ 审计日志
  □ 记录了所有数据处理操作
  □ 包括了数据访问、修改、删除的日志
  □ 日志保存期符合法规要求
  □ 日志不可篡改

□ 定期审计
□ 按组织定义的计划定期进行数据治理审计
  □ 文档化了审计发现
  □ 制定了改进计划
```

## 11.7.2 不同地区法规速查表

````markdown
# AI 安全法规差异速查表

## 关键要求对比

| 要求项 | EU AI Act | 美国（综合） | 中国 | 加拿大 / 日本 |
|--------|-----------|--------------|------|---------------|
| **法规制定** | 已生效并分阶段适用 | 分散（州+联邦+行业） | 已实施并持续细化 | 持续更新 |
| **是否强制** | 强制 | 部分强制 | 强制 | 以提案 / 指南 / 既有数据法为主 |
| **透明度披露** | 依风险等级适用 | 推荐/部分强制 | 依服务类型适用 | 多为指导性 |
| **影响评估** | 高风险需要 | 某些州或特定场景强制 | 需结合具体服务判断 | 多为治理建议 |
| **人工监督** | 高风险要求 | 依法域和行业而定 | 依场景适用 | 多为建议性 |
| **数据处理** | 与 GDPR 体系联动 | CCPA/州法/行业法并存 | 与 PIPL 等联动 | 与本地隐私法和指南联动 |

## 快速查询流程

```text
你的系统服务于？
├─ 涉及欧盟市场/使用场景
│  └─ 先判断是否落入 EU AI Act 范围
│     ├─ 高风险? → 完整风险管理体系
│     ├─ 有限风险? → 透明度披露
│     └─ 最小风险? → 基本要求
│
├─ 仅美国用户
│  └─ 检查州法规
│     ├─ 加州? → 信息披露
│     ├─ 科罗拉多? → 披露/透明度
│     └─ 联邦机构? → NIST RMF
│
├─ 仅中国用户
│  └─ 需要按具体服务类型判断
│     ├─ 面向公众提供生成式 AI 服务? → 关注备案/安全评估等要求
│     ├─ 处理个人数据? → PIPL
│     └─ 使用用户数据? → 隐私评估
│
└─ 多地域用户
   └─ 常见保守做法是建立统一高水位基线
      → 先确定主法域与主要业务场景
      → 再补齐各地特殊要求
      → 定期复核法规变化
```

## 关键时间节点

| 日期 | 事件 | 影响 |
|------|------|------|
| 2025-02-02 | EU AI Act 禁用实践生效 | 禁止特定 AI 应用 |
| 2025-08-02 | EU GPAI 义务生效 | 文档与评估要求 |
| 2027-12-02（2026-05-07 政治协议后的高风险领域时间线） | 某些 EU 高风险使用领域规则开始适用 | 不等待最后期限；先建立风险管理、技术文档、人工监督等落地能力 |
| 2028-08-02（2026-05-07 政治协议后的受监管产品时间线） | 嵌入受监管产品的高风险系统规则开始适用 | 针对特定受监管产品场景进一步适用，并跟踪最终文本 |
| 2026年动态 | 美国州级法规持续更新 | 需持续跟踪 |
| 持续 | 中国生成式 AI 服务备案 / 安全评估要求 | 增量式评估 |

> 注：欧盟委员会服务页显示，Digital Omnibus / AI omnibus 已在 2026-05-07 达成政治协议，2027-12-02 / 2028-08-02 是当前公开实施时间线。正式落地仍应核对最终生效文本、委员会指南和适用场景。

## 不同法域的最小实施需求

### 欧盟起步清单（高风险示例）

```text
□ 建立风险管理体系
□ 准备系统说明、技术文档与常见治理工件（如 system card / model card）
□ 进行安全和隐私影响评估
□ 实施人工监督
□ 制定可接受的使用政策
□ 完整的文档和审计跟踪
```

### 美国起步清单（典型场景示例）

```text
□ 进行 AI 影响评估（某些州）
□ 提供透明度信息
□ 建立申述机制
□ 行业特定的合规（医疗/金融等）
□ NIST AI RMF 框架集成
```

### 中国起步清单（示例）

```text
□ 视服务类型判断是否触发安全评估和备案要求
□ 建立内容审核体系
□ 数据安全合规（PIPL）
□ 用户隐私政策披露
□ 接受监管检查
```

## 常见法规冲突解决方案

**冲突1：GDPR“删除权” vs 模型精确性**
问题：删除个人数据可能降低模型准确性
解决方案：
- 先判断 GDPR 第 17 条删除权是否适用，以及是否落入科研、法定义务、法律主张等例外
- 联邦学习、差分隐私、machine unlearning 和重训练都只是候选技术手段，不是当然合规豁免
- 清晰记录删除请求、技术限制与对模型质量的影响

**冲突2：开源数据使用 vs 版权**
问题：开源数据集中可能包含受版权保护内容
解决方案：
- 在使用前审计数据集的许可证
- 获得所有者的明确许可
- 考虑 opt-out 机制（允许创作者要求删除）
- 在模型卡中清晰披露

**冲突3：模型可解释性 vs 性能**
问题：提高可解释性可能降低性能
解决方案：
- 权衡使用：关键决策需要可解释性，一般任务可较低解释性
- 组合使用可解释和高性能模型
- 投资可解释的深度学习方法
- 由人类做最终决策
````

## 11.7.3 事件响应流程模板

````markdown
# AI 安全事件响应计划（模板）

## 事件定义

### 定义严重级别

**Level 1 - 关键（Critical）**
- 大规模数据泄露（>10,000条记录）
- 系统完全不可用
- 已被利用的0-day漏洞
- 可导致严重人身伤害的行为

**Level 2 - 高（High）**
- 中等规模数据泄露（1,000-10,000条记录）
- 功能部分不可用（>1小时）
- 已知漏洞被成功利用
- 检测到高置信度的入侵

**Level 3 - 中（Medium）**
- 小规模数据泄露（<1,000条记录）
- 短期功能不可用（<1小时）
- 低级别异常活动
- 可疑但未确认的威胁

**Level 4 - 低（Low）**
- 潜在的隐私问题
- 配置问题
- 轻微的访问控制异常

## 事件响应流程

### 第一阶段：检测与初步响应（0-1小时）

**检测**
□ 监控系统告警
□ 用户报告
□ 安全审计发现
□ 日志分析检测

**初步响应**
```text
01. 确认事件存在
    - 验证告警的真实性
    - 排除误报
    - 评估严重级别

02. 启动事件响应
    - 通知CISO/安全负责人
    - 组建事件响应小组
    - 激活事件响应计划

03. 初步遏制
    - 隔离受影响系统（如需要）
    - 保存证据
    - 停止持续的访问/泄露
```

**检查清单**
□ 事件严重级别评估
□ 事件响应小组通知
□ 初步证据收集
□ 通知相关部门
□ 法务初步评估

### 第二阶段：深入分析（1-8小时）

**取证**
```text
01. 日志分析
    - 收集所有相关日志
    - 建立事件时间线
    - 识别攻击向量
    - 确定影响范围

02. 系统检查
    - 扫描是否有后门或持久化
    - 检查数据是否被修改
    - 验证配置是否被改动
    - 检查是否有未授权的访问

03. 数据评估
    - 确定泄露的具体数据
    - 评估数据的敏感性
    - 计算受影响的用户/实体数量
    - 评估潜在危害
```

**根本原因分析**
□ 技术根本原因
  □ 漏洞类型
  □ 是否已知或0-day
  □ 是否有补丁可用

□ 过程根本原因
  □ 为什么防御措施未生效
  □ 检测延迟分析
  □ 响应流程的改进点

**影响评估**
□ 业务影响
  □ 服务不可用时长
  □ 财务影响
  □ 用户影响

□ 法规影响
  □ 是否触发通知义务
  □ 受影响的法规
  □ 潜在的罚款

### 第三阶段：遏制与恢复（恢复期限取决于严重级别）

**短期遏制**
```text
对于Level 1事件（1-2小时内）:
□ 完全隔离受影响系统
□ 撤销被攻破的凭证
□ 更改关键密钥
□ 启动应急备份恢复

对于Level 2事件（2-4小时内）:
□ 限制系统访问范围
□ 加强监控
□ 部署补丁或应急修复

对于Level 3-4事件（24小时内）:
□ 持续监控
□ 计划长期修复
```

**长期修复**
```text
□ 部署永久补丁
□ 加强访问控制
□ 改进监控和检测
□ 更新安全政策
```

**恢复验证**
□ 验证系统恢复到正常状态
□ 进行安全扫描和渗透测试
□ 确保没有遗留的后门或问题
□ 恢复正常监控

### 第四阶段：通知与沟通（并行进行）

**内部通知**
```text
立即通知（事件检测后30分钟内）:
□ CISO
□ 首席技术官
□ 法务团队
□ 公共关系（PR）

后续通知（1小时内）:
□ 董事会成员
□ 受影响产品团队
□ 相关业务部门
```

**外部通知**
```text
监管部门（根据适用法规要求）:
□ 如果涉及数据泄露或安全事件，在满足法定门槛时于法定期限内通知
  - 欧盟：若构成 GDPR 第 33 条意义上的个人数据泄露，通常需在知悉后 72 小时内通知监管机构
  - 美国：视州法 and 行业法而定，期限差异较大
  - 中国：按事件类型、数据类别和适用监管要求判断通知路径

用户通知:
□ 清晰、易懂的通知信
□ 说明被泄露的数据类型
□ 提供的补救措施
□ 联系方式
□ 监控建议（如信用卡监控）

媒体沟通:
□ 准备新闻稿
□ 透明且真诚的沟通
□ 强调采取的补救措施
```

### 第五阶段：事后复盘与改进（事件后1周内）

**事件复盘会**
```text
参与者:
□ 事件响应小组
□ 技术团队
□ 管理层
□ 法务和合规

议题:
1. 事件时间线回顾
2. 根本原因再确认
3. 什么做得好，什么可以改进
4. 短期行动项（立即）
5. 长期行动项（30天内）
6. 流程改进
```

**改进执行**
```text
技术改进:
□ 部署补丁和更新
□ 改进监控和告警
□ 加强访问控制
□ 改进安全架构

流程改进:
□ 更新事件响应计划
□ 改进检测和报告流程
□ 加强培训

文档:
□ 更新事件响应流程文档
□ 记录教训
□ 分享知识库文章
```

## 事件响应团队角色与职责

| 角色 | 责任 | 联系方式 | 备选人 |
|------|------|----------|--------|
| CISO | 总体协调，决策 | | |
| 技术负责人 | 取证与恢复 | | |
| 法务代表 | 法规合规评估 | | |
| PR负责人 | 外部沟通 | | |
| 产品经理 | 业务影响评估 | | |

## 事件响应联系方式（应急）

```text
内部:
- 24/7值班热线: ___________
- 紧急邮件列表: ___________
- 紧急Slack频道: #security-incident

外部:
- 法务咨询: ___________
- 公关公司: ___________
- 外部安全专家: ___________
- 执法部门: ___________
```

## 事件报告模板

```text
事件ID: SEC-[YYYY]-[NNN]（格式：SEC-年份-序号，如 SEC-2026-001）
报告日期: ____________
严重级别: □ Critical □ High □ Medium □ Low

事件摘要:
- 发生时间: __________
- 发现时间: __________
- 影响系统: __________
- 影响用户数: __________
- 数据类型: __________

时间线:
[详细的事件发展时间线]

根本原因:
[RCA分析结果]

影响评估:
- 业务影响: __________
- 法规影响: __________
- 用户影响: __________

采取的行动:
- 立即行动: __________
- 短期行动: __________
- 长期行动: __________

预防措施:
[未来预防此类事件的措施]
```
````

## 11.7.4 合规审计周期建议

````markdown

# AI 系统安全合规审计周期计划

## 不同类型系统的审计频率

| 系统风险等级 | 完整安全审计（示例频率） | 快速合规检查（示例频率） | 威胁评估 |
|-------------|-------------------------|---------------------------|---------|
| 高风险 | 可按季度 | 可按月 | 深度评估需单独规划 |
| 中风险 | 可按半年 | 可按季度 | 每年或按重大变更触发 |
| 低风险 | 可按年 | 可按半年 | 按需 |

## 年度合规审计计划（示例）

```text
Q1 (1月-3月)
┌─────────────────────────────────────┐
│ 重点：数据与训练合规               │
├─────────────────────────────────────┤
│ □ 训练数据源审计                    │
│ □ 个人数据处理流程检查              │
│ □ 版权与IP合规评估                  │
│ □ 模型卡更新                        │
│ □ 数据治理流程复核                  │
└─────────────────────────────────────┘

Q2 (4月-6月)
┌─────────────────────────────────────┐
│ 重点：安全与防御检查                │
├─────────────────────────────────────┤
│ □ 红队演练                          │
│ □ 越狱测试与评估                    │
│ □ 提示注入防护检查                  │
│ □ 安全工具与控制审计                │
│ □ 系统卡更新                        │
└─────────────────────────────────────┘

Q3 (7月-9月)
┌─────────────────────────────────────┐
│ 重点：操作与治理审核                │
├─────────────────────────────────────┤
│ □ 访问控制与权限审计                │
│ □ 审计日志完整性检查                │
│ □ 事件响应计划演练                  │
│ □ 安全培训有效性评估                │
│ □ 第三方供应商安全检查              │
└─────────────────────────────────────┘

Q4 (10月-12月)
┌─────────────────────────────────────┐
│ 重点：合规与年度总结                │
├─────────────────────────────────────┤
│ □ 法规更新与新要求评估              │
│ □ 年度合规报告生成                  │
│ □ 整年安全漏洞与事件总结            │
│ □ 下一年度改进计划制定              │
│ □ 管理层合规汇报                    │
└─────────────────────────────────────┘
```
````

## 11.7.5 审计检查清单

### 数据安全审计

```
数据来源与采集
□ 所有数据来源已文档化
□ 数据采集流程符合法规
□ 获得必要的用户同意
□ 版权和IP问题已解决

数据处理与存储
□ 个人数据已识别和脱敏
□ 数据存储环境安全
□ 访问控制适当
□ 数据加密到位

数据保留与删除
□ 定义了保留期限
□ 实施了自动删除流程
□ 用户删除请求有流程
□ 删除的有效性已验证
```

### 模型安全审计

```
训练与微调安全
□ 训练流程文档完整
□ 安全对齐已实施
□ 使用的数据经过审计
□ 微调后重新评估了安全性

推理与部署
□ 输入验证有效
□ 输出审核到位
□ 系统隔离充分
□ 监控和告警有效

更新与版本管理
□ 版本控制完善
□ 更新前进行安全测试
□ 可追踪更改历史
□ 有回滚能力
```

### 操作安全审计

```
访问与权限管理
□ 最小权限原则已应用
□ 权限矩阵已定义和审计
□ 定期检查过期权限
□ 异常权限使用已检测

日志与审计
□ 日志记录完整
□ 日志保留符合法规
□ 日志不可篡改
□ 审计能够追踪所有操作

事件响应
□ 事件响应计划已更新
□ 团队已培训
□ 流程已演练
□ 工具和流程已测试
```

### 合规性审计

```
法规遵守
□ 适用的法规已识别
□ 具体要求已明确
□ 合规差距已评估
□ 改进计划已制定

文档与透明度
□ 系统卡和模型卡已更新
□ 隐私政策已审查
□ 用户说明已清晰
□ 技术文档完整

第三方审查
□ 外部安全审计已进行
□ 审计发现已解决
□ 法务审查已完成
□ 行业标准已考量
```

## 11.7.6 审计发现分类与优先级

```
优先级1 - 立即修复（Critical）
- 直接违反法规的行为
- 活跃的安全威胁
- 大规模数据泄露风险
修复时间限制：1周内

优先级2 - 紧急修复（High）
- 重大安全漏洞
- 部分合规缺陷
- 可能导致泄露的弱点
修复时间限制：30天

优先级3 - 计划修复（Medium）
- 工程改进机会
- 流程优化
- 最佳实践更新
修复时间限制：90天

优先级4 - 观察（Low）
- 建议性改进
- 未来优化方向
修复时间限制：视情况而定
```

组织应该根据自身的系统复杂性、风险等级和法规要求，定制适合的审计周期和检查项目。定期的、结构化的审计是确保持续合规的关键。

本部分的所有模板和清单都可以直接应用到实际工作中，并根据组织的具体情况进行定制。