ai-change-evidence

AI 变更证据

变更管理控制措施最初是以由人来实施变更为前提编写的。当 Agent 编写代码、由人审批拉取请求时，控制措施依然有效——但前提是记录能说明谁决定了什么，而记录通常做不到这一点。

目标不是证明 Agent 足够谨慎，而是展示任何变更都必须满足的要求：变更经过授权、由具备相应能力且与实施者分开的人员审核，并且能够还原整个过程。

1. 确定 Agent 实际参与的范围

审计人员会先询问范围，再看控制措施。确定审计期间内：

• 哪些代码仓库和服务接受 Agent 编写的变更
• 其中哪些属于评估范围
• 是否能区分 Agent 提交和人工提交

如果提交都归属到某个人的身份，且没有任何标记，就应坦率说明，而不是事后再还原。无法标记的变更群体是范围界定问题，不是文书问题。

2. 确立来源记录

对于每项纳入范围的变更，记录应能说明：

问题	证据
谁发起了变更？	触发此次运行的人员、工单或计划
提出了什么要求？	提示词、规范或计划，与差异一起进行版本控制
是什么生成了变更？	当时使用的 Agent、模型和配置
变更影响了什么？	差异，以及运行过的测试和检查
谁批准了变更？	一位具名人员，且不是请求者

配置的重要性超乎想象。“已通过 Agent 的策略审核”毫无意义，除非你能证明当天加载的是哪项策略。

3. 保持职责分离

这是最可能在不知不觉中被破坏的控制措施：

• 请求变更的人不应是唯一审批者——中间有 Agent 并不构成职责分离
• Agent 审批自己的输出不算审核，无论检查项的标签怎么写
• 自动化检查是验证证据，不是独立审批的证据
• 如果 Agent 既编写变更又合并变更，那么控制责任已转移到授权其自主操作的人身上——应在该处记录，而不是假装发生过审核

4. 对照评估所依据的控制措施

不要另造一套“AI 控制措施”。应映射到框架已有的要求：

• 变更管理——上线前的授权、测试和审批（SOC 2 CC8.1、ISO 27001 A.8.32、PCI DSS 6.5）
• 访问控制——Agent 的身份、权限，以及对这些权限的定期审核（SOC 2 CC6.1-6.3、ISO 27001 A.5.15）
• 日志记录与监控——Agent 的操作可归属到具体主体，并在整个审计期间内保留（SOC 2 CC7.2）
• 供应商管理——当源代码或客户数据离开你的边界时，将模型提供商视为子处理方（SOC 2 CC9.2、ISO 27001 A.5.19）

请根据评估日期核实框架版本；控制措施标识符会随修订版变化。

5. 回答数据相关问题

预期会遇到以下问题，并依据合同而非营销页面作答：

• 源代码是否会离开当前环境？会发送给谁？
• 源代码会保留多久？是否会用于训练？
• 数据会在哪些区域处理？这是否符合你对客户的承诺？
• 如果客户数据可能进入 Agent 的上下文，应由哪份协议涵盖？

6. 按审计人员的方式抽样

从审计期间随机选取一些变更，尝试端到端地整理完整记录。记录哪些地方需要询问某个人、进行猜测或凭记忆还原。这些才是审计发现——问题不在于变更本身，而在于追踪链断裂之处。

如果确实缺少证据，应将其记录为差距，并注明负责人和日期。记录在案的差距可以辩护；而事后还原、暗示流程比实际更加严谨的记录则不可辩护，并且一旦真相暴露，就会损害评估结果。

范围与参与规则

仅评估你获准审查的环境，并按照适用于相关内容的保密条款处理轨迹中包含的所有内容，包括提示词、差异和工单内容。不要将此输出作为审计意见或认证：它是为审计做准备，评估人员自行作出判断。

输出

按控制项逐项制作表格，列出控制项、支持它的证据、证据所在位置，以及证据覆盖整个期间还是部分期间。单独列出差距，并注明负责人和整改日期。明确说明哪些声明依据你已验证的工具，哪些依据某人对流程的描述。