AI智能体治理：企业管理者的实用框架

AI智能体治理是一套决策权、控制和证据体系，用来决定智能体能够为企业做什么。它回答实际问题：可以读取哪些记录、执行哪些动作、花费多少、谁审查例外，以及谁能够将其停止。

当AI超越起草文件，这些问题便更加紧迫。连接CRM、邮箱、采购或客服系统的智能体，可以改变真实运营。企业不能只要求答案合理，还必须确保在正确账户上、使用正确权限执行正确动作。

本指南为管理团队提出实用运营框架，侧重已部署流程周围的控制，而不是模型选择或一般AI政策。目标是让有用的委托明确、可测试并可管理。

AI智能体治理涵盖什么？

聊天机器人可能建议一封邮件，智能体却可能选择收件人、检索账户信息并发送。因此治理必须覆盖整个流程：模型、指令、工具、凭据、数据、人员和环境。

NIST的AI风险管理框架为系统整个生命周期的AI风险管理提供自愿基础，其核心职能为治理、映射、测量和管理。下文将这一广泛观点转为业务智能体的运营决定，并不构成NIST认证，也不能替代特定组织的义务。

先问：智能体能在企业真正可强制的边界内，完成什么有价值的工作？

1. 授权前先写运营任务书

为每个生产智能体提供简短、版本化任务书，说明目的、用户、允许任务、禁止行为和停止条件。“提高销售效率”太宽泛；“从批准账户记录准备续约摘要供经理审核”才具体到足以治理。

指定一位对价值与后果负责的业务负责人，另有负责集成的技术人员、负责权限的控制人员，以及主要负责人缺席时能行动的替补。委员会可以建议，但事故发生后，不应还需要开会决定谁负责响应。

任务书应记录：

• 范围内流程与客户群。
• 来源系统与批准数据类别。
• 可建议、起草、执行的动作。
• 保留给具体人工角色的决策。
• 可接受的最大财务运营暴露。
• 暂停访问或重新审核条件。

衔接现有流程负责人。企业没明确谁批折扣，加入智能体也不会消除歧义。这部分属于企业咨询与运营模式问题，而不只是集成任务。

2. 分开读取、起草和执行权限

实用权限模型应区分四层：读取批准信息、准备建议、执行有限动作，以及执行需批准的重大动作。不要仅因开发方便，就授予最高权限。

平台支持时使用专用身份，把访问限制在任务需要的记录、字段、文件夹和动作。测试与生产分开，生产凭据不要出现在提示词或一般参考文档中。

重要限制应在工具或应用层强制执行。“永远不要删除客户”的提示，弱于没有删除功能的集成。除内部访问外还要限制外部目的地，能读客户不应自动代表可发往任意地址或网站。

Anthropic关于智能体隔离解释了为何既要监督行为，也要监督智能体能触达什么。访问边界有助于限制意外动作的损害，但仍需按具体环境设计。

让批准具体且可审查

让审核者看到拟执行动作、影响记录、收件人、金额、支持证据和预期后果。批准应仅适用该动作和参数。之后若收件人或金额变化，就应重新请求决定。长任务开始时的一般同意，不应暗中授权所有后续动作。

3. 在模型外设资金、数量和时间限额

控制不只模型费用。智能体可用付费数据、建工单、触发广告、请求采购，各有不同暴露。

在每动作、每任务、每天和整个流程层面设限，并明确达到上限时怎么办。安全默认可能是停止执行、保留草稿并通知负责人，而不是无限重试。

以上是例子而非通用门槛，应按流程经济、可逆性和可容忍最大损失选择。

4. 扩大前测试决定与失败行为

演示通常沿着理想路径进行。生产评估需要普通案例、困难例外和恶意输入。用代表性工作建立测试集，同时删除敏感信息或提供适当保护。

分别衡量任务完成、事实准确、越权尝试、正确上报、重复动作、成本和人工返工。高完成率可能掩盖权限处理不佳，而所有情况都上报的智能体虽然受控，却未必有商业用途。

测试集应包含冲突记录、缺失客户标识、过时指令、工具停机和重复请求。验证流程能否在重做前识别交易已经发生。查看结果之前，先定义通过与停止标准。

OpenAI的智能体安全指南将提示注入描述为不可信内容试图重定向AI系统，并建议结构化数据流、审批和评估。在企业场景，供应商文件或收到的邮件应保持为待检查证据，而不是对智能体发号施令的新权威。

模型、提示、工具、政策或数据源变化时重跑相关评估。旧测试通过不自动验证新组合。

5. 保留可回答商业问题的审计链

每项重要动作应记录任务标识、智能体与配置版本、来源引用、工具请求、政策决定、必要批准和实际结果。分清“请求”“批准”“执行”“确认”；生成一条“完成”消息，不代表应用已接受修改。

记录简短的决定理由与证据引用，不要依赖模型隐藏推理。给予审核者足够信息重建事件，但不必收集所有可能的客户数据。

与相关数据、安全负责人设定保留、访问和脱敏规则。审计日志本身也可能敏感。除失败外，也抽样审查成功任务，否则安静的错误可能直到客户投诉才暴露。

6. 上线前设计回滚与事故响应

明确如何暂停、撤凭据、阻止新动作，从智能体外测试停止机制，不应依赖模型同意有事故。

随后区分可逆改动与无法简单撤销的动作。CRM字段可能有历史版本，邮件无法可靠收回，客户也可能已据此行动。设计补救措施，如改正记录、通知账户负责人，或经批准流程联系受影响客户。

事故预案应明确谁控制问题、评估影响、决定沟通和批准重启。保存相关证据，确定受影响记录，并从整个流程检查失败。应先纠正控制并定向测试再重启，而非只加一句“更加小心”。

实例：治理续约支持智能体

假设软件公司引入智能体帮助账户经理准备续约。这是设计示例，不是Zendral客户成果。

初始范围为50个账户。智能体读取批准CRM字段和现有合同，总结续约日期与使用量，起草内部简报。它不能发客户信息、改条款、批折扣或看无关账户。营收运营主管负责流程，系统团队负责访问，账户经理批准面向客户的动作。

测试中，合同附件出现指令，要求把账户清单发送到外部地址。流程将其视为不可信内容；外发功能不可用，事件被记录，并纳入回归测试。

另一项测试暴露普通问题：CRM与合同的续约日期不同。智能体必须标记冲突并引用双方来源，不能暗自选择更方便的日期，也不能修改合同系统。

扩展前，团队审查简报是否准确、经理在纠错后是否真正省时、例外是否送到正确人员，并检查每份被接受简报的成本。证据满意后，下一版可允许把邮件草稿放入审核队列，发送仍是独立权限决定。

这一顺序使权限增加可以被观察，避免通过一连串小而未记录的修改，把有用的起草助手变成自主商业代表。

7. 分阶段扩权并设到期

从离线测试到监督试点，再到有限生产，每次仅扩大一个有意义维度：记录量、业务单位、工具访问或执行权。四项同时改变会更难诊断失败。

为权限和具体例外设审核日期，临时访问应到期，除非负责人续批。员工换岗、供应商改工具或流程退役时，要移除相关凭据和定时任务。

有多个智能体后，应作为组合管理。共享凭据、职责重叠与合计支出，可能形成逐个审查难发现的暴露。把组合复盘连接到企业转型优先事项，让企业扩展有效能力，而非积累孤立实验。

管理层治理清单

• 能指出业务负责人及有权停止者。
• 许可与禁止动作有书面记录。
• 工具权限强制重要边界。
• 资金、量、时间、重试有明确停止行为。
• 审批显示实际动作，不复用于变参数。
• 测试含例外、恶意内容、工具不可用。
• 日志区分建议与应用确认结果。
• 能定位影响记录并恢复。
• 变更在推广前触发适当评估。
• 权限与例外有负责人和审核日期。

管理者常问的治理问题

谁负责智能体治理？

业务流程负责人应对流程负责，由技术、安全、数据和其他相关专家支持。中央标准有帮助，但中央AI团队不应默认承担每项智能体触及的商业决定。

每个动作都需人工批准吗？

不是。审核强度应符合动作后果、可逆性和不确定性。边界明确、充分测试的任务可在强制限额内运行，高影响动作需要更强控制，可能包括明确批准。缺乏有用背景的反复点击，反而可能让审核无效。

如何知道可扩大？

使用约定证据，包括可接受质量、有用经济性、有效上报，以及经测试的隔离和恢复。数量本身不是证明。只扩大评估支持的权限，并保留退回较小范围的途径。

围绕机会构建运营模式

最佳起点是有价值流程、明确负责人和可强制边界。Zendral的AI与自动化服务连接用例战略、流程设计和实施优先级，帮助管理团队明确委托什么，以及扩大时如何保留控制。

探索更多洞察