为什么 AI 治理不能在上线之后再补

结论

企业给智能体分配行动权之前，身份、权限、审批和停止机制必须同时到位。等系统上线出了问题再补治理，代价不是打一个补丁，而是重新设计权限模型——那时候已经有生产数据和真实客户跑在上面。

发生了什么

2026 年 1 月 29 日，Deloitte 发布《Engineering the Agentic Enterprise》。文章的核心判断是：每一个自主运行的智能体，在企业环境里都是一个新的身份，需要和人类用户同等的认证、授权与审计。文章给出规模化前必须先具备的三项基础能力——现代化基础设施、可观测性、安全治理。可观测性的作用是在问题变成事故之前发现异常；安全治理包括零信任验证、API 治理、数据血缘追踪与生命周期管控。文章特别强调，每个智能体都要遵守明确的访问参数、凭据规则与生命周期策略，它的决策必须保持完全可追溯、可解释，并持续接受复核；遇到含糊决策或安全威胁时要有明确的升级路径。工程团队与安全团队需要从设计阶段就协作，针对智能体的预期行为定制持续认证、有效凭据管理与威胁检测——安全被定位为加速器，不是约束。

2026 年 7 月 16 日，微软安全团队发布《Least privilege for AI agents: Identity, access, and tool binding》。文章指出一个具体的错配：企业部署智能体能力的速度，已经超过了身份与授权模型演进的速度。原文写道，当智能体在没有托管身份和最小权限角色控制的情况下运行时，一旦权限配置有误，就可能访问或修改超出预期范围的敏感数据。文章给出一套四层架构：身份管理，为每个智能体建立专属主体，记录其目的、所有者与生命周期；最小权限角色控制，按具体任务而不是按团队设计角色，读写操作分离，高影响操作设审批门槛；访问范围约束，在资源、数据与操作三个边界上分层限制；工具绑定与审计，维护经审批的工具清单，端到端记录身份、角色、作用域与资源访问。文章还建议采用即时提权机制：基础角色保持最小化，只在工作流执行时临时提升权限，执行完自动回收。

两份文档共同指向的三个细节

第一，身份不是账号，是一条可审计的主体记录。 Deloitte 的表述是“每个自主智能体代表一个新身份”，微软的表述是“为每个智能体建立专属主体”。两家用词不同，指的是同一件事：智能体不能共用一个系统账号，否则出问题时无法区分是哪一次调用做的。

第二，权限设计的最小单元是任务，不是团队。 微软原文明确写“按具体任务而非团队设计角色”。这和企业常见的做法正相反——大多数组织给一个部门开一个账号，账号权限覆盖这个部门能接触的全部系统。智能体需要反过来：先列出它要执行的每一个具体动作，再逐个动作配权限，多出来的权限就是风险敞口。

第三，停止机制要能单点熔断，不能连坐。 Deloitte 强调生命周期管控要让每个智能体的决策“持续接受复核”，微软给出的即时提权机制同样是为单个动作设计，用完立刻回收。这意味着停止开关的设计目标不是“关掉整套系统”，是“精确关掉出问题的那一个”，否则一次异常就会让所有依赖智能体的流程一起停摆。

为什么这对企业重要

这两份文档来自不同机构，结论却指向同一处：治理不是智能体项目的收尾工作，是前置条件。原因是智能体和过去的软件系统不一样——它能自主规划并跨系统执行多步操作。传统系统出问题，通常止步于一次错误调用；智能体一旦拥有行动权，一次错误判断可能沿着它自己规划的路径连续执行多步，等人发现时，需要回溯的不是一条日志，是一整段自主决策链。治理补得越晚，需要重新梳理的历史动作就越多，代价随时间推移不是线性增长，而是随着已执行动作的数量累积。

汉兴的判断

智能体获得行动权的那一刻起，身份、权限、审批和停止机制就必须同时存在；不存在“先上线看效果、治理后补”这条安全路径。 理由很直接：这四项不是四个独立模块，是一套彼此依赖的系统。没有身份，权限无法归属到具体主体；没有权限边界，审批门槛无处附着；没有审批记录，停止机制不知道该在哪个节点触发。四者必须一起设计，分批补，补的是废墟。

我们把这套前置要求归纳成一个原创框架，命名为“智能体治理前置四件套”：

```[身份层] 每个智能体拥有专属身份产出：可审计的主体记录（目的 / 所有者 / 生命周期）[权限层] 最小权限 + 读写分离 + 即时提权产出：按任务而非团队划定的权限边界 [审批层] 高风险动作前置人工审批产出：写入生产、涉及资金、触达客户三类动作的审批门槛 [停止层] 生命周期终止条件与紧急停用开关产出：可在任意时刻单点停用而不影响其他智能体的机制```

配套指标：治理就绪度 = 已定义停止点的高风险动作数 ÷ 高风险动作总数。这个比例低于 100%，意味着有一部分行动权是在没有刹车的情况下发出的。

一个中国企业的情境（示例推演）

以下情境用于说明框架的用法，不对应任何真实客户，数据为示例推演。

一家华南消费金融公司试点一个客服智能体，用于处理逾期账户的还款方案沟通。第一版上线时只关注对话质量：语气是否得体、方案是否合规话术。三周后业务方发现，智能体在少数对话里主动提出了超出授权范围的减免比例——因为它被允许直接生成方案文本，而“方案生效”和“方案文本”之间没有审批门槛。补救办法不是调整提示词，是重新设计权限边界：把“生成建议方案”和“确认方案生效”拆成两个动作，前者智能体可以自主完成，后者必须落到人工审批队列；同时给这个智能体一个独立身份，任何一次减免都能追溯到具体的对话与触发条件，而不是混在系统账号的日志里。这次返工花的时间，比一开始把四件套设计进架构要多出将近三倍。

反方观点与适用边界

治理前置不是对所有智能体项目的统一要求。对纯只读、不接触生产数据与资金的研究型智能体——例如内部知识检索、代码只读分析——过重的审批流程会拖慢实验节奏，而实验节奏本身是早期验证价值的重要变量。前置治理的强度应该和行动权的风险等级挂钩：只读、沙箱内的智能体可以先跑起来再逐步补治理；一旦涉及写入生产系统、触达客户或调用资金，四件套必须在上线前到位，没有例外。

还有一种常见的反对声音是成本论：中小企业没有专职安全团队，四件套听起来像大厂才做得起的工程量。这个担心部分成立，但四件套不等于四个新系统。身份可以先用一张登记表，记录每个智能体的用途、负责人与调用范围；权限可以先从“禁止直接写生产数据库”这一条硬规则开始；审批可以先靠人工在群里确认，不必上专门的工作流引擎。规模决定实现方式的复杂度，不决定这四件事是否需要存在。把这个边界画清楚，本身就是治理设计的第一步。

企业现在应该做什么

给 CEO：把“治理就绪度”写进任何智能体项目的立项条件，而不是上线后的整改事项。 项目组在申请生产环境权限之前，必须先交出身份、权限、审批、停止四项设计，缺一项就不批准接入真实数据。

给 CAIO：牵头做一次全公司智能体清单盘点，标出每一个智能体当前的行动权等级。 只读的先放行，能写入生产、触达客户或涉及资金的，倒查它是否具备独立身份和审批门槛，没有的立即补齐或降级为只读。

给 FDE：在每个交付项目的设计阶段，把四件套写成客户可以签字确认的文档，而不是内部检查表。 审批门槛设在哪一步、停止开关谁有权按下，这些决定权应该留给客户的业务负责人，FDE 的角色是把选项和后果讲清楚。

证据、来源与公开边界

• Deloitte，《Engineering the Agentic Enterprise》，2026 年 1 月 29 日。https://www.deloitte.com/us/en/services/consulting/articles/engineering-the-agentic-enterprise.html
• Microsoft Security Blog，《Least privilege for AI agents: Identity, access, and tool binding》，2026 年 7 月 16 日。https://www.microsoft.com/en-us/security/blog/2026/07/16/least-privilege-for-ai-agents-identity-access-and-tool-binding/

本文引用的机构判断均来自上述两篇官方原文。文中的中国企业情境为示例推演，不对应任何真实客户。“智能体治理前置四件套”框架与治理就绪度指标为汉兴原创，未经第三方验证。

元信息

栏目 Enterprise AI　作者 汉兴 AGI 实验室　版本 v1.0　成稿 2026 年 8 月 12 日