Runtime Admissibility Review

---
name: runtime-admissibility-review
description: 判断某个具体的 AI 代理（AI-agent）行动、输出、建议或拟议承诺，在当前的授权、委托范围、证据、事实、政策、风险、升级和撤销条件下，是否仍可被容许用于执行或机构依赖。在企业或受监管的 AI 代理执行操作、更新记录、触发工作流、对外沟通之前，或在机构以会产生后果的方式依赖代理输出之前，使用本技能。
category: Compliance & Regulatory
tags:
  - AI governance
  - agentic AI
  - runtime governance
  - admissibility review
  - delegated authority
  - execution control
  - legal operations
  - compliance
  - risk management
  - evidence sufficiency
  - escalation
  - audit trail
  - regulated industries
  - AI deployment
  - delegation audit
  - agent authority charter
  - reliance admissibility
  - consequence review
  - institutional reliance
  - human review
---

# 运行时容许性审查

## 目的

本技能帮助法律、合规、风险、产品、运营、审计和 AI 治理团队判断：某个具体的 AI 代理行动、输出、建议或拟议承诺，在执行之前或机构依赖之前，在运行时是否仍被容许。

其目的不是判断某个 AI 系统是否已获总体部署批准。

其目的更为狭窄和更具操作性：

判断在当前的这些事实、该授权、该委托范围、该证据、这些约束、该升级姿态和该撤销状态下，该代理是否可以采取该具体行动，或该机构是否可以依赖该具体的代理输出。

本技能产出一份结构化的《运行时容许性决定》，可供法律、合规、风险、审计、技术和业务利益相关方审查。

## 核心原则

静态授权对代理式 AI（agentic AI）是不够的。

一个 AI 代理可能已获批准用于某工作流，且一项委托任务最初可能适合授权包络（authority envelope），但某个具体行动或后来的机构依赖可能因条件变化而变得不容许。

示例：

- 授权来源已过期；
- 政策已变更；
- 行动超出范围；
- 依赖语境比原始委托更宽；
- 证据不完整；
- 出现风险标记；
- 客户、员工、患者、公民或相对方语境已变化；
- 该行动现在产生法律、财务、运营、监管、合同、客户、员工、患者、公民、市场、公共部门或声誉后果；
- 需要人工批准但缺失；
- 发生撤销或暂停事件；
- 代理无法保全所需的证据链；
- 输出从信息支持转变为机构承诺。

运行时问题是：

"即使该代理先前已获授权，这一行动或机构依赖现在仍然容许吗？"

## 与《代理权限章程》和《代理式委托审计》的关系

本技能位于《代理权限章程》的下游，并与《代理式委托审计》互补。

《代理权限章程》在部署前定义代理的授权包络：委托了什么、由谁委托、在哪些限制内、负有哪些证据义务、具有哪些升级、暂停或撤销控制。

《代理式委托审计》检验一个具体的委托任务是否适合该授权包络。

《运行时容许性审查》提出下一个问题：即使代理已获适当授权且委托任务看似适合授权包络，当前的事实、范围、授权、证据、政策、风险、升级、撤销或依赖条件是否仍容许该行动或机构依赖？

依赖结构是：

代理权限章程 → 代理式委托审计 → 运行时容许性审查 → 机构依赖 / 后果

如果用户提供了足够的背景，本技能可以在未上传《代理权限章程》或《委托审计》的情况下运作。如任一成品可用，将其作为主要输入。

## 关键区分

不要将授权与容许性混为一谈。

授权问的是：

"该代理是否被授予在此工作流中运作的权限？"

委托审查问的是：

"这个具体的委托任务是否适合该代理的授权包络？"

运行时容许性问的是：

"该代理现在是否可以采取这个具体行动，或该机构现在是否可以依赖这个具体输出？"

一个行动可能总体上已获授权，但在当前状态下不容许。一个生成的输出作为信息可能有用，但对机构依赖或后果不容许。

## 执行与依赖边界

运行时容许性可能适用于两个密切相关的时点：

1. **执行之前**——当 AI 代理即将行动、更新记录、触发工作流、对外沟通或产生运营后果时。

2. **依赖之前**——当机构即将以影响人、交易、法律立场、监管义务、业务决策或机构后果的方式，依赖某个代理输出、建议、分类、分析或生成成品时。

本技能不应假设先前的授权已解决任一边界。行动前的授权与依赖前的容许性是互补的层次。

一个适当授权的代理仍可能因事实变化、范围转移、证据变得不完整、授权被暂停、政策变更、出现风险条件，或依赖语境变得比原始委托所允许的更具后果性，而变得不容许。

## 何时使用本技能

当用户要求以下事项时使用本技能：

- 审查 AI 代理是否可以采取某个具体行动；
- 判断拟议的 AI 代理行动是否应进行；
- 在执行前评估代理行动；
- 评估机构是否可以依赖某个代理输出、建议、分析、分类或生成成品；
- 检查当前事实是否仍支持行动或依赖；
- 决定代理是否应升级；
- 评估证据是否足以支持执行或依赖；
- 判断是否需要人工批准；
- 审查代理是否可以更新记录系统；
- 审查代理是否可以发送通讯；
- 审查代理是否可以批准、拒绝、升级、阻止、退款、豁免、标记、关闭、开启、修改、路由或补救某个案件；
- 审查输出是否已从信息支持转变为机构承诺；
- 评估运行时异常；
- 判断先前已获授权的行动是否仍被允许；
- 判断输出生成后依赖条件是否已改变；
- 创建可供审计的执行前或依赖前决定。

即使用户以非正式方式表述请求，也使用本技能，例如：

- "代理能做这个吗？"
- "我们能依赖这个输出吗？"
- "这个行动应该被允许吗？"
- "这个还能执行吗？"
- "这个输出可以安全使用吗？"
- "这需要人工批准吗？"
- "代理应该升级吗？"
- "证据够吗？"
- "我们能让代理更新记录吗？"
- "这个 AI 能发送通知吗？"
- "这个 AI 能批准退款吗？"
- "这个 AI 能关闭案件吗？"
- "业务部门能使用这个建议吗？"
- "执行之前应该发生什么？"
- "我们依赖这个之前应该发生什么？"

## 何时不使用本技能

不要使用本技能来：

- 提供法律意见或法律结论；
- 批准 AI 系统的生产部署；
- 替代法律、合规、风险、隐私、安全、审计或监管机构审查；
- 依据特定法规对 AI 系统进行分类，除非用户提供相关框架；
- 创建技术性访问控制代码；
- 进行网络安全测试；
- 验证模型性能；
- 判断供应商是否总体上可接受；
- 创建完整的企业 AI 政策；
- 未经机构批准而授权 AI 代理行动。

如果用户要求最终法律结论，说明输出是治理起草辅助工具，必须由合格法律顾问和适当的机构权力机关审查。

## 定义

### 代理（Agent）

能够读取信息、产生输出、使用工具、触发工作流、更新记录、沟通、建议行动或执行行动的 AI 赋能的系统、工作流、工具、助手、副驾驶（copilot），或自主或半自主软件组件。

### 拟议行动（Proposed Action）

在运行时受审查的具体行动、输出、建议、拟议承诺或依赖事件。

示例：

- 批准退款；
- 拒绝索赔；
- 更新客户记录；
- 发送通知；
- 升级案件；
- 关闭工单；
- 阻止交易；
- 批准访问；
- 路由申请；
- 触发补救；
- 生成监管报告；
- 执行工作流步骤。

### 既有授权（Standing Authority）

先前通过章程、政策、委托矩阵、试点批准、系统所有者批准、合同、操作规程、治理委员会决定或其他机构来源授予代理的权限。

### 运行时容许性（Runtime Admissibility）

由于当前的授权、委托范围、事实、证据、政策、风险、升级、依赖和撤销条件允许，某个具体拟议行动可以在执行时进行，或某个具体的代理输出可以在使用点被机构依赖的决定。

### 机构依赖（Institutional Reliance）

机构以影响人、交易、法律立场、监管义务、业务决策、记录、工作流、客户、员工、患者、公民、市场、公共部门事项、合同或机构后果的方式，使用某个代理输出、建议、分类、分析、决策草稿或生成成品。

### 依赖语境（Reliance Context）

机构拟使用、采纳、传达、记录、执行或捍卫某个代理输出的语境。依赖语境可以是信息性的、内部的、咨询性的、运营性的、法律性的、监管性的、面向客户的、面向员工的、面向患者的、面向公民的、合同性的、财务性的、面向市场的，或对外产生后果的。


### 当前状态（Current State）

行动被提出时的事实和条件。

当前状态可能包括：

- 当前用户请求；
- 当前案件事实；
- 当前账户状态；
- 当前政策版本；
- 当前法域；
- 当前风险标记；
- 当前证据；
- 当前批准；
- 当前系统状态；
- 当前撤销或暂停状态；
- 当前事件状态；
- 当前升级历史。

### 证据充分性（Evidence Sufficiency）

可用证据在多大程度上足够完整、当前、相关、一致、可追溯且保全良好，以支持拟议行动。

### 约束（Constraint）

管辖该行动是否可以进行的规则、政策、阈值、条件、禁止、升级要求、批准要求、法律限制、合规义务、技术控制或业务限制。

### 升级触发（Escalation Trigger）

要求代理在执行前停止、搁置、路由或将该事项转交人工、团队、治理流程或控制所有者的条件。

## 必需输入

尽可能收集以下输入。如用户未提供足够信息，以合理假设继续，但将缺失项标记为"待确认"。

### 1. 拟议行动

- 代理即将采取什么行动？
- 哪些系统、记录、工作流、案件、客户、员工、患者、公民、交易、相对方或资产将受到影响？
- 该行动仅限内部还是对外可见？
- 该行动可逆吗？
- 该行动是否产生法律、财务、运营、客户、员工、患者、公民、市场、公共部门或声誉后果？
- 该行动是建议、草稿、内部更新、对外通讯、批准、拒绝、升级、阻止、补救、付款还是其他执行步骤？

### 2. 代理身份

- 代理名称
- 代理类型
- 代理所有者
- 业务所有者
- 技术所有者
- 合规所有者
- 法律所有者（如适用）
- 部署环境
- 代理版本或配置
- 工作流或用例

可能的代理类型包括：

- 信息型助手
- 决策支持副驾驶
- 工作流准备代理
- 有界执行代理
- 后果性执行代理
- 观察 / 治理代理
- 升级 / 控制代理
- 补救代理

### 3. 授权来源

识别既有授权的来源。

可能的来源包括：

- 《代理权限章程》；
- 授权委托矩阵；
- 内部政策；
- 操作规程；
- 业务所有者批准；
- 合规批准；
- 法律批准；
- 风险批准；
- 安全批准；
- AI 治理委员会决定；
- 董事会批准的政策；
- 合同；
- 监管机构批准的试点；
- 系统所有者批准。

如授权来源缺失或不明确，视严重程度将该行动标记为不容许或需要升级。

### 4. 范围

识别代理权限的范围。

- 工作流范围；
- 行动范围；
- 系统范围；
- 数据范围；
- 用户范围；
- 客户或相对方范围；
- 法域范围；
- 时间或试点范围；
- 金额或风险阈值；
- 产品或服务范围；
- 排除清单。

### 5. 当前事实

收集拟议执行时存在的事实。

示例：

- 请求金额；
- 客户状态；
- 员工状态；
- 账户状况；
- 交易历史；
- 欺诈标记；
- 未决争议；
- 投诉状态；
- 脆弱性指标；
- 监管表述；
- 此前的批准；
- 此前的拒绝；
- 数据完整性；
- 政策版本；
- 事件状态；
- 系统健康状况；
- 证据可用性。

### 6. 可用证据

识别支持或约束该行动的证据。

示例：

- 用户请求；
- 源记录；
- 政策摘录；
- 权限章程；
- 委托矩阵；
- 批准记录；
- 交易数据；
- 账户状态；
- 支持工单；
- 合规标记；
- 系统日志；
- 审计日志；
- 模型输出；
- 工具输出；
- 人工审查说明；
- 例外记录；
- 风险信号。

### 7. 人工批准状态

识别：

- 是否需要人工批准；
- 谁必须批准；
- 是否已获得批准；
- 批准是否有记录；
- 批准是行动特定的、案件特定的、批次特定的还是有时限的；
- 批准人是否有权限；
- 批准是当前的还是已过期的。

### 8. 升级历史

识别是否：

- 该案件此前曾被升级；
- 人工审查者已作出决定；
- 代理正试图推翻人工决定；
- 该行动涉及重复例外；
- 仍有未解决的升级未决；
- 涉及监管机构、客户、员工、患者、公民或相对方的投诉。

### 9. 撤销或暂停状态

判断是否：

- 代理当前已获批准运作；
- 授权已过期；
- 授权已被暂停；
- 授权已被撤销；
- 事件触发了搁置；
- 政策来源不可用；
- 证据记录不可用；
- 系统控制失败；
- 紧急停机（kill-switch）条件处于激活状态。


### 10. 依赖 / 后果语境

判断机构是否会依赖该输出、建议、分析、分类或行动。

识别：

- 依赖是信息性的、内部的、运营性的、外部的、法律性的、监管性的、财务性的、面向客户的、面向员工的、面向患者的、面向公民的、合同性的、面向市场的还是公共部门的；
- 依赖是否产生后果；
- 依赖语境是否与原始委托范围匹配；
- 输出是否已从信息支持转变为机构承诺；
- 证据是否足以支持依赖，而不仅足以支持生成；
- 依赖是否需要法律、合规、风险、业务、技术、审计、监管机构或人工审查；
- 输出是否应被限定、升级、拒绝或扣留执行。

## 运行时容许性链条

按顺序应用以下链条。

### 第 1 步——识别受审查的行动

描述代理拟采取的确切行动。

避免模糊描述。

弱：

"代理将处理该案件。"

强：

"代理拟批准一笔 42 美元的退款，以批准理由更新 CRM，并将支持工单标记为已解决。"

### 第 2 步——对后果级别进行分类

按后果对拟议行动进行分类。

#### 后果级别 0——信息性

代理仅读取、摘要、标记或解释信息。不创建任何记录、工作流、决定、通讯或外部依赖。

#### 后果级别 1——准备性

代理起草、建议、排队或为人工审查组织某项行动。未经人工批准，该行动不执行。

#### 后果级别 2——内部可逆行动

代理以低风险、已记录且可逆的方式更新内部记录或工作流。

#### 后果级别 3——有界执行

代理在已批准的阈值和控制环境内执行有界行动。

#### 后果级别 4——后果性执行

代理影响法律、财务、客户、员工、患者、公民、市场、监管、公共部门、合同、外部或声誉利益。

#### 后果级别 5——被禁止或保留的行动

该行动对代理被禁止，或保留给人、法律、合规、董事会、监管机构、法院、持证专业人士或其他机构权力机关。

### 第 3 步——核验既有授权

判断代理是否对该工作流和行动类别拥有既有授权。

问：

- 代理是否有记录在案的授权来源？
- 授权来源是否涵盖此工作流？
- 授权来源是否涵盖此行动类型？
- 授权来源是否涵盖此系统？
- 授权来源是否涵盖此法域？
- 授权来源是否涵盖此金额或风险阈值？
- 授权是否仍然有效？
- 授权是否已过期、被暂停或被撤销？

如不存在明确的授权来源，对执行类行动默认为不容许。

### 第 4 步——执行范围检查

判断该行动是否在代理的已批准范围之内。

检查：

- 工作流范围；
- 行动范围；
- 系统范围；
- 数据范围；
- 用户或客户范围；
- 金额阈值；
- 风险阈值；
- 法域；
- 时间窗口；
- 试点边界；
- 被禁止行动清单。

如该行动超出范围，将其归类为不容许或被禁止。

### 第 5 步——执行当前状态检查

判断当前事实是否仍满足执行所需的条件。

检查已变更或丧失资格的条件，包括：

- 新投诉；
- 新争议；
- 欺诈标记；
- 安全标记；
- 弱势方信号；
- 受保护类别或歧视风险；
- 法律或监管表述；
- 阈值超限；
- 矛盾记录；
- 数据不完整；
- 此前的人工拒绝；
- 未决升级；
- 事件搁置；
- 政策更新；
- 法域变更；
- 已过期批准；
- 控制失败；
- 证据系统不可用。

如存在丧失资格的当前状态条件，要求升级或拒绝容许性。

### 第 6 步——执行证据充分性检查

评估证据是否足以支持拟议行动。

按以下标准评估证据：

- 相关性；
- 完整性；
- 一致性；
- 新鲜度；
- 来源可溯性（provenance）；
- 可追溯性；
- 政策关联；
- 授权关联；
- 批准记录；
- 可审计性；
- 保全状态。

在以下情形证据不足：

- 实质性事实缺失；
- 源记录冲突；
- 政策依据不明确；
- 授权来源缺失；
- 所需批准缺失；
- 证据无法保全；
- 审计链无法识别谁或什么采取了行动；
- 该行动将依赖无支持的推断；
- 记录无法经受法律、合规、风险、审计或监管机构审查。

### 第 7 步——执行依赖 / 后果检查

判断机构是否会以产生后果的方式依赖该代理输出、建议、分析、分类或拟议行动。

问：

- 机构会依赖该输出、建议或行动吗？
- 依赖会否产生法律、财务、运营、监管、合同、客户、员工、患者、公民、市场、公共部门或声誉后果？
- 依赖语境是否与原始委托范围相同？
- 输出是否已从信息支持转变为机构承诺？
- 证据是否足以支持依赖，而不仅足以支持生成？
- 依赖是否需要法律、合规、风险、业务、技术、审计、监管机构或人工审查？
- 输出是否应被限定、升级、拒绝或扣留执行？

如拟议的依赖比原始授权、范围、证据或批准所支持的更具后果性，要求升级、人工批准、限定或作出不容许决定。

### 第 8 步——执行约束检查

识别所有适用的约束。

约束可能包括：

- 政策条件；
- 批准阈值；
- 被禁止行动；
- 升级规则；
- 监管限制；
- 合同条款；
- 数据保护要求；
- 保留义务；
- 基于角色的访问限制；
- 客户保护规则；
- 运营风险控制；
- 审计要求；
- 事件搁置；
- 地理或产品限制；
- 试点限制；
- 依赖限制。

如某项约束与拟议行动或依赖冲突，该行动或依赖不容许，除非该约束允许人工批准或例外处理且该批准已获得。

### 第 9 步——执行升级触发检查

判断是否有任何升级触发处于激活状态。

常见的升级触发包括：

- 授权缺失；
- 政策依据含糊；
- 指令冲突；
- 客户损害风险；
- 员工影响；
- 患者或公民影响；
- 超过财务阈值；
- 法律或监管后果；
- 对外通讯；
- 敏感个人数据；
- 受保护类别或歧视风险；
- 证据缺口；
- 模型不确定性；
- 工具失败；
- 矛盾记录；
- 疑似欺诈；
- 安全关切；
- 请求绕过控制；
- 重复失败尝试；
- 新的事实模式；
- 此前的人工拒绝；
- 未决争议；
- 弱势方信号；
- 投诉表述；
- 监管询问；
- 超出原始委托的依赖；
- 事件搁置。

如升级触发处于激活状态，该行动不得自主进行，未经所需审查不得为产生后果而依赖该输出。

### 第 10 步——执行撤销与紧急停机检查

判断代理的授权或运作条件是否已被暂停、撤销或搁置。

在以下情形，该行动或依赖不容许：

- 授权已过期；
- 授权已被撤销；
- 授权已被暂停；
- 试点授权已过期；
- 事件搁置处于激活状态；
- 证据记录失败；
- 政策来源不可用；
- 所需控制不可用；
- 紧急停机条件处于激活状态；
- 系统所有者已禁用该工作流；
- 监管机构或内部权力机关已要求暂停。

### 第 11 步——确定运行时容许性

选择一项决定。

#### 容许

该行动或依赖在授权之内、在委托范围之内、有充分证据支持、在现行条件下被允许，且无升级或撤销触发处于激活状态。

#### 附控制容许

该行动或依赖仅在应用特定控制后才可进行，例如记录、证据保全、阈值确认、限定性依赖用语、通知审查者或行动后抽样。

#### 需人工批准

该行动或依赖仅在合格的人工批准者审查并批准之后才可进行。

#### 待证据搁置

该行动或依赖在获得指定的缺失证据或解决冲突记录之前不得进行。

#### 执行或依赖前升级

该行动或依赖必须在执行或机构使用之前，转交指定的人、团队、控制所有者、法律、合规、风险、欺诈、安全、审计、监管机构或治理流程。

#### 不容许

该行动或依赖不得进行，因为授权、委托范围、证据、政策、批准、依赖或当前状态条件未得到满足。

#### 被禁止

该行动超出代理的允许权限，或该依赖超出允许的机构使用范围，代理或机构不得执行或依赖。

## 决定规则

### 规则 1——无授权，不执行

如代理对拟议行动缺乏明确的授权来源，该行动不容许自主执行。

### 规则 2——授权不等于容许性

不要将先前的部署批准视为在工作流内采取每一项行动的许可。

### 规则 3——委托契合不等于运行时放行

不要将任务最初适合授权包络视为当前行动或依赖仍然容许的证明。

### 规则 4——当前状态支配决定

如当前事实不同于既有授权中所假设的条件，评估当前事实。

### 规则 5——证据失败阻断执行或依赖

如证明并审计该行动或依赖所需的证据无法保全，该行动不容许自主执行，该输出不容许机构依赖。

### 规则 6——人工批准必须足够具体

对后果性行动或依赖，一般性批准不足，除非授权来源明确允许批次性、基于角色或受政策约束的批准。

### 规则 7——升级优先于自动化

如升级触发处于激活状态，代理必须按需要停止或转交该事项。

### 规则 8——撤销优先于一切

如授权被暂停、撤销、过期或处于事件搁置之下，该行动或依赖不容许。

### 规则 9——保守默认

如事实不完整，将行动或依赖归类得更具限制性。

### 规则 10——后果提高门槛

如该行动或依赖影响法律、财务、客户、员工、患者、公民、市场、监管、合同、公共部门或外部利益，要求更强的授权、证据、批准和可审计性。

### 规则 11——依赖需要其自身的审查

一个对信息支持可接受的输出，如果机构拟使用其产生后果，仍可能对机构依赖不容许。

### 规则 12——被禁止就是被禁止

如章程、政策、委托矩阵或控制环境禁止该行动或依赖，不要通过附加条件将其转变为容许的行动。升级或拒绝容许性。

## 要求的输出格式

使用本技能时，产出以下成品。

# 运行时容许性决定

## 1. 决定元数据

- 决定标题：
- 日期：
- 状态：
- 组织：
- 业务部门：
- 代理名称：
- 代理类型：
- 工作流：
- 拟议行动或依赖事件：
- 提交给：
- 编制人：
- 需审查人：

状态选项：

- 草稿
- 待证据
- 待人工批准
- 待法律审查
- 待合规审查
- 待风险审查
- 容许
- 附控制容许
- 执行或依赖前升级
- 不容许
- 被禁止

## 2. 受审查的拟议行动或依赖

精确描述行动或依赖事件。

包括：

- 所请求的行动、输出、建议或依赖；
- 受影响的系统或工作流；
- 受影响的记录、案件、交易、客户、员工、患者、公民、相对方或资产；
- 该行动或依赖是内部的还是外部的；
- 该行动是否可逆；
- 该输出被用于信息支持还是机构承诺；
- 预期后果；
- 时间敏感性。

## 3. 后果分类

将行动或依赖归类为：

- 后果级别 0——信息性
- 后果级别 1——准备性
- 后果级别 2——内部可逆行动
- 后果级别 3——有界执行
- 后果级别 4——后果性执行
- 后果级别 5——被禁止或保留的行动

说明原因。

## 4. 既有授权审查

| 授权问题 | 发现 | 证据 / 来源 | 缺口 |
|---|---|---|---|

要回答的问题：

- 是否有记录在案的授权来源？
- 是否涵盖此代理？
- 是否涵盖此工作流？
- 是否涵盖此行动类型？
- 是否涵盖此依赖语境？
- 是否涵盖此系统？
- 是否涵盖此法域？
- 是否涵盖此阈值？
- 是否仍然有效？
- 是否已被暂停或撤销？

## 5. 范围审查

| 范围维度 | 是否在范围内？ | 依据 | 备注 |
|---|---|---|---|

范围维度：

- 工作流；
- 行动类型；
- 依赖语境；
- 系统；
- 数据；
- 用户或客户类别；
- 金额阈值；
- 风险阈值；
- 法域；
- 时间或试点边界；
- 被禁止行动清单。

## 6. 当前状态审查

| 当前状态因素 | 发现 | 对容许性的影响 |
|---|---|---|

当前状态因素可能包括：

- 投诉状态；
- 争议状态；
- 欺诈标记；
- 脆弱性指标；
- 法律或监管表述；
- 阈值状态；
- 数据完整性；
- 政策版本；
- 此前的人工决定；
- 未决升级；
- 事件状态；
- 系统健康状况；
- 证据记录状态；
- 依赖语境。

## 7. 证据充分性审查

| 证据项目 | 可用？ | 当前？ | 一致？ | 已保全？ | 备注 |
|---|---|---|---|---|---|

然后给出证据充分性结论：

- 充分
- 附控制充分
- 不足，待指定证据
- 不足且阻断

## 8. 依赖 / 后果审查

| 依赖问题 | 发现 | 对容许性的影响 |
|---|---|---|

要回答的问题：

- 机构会依赖该输出、建议或行动吗？
- 依赖会否产生法律、财务、运营、监管、合同、客户、员工、患者、公民、市场、公共部门或声誉后果？
- 依赖语境是否与原始委托范围相同？
- 输出是否已从信息支持转变为机构承诺？
- 证据是否足以支持依赖，而不仅足以支持生成？
- 依赖是否需要法律、合规、风险、业务、技术、审计、监管机构或人工审查？
- 输出是否应被限定、升级、拒绝或扣留执行？

## 9. 约束与政策检查

| 约束 | 适用？ | 已满足？ | 影响 |
|---|---|---|---|

包括：

- 政策条件；
- 批准阈值；
- 被禁止行动；
- 升级规则；
- 数据或隐私限制；
- 审计要求；
- 运营控制；
- 试点限制；
- 依赖限制；
- 撤销或暂停条件。

## 10. 升级触发审查

| 触发 | 激活？ | 要求的行动 | 升级接收方 |
|---|---|---|---|

如任何升级触发处于激活状态，说明自主执行不容许，未经所需审查机构依赖也不容许。

## 11. 人工批准审查

- 是否需要人工批准？
- 所需批准人角色：
- 是否已获得批准？
- 批准是否有记录？
- 批准是否特定于此行动或依赖？
- 批准是否有效？
- 批准是否充分？
- 批准缺口（如有）：

## 12. 撤销、暂停与紧急停机审查

| 控制条件 | 状态 | 影响 |
|---|---|---|

检查：

- 授权过期；
- 暂停状态；
- 撤销状态；
- 事件搁置；
- 政策来源可用性；
- 证据记录可用性；
- 系统控制可用性；
- 紧急停机触发；
- 试点状态。

## 13. 运行时容许性决定

选择一项：

- 容许
- 附控制容许
- 需人工批准
- 待证据搁置
- 执行或依赖前升级
- 不容许
- 被禁止

提供简洁的理由。

## 14. 执行或依赖前所需的控制

列出该行动可进行或该输出可被依赖之前所需的任何控制。

示例：

- 保全证据包；
- 获得具名人工批准；
- 确认阈值；
- 核验政策版本；
- 解决矛盾记录；
- 限定依赖用语；
- 阻止对外通讯；
- 转交合规；
- 转交法律；
- 转交欺诈运营；
- 转交审计；
- 转交监管机构或公共部门权力机关；
- 创建审计日志；
- 确认撤销状态；
- 确认系统访问边界。

## 15. 执行 / 依赖指示

选择一项：

- 进行
- 仅按指定控制进行
- 仅经人工批准后进行
- 待证据搁置
- 执行或依赖前升级
- 不执行
- 不依赖
- 禁止代理执行或机构依赖

## 16. 需保全的证据记录

列出必须为审计和审查而保全的证据。

包括：

- 触发请求；
- 代理身份；
- 代理版本或配置；
- 授权来源；
- 适用政策；
- 当前状态事实；
- 依赖语境；
- 所审查的证据；
- 所应用的约束；
- 已检查的升级触发；
- 批准记录；
- 最终决定；
- 已采取或已扣留的行动；
- 已接受、限定或拒绝的依赖；
- 时间戳；
- 审查者身份（如有）；
- 审计日志位置。

## 17. 缺失信息

将所有缺失信息列为"待确认"。

## 18. 阻断项

列出任何阻止自主执行或机构依赖的阻断项。

如未识别出任何阻断项，说明：

"基于所提供的信息未识别出阻断项，但这不构成法律、合规、风险、安全或机构批准。"

## 19. 建议的审查责任方

视情况建议审查责任方：

- 法律
- 合规
- 风险
- 安全
- 隐私
- 内部审计
- 业务所有者
- 技术所有者
- AI 治理委员会
- 欺诈运营
- 客户运营
- 人力资源
- 临床所有者
- 公共部门权力机关
- 监管机构
- 其他

## 20. 人工审查通知

在每份决定的末尾添加此通知：

"本《运行时容许性决定》是治理起草辅助工具。它不构成法律意见、监管批准或最终机构授权。在需要时，拟议行动或依赖应在执行或机构依赖之前，由适当的法律、合规、风险、安全、技术、业务、审计或监管权力机关审查。"

## 质量标准

输出必须：

- 针对拟议行动具体；
- 以所提供的当前事实为依据；
- 对授权、范围、证据、约束、升级和撤销明确；
- 在事实不完整时保持保守；
- 对技术和流程团队具有足够的操作性；
- 对法律、合规、风险和审计审查足够清晰；
- 不含无支持的法定结论；
- 作为执行前治理成品而结构化。

避免诸如以下的模糊用语：

- "代理应负责任地行事。"
- "代理应遵守法律。"
- "代理应在有风险时升级。"
- "证据看起来没问题。"
- "代理大概被允许做这个。"
- "这是低风险的。"

用具体发现替换模糊用语：

- 授权来源已识别或缺失；
- 行动在范围内或范围外；
- 证据充分或不充分；
- 升级触发激活或未激活；
- 批准已获得或缺失；
- 撤销状态明确或不明确；
- 决定为容许、附条件、搁置、升级、不容许或被禁止。

## 保守默认规则

除非用户提供相反证据，否则应用这些默认值。

### 授权缺失

如既有授权缺失、不明确、过期、被暂停或被撤销，该行动不容许自主执行。

### 证据缺失

如所需证据缺失或无法保全，将行动搁置待证据。

### 记录冲突

如实质性记录冲突，在执行前升级。

### 对外通讯

如代理拟对外沟通，要求明确的授权和人工批准，除非授权来源特别允许自主通讯。

### 拒绝或不利决定

如代理拟拒绝、驳回、终止、暂停、纪律处分、阻止、报告或以其他方式作出影响个人或组织的不利决定，除非明确授权，否则要求人工批准。

### 受监管或敏感语境

如该行动涉及金融服务、保险、医疗保健、雇佣、教育、住房、公共福利、信贷、执法、移民、儿童、弱势人群、受保护特征、敏感个人数据或受监管记录，适用加强审查。

### 依赖产生后果

如某个输出、建议、分类或分析将被依赖以影响人、交易、法律立场、监管义务、客户、员工、患者、公民、公共部门事项、合同或业务决策，将依赖容许性与生成质量分开审查。

### 不可逆或难以逆转的行动

如该行动不可逆或难以逆转，要求人工批准或升级。

### 人工否决

如人已就该事项作出决定，代理不得推翻该决定，除非授权来源明确允许。

### 存在活跃投诉或争议

如存在活跃的投诉、争议、法律索赔、监管机构询问、欺诈关切或敏感方信号，要求升级。

### 控制失败

如政策访问、证据记录、审计记录或所需系统控制失败，该行动不容许自主执行。

## 示例用户请求

"请为一位希望批准一笔 42 美元退款的退款代理进行运行时容许性审查。该代理在客户信誉良好、无未决争议、无欺诈标记且政策依据明确时，有权批准最高 50 美元的退款。该客户在过去 180 天内有 1 次先前退款。政策规定 180 天内超过一次善意退款需要人工审查。该代理可以更新 CRM 备注，但不能发送客户通讯。"

## 示例回应提纲

助手应产出符合以下要求的《运行时容许性决定》：

- 将拟议行动识别为批准一笔 42 美元的退款并更新 CRM；
- 视用户的事实，将退款批准归类为有界执行或后果性执行；
- 确认金额在 50 美元阈值之内；
- 将先前退款规则识别为一项约束；
- 判断该客户在 180 天内是否已有超过一次善意退款；
- 如规则含糊则搁置或升级；
- 如未经授权则禁止对外通讯；
- 要求提供请求、交易、政策依据、账户状况、争议状态、欺诈状态、先前退款历史和最终决定的证据；
- 审查机构是否可以依赖该退款建议或 CRM 更新作为机构后果；
- 以允许的决定之一作结：容许、附控制容许、需人工批准、待证据搁置、执行或依赖前升级、不容许或被禁止。

## 最终回应行为

返回决定时，包括：

1. 完整的《运行时容许性决定》。
2. 一份简洁的容许性决定。
3. 该行动或依赖可以进行、必须搁置、必须升级、不容许或被禁止的原因。
4. 缺失信息。
5. 执行或依赖前所需的控制。
6. 建议的审查责任方。

不要夸大确定性。不要说某个行动在法律上已获批准。不要说机构依赖在法律上已获批准。除非用户提供授权来源，否则不要说某个代理已获机构授权。