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

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

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

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

风险评估阶段

# 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 24-205 （影响评估）
    □ 其他州: ___________

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

**中国**
□ 是否面向中国用户或处理中国数据？
  □ 是 → 需要合规：
    □ 《生成式AI服务管理暂行办法》
    □ 《数据安全法》
    □ 《个人信息保护法》
    □ 大模型备案制度

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

### 2.2 具体合规要求

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

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

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

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

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

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

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

### 3.1 技术控制措施

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

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

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

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

### 3.2 组织与管理控制

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

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

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

### 3.3 持续监控与改进

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

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

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

## 第四部分：评估结论

### 综合风险评分

____ / 100

### 推荐行动优先级

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

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

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

### 签署与确认

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

数据治理阶段

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

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

### 1.1 数据合法性

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

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

### 1.2 数据来源记录

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

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

### 2.1 敏感信息处理

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

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

### 2.2 数据质量保证

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

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

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

### 3.1 训练过程

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

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

### 3.2 隐私保护

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

□ 数据保留与删除
  □ 定义了数据保留期限
  □ 建立了数据删除流程
  □ 能够验证培训数据的删除
  □ 符合GDPR"被遗忘权"等要求

## 第四部分：持续合规

### 4.1 模型更新

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

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

### 4.2 审计与报告

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

□ 定期审计
  □ 每年至少进行一次数据治理审计
  □ 文档化了审计发现
  □ 制定了改进计划

11.6.2 不同地区法规速查表

# AI 安全法规差异速查表（2026年2月更新）

## 关键要求对比

| 要求项 | EU AI Act | 美国（综合） | 中国 | 日本/加拿大 |
|--------|-----------|-----------|------|----------|
| **法规制定** | 已生效 | 分散（州+联邦+行业） | 已实施 | 持续更新 |
| **是否强制** | 强制 | 部分强制 | 强制 | 多为指导性 |
| **透明度披露** | 必须 | 推荐/部分强制 | 需要 | 推荐 |
| **影响评估** | 高风险需要 | 某些州强制 | 备案时需要 | 推荐 |
| **人工监督** | 必须 | 建议 | 必须 | 建议 |
| **数据处理** | GDPR兼容 | CCPA/州法 | PIPL兼容 | 类似GDPR |

## 快速查询流程

你的系统服务于？ ├─ 涉及欧盟市场/使用场景 │ └─ 先判断是否落入 EU AI Act 范围 │ ├─ 高风险? → 完整风险管理体系 │ ├─ 有限风险? → 透明度披露 │ └─ 最小风险? → 基本要求 │ ├─ 仅美国用户 │ └─ 检查州法规 │ ├─ 加州? → 信息披露 │ ├─ 科罗拉多? → 影响评估 │ └─ 联邦机构? → NIST RMF │ ├─ 仅中国用户 │ └─ 必须合规 │ ├─ 涉及内容生成? → 备案制度 │ ├─ 处理个人数据? → PIPL │ └─ 使用用户数据? → 隐私评估 │ └─ 多地域用户 └─ 采用”最严法域”标准 → 以欧盟要求为基线 → 补充各地特殊要求 → 定期复核法规变化

## 关键时间节点

| 日期 | 事件 | 影响 |
|------|------|------|
| 2025-02-02 | EU AI Act 禁用实践生效 | 禁止特定AI应用 |
| 2025-08-02 | EU GPAI义务生效 | 文档与评估要求 |
| 2026-08-02 | EU高风险系统完整要求 | 最严格的合规义务 |
| 2026年动态 | 美国州级法规持续更新 | 需持续跟踪 |
| 持续 | 中国大模型备案 | 增量式评估 |

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

### 欧盟最小实施（高风险）

□ 建立风险管理体系 □ 创建系统卡和模型卡 □ 进行安全和隐私影响评估 □ 实施人工监督 □ 制定可接受的使用政策 □ 完整的文档和审计跟踪

### 美国最小实施（典型场景）

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

### 中国最小实施

□ 通过安全评估和算法备案 □ 建立内容审核体系 □ 数据安全合规（PIPL） □ 用户隐私政策披露 □ 接受监管检查

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

**冲突1：GDPR"删除权" vs 模型精确性**
问题：删除个人数据可能降低模型准确性
解决方案：
- 使用联邦学习，本地训练不传输数据
- 使用差分隐私，无法恢复个人数据
- 重新训练模型而非删除单个样本
- 清晰记录删除的影响

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

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

11.6.3 事件响应流程模板

# 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小时）

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

**初步响应**

1. 确认事件存在

   • 验证告警的真实性

   • 排除误报

   • 评估严重级别

2. 启动事件响应

   • 通知CISO/安全负责人

   • 组建事件响应小组

   • 激活事件响应计划

3. 初步遏制

   • 隔离受影响系统（如需要）

   • 保存证据

   • 停止持续的访问/泄露

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

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

**取证**

1. 日志分析

   • 收集所有相关日志

   • 建立事件时间线

   • 识别攻击向量

   • 确定影响范围

2. 系统检查

   • 扫描是否有后门或持久化

   • 检查数据是否被修改

   • 验证配置是否被改动

   • 检查是否有未授权的访问

3. 数据评估

   • 确定泄露的具体数据

   • 评估数据的敏感性

   • 计算受影响的用户/实体数量

   • 评估潜在危害

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

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

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

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

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

**短期遏制**

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

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

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

**长期修复**

□ 部署永久补丁 □ 加强访问控制 □ 改进监控和检测 □ 更新安全政策

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

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

**内部通知**

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

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

**外部通知**

规管部门（根据法规要求）: □ 如果涉及大规模数据泄露，在法定时间内通知

• 欧盟：GDPR要求72小时内通知监管机构

• 美国：视州法，通常要求30-60天内通知

• 中国：通知监管机构和用户

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

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

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

**事件复盘会**

参与者: □ 事件响应小组 □ 技术团队 □ 管理层 □ 法务和合规

议题:

1. 事件时间线回顾

2. 根本原因再确认

3. 什么做得好，什么可以改进

4. 短期行动项（立即）

5. 长期行动项（30天内）

6. 流程改进

**改进执行**

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

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

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

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

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

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

内部:

• 24/7值班热线: ___________

• 紧急邮件列表: ___________

• 紧急Slack频道: #security-incident

外部:

• 法务咨询: ___________

• 公关公司: ___________

• 外部安全专家: ___________

• 执法部门: ___________

## 事件报告模板

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

事件摘要:

• 发生时间: __________

• 发现时间: __________

• 影响系统: __________

• 影响用户数: __________

• 数据类型: __________

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

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

影响评估:

• 业务影响: __________

• 法规影响: __________

• 用户影响: __________

采取的行动:

• 立即行动: __________

• 短期行动: __________

• 长期行动: __________

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

### 11.6.4 合规审计周期建议

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

不同类型系统的审计频率

系统风险等级	完整安全审计	快速合规检查	威胁评估
高风险	每季度	每月	每年深度
中风险	每半年	每季度	每年
低风险	每年	每半年	按需

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

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

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

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

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

审计检查清单

数据安全审计

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

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

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

模型安全审计

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

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

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

操作安全审计

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

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

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

合规性审计

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

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

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

审计发现分类与优先级

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

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

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

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

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

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