AI 辅助开发中无人谈及的合规认证缺口
你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。
AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。
你所同意的认证契约
SOC 2 Type II 变更管理控制——尤其是 CC6.1 和 CC8.1——要求"所有代码变更在实施前须经授权人员审查和批准"。这一措辞听起来直接明了，但审计人员基于特定的思维模型来解读它：审查人阅读了代码、理解了逻辑，并对其正确性负责。
这就是"认证"在此语境中的含义。代码审查的合规价值不在于为差异提供第二双眼睛，而在于建立一条人类问责链。有人理解了所提交的内容，并且那个人可以被追责。SOX 第 404 条进一步将此正式化：没有任何一人可以既开发代码又将其部署到生产环境，每次变更都必须有来自非作者的文档化审批工作流。
HIPAA 的安全规则为处理受保护健康信息的系统增加了额外要求：访问控制必须可审计，代码审查应验证 PHI 已加密、访问受到适当限制，且敏感数据不会意外暴露。PCI-DSS v4.0 第 6 节要求"具备资质的人员"通过"正式审批流程"评估系统修改。
在所有这些框架中，隐含的契约是：一个具备相关判断力的人类审查了这次变更并签字确认。
AI 生成代码的实际情况
以下是这一缺口在实践中的样貌。一名开发人员要求 AI 助手实现一个符合 HIPAA 的 API 端点。AI 生成了 300 行代码——包括请求处理器、数据访问模式和单元测试。开发人员阅读了差异，认为看起来合理，运行了生成的测试（测试通过），并开启了一个 PR。第二名开发人员审查、批准，代码上线。
根据变更管理日志：两名工程师审查并批准了这次变更。根据实际执行的认知工作：两名开发人员都没有编写他们认证为"已理解"的逻辑。提交 PR 的开发人员在没有推演访问控制设计的情况下审查了差异。审查人在没有审计 AI 选择的测试覆盖范围的情况下批准了代码。
2025 年 DORA 报告发现，超过 60% 的开发人员在部署后才发现 AI 相关错误，传统流水线允许 AI 生成的变更在没有对逻辑进行独立验证的情况下合并和部署。Stack Overflow 2024 年调查数据发现，在受监管场景中，42.7% 的 AI 建议代码实现包含潜在安全缺陷，身份验证代码的漏洞率高达 61.3%。更值得关注的是：96% 的开发人员表示他们不完全信任 AI 生成的代码——但只有 48% 的人表示在提交前总会检查。
审批记录说的是一回事。实际的认知问责链条则弱得多。
审计人员开始关注什么
大多数审计人员尚未跟上这一变化——AICPA 本身在 2025 年承认，其工作组仍在探索如何为 AI 辅助开发更新信托服务准则。但已开始提问的审计人员正在聚焦三件事。
谁发起了这次变更？ 传统变更管理日志记录的是开启 PR 的开发人员。当逻辑由 AI 模型编写时，审计人员越来越想知道生成的触发因素：给出了什么输入、使用了哪个模型版本，以及生成的输出是否可确定性复现。一条仅显示"merged by: [email protected]"的日志记录无法回答这些问题。
测试覆盖实际上是为了测试什么而设计的？ 当 AI 同时编写实现和测试时，测试覆盖反映的是 AI 对需求的理解，而非人类对需求的独立验证。审查 SOX 金融系统或 HIPAA 医疗系统的审计人员希望看到证据——测试覆盖是由一个推演过覆盖范围的人类根据需求验证的——而不仅仅是测试运行并通过的证据。
