您的 AI 治理计划存在夜班问题

想象一下，一个 AI 工作流在凌晨 2:13 标记了一个异常。系统正好按照治理计划的要求：停止并呼叫人工介入。唯一的问题是，具备决策资格的人员要到上午九点才上班。

在任何超出办公时间的运营中，这一时段差距都至关重要。政策可以指定负责人并绘制清晰的升级路径。但在凌晨 2 点，如果唯一了解该请求或拥有批准权限的人离线，这些都无济于事。

因此，可用性必须体现在控制本身。对于夜间运行的系统，实际问题非常直接：谁负责值班、他们能做出何种决定、需要看到哪些信息、如果无人响应会怎样？答案还必须能够在换班时仍然有效。

监管有时间限制，运营则有多重时段

监管日程为该问题增添了时效性。2026 年 8 月 2 日，欧盟委员会的 AI 办公室和各国监管机构开始执行《AI 法案》的适用条款，并且新的透明度规则生效。

该日期不应被夸大为所有高风险 AI 义务一次性生效的说法。委员会目前的时间表将附件 III 高风险系统的规则定于 2027 年 12 月 2 日，而嵌入受监管产品的高风险 AI 规则则在 2028 年 8 月 2 日之后生效。

更具体的运营视角反而更有价值。治理要求正从政策制定转向强制执行，而被治理的系统已经在夜间、周末和跨时区运行。基于周一至周五组织结构设计的控制最终会碰到周六早晨的异常情况。

许多治理方案并未描述这种情形。它们会指明系统的所有者、用例的批准人以及负责审查风险的委员会。这些决定固然必要，却未告知夜班操作员该交易是否应保持七小时的待处理状态、值班分析师是否可以放行，或在队列持续增长时由谁承担风险。

政策只是一张标有名称的框，而运营则需要有人值班。

人工在环需要排班表

Unite.AI 已经阐明，真正的 验证关卡需要具备有意义的可视性和控制。审阅者必须看到所提议的操作以及系统停止的原因。更重要的是，界面必须让他们能够执行实际操作：批准、修改、拒绝或关闭该流程。

覆盖范围是下一个设计难题。当唯一符合条件的审阅者正处于睡眠、休假或在另一个地区工作且没有正式交接时，即使是精心设计的审阅界面也无济于事。

这正是“人工在环”这一表述过于模糊的地方。它可能掩盖多种不同的岗位。工作流所有者负责流程的运行方式，而当班审阅者负责解释异常并收集缺失的上下文。主题专家评估领域风险。批准者拥有批准、修改或终止所提议操作的权限。当异常指示更大范围的故障时，事件负责人则协调响应。

合并角色并非必然是问题。在低风险工作流中，这可能是最简洁的安排。但必须将其记录下来。即便分析师了解模型输出，他仍可能没有权限放行大额付款、覆盖安全限制或批准影响客户的操作。

NIST AI 风险管理框架 在此非常有用，因为它将治理视为一种运营结构。其 Govern（治理）功能要求明确的角色、职责和沟通渠道，并赋予合适人员权力、责任和培训。它还要求对人工监督流程进行定义、评估和记录。仅说“会有人审查”并未达到这种清晰度的标准。

在警报出现前确定“合格”的含义

值班并不等同于具备决策准备。即使他们对业务流程了如指掌，也可能缺乏判断该模型异常的依据。

资格应针对具体决策进行定义，而非笼统的职位头衔。组织可能要求审阅者了解工作流的目的、系统展示的证据、模型的限制、相关政策阈值以及每种可选操作的后果。某些角色还可能需要最新的培训、认证或近期的监督实践。

近期性很重要。即便某人在两年前完成培训，在静态表格中仍可能被视为合格，但模型、界面和升级规则已经发生了两次变更。治理的关键在于，这些准备的证据是否仍与当前工作流相匹配。

权限必须单独记录。以能够解释交易为何被标记的欺诈分析师为例。该分析师可能完全有资格评估证据，却无法批准超出设定额度的付款。夜间决策因此取决于两类覆盖：能够作出判断的人和被授权执行该操作的人。

这种区分可以防止常见的失误。团队找到一位有知识的人，把该人的可用性视为完整覆盖，却在事件中发现此人无法采取所需步骤。升级会一直向上进行，直到找到既具备资格又有授权的人，往往已经超过了运营截止时间。

可用的覆盖定义从四个问题开始。审查员必须了解什么？哪些证据能够证明？审查员还需要一个明确的决策限制。最后，这项权限何时失效或需要重新评估？如果这些答案分散在不同系统中，升级流程需要在分配案件之前将它们统一起来。

赋予审查员权限并为系统设定安全默认值

非工作时间的审查员需要的不仅是通知。警报应随同拟议的操作、背后的来源或记录、触发审查的例外、可用时间以及延迟的后果一起发送。它还应显示审查员被允许执行的操作。

这些权限需要边界。审查员是被允许按提议批准操作，还是只能编辑？拒绝可能是永久的，亦或仅将案件返回队列。若有多个类似的例外，也可能需要停止更广的工作流。最终的边界是必须调用第二位批准者的点。

这些问题应在AI 代理的运行时控制的设计阶段提出，而不是在队列已经形成后的紧急讨论中。暂停、隔离和受限权限状态为运营团队提供了一个安全的放置不确定工作的场所。遥测和审计记录显示在流程等待期间发生了什么。

最棘手的情况是没有响应。每个受治理的工作流都需要为此情形预先批准一个答案。根据风险不同，系统可能会保留该操作、将其排入下一个合格班次的队列、以受限模式继续执行，或停止受影响的流程。客户支持系统可能会在继续处理常规请求的同时暂停异常大的退款。制造质量工作流可能会将可疑批次隔离，而不是让生产线将沉默视为批准。

沉默不能视为批准。

委托只能在有护栏的情况下运行。记录谁转授了权限、谁接收了权限、它覆盖了哪些调用、何时失效以及任何限制。没有这些记录，非工作时间的流程就只是一串信息，事后将无法拼凑完整。

班次交接是控制的一部分

某些例外会跨越班次。离职审查员可能已经收集了证据、联系了专家并排除了一种选项，但尚未作出最终决定。仅有工单号和匆忙的备注并不足以交接。下一位审查员会浪费宝贵时间去重建已经完成的工作。

这并不是新问题。安全关键的运营长期以来将交接视为独立的工作。英国健康与安全执行局将有效的班次交接描述为三部分流程：离职人员的准备、任务相关信息的交换以及进入人员在承担责任时的交叉检查。其指南强调双向沟通，辅以书面和口头信息，并提供足够的时间和资源来完成工作。

AI 例外的交接需要同样的纪律，只是要适应工作流。记录应包含拟议的操作、系统提供的证据、升级原因、已采取的步骤、已排除的选项、剩余时间以及当前的风险等级。还需要在转移双方标明所有权。

最关键的部分是确认。日志可以显示信息已被记录下来，但无法证明接收审查员理解案件状态或接受下一步决策的责任。交叉检查为接收者提供机会，挑战缺失的证据、确认截止时间并重新阐明下一步允许的操作。

界面设计在此尤为重要。交接界面不应把模型的推理、人类的备注和权限状态埋在不同的标签页中。接收审查员需要看到前一班次期间的变更以及哪些事实仍需核查。否则，每一次交接都会产生新的上下文丢失风险。

跨班次映射合格覆盖范围

大多数团队能够列出与 AI 工作流相关的人员。但更少的团队能够证明每个运营时段都具备合适的知识和授权组合。

实际的起点是按角色和班次的视图。围绕实际决策而非名册上的姓名构建视图。对于每一种可能的升级，记录所需的知识、当前能力的证明方式以及采取行动所需的授权。然后将这些信息与夜班、周末和假期的人员对应起来。

技能或能力矩阵可以通过映射合格覆盖跨班次、角色和地点，在异常发生前使人员风险可见。矩阵可能会显示某个人拥有关键审查的唯一当前资格，某项认证将在计划部署期间到期，或周末班次具备技术专长但缺乏最终批准人。

这些差距变得具体可见。然而，这种可视性并不证明任何人都能完成工作，因为已展示的实践、当前的培训和观察到的决策仍然重要，且矩阵无法授予法律或组织权力。它的职责更为狭窄：展示覆盖模型依赖于假设、过时记录或单个人的地方。

一旦差距显现，团队就有多种选择。他们可以对另一位审查员进行交叉培训，调整随叫随到的覆盖范围，收紧夜间工作流的权限，或在覆盖率提升之前更改安全后备方案。正确的响应取决于延迟的后果以及错误决策的后果。低风险的队列可以等待。与安全相关的异常可能需要立即的专家覆盖或强制停止。

覆盖范围也应进行测试，而不仅仅是记录。进行一次非工作时间演练。触发一次代表性的异常，沿着升级路径进行，并衡量被指派人员是否在允许的时间内获得足够的上下文以采取行动。随后在班次交接时重复该测试。纸面上的覆盖往往看起来令人安心，直到第一条信息发送到过时的电话号码或到达审批额度过低的人员为止。

执行夜班测试

企业治理已经依赖于已定义的所有者和升级路径。夜班测试检查当常规人员不在办公桌前时，这些结构是否仍可使用。

从真实的工作流和一个合理的异常开始。询问在最不便利的时间谁会收到警报。确认该人员具备对该判断的资格，然后检查其可以批准、修改、停止或委派的内容。遵循无响应路径。最后，将未解决的案例通过班次交接传递，观察接收审查员是否能够在不重新调查的情况下说明其状态。

测试通常会暴露出平凡的问题：缺少随叫随到轮班表的角色、与当前模型不匹配的资格记录、审批额度过低的批准人，或在交接时仅转移笔记而未转移所有权的情况。平凡的问题是好事。只要在真实异常导致紧迫期限之前发现，这些可操作的问题都是可以修复的。

AI 工作流可以整夜运行。其治理也必须如此。