尧图网页设计 
AI 进入企业之后有一句话正在迅速成为最常见的安全保证我们有人类在环。这句话几乎适用于所有场合。AI 可以生成内容但最后有人审核Agent 可以发起动作但关键步骤需要人工批准系统可以自动运行但遇到高风险操作会弹出一个确认框。这套设计听起来非常合理因为它符合一个几乎不需要解释的直觉——机器可以自动化但最后的决定权仍然在人。问题在于有人在场和人拥有决定权其实是两件完全不同的事情。2026 年 9 月 3 日CIO 刊登了记者 Grant Gross 的一篇报道题为When AIs human in the loop really isnt。Cloudflare 攻击性安全负责人 Doug Shepherd 在文中提出了一个相当尖锐的判断如果一个人只能发现问题、标记问题却不能真正阻止动作发生那么这并不是真正的 Human-in-the-Loop而更接近 Human Adjacent to the Loop。他把这种现象称为 performative governance——表演式治理。他还补充了一句更值得管理者警惕的话这套说法帮助项目获得批准它完成的往往是政治工作而不是风险工作。这个判断值得认真对待因为很多企业今天拥有的可能并不是 Human-in-the-Loop而只是 Human-next-to-the-Loop。人坐在系统旁边看着它运行收到它的通知甚至拥有一个醒目的红色按钮。但有一个真正的问题始终没有被回答当人说不的时候现实真的会停下来吗一、HUMAN-IN-THE-LOOP 已经从一种设计变成了一句安慰Human-in-the-Loop 最初是一个非常具体的系统设计概念。机器处理大部分工作在机器能力不足、风险较高或者需要价值判断的位置由人介入。它的核心从来不是有人而是某些决定必须经过人才能继续发生。这里的关键词是必须它描述的是一种技术上的强制关系而不是一种组织上的姿态。但随着 AI Governance 成为企业议题这个词开始发生一种微妙的变化。它越来越像一句组织层面的安全声明。当管理层问 AI 出错怎么办回答是有人审核当合规部门问 Agent 会不会做出错误操作回答是关键动作需要人工确认当董事会问我们如何保证 AI 不会失控回答仍然是 Human-in-the-Loop。同一个短语在不同层级被反复引用久而久之有人本身就变成了安全证明。这其实偷换了一个概念Human Presence 不等于 Human Authority。一个人能够看到系统发生了什么不代表他能够改变系统正在发生什么。能够收到告警不代表能够阻止执行能够点击 Reject不代表 Reject 最终会被执行端接受能够发送 Override也不代表下游系统必须服从这个 Override。这四层落差中的任何一层断裂整条控制链都不再成立而从组织架构图上完全看不出这种断裂。于是一个看上去拥有完整人工治理流程的系统在真正的权力结构上可能仍然是AI 决定系统执行人类旁观。二、真正的问题不是有没有人而是谁能让事情发生如果 Human Presence 不足以构成控制那么下一个问题就变得不可回避控制究竟由什么构成。在同一篇报道中AI 集成平台厂商 AISquared 的 CEO 兼总裁 Darren Kimura 给出了一组非常实际的检查问题。他认为多数声称拥有 Human-in-the-Loop 的公司实际拥有的只是一个看着 Loop 的人——这个人能看到决定也能标记疑虑但无法停止、修改、拒绝或者升级它。因此 IT 负责人应该反复追问审核者能不能在动作生效以前停止它能不能修改结果他们的 Override 是否会被下游系统真正记录并强制执行只要其中任何一个答案是否定的这个人做的事情就只是监视 AI。这几个问题表面上是在检查流程实际上是在检查另外一样东西Authority。我们过去很容易把 Authority 和 Permission 混在一起。一个人拥有审批权限于是我们自然认为他拥有最终决定权。但数字系统里的真正权力并不取决于 UI 上有没有一个 Approve 或 Reject 按钮而取决于一个更加底层的事实——谁能够改变系统最终的状态。这种落差在现实中随处可见。一个风控人员可以在 Dashboard 里拒绝一笔交易但如果拒绝之后执行系统仍然可以通过另一条 API 把交易发出去那么他拥有的是界面权限而不是执行权。一个安全人员可以要求 Agent 停止但如果指令已经进入异步任务队列而下游系统并不负责撤销这个动作那么这个 Stop 只是一个请求。一个管理员可以撤销 Agent 的某项权限但如果一个已经签发的 Token 仍然有效十分钟那么在这十分钟里现实中的 Authority 仍然留在旧系统手中。这三个场景的共同点在于人的意志都被完整地表达了也都被系统忠实地记录了唯独没有被执行链所服从。所以判断 Human-in-the-Loop 是否真实存在不能看组织架构图不能看 Dashboard甚至不能只看审批流程。真正应该问的是当人类和自动系统发生冲突的时候最终谁能让现实结果发生谁拥有这个能力Authority 就在哪里。三、一个红色按钮本身不是安全机制Authority 之所以经常被误判是因为软件行业很容易产生一种 UI 幻觉只要界面上出现了一个明确的操作入口我们就会下意识认为背后存在相应的控制能力。Pause Agent、Reject、Emergency Stop、Override这些词天然带有控制感。它们被设计成红色、加粗、需要二次确认视觉语言不断强化这是最后一道防线的印象。但按钮只是表达意图的入口它并不是 Authority 本身。真正的 Authority 必须沿着按钮继续向下追问按下之后发生了什么请求送给谁谁负责验证谁有权拒绝这个请求已经进入队列的动作会不会被撤销已经生成的 Credential 是否立刻失效执行节点是否必须服从还是可以选择性忽略如果网络断开会怎样如果被调用的 SaaS 本身已经异常会怎样如果 Agent 还能找到另一条执行路径又会怎样只有当最后一个真正改变现实状态的组件仍然必须服从这次 Reject这个红色按钮才拥有真正意义上的停止权。否则它只是一个非常漂亮的意见表达器。这也是为什么企业 AI 治理真正困难的部分正在从界面、流程和 Policy向更底层的系统结构移动。因为 Policy 说不允许与系统事实上无法执行中间存在巨大的差别。前者是一条规则后者才是一条边界。规则依赖服从而边界不需要服从。规则可以被绕过、被例外、被遗忘边界只在被拆掉的时候才会消失。企业真正需要确认的是自己手里握着的究竟是哪一种。四、即使人真的拥有 AUTHORITY还有另一个更难的问题现在不妨做一个乐观的假设前面所有技术问题都被解决了。审核人员确实能够停止 AgentReject 能够向下传播Override 能够真正改变执行结果。Human-in-the-Loop 是不是就可靠了仍然不是。因为还有一个更加古老的问题人类的注意力。AI 保障公司 TrustScale 的 COO 兼 CTO Eric Billingsley 在同一篇报道中描述了一个很有意思的场景如果一个系统 95% 的时间都是正确的那么这个人的工作就变成了等待那少数出错的时刻。而人并不擅长长时间监视一个高度可靠的自动系统随着正确结果不断重复Review 最终会退化成 Confirmation。他还给出了一个更进一步的判断一套好的 AI 系统可以制造出一套糟糕的人工控制——当真正的例外出现时审核者很可能会批准它因为此前数百次正确的推荐已经把他训练成了信任者。Akamai 的 EVP 兼 CTO Robert Blumofe 观察到了同样的现象。他认为大模型输出正确结果的频率恰好高到足以让人产生一种自满的错觉以为它比实际更可靠在认真检查若干次却始终没有发现错误之后认真本身会衰减Human-in-the-Loop 于是变成机械式的例行批准。这个过程非常符合人的行为方式。第一次认真阅读第二次认真检查第十次快速确认第一百次扫一眼第一千次直接 Approve。真正危险的地方在于系统越可靠这种退化反而越容易发生。如果一个系统每十次就错一次人会保持高度警觉但如果它连续正确了 999 次那么第 1000 次错误出现的时候人可能已经不再真正进行判断。一个越来越可靠的自动系统可能训练出一个越来越不可靠的人类监督者。这不是人的道德问题而是人的认知结构决定的。持续注意力是一种稀缺资源而现代自动化系统却在试图把这种稀缺资源当成一种可以无限供应的安全组件。五、APPROVAL FATIGUE 的本质是把人当成了实时安全设备企业内部讨论 Approval Fatigue 时通常会把它理解为一个效率问题审批太多员工太累流程太慢所以需要减少审批环节。这种理解并不算错但它把一个结构问题降级成了一个体验问题。如果从系统设计的角度看Approval Fatigue 其实是一种安全架构缺陷。因为它意味着系统正在要求一个人持续在线、持续理解上下文、持续保持注意力、持续识别异常、持续独立判断并且在极短时间内正确处理大量高度重复的动作。换句话说我们正在试图把人设计成一种高可靠的实时 Guardrail。但人类从来就不适合承担这种角色。人的优势在于理解复杂语境、处理真正的新情况、制定目标、判断价值冲突、承担责任以及在模糊世界里作出取舍人的劣势恰恰是每分钟重复检查同一种事情几百次。把人放在后一种位置上等于用一个人最不稳定的能力去支撑整个系统最关键的假设。Billingsley 提出的一个建议因此格外重要Human-in-the-Loop 应该像其他安全控制一样被对待——它必须被监控、被测试并且能够产出证明它按预期运行的证据。一条显示某人点击了 Approve 的日志远远不够真正需要的证据是这个人当时具备必要的上下文作出了独立判断并且拥有推翻 AI 的权限。这三件事一旦无法被证明审批记录就只是活动记录而不是控制记录。所以如果一套 AI 系统每天产生一万个动作而安全架构要求人在每个动作之前完成一次认真判断那么问题并不是需要更多审核人员。真正的问题是这套系统把人放错了位置。六、HUMAN-IN-THE-LOOP 可能需要变成 HUMAN-OVER-THE-LOOP位置错了就需要重新安排位置而不是取消这个角色。未来真正可靠的自动化系统恰恰需要重新定义人在其中的位置。它不再是AI 做一个决定 → 人点击一次 → AI 执行这样的线性结构而更接近另一种安排人定义边界系统判断动作是否处于边界之内独立机制负责强制执行这条边界人只处理真正的例外。Blumofe 在报道中给出的建议正指向这个方向。他认为企业需要让 non-AI 系统承担 Guardrail 的角色由这些技术工具自动完成对 AI 输出的测试与验证、标记问题并且拥有暂停 AI 工作的能力从而把人从逐笔审批的循环中解放出来同时降低风险。这是一个非常重要的方向变化因为它把可靠性的来源从人的状态转移到了结构的属性。人类的价值不再来自不停点击 Approve而是来自定义什么可以发生什么绝不能发生哪些条件必须成立什么情况必须升级哪些例外需要重新进入人的判断。于是人从 Loop 里面的一颗按钮变成 Loop 上方规则的制定者。某种意义上这才是真正意义上的 Human Control——它不要求人类亲手控制每一次动作而是让自动系统只能在人类预先定义、并且无法轻易绕过的边界之内行动。值得强调的是这条路径的重点不在于减少人的参与而在于改变企业信任的对象。过去我们信任的是一个可信的人他有经验有责任心会在关键时刻踩下刹车。今后我们必须信任的是一个可信的结构即使那个人疲惫、分心、被误导甚至根本不在场某些动作依然无法发生。治理的成熟是从依赖可信的人走向依赖可信的结构。七、未来 AI GOVERNANCE 最重要的问题可能不是谁批准了一旦控制的重心从逐笔审批转向边界定义审计的问题本身也必须随之改写。过去很多企业系统的审计逻辑都围绕同一个问题Who approved it谁批准了这件事这个问题在人的时代非常合理因为执行频率有限很多重要动作确实可以逐笔追溯到一个具体的人而这个人的签字既是控制点也是责任点。但 Agent 改变了这个前提。一个 Agent 可能在一分钟里执行几百个动作多个 Agent 可以彼此调用一个动作又可能触发另外几十个动作。在这种密度下如果我们仍然要求人为每一个动作提供一次实时确认最终得到的很可能不是更好的治理而是一座巨大的审批工厂——它消耗真实的人力产出大量看起来合规的记录却几乎不产生任何真实的判断。所以更重要的问题会慢慢变成Under what boundary was this allowed to happen这件事是在什么边界条件下被允许发生的那个边界是谁定义的输入是否满足条件执行对象是否与原始意图一致中途状态有没有发生变化条件失效以后动作还能不能继续系统有没有能力在边界被突破以前阻止它这套逻辑与传统审批最大的不同在于责任的落点。它并没有让人退出治理而是把人的责任从逐次行使 Authority前移到定义 Authority 的范围。当一个动作出了问题追问的对象不再只是那个点击按钮的人而是那条允许它发生的边界以及负责让这条边界生效的机制。这是自动化真正成熟以后必然发生的一次变化。八、最危险的不是 AI 没有人监督而是我们误以为它有人监督回到最初的那个问题就会发现真正令人担心的系统未必是完全无人监管的系统。对于一个明确无人值守、全自动运行的系统我们至少知道风险在哪里也知道自己在承担什么。更加危险的是另一种系统Dashboard 上有人日志里有人审批记录里有人事故复盘时也一定能找到一个名字。于是所有人都相信人在控制。但真正沿着执行链一路向下追踪之后却会发现那个所谓的人类控制从未真正成为系统必须服从的技术事实。这才是 Human-next-to-the-Loop 最值得警惕的地方它提供了控制的感觉却没有提供控制的结构。而一个系统是否真正受到控制从来不取决于谁坐在屏幕前最终只取决于一件事——当某个动作不应该发生的时候究竟有没有一种力量可以让它真的无法发生。Kimura 在文章最后提醒目标从来不是把人塞进每一个 AI 决定而是把合适的人带着足够的上下文和真实的权限放在流程中正确的位置上。这句话的重量全部落在真实的权限上。所以也许未来我们不应该再满足于问Is there a human in the loop而应该继续追问Where is the authority因为人类在场并不意味着人类拥有最后决定权。真正重要的从来不是人是否在 Loop 里而是 Authority 是否在正确的位置。 Havenlon | 杂谈：从可信的人到可信的结构：Human-in-the-Loop 的下一次迁移
AI 进入企业之后有一句话正在迅速成为最常见的安全保证我们有人类在环。这句话几乎适用于所有场合。AI 可以生成内容但最后有人审核Agent 可以发起动作但关键步骤需要人工批准系统可以自动运行但遇到高风险操作会弹出一个确认框。这套设计听起来非常合理因为它符合一个几乎不需要解释的直觉——机器可以自动化但最后的决定权仍然在人。问题在于有人在场和人拥有决定权其实是两件完全不同的事情。2026 年 9 月 3 日CIO 刊登了记者 Grant Gross 的一篇报道题为When AIs human in the loop really isnt。Cloudflare 攻击性安全负责人 Doug Shepherd 在文中提出了一个相当尖锐的判断如果一个人只能发现问题、标记问题却不能真正阻止动作发生那么这并不是真正的 Human-in-the-Loop而更接近 Human Adjacent to the Loop。他把这种现象称为 performative governance——表演式治理。他还补充了一句更值得管理者警惕的话这套说法帮助项目获得批准它完成的往往是政治工作而不是风险工作。这个判断值得认真对待因为很多企业今天拥有的可能并不是 Human-in-the-Loop而只是 Human-next-to-the-Loop。人坐在系统旁边看着它运行收到它的通知甚至拥有一个醒目的红色按钮。但有一个真正的问题始终没有被回答当人说不的时候现实真的会停下来吗一、HUMAN-IN-THE-LOOP 已经从一种设计变成了一句安慰Human-in-the-Loop 最初是一个非常具体的系统设计概念。机器处理大部分工作在机器能力不足、风险较高或者需要价值判断的位置由人介入。它的核心从来不是有人而是某些决定必须经过人才能继续发生。这里的关键词是必须它描述的是一种技术上的强制关系而不是一种组织上的姿态。但随着 AI Governance 成为企业议题这个词开始发生一种微妙的变化。它越来越像一句组织层面的安全声明。当管理层问 AI 出错怎么办回答是有人审核当合规部门问 Agent 会不会做出错误操作回答是关键动作需要人工确认当董事会问我们如何保证 AI 不会失控回答仍然是 Human-in-the-Loop。同一个短语在不同层级被反复引用久而久之有人本身就变成了安全证明。这其实偷换了一个概念Human Presence 不等于 Human Authority。一个人能够看到系统发生了什么不代表他能够改变系统正在发生什么。能够收到告警不代表能够阻止执行能够点击 Reject不代表 Reject 最终会被执行端接受能够发送 Override也不代表下游系统必须服从这个 Override。这四层落差中的任何一层断裂整条控制链都不再成立而从组织架构图上完全看不出这种断裂。于是一个看上去拥有完整人工治理流程的系统在真正的权力结构上可能仍然是AI 决定系统执行人类旁观。二、真正的问题不是有没有人而是谁能让事情发生如果 Human Presence 不足以构成控制那么下一个问题就变得不可回避控制究竟由什么构成。在同一篇报道中AI 集成平台厂商 AISquared 的 CEO 兼总裁 Darren Kimura 给出了一组非常实际的检查问题。他认为多数声称拥有 Human-in-the-Loop 的公司实际拥有的只是一个看着 Loop 的人——这个人能看到决定也能标记疑虑但无法停止、修改、拒绝或者升级它。因此 IT 负责人应该反复追问审核者能不能在动作生效以前停止它能不能修改结果他们的 Override 是否会被下游系统真正记录并强制执行只要其中任何一个答案是否定的这个人做的事情就只是监视 AI。这几个问题表面上是在检查流程实际上是在检查另外一样东西Authority。我们过去很容易把 Authority 和 Permission 混在一起。一个人拥有审批权限于是我们自然认为他拥有最终决定权。但数字系统里的真正权力并不取决于 UI 上有没有一个 Approve 或 Reject 按钮而取决于一个更加底层的事实——谁能够改变系统最终的状态。这种落差在现实中随处可见。一个风控人员可以在 Dashboard 里拒绝一笔交易但如果拒绝之后执行系统仍然可以通过另一条 API 把交易发出去那么他拥有的是界面权限而不是执行权。一个安全人员可以要求 Agent 停止但如果指令已经进入异步任务队列而下游系统并不负责撤销这个动作那么这个 Stop 只是一个请求。一个管理员可以撤销 Agent 的某项权限但如果一个已经签发的 Token 仍然有效十分钟那么在这十分钟里现实中的 Authority 仍然留在旧系统手中。这三个场景的共同点在于人的意志都被完整地表达了也都被系统忠实地记录了唯独没有被执行链所服从。所以判断 Human-in-the-Loop 是否真实存在不能看组织架构图不能看 Dashboard甚至不能只看审批流程。真正应该问的是当人类和自动系统发生冲突的时候最终谁能让现实结果发生谁拥有这个能力Authority 就在哪里。三、一个红色按钮本身不是安全机制Authority 之所以经常被误判是因为软件行业很容易产生一种 UI 幻觉只要界面上出现了一个明确的操作入口我们就会下意识认为背后存在相应的控制能力。Pause Agent、Reject、Emergency Stop、Override这些词天然带有控制感。它们被设计成红色、加粗、需要二次确认视觉语言不断强化这是最后一道防线的印象。但按钮只是表达意图的入口它并不是 Authority 本身。真正的 Authority 必须沿着按钮继续向下追问按下之后发生了什么请求送给谁谁负责验证谁有权拒绝这个请求已经进入队列的动作会不会被撤销已经生成的 Credential 是否立刻失效执行节点是否必须服从还是可以选择性忽略如果网络断开会怎样如果被调用的 SaaS 本身已经异常会怎样如果 Agent 还能找到另一条执行路径又会怎样只有当最后一个真正改变现实状态的组件仍然必须服从这次 Reject这个红色按钮才拥有真正意义上的停止权。否则它只是一个非常漂亮的意见表达器。这也是为什么企业 AI 治理真正困难的部分正在从界面、流程和 Policy向更底层的系统结构移动。因为 Policy 说不允许与系统事实上无法执行中间存在巨大的差别。前者是一条规则后者才是一条边界。规则依赖服从而边界不需要服从。规则可以被绕过、被例外、被遗忘边界只在被拆掉的时候才会消失。企业真正需要确认的是自己手里握着的究竟是哪一种。四、即使人真的拥有 AUTHORITY还有另一个更难的问题现在不妨做一个乐观的假设前面所有技术问题都被解决了。审核人员确实能够停止 AgentReject 能够向下传播Override 能够真正改变执行结果。Human-in-the-Loop 是不是就可靠了仍然不是。因为还有一个更加古老的问题人类的注意力。AI 保障公司 TrustScale 的 COO 兼 CTO Eric Billingsley 在同一篇报道中描述了一个很有意思的场景如果一个系统 95% 的时间都是正确的那么这个人的工作就变成了等待那少数出错的时刻。而人并不擅长长时间监视一个高度可靠的自动系统随着正确结果不断重复Review 最终会退化成 Confirmation。他还给出了一个更进一步的判断一套好的 AI 系统可以制造出一套糟糕的人工控制——当真正的例外出现时审核者很可能会批准它因为此前数百次正确的推荐已经把他训练成了信任者。Akamai 的 EVP 兼 CTO Robert Blumofe 观察到了同样的现象。他认为大模型输出正确结果的频率恰好高到足以让人产生一种自满的错觉以为它比实际更可靠在认真检查若干次却始终没有发现错误之后认真本身会衰减Human-in-the-Loop 于是变成机械式的例行批准。这个过程非常符合人的行为方式。第一次认真阅读第二次认真检查第十次快速确认第一百次扫一眼第一千次直接 Approve。真正危险的地方在于系统越可靠这种退化反而越容易发生。如果一个系统每十次就错一次人会保持高度警觉但如果它连续正确了 999 次那么第 1000 次错误出现的时候人可能已经不再真正进行判断。一个越来越可靠的自动系统可能训练出一个越来越不可靠的人类监督者。这不是人的道德问题而是人的认知结构决定的。持续注意力是一种稀缺资源而现代自动化系统却在试图把这种稀缺资源当成一种可以无限供应的安全组件。五、APPROVAL FATIGUE 的本质是把人当成了实时安全设备企业内部讨论 Approval Fatigue 时通常会把它理解为一个效率问题审批太多员工太累流程太慢所以需要减少审批环节。这种理解并不算错但它把一个结构问题降级成了一个体验问题。如果从系统设计的角度看Approval Fatigue 其实是一种安全架构缺陷。因为它意味着系统正在要求一个人持续在线、持续理解上下文、持续保持注意力、持续识别异常、持续独立判断并且在极短时间内正确处理大量高度重复的动作。换句话说我们正在试图把人设计成一种高可靠的实时 Guardrail。但人类从来就不适合承担这种角色。人的优势在于理解复杂语境、处理真正的新情况、制定目标、判断价值冲突、承担责任以及在模糊世界里作出取舍人的劣势恰恰是每分钟重复检查同一种事情几百次。把人放在后一种位置上等于用一个人最不稳定的能力去支撑整个系统最关键的假设。Billingsley 提出的一个建议因此格外重要Human-in-the-Loop 应该像其他安全控制一样被对待——它必须被监控、被测试并且能够产出证明它按预期运行的证据。一条显示某人点击了 Approve 的日志远远不够真正需要的证据是这个人当时具备必要的上下文作出了独立判断并且拥有推翻 AI 的权限。这三件事一旦无法被证明审批记录就只是活动记录而不是控制记录。所以如果一套 AI 系统每天产生一万个动作而安全架构要求人在每个动作之前完成一次认真判断那么问题并不是需要更多审核人员。真正的问题是这套系统把人放错了位置。六、HUMAN-IN-THE-LOOP 可能需要变成 HUMAN-OVER-THE-LOOP位置错了就需要重新安排位置而不是取消这个角色。未来真正可靠的自动化系统恰恰需要重新定义人在其中的位置。它不再是AI 做一个决定 → 人点击一次 → AI 执行这样的线性结构而更接近另一种安排人定义边界系统判断动作是否处于边界之内独立机制负责强制执行这条边界人只处理真正的例外。Blumofe 在报道中给出的建议正指向这个方向。他认为企业需要让 non-AI 系统承担 Guardrail 的角色由这些技术工具自动完成对 AI 输出的测试与验证、标记问题并且拥有暂停 AI 工作的能力从而把人从逐笔审批的循环中解放出来同时降低风险。这是一个非常重要的方向变化因为它把可靠性的来源从人的状态转移到了结构的属性。人类的价值不再来自不停点击 Approve而是来自定义什么可以发生什么绝不能发生哪些条件必须成立什么情况必须升级哪些例外需要重新进入人的判断。于是人从 Loop 里面的一颗按钮变成 Loop 上方规则的制定者。某种意义上这才是真正意义上的 Human Control——它不要求人类亲手控制每一次动作而是让自动系统只能在人类预先定义、并且无法轻易绕过的边界之内行动。值得强调的是这条路径的重点不在于减少人的参与而在于改变企业信任的对象。过去我们信任的是一个可信的人他有经验有责任心会在关键时刻踩下刹车。今后我们必须信任的是一个可信的结构即使那个人疲惫、分心、被误导甚至根本不在场某些动作依然无法发生。治理的成熟是从依赖可信的人走向依赖可信的结构。七、未来 AI GOVERNANCE 最重要的问题可能不是谁批准了一旦控制的重心从逐笔审批转向边界定义审计的问题本身也必须随之改写。过去很多企业系统的审计逻辑都围绕同一个问题Who approved it谁批准了这件事这个问题在人的时代非常合理因为执行频率有限很多重要动作确实可以逐笔追溯到一个具体的人而这个人的签字既是控制点也是责任点。但 Agent 改变了这个前提。一个 Agent 可能在一分钟里执行几百个动作多个 Agent 可以彼此调用一个动作又可能触发另外几十个动作。在这种密度下如果我们仍然要求人为每一个动作提供一次实时确认最终得到的很可能不是更好的治理而是一座巨大的审批工厂——它消耗真实的人力产出大量看起来合规的记录却几乎不产生任何真实的判断。所以更重要的问题会慢慢变成Under what boundary was this allowed to happen这件事是在什么边界条件下被允许发生的那个边界是谁定义的输入是否满足条件执行对象是否与原始意图一致中途状态有没有发生变化条件失效以后动作还能不能继续系统有没有能力在边界被突破以前阻止它这套逻辑与传统审批最大的不同在于责任的落点。它并没有让人退出治理而是把人的责任从逐次行使 Authority前移到定义 Authority 的范围。当一个动作出了问题追问的对象不再只是那个点击按钮的人而是那条允许它发生的边界以及负责让这条边界生效的机制。这是自动化真正成熟以后必然发生的一次变化。八、最危险的不是 AI 没有人监督而是我们误以为它有人监督回到最初的那个问题就会发现真正令人担心的系统未必是完全无人监管的系统。对于一个明确无人值守、全自动运行的系统我们至少知道风险在哪里也知道自己在承担什么。更加危险的是另一种系统Dashboard 上有人日志里有人审批记录里有人事故复盘时也一定能找到一个名字。于是所有人都相信人在控制。但真正沿着执行链一路向下追踪之后却会发现那个所谓的人类控制从未真正成为系统必须服从的技术事实。这才是 Human-next-to-the-Loop 最值得警惕的地方它提供了控制的感觉却没有提供控制的结构。而一个系统是否真正受到控制从来不取决于谁坐在屏幕前最终只取决于一件事——当某个动作不应该发生的时候究竟有没有一种力量可以让它真的无法发生。Kimura 在文章最后提醒目标从来不是把人塞进每一个 AI 决定而是把合适的人带着足够的上下文和真实的权限放在流程中正确的位置上。这句话的重量全部落在真实的权限上。所以也许未来我们不应该再满足于问Is there a human in the loop而应该继续追问Where is the authority因为人类在场并不意味着人类拥有最后决定权。真正重要的从来不是人是否在 Loop 里而是 Authority 是否在正确的位置。