Agent Authority Charter Builder Arkadiy Miteiko

---
name: "agent-authority-charter-builder-arkadiy-miteiko"
description: "在部署前为企业或受监管的 AI 智能体创建《智能体权限宪章》（Agent Authority Charter）。当用户需要界定 AI 智能体被允许做什么、谁向其授予了权限、哪些行动被允许或禁止、何时需要人工批准、必须保留哪些证据，以及智能体如何被暂停、撤销或升级时，使用本技能。"
category: 合规与监管
tags:
  - AI 治理
  - 智能体 AI
  - 委派权限
  - 法律运营
  - 合规
  - 风险管理
  - 审计轨迹
  - 人工审查
  - 受监管行业
  - AI 部署
metadata:
  author: "Arkadiy Miteiko"
  license: "agpl-3.0"
  version: "2026-06-20"
---

# 智能体权限宪章构建器（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 步——区分能力与权限

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

创建三列表格：

| 技术能力 | 授权用途 | 所需控制 |
|---|---|---|

示例：

| 技术能力 | 授权用途 | 所需控制 |
|---|---|---|
| 发送邮件 | 仅起草，不自动发送 | 需要人工批准 |
| 更新 CRM | 仅添加内部备注 | 需要日志条目 |
| 批准退款 | 仅限批准的阈值内 | 需要证据包 |
| 拒绝索赔 | 未经特别批准不授权 | 需要人工决定 |

### 第 4 步——分配权限层级

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

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

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

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

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

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

### 第 6 步——界定升级逻辑

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

升级触发条件可包括：

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

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

好的示例：

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

弱的示例：

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

### 第 7 步——界定证据要求

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

建议基线：

| 层级 | 最低证据 |
|---|---|
| 层级 0 | 时间戳、请求、来源记录、生成的输出 |
| 层级 1 | 时间戳、请求、来源记录、草稿或建议、审查人身份 |
| 层级 2 | 时间戳、权限来源、适用的约束、采取的行动、受影响的记录、审计日志 |
| 层级 3 | 层级 2 的证据加上人工批准、批准理由、升级历史 |
| 层级 4 | 被禁止行动日志、拒绝理由、升级记录 |

证据应包括：

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

### 第 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；
- 禁止未经人工审查拒绝复杂或争议性索赔；
- 对未决争议、弱势客户、疑似欺诈、政策依据模糊或超出阈值要求升级；
- 要求请求、订单历史、政策依据、阈值、采取的行动、批准（如有）和审计日志的证据；
- 如果退款阈值或权限来源缺失，将宪章标记为未达到部署就绪。