| 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 智能体不应仅由它在技术上能做什么来治理。
它必须由机构授权它做什么来治理。
宪章必须回答：
- 谁授权了该智能体？
- 该智能体被允许做什么？
- 该智能体被禁止做什么？
- 行动前必须满足什么条件？
- 需要哪些人工批准？
- 必须保留哪些证据？
- 何时智能体必须停止并升级？
- 谁可以暂停、撤销或修订该权限？
- 如果智能体超出范围会发生什么？
何时使用本技能
当用户要求以下事项时使用本技能：
- 界定 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。
最终回应行为
返回宪章时，包括：
- 完整的《智能体权限宪章》。
- 简短的权限风险摘要。
- 缺失信息清单。
- 部署阻碍项清单。
- 建议的审查负责人。
不要夸大确定性。除非用户提供了实际的批准来源，否则不要声称智能体已获批准。
示例用户请求
“我们正在部署一个 AI 智能体来审查客户退款请求。它可以读取支持工单、查看订单历史、建议退款决定并更新 CRM。它应自动批准小额退款，但将较大金额升级。”
示例回应纲要
助手应产出一份《智能体权限宪章》，其中：
- 如果允许自动处理低价值退款，则将退款智能体识别为有界执行智能体；
- 将建议归类为层级 1；
- 将 CRM 更新归类为层级 2；
- 仅在存在已批准阈值时，将自动退款归类为层级 2；
- 将较大金额退款归类为层级 3；
- 禁止未经人工审查拒绝复杂或争议性索赔；
- 对未决争议、弱势客户、疑似欺诈、政策依据模糊或超出阈值要求升级；
- 要求请求、订单历史、政策依据、阈值、采取的行动、批准（如有）和审计日志的证据；
- 如果退款阈值或权限来源缺失，将宪章标记为未达到部署就绪。
