Agent Authority Charter Builder Arkadiy Miteiko

智能体权限宪章构建器（Agent Authority Charter Builder）

目的

本技能帮助法律、合规、风险、产品、运营和 AI 治理团队在 AI 智能体部署到企业或受监管工作流之前创建《智能体权限宪章》。

目的不是判断一个 AI 系统总体上是否合乎道德、安全或合规。目的更窄、更具操作性：

在智能体行动之前，界定其拥有何种机构权限。

本技能将一个拟议的 AI 智能体用例转化为结构化的、可审查的治理文件，涵盖：

• 智能体身份；
• 委托人及委派来源；
• 操作范围；
• 被允许的行动；
• 被禁止的行动；
• 人工批准规则；
• 升级触发条件；
• 证据和审计要求；
• 暂停、撤销和紧急停止（kill-switch）条件；
• 部署就绪判定。

最终输出应适合法律、合规、风险、安全、业务、审计和技术利益相关者审查。

核心原则

AI 智能体不应仅由它在技术上能做什么来治理。

它必须由机构授权它做什么来治理。

宪章必须回答：

1. 谁授权了该智能体？
2. 该智能体被允许做什么？
3. 该智能体被禁止做什么？
4. 行动前必须满足什么条件？
5. 需要哪些人工批准？
6. 必须保留哪些证据？
7. 何时智能体必须停止并升级？
8. 谁可以暂停、撤销或修订该权限？
9. 如果智能体超出范围会发生什么？

何时使用本技能

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

• 界定 AI 智能体的权限；
• 为 AI 智能体的企业部署做准备；
• 记录智能体权限；
• 为 AI 工作流创建治理文件；
• 为智能体接受法律、合规、风险或审计审查做准备；
• 区分助手、副驾驶、工作流自动化和智能体权限；
• 准备面向监管机构或内部的 AI 试点；
• 界定人工批准、升级或紧急停止要求；
• 评估智能体是否应被允许在企业系统内采取行动；
• 为自主或半自主 AI 创建权限模型；
• 审查 AI 智能体能否安全地影响记录、客户、交易、工作流或外部承诺。

即使用户以非正式措辞提出请求，也使用本技能，例如：

• “这个智能体能批准事情吗？”
• “部署这个智能体之前，我们应该记录什么？”
• “帮我界定这个 AI 被允许做什么。”
• “我们需要为内部智能体制定一份治理宪章。”
• “这个智能体应该有什么权限？”
• “我们如何让这个智能体通过合规审查？”
• “什么需要人工批准？”
• “我们应该把升级规则放在哪里？”
• “这个 AI 能代表公司行事吗？”

何时不使用本技能

不要使用本技能来：

• 提供法律意见或法律结论；
• 批准智能体部署；
• 对 AI 系统进行特定法规下的分类，除非用户提供了相关法律框架；
• 起草完整的企业 AI 政策；
• 进行网络安全测试；
• 替代法律、合规、风险、隐私、安全或监管机构的审查；
• 创建技术性访问控制代码；
• 对监管合规作出最终认定；
• 授权 AI 智能体运行。

如果用户要求法律结论，说明输出是治理起草辅助工具，应由合格律师和适当的机构权力部门审查。

必需输入

尽量收集以下输入。如果用户未提供足够信息，以合理假设继续，但将缺失项标记为“待确认”（To be confirmed）。

1. 组织背景

• 组织名称
• 行业
• 法域或运营地区
• 受监管或非受监管环境
• 业务部门
• 相关内部政策
• 相关控制环境
• 相关监管义务（如已知）

2. 智能体身份

• 智能体名称
• 智能体目的
• 智能体类型
• 业务负责人
• 技术负责人
• 合规负责人
• 法律负责人（如适用）
• 部署环境
• 所访问的系统

可能的智能体类型包括：

• 信息助手（Informational Assistant）
• 决策支持副驾驶（Decision Support Copilot）
• 工作流准备智能体（Workflow Preparation Agent）
• 有界执行智能体（Bounded Execution Agent）
• 重大后果执行智能体（Consequential Execution Agent）
• 观察 / 治理智能体（Observer / Governance Agent）
• 升级 / 控制智能体（Escalation / Control Agent）
• 补救智能体（Remediation Agent）

3. 委托人和委派权限

识别谁或什么向智能体委派权限。

权限可能来自：

• 具名高管负责人；
• 业务流程负责人；
• 法律部门；
• 合规部门；
• 风险职能；
• 内部 AI 治理委员会；
• 董事会批准的政策；
• 合同；
• 监管机构批准的试点；
• 系统负责人；
• 工作流特定的操作规程。

如果权限来源不明确，将宪章标记为未达到部署就绪。

4. 操作范围

识别：

• 业务流程或工作流；
• 智能体可访问的系统；
• 智能体可使用的工具；
• 智能体可读取的数据；
• 智能体可写入、更改或修改的数据；
• 智能体可影响的交易或记录；
• 智能体可服务的内部用户；
• 智能体可交互的外部当事方；
• 地理限制；
• 客户、产品、交易或风险限制；
• 时间限制或试点限制。

5. 被允许的行动

界定智能体可以做什么：

• 无需人工批准；
• 仅在有批准时；
• 仅在试点期间；
• 仅在阈值以下；
• 仅针对特定类别的用户、案件、客户或交易。

被允许的行动示例：

• 检索信息；
• 总结文件；
• 对记录分类；
• 准备建议；
• 起草沟通内容；
• 更新内部备注；
• 启动工作流；
• 在阈值内批准低风险案件；
• 拒绝不完整的提交；
• 升级例外情况；
• 通知人工审查员；
• 生成证据包。

6. 被禁止的行动

界定智能体不得做什么。

被禁止的行动示例：

• 在合同上约束组织；
• 未经审查批准信贷、保险、招聘、福利、医疗、法律、财务或纪律决定；
• 代表组织发表外部声明；
• 推翻人工决定；
• 更改审计日志；
• 删除记录；
• 访问未授权系统；
• 为自己创造新的权限；
• 在其界定的工作流之外行动；
• 在暂停或撤销后继续运行；
• 作出涉及受保护特征的决定，除非经特别授权并经法律审查；
• 在政策依据模糊时行动。

7. 行动层级

将每个智能体行动归类到以下权限层级之一。

层级 0 —— 仅观察

智能体可以读取、总结、分类或标记信息。不得更改记录、触发工作流、作出决定、对外沟通或产生业务后果。

层级 1 —— 准备

智能体可以起草、结构化、建议或将行动排入队列供人工审查。未经人工批准不得执行该行动。

层级 2 —— 执行有界内部行动

智能体可以在明确界定的阈值内执行低风险内部行动。该行动必须被记录，并在可能情况下可逆。

层级 3 —— 经人工批准执行重大后果行动

智能体只能在明确的人工批准后准备或启动重大后果行动。批准必须作为证据记录的一部分予以保留。

层级 4 —— 被禁止或保留权限

智能体不得执行这些行动。它们需要人工、法律、合规、董事会、监管机构或其他机构权限。

起草工作流

创建宪章时遵循此流程。

第 1 步——识别智能体的机构角色

确定智能体是在辅助人类，还是在行使委派权限。

询问：

• 智能体是否仅产生信息？
• 它是否在更改记录？
• 它是否在触发工作流？
• 它是否在批准或拒绝某事？
• 它是否在对内沟通？
• 它是否在产生法律、财务、运营、客户、员工、患者、公民、市场或声誉后果？

将智能体归类为：

• 信息助手
• 决策支持副驾驶
• 工作流准备智能体
• 有界执行智能体
• 重大后果执行智能体
• 观察 / 治理智能体
• 升级 / 控制智能体

第 2 步——界定委派链

宪章绝不应在未指明谁或什么授权的情况下说"智能体已获授权"。

记录：

• 委派权限的委托人；
• 委派来源；
• 批准机构或人员；
• 生效日期；
• 到期或审查日期；
• 权限条件；
• 未解决的权限缺口。

如果权限不明确，写明：

“未就绪——权限来源未确立。”

第 3 步——区分能力与权限

智能体在技术上可能具备许多行动能力。只有部分行动获得机构授权。

创建三列表格：

示例：

第 4 步——分配权限层级

将每个行动归类到层级 0 至层级 4。

当事实不明确时，采用保守分类。

任何涉及法律、财务、医疗、雇佣、信贷、保险、公共部门、客户损害或外部承诺后果的行动，除非用户提供具体的已批准阈值和权限来源，否则应默认归入层级 3 或层级 4。

第 5 步——界定人工批准规则

对每个需要人工批准的行动，界定：

• 批准人角色；
• 批准方式；
• 批准记录；
• 所需理由；
• 超时规则；
• 批准人不可用时的回退方案；
• 批准是适用于单一行动、单一案件、一批，还是有时限的运营期间。

第 6 步——界定升级逻辑

宪章必须规定智能体何时必须停止并升级。

升级触发条件可包括：

• 权限缺失；
• 政策依据模糊；
• 指示冲突；
• 异常交易规模；
• 客户损害风险；
• 法律或监管后果；
• 超出财务阈值；
• 敏感个人数据；
• 受保护群体或歧视风险；
• 证据缺口；
• 模型不确定性；
• 工具故障；
• 相互矛盾的记录；
• 疑似欺诈；
• 安全关切；
• 请求覆盖某项控制；
• 反复尝试失败；
• 新颖事实模式；
• 外部承诺风险；
• 待决诉讼或投诉；
• 监管机构问询；
• 不利的客户结果。

以操作性语言书写升级规则。

好的示例：

“当所请求的退款超过已批准阈值、客户账户存在未决争议，或智能体无法识别该行动的政策依据时，智能体必须升级。”

弱的示例：

“当事项有风险时，智能体应升级。”

第 7 步——界定证据要求

对每个行动层级，界定最低证据。

建议基线：

证据应包括：

• 用户请求或触发事件；
• 智能体身份；
• 智能体版本或配置；
• 权限来源；
• 政策或规则依据；
• 已审查的输入记录；
• 适用的约束；
• 使用的工具；
• 决策路径；
• 人工批准；
• 升级事件；
• 最终采取的行动；
• 时间戳；
• 审计轨迹位置；
• 行动时的撤销状态。

第 8 步——界定暂停、撤销和紧急停止条件

宪章必须界定智能体的权限何时必须被暂停或撤销。

示例：

• 政策变更；
• 监管变更；
• 数据源故障；
• 模型漂移；
• 工具故障；
• 反复出错行动；
• 未经授权的访问尝试；
• 未解决的事件；
• 审计失败；
• 负责人批准被撤销；
• 试点授权到期；
• 无法解释的行为；
• 证据记录失败；
• 升级失败；
• 用例发生实质性变化。

界定：

• 谁可以暂停智能体；
• 谁可以撤销权限；
• 紧急停止条件；
• 待决行动的处理；
• 事件后审查流程；
• 通知义务；
• 记录要求；
• 补救责任；
• 恢复运行条件。

第 9 步——确定部署就绪状态

选择一项就绪状态：

• 可进行有限内部测试
• 可进行受监督试点
• 可带控制进入生产环境
• 未就绪——权限缺口仍然存在
• 未就绪——需要法律/合规审查
• 未就绪——被禁止的用例

当事实不完整时，采用保守状态。

必需输出格式

使用本技能时，产出以下文件。

智能体权限宪章

1. 宪章元数据

• 宪章标题：
• 版本：
• 日期：
• 状态：
• 组织：
• 业务部门：
• 法域：
• 行业：
• 编制目的：
• 编制人：
• 需由谁审查：

状态选项：

• 草稿
• 待法律审查
• 待合规审查
• 待风险审查
• 待安全审查
• 已批准
• 已暂停
• 已撤销

2. 智能体身份

• 智能体名称：
• 智能体类型：
• 智能体目的：
• 业务负责人：
• 技术负责人：
• 合规负责人：
• 法律负责人：
• 部署环境：
• 所访问的系统：
• 受影响的外部当事方（如有）：

3. 权限来源

• 委派权限的委托人：
• 委派来源：
• 批准机构：
• 生效日期：
• 到期或审查日期：
• 权限条件：
• 权限缺口或未决事项：

4. 机构角色分类

将智能体归类为以下之一：

• 信息助手
• 决策支持副驾驶
• 工作流准备智能体
• 有界执行智能体
• 重大后果执行智能体
• 观察 / 治理智能体
• 升级 / 控制智能体

说明理由。

5. 操作范围

描述智能体可运行的工作流。

包括：

• 允许的工作流；
• 允许的用户；
• 允许的数据来源；
• 允许的系统；
• 允许的工具；
• 地理或法域限制；
• 客户或交易限制；
• 时间或试点限制；
• 排除项。

6. 能力与权限矩阵

7. 被允许的行动

8. 被禁止的行动

9. 人工批准规则

界定：

• 需要批准的行动；
• 批准人角色；
• 批准方式；
• 批准记录；
• 超时规则；
• 批准人不可用时的回退方案。

10. 升级触发条件

11. 证据与审计要求

界定：

• 每个行动的最低证据；
• 审计轨迹要求；
• 存储位置；
• 保留期限（如已知）；
• 审计负责人；
• 所需日志；
• 证据格式；
• 例外处理。

12. 暂停、撤销和紧急停止

界定：

• 谁可以暂停智能体；
• 谁可以撤销权限；
• 紧急停止触发条件；
• 待决行动的处理；
• 撤销后审查；
• 通知义务；
• 补救义务；
• 恢复运行条件。

13. 剩余风险与未决问题

风险级别：

• 低
• 中
• 高
• 阻碍部署

14. 部署就绪判定

选择一项：

• 可进行有限内部测试
• 可进行受监督试点
• 可带控制进入生产环境
• 未就绪——权限缺口仍然存在
• 未就绪——需要法律/合规审查
• 未就绪——被禁止的用例

附简短理由。

15. 权限风险摘要

提供主要权限风险的简短摘要，包括：

• 委派不明确；
• 范围过度；
• 人工批准不足；
• 证据轨迹薄弱；
• 升级不明确；
• 缺少紧急停止；
• 法律或合规审查缺口；
• 外部后果风险。

16. 缺失信息

将所有重要的缺失信息列为“待确认”。

17. 部署阻碍项

列出任何阻止部署的问题。

如果未识别出任何问题，写明：

“根据所提供的信息未识别出部署阻碍项，但这不构成法律、合规、风险或安全批准。”

18. 建议的审查负责人

建议哪些利益相关者应审查该宪章：

• 法律
• 合规
• 风险
• 安全
• 隐私
• 内部审计
• 业务负责人
• 技术负责人
• AI 治理委员会
• 监管机构
• 其他

19. 人工审查通知

在每个宪章末尾添加以下通知：

“本《智能体权限宪章》是治理起草辅助工具。它不构成法律意见、监管批准或最终的机构授权。部署应由适当的法律、合规、风险、安全、技术和业务权力部门审查。”

质量标准

输出必须：

• 具体到足以指导部署；
• 清晰到足以供法律、合规和风险审查；
• 具备操作性到足以供技术团队使用；
• 在权限不明确时保持保守；
• 对委派、范围、升级、证据和撤销明确具体；
• 不含无依据的法律结论；
• 结构化为可复用的治理文件。

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

• “智能体应负责任地行事。”
• “智能体应遵守法律。”
• “智能体应是安全的。”
• “智能体应在需要时升级。”
• “智能体应运用良好判断。”

用具体的权限、阈值、证据和升级规则替换模糊语言。

部署就绪规则

如果智能体能够产生法律、财务、运营、客户、员工、患者、公民、市场、公共部门或外部后果，而用户未识别出明确的权限来源，则将宪章标记为：

“未就绪——权限来源未确立。”

保守默认规则

如果信息不完整，选择限制更严的权限层级。

如果拟议的行动可能约束组织、影响他人的权利、改变资金流动、改变法律地位、影响受监管记录或产生外部依赖，除非用户提供明确的权限来源和已批准阈值，否则将其归类为层级 3 或层级 4。

最终回应行为

返回宪章时，包括：

1. 完整的《智能体权限宪章》。
2. 简短的权限风险摘要。
3. 缺失信息清单。
4. 部署阻碍项清单。
5. 建议的审查负责人。

不要夸大确定性。除非用户提供了实际的批准来源，否则不要声称智能体已获批准。

示例用户请求

“我们正在部署一个 AI 智能体来审查客户退款请求。它可以读取支持工单、查看订单历史、建议退款决定并更新 CRM。它应自动批准小额退款，但将较大金额升级。”

示例回应纲要

助手应产出一份《智能体权限宪章》，其中：

• 如果允许自动处理低价值退款，则将退款智能体识别为有界执行智能体；
• 将建议归类为层级 1；
• 将 CRM 更新归类为层级 2；
• 仅在存在已批准阈值时，将自动退款归类为层级 2；
• 将较大金额退款归类为层级 3；
• 禁止未经人工审查拒绝复杂或争议性索赔；
• 对未决争议、弱势客户、疑似欺诈、政策依据模糊或超出阈值要求升级；
• 要求请求、订单历史、政策依据、阈值、采取的行动、批准（如有）和审计日志的证据；
• 如果退款阈值或权限来源缺失，将宪章标记为未达到部署就绪。