2026年9月30日 · KI · Automatisierung · Regulatorik · Mittelstand

无人看见的审批

一项审批可能完全按计划运作，却仍然长时间无人察觉地处于等待状态。为什么自动化和 AI 智能体中的等待状态需要受到监控。

把任务交给自动化流程或 AI 智能体的人，会在关键环节安排一个人：在一项变更投入生产之前、在数据离开公司之前，或在某件事变得无法撤销之前，必须有人同意。这一原则是正确的，各类规范也都采纳了它。但这类审批有一个特性很少被谈及：只要没人去看，它们就是不可见的。

一个典型场景

假设一个自动化流程——一次数据同步、一次软件推送、一次权限变更——走到了需要人工审批的步骤。这些步骤等待了许多个小时，无人察觉。没有任何东西坏掉。审批关卡完全按照其设计在运作：它停下来，等待。失灵的唯独是它的可见性。

原因是结构性的。一个以阻塞方式等待审批的进程，通常不会自己发出提醒——毕竟它被阻塞了。从外部看，一个正在等待的进程就像一个安静的进程：没有错误信息，没有告警，没有输出。不专门去查看的人，会把这份安静当作正常运行，或者当作某个仍在进行中的工作步骤。而本该给出审批的人，可能甚至不知道有审批待处理——请求停留在一个此刻没有人打开的界面里。

这类等待时间通常要到事后才会显现，即有人分析日志时间戳的时候。由此还可以得出第二点：如果没有这些时间戳，连等待时间的量级都无从知晓——只剩下一个模糊的印象，觉得“这次花的时间长了一点”。

规范如何理解人的监督

欧洲 AI 法规（法规（EU）2024/1689）第 14 条规定了对高风险 AI 系统的人的监督。这些系统应当设计成能够让自然人在其使用期间对其进行有效监督。第 4 款列举了进行监督的人员应当具备哪些能力。其中包括：监控运行，以发现异常、功能失常和意外表现；同样包括“始终意识到可能存在自动地或过度地依赖高风险 AI 系统所产生输出的倾向（‘自动化偏见’）”（„sich einer möglichen Neigung zu einem automatischen oder übermäßigen Vertrauen in die von einem Hochrisiko-KI-System hervorgebrachte Ausgabe (‚Automatisierungsbias‘) bewusst zu bleiben“）；忽略、推翻或撤销输出；以及“干预高风险 AI 系统的运行，或通过‘停止按钮’或类似程序中断系统运行”（„in den Betrieb des Hochrisiko-KI-Systems einzugreifen oder den Systembetrieb mit einer ‚Stopptaste‘ oder einem ähnlichen Verfahren zu unterbrechen“）。

某个具体系统是否适用这一规定，是一个需要在个案中进行分类的问题。即便在该法规不适用的地方，这一思路也可以作为衡量标准。

NIST AI 风险管理框架（AI RMF 1.0，2023 年 1 月）将其表述为一项组织任务：人的监督流程应当得到定义、评估和记录（MAP 3.5），人与 AI 协作中的角色和职责应当清晰划分（GOVERN 3.2）。该框架还指出，收集有关人在多大频率上、出于何种原因否决已部署 AI 系统输出的数据，可能是有益的。

两份文本都预设，人在需要的时候就在那里。人如何及时得知这一需要，则是落实层面的事——而这恰恰是上述场景中的缺口所在。

等待是一种必须受到监控的状态

从这一场景中可以推导出四条规则。它们适用于脚本、流水线和工作流工具，也同样适用于 AI 智能体——而且一个流程越是自主运行，就越是适用，因为越少有人在一旁看着。

“等待审批”成为一种独立的、受监控的状态。 附带请求提出的时间、一个约定的阈值，以及超出阈值时的告警。告警发给一个指定的、配有代理人的岗位，而不是发到一个没人读的邮箱。由于以阻塞方式等待的进程通常不会自己发出提醒，必须由另一方来查询这一状态——监控来自外部。阈值取决于这一步骤之后有什么在等着：一项夜间例行任务可以容忍数小时，一项整个团队都在等待的变更则不行。

需要审批的步骤在触发之前就要预告。 知道几分钟后需要做出同意的人，会去看一眼。给审批人发一条简短的消息不费任何成本——而且这是进程在被阻塞之前还能自己发出的最后一条消息。

需要审批的步骤放到最后。 如果它位于流程中间，那么其后的一切都会跟着等待——包括根本不需要审批的工作。放在最后，它只会阻塞它自己。做不到这一点时，独立的步骤应当事先完成，或并行继续推进。

等待时间要测量，而不是估计。 请求开始的时间和做出决定的时间都记录在日志中；两者之差是一个可以分析的指标。这与 NIST 框架关于收集人为干预数据的提示相一致：不去测量监督实际上是如何发生的人，就不知道监督是否在发生。

审批过多同样不是监督

对一项被忽视的审批，最直接的反应是增加更多控制。这只会转移问题。一个每天要确认十次的人，迟早会不看就确认。审批沦为走形式，监督只存在于纸面上——这正是第 14 条所描述的那种自动化偏见，只不过高了一个层级。

这种模式在告警领域早已为人熟知。BSI 在 IT 基本保护模块 DER.1 中将以下情况描述为一种威胁：告警设置不当时，误报可能增多；相关负责人随后“可能再也无法区分误报与安全相关事件”，并可能无法足够迅速地注意到告警信息。审批同样如此。Google 的 SRE 一书为告警提出了一条可以借鉴的原则：“每一次呼叫都应当是可操作的。”（“Every page should be actionable.”）一项审批人无需做出任何决定的审批，就不是审批。

另一个极端——完全没有审批——同样不是解决办法。目标是少而有意义的审批。适合的候选包括：无法可靠撤回的步骤、影响超出自身职责范围的步骤、涉及数据离开公司的步骤，或涉及授予权限的步骤。凡是能够干净回滚、且其结果会被自动检查的操作，通常不需要在其之前安排一个人，而需要在其之后安排一项检查。

自动化中审批的检查清单

  • 每一项审批都有一位指定的负责人，并配有代理人。
  • “等待审批”状态是可见的，设有阈值，并会触发告警。
  • 审批在进程被阻塞之前就已预告。
  • 需要审批的步骤在流程中尽可能靠后。
  • 等待时间和决定都有日志记录，并定期分析。
  • 针对待处理审批的告警至少被测试性地触发过一次，并且确实送达了。
  • 定期审查审批清单，检查每一项审批是否仍然发挥其作用。

sector7 如何提供支持

我们与您一起梳理贵企业的 AI 使用在 EU AI Act 下会引发什么，并确定风险分类、记录义务和明确的职责——详情请见主权 AI。对于受托管的环境，我们的 NOC 全天候自动化监控；发现的异常按合同约定的流程处理，具体见托管服务与支持。

来源

让我们聊聊您的具体情况。

预约洽谈+49 212 240915 0