The compliance frameworks were written before AI coding tools existed

合规框架编写于 AI 编程工具出现之前

ISO 27001, SOC 2, and NIST assume humans made decisions and left a paper trail. That assumption is breaking. Imagine an auditor sitting across from your engineering team. They’re working through your change management controls. They want to know: who approved this code change? What was the review process? Is there evidence that a qualified person made a deliberate decision? ISO 27001、SOC 2 和 NIST 等标准都基于一个假设：决策由人类做出，并留下了书面记录。但这一假设正在失效。试想一下，审计员坐在你的工程团队对面，正在审查你们的变更管理控制措施。他们想知道：是谁批准了这次代码变更？审查流程是什么？是否有证据表明具备资质的人员做出了审慎的决定？

Six months ago, the answer was straightforward: here’s the pull request, here’s the review, here are the approvals. Today, the honest answer for many teams is: “We described the problem to Claude, it suggested this implementation, we thought it looked right, and we merged it.” That answer is not covered anywhere in ISO 27001. It barely appears in SOC 2. NIST is only now beginning to grapple with it. And the gap between those frameworks and how engineering teams actually work in 2026 is widening every week. 六个月前，答案很简单：这是合并请求（Pull Request），这是审查记录，这是批准记录。而今天，许多团队诚实的回答是：“我们向 Claude 描述了问题，它建议了这种实现方式，我们觉得没问题，就合并了。” ISO 27001 中没有任何条款涵盖这种回答，SOC 2 中也几乎找不到相关内容，NIST 也是最近才开始着手处理这一问题。这些框架与 2026 年工程团队实际工作方式之间的鸿沟，正每周都在扩大。

What compliance frameworks actually assume

合规框架的实际假设

ISO 27001, SOC 2 Type II, and NIST SP 800-53 were designed with a set of assumptions that seemed self-evident at the time: A human made a decision. That human was authenticated and authorized to make it. The decision was documented — a ticket, a comment, a change record, a signature. If something went wrong, you could trace back to who decided what. ISO 27001、SOC 2 Type II 和 NIST SP 800-53 在设计时基于一套在当时看来不言自明的假设：决策由人类做出；该人员经过身份验证并获得授权；决策有据可查——如工单、评论、变更记录或签名。如果出现问题，可以追溯到是谁做出了什么决定。

These frameworks are not wrong. They describe exactly the kind of accountability that responsible engineering requires. The problem is not the principles — it’s that they were operationalized around human workflows. Every control, every audit procedure, every evidence request assumes the actor was a person who left a recognizable trail. 这些框架本身并没有错。它们准确地描述了负责任的工程实践所要求的问责制。问题不在于原则，而在于它们是围绕人类工作流程来实施的。每一项控制、每一道审计程序、每一份证据请求，都假设操作者是一个留下了可识别痕迹的人。

AI coding tools are not authenticated. They don’t sign commits. They don’t have a name in your issue tracker. The conversation that produced a significant architectural decision might exist for exactly as long as the browser tab stays open. When an organization gets ISO 27001 certified or completes a SOC 2 Type II audit, the auditors are certifying a snapshot: as of this date, these controls were in place. What they are increasingly unable to assess is whether those controls account for the AI sessions happening every day in the engineering org. AI 编程工具无法进行身份验证。它们不会签署提交记录，在你的问题追踪系统中也没有名字。产生重大架构决策的对话，可能只存在于浏览器标签页打开的那段时间。当一个组织获得 ISO 27001 认证或完成 SOC 2 Type II 审计时，审计员认证的是一个快照：即截至该日期，这些控制措施是到位的。但他们越来越难以评估的是，这些控制措施是否涵盖了工程组织中每天都在发生的 AI 会话。

Three gaps that are already present

已经存在的三个缺口

1. Change management evidence SOC 2 CC6.6 requires that changes to infrastructure and software are authorized, tested, and documented before deployment. Most interpretations of this control assume a human reviewer in the loop who exercised judgment. When an AI tool suggests and partially writes a change, the question becomes: what is the evidence of review? “A developer approved the PR” is technically true. But if that review consisted of reading an AI-generated summary of the AI’s own change, is that the control your auditor is certifying? What judgment was actually exercised, and by whom? 1. 变更管理证据 SOC 2 CC6.6 要求基础设施和软件的变更在部署前必须经过授权、测试和记录。对该控制的大多数解读都假设流程中存在行使判断力的人类审查员。当 AI 工具建议并部分编写了变更时，问题就变成了：审查的证据是什么？“开发人员批准了 PR”在技术上是事实。但如果审查过程仅仅是阅读 AI 对其自身变更生成的摘要，这还是审计员所认证的控制吗？到底行使了什么判断力，由谁行使的？

2. Audit trails and session records NIST SP 800-53 AU-2 through AU-12 cover audit and accountability: what events are logged, how records are retained, and how they can be reconstructed for investigation. By default, none of your AI coding sessions are covered by any of this. The conversation where you asked your AI assistant to redesign the authentication flow, the session where you refactored database access patterns, the task that generated your API client library — these produced real changes to production systems, and they leave no audit record whatsoever. 2. 审计追踪与会话记录 NIST SP 800-53 AU-2 到 AU-12 涵盖了审计和问责制：记录哪些事件、如何保留记录以及如何重建记录以供调查。默认情况下，你的 AI 编程会话都不在这些范围内。你要求 AI 助手重新设计身份验证流程的对话、重构数据库访问模式的会话、生成 API 客户端库的任务——这些都对生产系统产生了实际变更，却没有任何审计记录。

3. Data handling and third-party disclosure GDPR Article 30 requires records of processing activities. ISO 27001 Annex A.15 covers supplier relationships and information security in them. In practice, developers regularly paste production schemas, error logs with user context, and system architecture details into AI prompts to get better answers. Some organizations have explicit policies against this. Most do not. Even where policies exist, enforcement is near-zero because there is no log of what was shared and when. 3. 数据处理与第三方披露 GDPR 第 30 条要求保留处理活动的记录。ISO 27001 附录 A.15 涵盖了供应商关系及其信息安全。在实践中，开发人员经常将生产环境架构、包含用户上下文的错误日志以及系统架构细节粘贴到 AI 提示词中以获得更好的答案。一些组织有明确的禁止政策，但大多数没有。即使有政策，执行力也几乎为零，因为没有关于何时共享了什么内容的日志。

What organizations are doing — and what’s missing

组织正在采取的措施——以及缺失的部分

Prohibition: Some organizations have banned AI coding tools entirely. This is understandable and also losing ground. The productivity differential is real, and enforcement on personal devices is functionally impossible.
Policy without enforcement: More common: “Don’t paste customer data into AI tools” lives in the acceptable use policy. There is no technical control, no session record, no way to verify.
Output review: Some teams have added AI-specific code review steps. This partially addresses change management but doesn’t touch data handling or audit trail requirements.
What’s mostly absent: Any systematic approach to capturing what AI tools did, what context they received, and what decisions they influenced.
禁止： 一些组织完全禁止了 AI 编程工具。这可以理解，但也正在失去阵地。生产力的差异是客观存在的，且在个人设备上执行禁令在功能上是不可能的。
有政策无执行： 更常见的情况是：“不要将客户数据粘贴到 AI 工具中”出现在可接受使用政策中。但没有技术控制，没有会话记录，也无法验证。
输出审查： 一些团队增加了针对 AI 的代码审查步骤。这在一定程度上解决了变更管理问题，但未触及数据处理或审计追踪要求。
缺失的部分： 任何系统性地捕获 AI 工具做了什么、接收了什么上下文以及影响了哪些决策的方法。

What needs to change — at two speeds

需要改变的地方——以两种速度进行

The slow track: framework updates ISO and NIST revision cycles are measured in years. The NIST AI Risk Management Framework is a meaningful step, but it is not yet integrated into how SP 800-53 controls are assessed in standard audits. Building your compliance strategy around waiting for it is not a viable approach. 慢车道：框架更新 ISO 和 NIST 的修订周期以年为单位。NIST AI 风险管理框架是一个有意义的步骤，但尚未整合到标准审计中对 SP 800-53 控制的评估方式中。围绕等待框架更新来制定合规策略是不可行的。

The fast track: interim controls Treat AI sessions as auditable activity. Decide — explicitly — whether AI coding sessions are in scope. 快车道：临时控制措施 将 AI 会话视为可审计的活动。明确决定 AI 编程会话是否在合规范围内。