# 11.7 AI 安全合规的可操作性指南 ### 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 24-205 / SB25B-004（要求生效日期已延后至 2026-06-30；仍需核对适用范围、规则制定与影响评估要求） □ 其他州: ___________ □ 是否涉及特定行业监管？ □ 医疗（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月) ┌─────────────────────────────────────┐ │ 重点：合规与年度总结 │ ├─────────────────────────────────────┤ │ □ 法规更新与新要求评估 │ │ □ 年度合规报告生成 │ │ □ 整年安全漏洞与事件总结 │ │ □ 下一年度改进计划制定 │ │ □ 管理层合规汇报 │ └─────────────────────────────────────┘ ``` ```` ### 审计检查清单 #### 数据安全审计 ``` 数据来源与采集 □ 所有数据来源已文档化 □ 数据采集流程符合法规 □ 获得必要的用户同意 □ 版权和IP问题已解决 数据处理与存储 □ 个人数据已识别和脱敏 □ 数据存储环境安全 □ 访问控制适当 □ 数据加密到位 数据保留与删除 □ 定义了保留期限 □ 实施了自动删除流程 □ 用户删除请求有流程 □ 删除的有效性已验证 ``` #### 模型安全审计 ``` 训练与微调安全 □ 训练流程文档完整 □ 安全对齐已实施 □ 使用的数据经过审计 □ 微调后重新评估了安全性 推理与部署 □ 输入验证有效 □ 输出审核到位 □ 系统隔离充分 □ 监控和告警有效 更新与版本管理 □ 版本控制完善 □ 更新前进行安全测试 □ 可追踪更改历史 □ 有回滚能力 ``` #### 操作安全审计 ``` 访问与权限管理 □ 最小权限原则已应用 □ 权限矩阵已定义和审计 □ 定期检查过期权限 □ 异常权限使用已检测 日志与审计 □ 日志记录完整 □ 日志保留符合法规 □ 日志不可篡改 □ 审计能够追踪所有操作 事件响应 □ 事件响应计划已更新 □ 团队已培训 □ 流程已演练 □ 工具和流程已测试 ``` #### 合规性审计 ``` 法规遵守 □ 适用的法规已识别 □ 具体要求已明确 □ 合规差距已评估 □ 改进计划已制定 文档与透明度 □ 系统卡和模型卡已更新 □ 隐私政策已审查 □ 用户说明已清晰 □ 技术文档完整 第三方审查 □ 外部安全审计已进行 □ 审计发现已解决 □ 法务审查已完成 □ 行业标准已考量 ``` ### 审计发现分类与优先级 ``` 优先级1 - 立即修复（Critical） - 直接违反法规的行为 - 活跃的安全威胁 - 大规模数据泄露风险 修复时间限制：1周内 优先级2 - 紧急修复（High） - 重大安全漏洞 - 部分合规缺陷 - 可能导致泄露的弱点 修复时间限制：30天 优先级3 - 计划修复（Medium） - 工程改进机会 - 流程优化 - 最佳实践更新 修复时间限制：90天 优先级4 - 观察（Low） - 建议性改进 - 未来优化方向 修复时间限制：视情况而定 ``` 组织应该根据自身的系统复杂性、风险等级和法规要求，定制适合的审计周期和检查项目。定期的、结构化的审计是确保持续合规的关键。 本部分的所有模板和清单都可以直接应用到实际工作中，并根据组织的具体情况进行定制。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yeasy.gitbook.io/ai_security_guide/di-si-bu-fen-zhi-li-yu-zhan-wang/11_governance/11.7_compliance_operational.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.