引言
监管要求本身只是愿景，真正的挑战在于落地。“知道要求”与“证明合规”之间，隔着数月的系统性工作。 本文基于一套完整的 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 可以复用，但需要补充监管上下文。 威胁模型、红队报告、监控日志都是合规证据的原材料。
-
跨部门协作是必须的。 工程、安全、法务、合规、运营和客户成功都需要参与。
-
合规责任延伸到部署之后。 售后监控、事件跟踪和反馈循环是持续合规的一部分。
最终目标： 构建一套完整的证据包，让监管机构和公告机构在合规评估中能够清楚地看到——每一个法规义务都被映射到了具体的技术控制、文档要求和组织程序，并且有测试证据和监控记录证明其持续有效。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/jimmyleeee/article/details/167213191
