# Runtime Admissibility Review > 判断某个具体的 AI 代理（AI-agent）行动、输出、建议或拟议承诺，在当前的授权、委托范围、证据、事实、政策、风险、升级和撤销条件下，是否仍可被容许用于执行或机构依赖。在企业或受监管的 AI 代理执行操作、更新记录、触发工作流、对外沟通之前，或在机构以会产生后果的方式依赖代理输出之前，使用本技能。 - Skill: `cslawyer1985/runtime-admissibility-review` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add cslawyer1985/runtime-admissibility-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/runtime-admissibility-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/cslawyer1985/runtime-admissibility-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. 建议的审查责任方。 不要夸大确定性。不要说某个行动在法律上已获批准。不要说机构依赖在法律上已获批准。除非用户提供授权来源，否则不要说某个代理已获机构授权。