引言监管要求本身只是愿景真正的挑战在于落地。“知道要求”与“证明合规”之间隔着数月的系统性工作。本文基于一套完整的 GenAI 合规实施经验总结出安全人员和开发人员如何协同工作使 GenAI 系统满足合规需求。核心原则合规不是检查运行系统而是检查文档证据监管机构和公告机构不会通过检查运行中的系统来评估组织的安全控制。他们评估的是描述这些控制的文档验证控制有效性的测试证据证明持续有效性的监控记录因此文档是合规评估中的首要证据 artifact。技术安全做得好但如果缺乏将每一层控制映射到具体法规条款的正式文档就无法满足合规要求。一、从“法规意识”到“可证明合规”的差距大多数组织失败的地方正是法规意识与可证明合规之间的鸿沟。安全团队往往已经部署了许多技术控制例如五层防御架构但将这些控制与具体法规要求连接起来的文档要么不完整要么根本不存在。实施建议将每一条监管义务映射到具体的技术控制、文档要求或组织程序。建立“合规要求表”每一行对应一条法规条款及其所需的证据。把已有的安全 artifact威胁模型、红队报告、监控日志转化为合规文档补充监管上下文。二、五层合规文档栈自底向上构建高风险 AI 系统的合规评估需要一套层层递进的文档栈。每一层都建立在下层之上形成完整的证据包。第 1 层风险管理系统基础法规对应EU-AI Act 第 9 条核心要求建立、记录并维护风险管理系统且必须在任何 AI 系统投产前就位。实施要点将 AI 威胁模型转化为正式的风险评估文档。威胁建模可以参考大模型安全之二十七Agent 工具层威胁建模-CSDN博客。识别 AI 特有的攻击面、严重性评级和缓解策略。将每个已识别风险映射到相关法规条款并记录所采取的风险管理措施。保持文档“活”的状态随新风险和缓解措施持续更新。为什么这是基础没有文档化的风险评估数据治理记录就缺乏评估数据风险的框架技术文档就缺乏驱动架构决策的安全需求透明度措施就缺乏决定用户需要知道什么的风险上下文。第 2 层数据治理记录法规对应第 10 条核心要求证明训练数据是合法收集的、代表预期使用场景的并已进行偏见评估。实施要点记录每一份训练文档的来源、许可治理、质量与偏见审查情况。对于微调模型追溯每一份训练数据的出处。现实挑战如果 AI 产品在正式数据治理程序建立之前就已开发需要工程团队追溯重建采购记录、评估许可合规性并对已用于训练的数据集进行偏见评估。常见缺口仅靠安全架构无法满足数据治理要求。这是安全团队需要与法务、数据团队协作的关键领域。第 3 层技术文档法规对应第 11 条核心要求记录系统架构、设计决策和开发方法。实施要点输入验证规则护栏配置沙箱边界输出过滤策略监控阈值纵深防御架构的每一层设计这些内容展示的是系统性工程实践是合规评估中技术能力的重要证据。第 4 层透明度措施法规对应第 13 条、第 50 条核心要求第 13 条向部署该系统的企业提供清晰的使用说明披露系统能力与局限。第 50 条确保与 AI 系统交互的个人被告知 AI 的参与。实施要点每一次 AI 交互都必须清晰披露系统的 AI 性质。提供面向用户的能力文档和局限性说明。这一层要求组织对“用户如何与 AI 交互”做出具体承诺。第 5 层人类监督程序法规对应第 14 条核心要求不仅仅是“有人审查 AI 输出”而是文档化的升级程序明确哪些输出需要人工审查谁负责审查审查者有什么权力覆盖系统覆盖决策如何被记录实施要点定义哪些客户交互被路由到人工代理。建立升级响应时间要求。创建审计轨迹证明覆盖能力被实际行使且有效。提供机制让人类可以覆盖系统。这一层将组织义务从工程团队延伸到运营、客户成功和法务部门。三、将安全 artifact 转化为合规证据安全团队在前期工作中产生的许多 artifact其实正是监管机构会评估的材料。挑战在于将其正式化为合规文档。安全 artifact对应法规转化方式AI 威胁模型第 9 条补充监管上下文将每个风险映射到法规条款记录风险管理措施红队评估报告第 15 条记录对抗性测试结果、防御有效性测量、修复行动作为鲁棒性测试证据监控管道日志第 72 条证明监控是持续的、事件被跟踪调查、发现驱动系统改进纵深防御架构第 11 条转化为技术文档展示系统性工程实践关键洞察红队项目产生的结构化报告正是合规评估所需要的测试证据。监控管道提供的技术基础正是售后监控合规所需的基础。四、持续监控合规不止于部署法规对应第 72 条售后监控核心要求合规责任从初始部署延伸到持续运营。实施要点记录 AI 交互检测异常行为触发警报证明监控是连续的证明事件被跟踪和调查证明发现通过文档化反馈循环驱动系统改进五、给安全人员和开发人员的行动清单安全人员不要只做技术控制要同步产出合规文档。每个控制措施都要有对应的文档说明它满足哪条法规。将威胁模型转化为风险管理系统。补充监管上下文映射到具体条款。把红队报告结构化。确保包含对抗性测试结果、防御有效性测量和修复行动。确保监控管道可审计。日志、异常检测、警报和事件跟踪都要能被监管机构评估。与法务和合规团队协作。风险管理系统、数据治理和人类监督程序需要跨部门协调。开发人员在系统投产前就建立风险管理系统。这是第 9 条的硬性要求。记录训练数据来源。每一份文档的来源、许可、质量与偏见审查都要可追溯。实现透明度披露。每次 AI 交互都要清晰告知用户 AI 的参与。构建人类覆盖机制。定义升级路径、响应时间、覆盖权限和审计轨迹。维护技术文档。架构决策、输入验证、护栏配置、沙箱边界、输出过滤和监控阈值都要记录在案。支持持续监控。确保系统能记录交互、检测异常并触发警报且这些记录可用于合规证据。六、关键教训监管合规不是一次性的项目而是一个持续的文档化过程。文档是合规评估的首要证据。没有文档技术控制再好也无法通过合规评估。自底向上构建文档栈。从风险管理系统开始逐层向上数据治理 → 技术文档 → 透明度 → 人类监督。安全 artifact 可以复用但需要补充监管上下文。威胁模型、红队报告、监控日志都是合规证据的原材料。跨部门协作是必须的。工程、安全、法务、合规、运营和客户成功都需要参与。合规责任延伸到部署之后。售后监控、事件跟踪和反馈循环是持续合规的一部分。最终目标构建一套完整的证据包让监管机构和公告机构在合规评估中能够清楚地看到——每一个法规义务都被映射到了具体的技术控制、文档要求和组织程序并且有测试证据和监控记录证明其持续有效。
引言监管要求本身只是愿景真正的挑战在于落地。“知道要求”与“证明合规”之间隔着数月的系统性工作。本文基于一套完整的 GenAI 合规实施经验总结出安全人员和开发人员如何协同工作使 GenAI 系统满足合规需求。核心原则合规不是检查运行系统而是检查文档证据监管机构和公告机构不会通过检查运行中的系统来评估组织的安全控制。他们评估的是描述这些控制的文档验证控制有效性的测试证据证明持续有效性的监控记录因此文档是合规评估中的首要证据 artifact。技术安全做得好但如果缺乏将每一层控制映射到具体法规条款的正式文档就无法满足合规要求。一、从“法规意识”到“可证明合规”的差距大多数组织失败的地方正是法规意识与可证明合规之间的鸿沟。安全团队往往已经部署了许多技术控制例如五层防御架构但将这些控制与具体法规要求连接起来的文档要么不完整要么根本不存在。实施建议将每一条监管义务映射到具体的技术控制、文档要求或组织程序。建立“合规要求表”每一行对应一条法规条款及其所需的证据。把已有的安全 artifact威胁模型、红队报告、监控日志转化为合规文档补充监管上下文。二、五层合规文档栈自底向上构建高风险 AI 系统的合规评估需要一套层层递进的文档栈。每一层都建立在下层之上形成完整的证据包。第 1 层风险管理系统基础法规对应EU-AI Act 第 9 条核心要求建立、记录并维护风险管理系统且必须在任何 AI 系统投产前就位。实施要点将 AI 威胁模型转化为正式的风险评估文档。威胁建模可以参考大模型安全之二十七Agent 工具层威胁建模-CSDN博客。识别 AI 特有的攻击面、严重性评级和缓解策略。将每个已识别风险映射到相关法规条款并记录所采取的风险管理措施。保持文档“活”的状态随新风险和缓解措施持续更新。为什么这是基础没有文档化的风险评估数据治理记录就缺乏评估数据风险的框架技术文档就缺乏驱动架构决策的安全需求透明度措施就缺乏决定用户需要知道什么的风险上下文。第 2 层数据治理记录法规对应第 10 条核心要求证明训练数据是合法收集的、代表预期使用场景的并已进行偏见评估。实施要点记录每一份训练文档的来源、许可治理、质量与偏见审查情况。对于微调模型追溯每一份训练数据的出处。现实挑战如果 AI 产品在正式数据治理程序建立之前就已开发需要工程团队追溯重建采购记录、评估许可合规性并对已用于训练的数据集进行偏见评估。常见缺口仅靠安全架构无法满足数据治理要求。这是安全团队需要与法务、数据团队协作的关键领域。第 3 层技术文档法规对应第 11 条核心要求记录系统架构、设计决策和开发方法。实施要点输入验证规则护栏配置沙箱边界输出过滤策略监控阈值纵深防御架构的每一层设计这些内容展示的是系统性工程实践是合规评估中技术能力的重要证据。第 4 层透明度措施法规对应第 13 条、第 50 条核心要求第 13 条向部署该系统的企业提供清晰的使用说明披露系统能力与局限。第 50 条确保与 AI 系统交互的个人被告知 AI 的参与。实施要点每一次 AI 交互都必须清晰披露系统的 AI 性质。提供面向用户的能力文档和局限性说明。这一层要求组织对“用户如何与 AI 交互”做出具体承诺。第 5 层人类监督程序法规对应第 14 条核心要求不仅仅是“有人审查 AI 输出”而是文档化的升级程序明确哪些输出需要人工审查谁负责审查审查者有什么权力覆盖系统覆盖决策如何被记录实施要点定义哪些客户交互被路由到人工代理。建立升级响应时间要求。创建审计轨迹证明覆盖能力被实际行使且有效。提供机制让人类可以覆盖系统。这一层将组织义务从工程团队延伸到运营、客户成功和法务部门。三、将安全 artifact 转化为合规证据安全团队在前期工作中产生的许多 artifact其实正是监管机构会评估的材料。挑战在于将其正式化为合规文档。安全 artifact对应法规转化方式AI 威胁模型第 9 条补充监管上下文将每个风险映射到法规条款记录风险管理措施红队评估报告第 15 条记录对抗性测试结果、防御有效性测量、修复行动作为鲁棒性测试证据监控管道日志第 72 条证明监控是持续的、事件被跟踪调查、发现驱动系统改进纵深防御架构第 11 条转化为技术文档展示系统性工程实践关键洞察红队项目产生的结构化报告正是合规评估所需要的测试证据。监控管道提供的技术基础正是售后监控合规所需的基础。四、持续监控合规不止于部署法规对应第 72 条售后监控核心要求合规责任从初始部署延伸到持续运营。实施要点记录 AI 交互检测异常行为触发警报证明监控是连续的证明事件被跟踪和调查证明发现通过文档化反馈循环驱动系统改进五、给安全人员和开发人员的行动清单安全人员不要只做技术控制要同步产出合规文档。每个控制措施都要有对应的文档说明它满足哪条法规。将威胁模型转化为风险管理系统。补充监管上下文映射到具体条款。把红队报告结构化。确保包含对抗性测试结果、防御有效性测量和修复行动。确保监控管道可审计。日志、异常检测、警报和事件跟踪都要能被监管机构评估。与法务和合规团队协作。风险管理系统、数据治理和人类监督程序需要跨部门协调。开发人员在系统投产前就建立风险管理系统。这是第 9 条的硬性要求。记录训练数据来源。每一份文档的来源、许可、质量与偏见审查都要可追溯。实现透明度披露。每次 AI 交互都要清晰告知用户 AI 的参与。构建人类覆盖机制。定义升级路径、响应时间、覆盖权限和审计轨迹。维护技术文档。架构决策、输入验证、护栏配置、沙箱边界、输出过滤和监控阈值都要记录在案。支持持续监控。确保系统能记录交互、检测异常并触发警报且这些记录可用于合规证据。六、关键教训监管合规不是一次性的项目而是一个持续的文档化过程。文档是合规评估的首要证据。没有文档技术控制再好也无法通过合规评估。自底向上构建文档栈。从风险管理系统开始逐层向上数据治理 → 技术文档 → 透明度 → 人类监督。安全 artifact 可以复用但需要补充监管上下文。威胁模型、红队报告、监控日志都是合规证据的原材料。跨部门协作是必须的。工程、安全、法务、合规、运营和客户成功都需要参与。合规责任延伸到部署之后。售后监控、事件跟踪和反馈循环是持续合规的一部分。最终目标构建一套完整的证据包让监管机构和公告机构在合规评估中能够清楚地看到——每一个法规义务都被映射到了具体的技术控制、文档要求和组织程序并且有测试证据和监控记录证明其持续有效。
