cslawyer1985 运行时容许性审查
目的
本技能帮助法律、合规、风险、产品、运营、审计和 AI 治理团队判断：某个具体的 AI 代理行动、输出、建议或拟议承诺，在执行之前或机构依赖之前，在运行时是否仍被容许。
其目的不是判断某个 AI 系统是否已获总体部署批准。
其目的更为狭窄和更具操作性：
判断在当前的这些事实、该授权、该委托范围、该证据、这些约束、该升级姿态和该撤销状态下，该代理是否可以采取该具体行动，或该机构是否可以依赖该具体的代理输出。
本技能产出一份结构化的《运行时容许性决定》，可供法律、合规、风险、审计、技术和业务利益相关方审查。
核心原则
静态授权对代理式 AI（agentic AI）是不够的。
一个 AI 代理可能已获批准用于某工作流，且一项委托任务最初可能适合授权包络（authority envelope），但某个具体行动或后来的机构依赖可能因条件变化而变得不容许。
示例：
- 授权来源已过期；
- 政策已变更；
- 行动超出范围；
- 依赖语境比原始委托更宽；
- 证据不完整；
- 出现风险标记；
- 客户、员工、患者、公民或相对方语境已变化；
- 该行动现在产生法律、财务、运营、监管、合同、客户、员工、患者、公民、市场、公共部门或声誉后果；
- 需要人工批准但缺失；
- 发生撤销或暂停事件；
- 代理无法保全所需的证据链；
- 输出从信息支持转变为机构承诺。
运行时问题是：
"即使该代理先前已获授权，这一行动或机构依赖现在仍然容许吗？"
与《代理权限章程》和《代理式委托审计》的关系
本技能位于《代理权限章程》的下游，并与《代理式委托审计》互补。
《代理权限章程》在部署前定义代理的授权包络：委托了什么、由谁委托、在哪些限制内、负有哪些证据义务、具有哪些升级、暂停或撤销控制。
《代理式委托审计》检验一个具体的委托任务是否适合该授权包络。
《运行时容许性审查》提出下一个问题：即使代理已获适当授权且委托任务看似适合授权包络，当前的事实、范围、授权、证据、政策、风险、升级、撤销或依赖条件是否仍容许该行动或机构依赖？
依赖结构是：
代理权限章程 → 代理式委托审计 → 运行时容许性审查 → 机构依赖 / 后果
如果用户提供了足够的背景，本技能可以在未上传《代理权限章程》或《委托审计》的情况下运作。如任一成品可用，将其作为主要输入。
关键区分
不要将授权与容许性混为一谈。
授权问的是：
"该代理是否被授予在此工作流中运作的权限？"
委托审查问的是：
"这个具体的委托任务是否适合该代理的授权包络？"
运行时容许性问的是：
"该代理现在是否可以采取这个具体行动，或该机构现在是否可以依赖这个具体输出？"
一个行动可能总体上已获授权，但在当前状态下不容许。一个生成的输出作为信息可能有用，但对机构依赖或后果不容许。
执行与依赖边界
运行时容许性可能适用于两个密切相关的时点：
执行之前——当 AI 代理即将行动、更新记录、触发工作流、对外沟通或产生运营后果时。
依赖之前——当机构即将以影响人、交易、法律立场、监管义务、业务决策或机构后果的方式，依赖某个代理输出、建议、分类、分析或生成成品时。
本技能不应假设先前的授权已解决任一边界。行动前的授权与依赖前的容许性是互补的层次。
一个适当授权的代理仍可能因事实变化、范围转移、证据变得不完整、授权被暂停、政策变更、出现风险条件，或依赖语境变得比原始委托所允许的更具后果性，而变得不容许。
何时使用本技能
当用户要求以下事项时使用本技能：
- 审查 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 更新作为机构后果；
- 以允许的决定之一作结：容许、附控制容许、需人工批准、待证据搁置、执行或依赖前升级、不容许或被禁止。
最终回应行为
返回决定时，包括：
- 完整的《运行时容许性决定》。
- 一份简洁的容许性决定。
- 该行动或依赖可以进行、必须搁置、必须升级、不容许或被禁止的原因。
- 缺失信息。
- 执行或依赖前所需的控制。
- 建议的审查责任方。
不要夸大确定性。不要说某个行动在法律上已获批准。不要说机构依赖在法律上已获批准。除非用户提供授权来源，否则不要说某个代理已获机构授权。