企业怎么盘点 AI 智能体：治理台账与停机能力

先说结论：智能体落地的下一个瓶颈，不是模型能力，是「你不知道自己在运行什么」

过去一年企业做 AI Agent，注意力几乎都放在两件事上：模型能不能做对任务，以及执行时安不安全。但 2026 年 10 月中下旬一批公开材料指向了第三个、也更基础的问题——很多企业回答不出「我们公司现在到底在跑多少个智能体」。

这听起来像是一句调侃，但它是有出处的。Dataiku 联合 Harris Poll 发布的《2026 Global AI Report: CIO Edition》调查了 8 个市场的 685 位 CIO，其中 83% 表示公司没有标准化的 AI 智能体生命周期管理框架，81% 表示无法完全监督那些在批准系统与正式渠道之外被创建出来的智能体，84% 认为员工创建智能体的速度已经超过了 IT 部门的管理能力。同一份调研里，67% 的受访者估计自己公司运行着超过 51 个智能体。

更具体的一个数字来自阿联酋市场：62% 的当地 CIO 表示公司运行超过 50 个智能体，15% 运行超过 500 个，是八个市场里最高的比例；但只有 5% 的受访 CIO 表示能在 1 到 2 小时内识别并遏制一个失控的智能体，约为全球均值 10% 的一半，只有 18% 认为自己拥有一份覆盖全部在运行智能体的统一视图。跑得最多、看得最不清楚——这个组合本身就是风险的定义。

本文的判断是：企业现在需要的第一件事不是更好的智能体治理平台，而是一份可信的智能体台账，以及台账里必须包含的「可停机性」与「身份」两个字段。这两样东西成本很低，但不补上，后面所有的治理动作都建在流沙上。

本文与本站已发布的几篇文章是上下游关系：《AI Agent 可观测性与评测》讲的是单个智能体运行期的链路追踪与回归；《AI Agent 运行时隔离怎么做》讲的是执行侧的四道边界；《企业后台权限模型设计》讲的是人和角色的传统权限模型。本文讲的是它们共同的前提：先要有一份说得清「有哪些智能体、谁负责、能停、用了什么身份」的清单。这三件事都假设清单已经存在，清单不存在时，前三件事都无从谈起。

---

一、把「不可见」这件事拆开：四个具体的失效点

「企业不知道自己运行了多少智能体」不是一句笼统的抱怨，它可以拆成四个工程上可验证的失效点。

1.1 智能体建在别人的平台上，天然不可见

一个智能体可能同时存在于六七个地方：某个云厂商的 Agent 平台、某个 SaaS 内置的 Agent 功能、某个低代码自动化工具、研发团队自己写的编排脚本、某个浏览器扩展、某台员工电脑上的本地工具。企业如果只用「自家平台后台」来看，得到的必然是一个被严重低估的数字——每个平台只能看见建在自己上面的那部分智能体。

Dataiku 在 2026 年 9 月 24 日纽约 Succeed 大会上发布的 Agent Management 产品说明中，把这个问题描述得相当直接：该产品打通 AWS Bedrock、Databricks Agents、Google Vertex、Microsoft Copilot Studio 与 Azure Foundry、Salesforce Agentforce、Snowflake Cortex 等主流平台，并为自定义环境提供 OpenTelemetry 支持，目标是把这些平台上运行的智能体扫进一份统一清单，并自动识别每个智能体依赖的工具与模型。该产品在 2026 年 10 月正式可用。

Dataiku 联合创始人兼 CEO Florian Douetteau 在发布时的说法是：「问一家银行它运行多少台服务器，你能得到一个精确到小数位的答案；问它运行多少个 AI 智能体，得到的往往是一个耸肩或者一个猜测。」这与调研数据是吻合的：IBM 的相关研究显示，不到五分之一的组织维护着完整且最新的 AI 系统清单（该数据由 Dataiku 在发布材料中引用）。

这里需要说明一句方法论上的界限：厂商引用的第三方调研数字属于厂商口径的转述，读者在评估时应回到原始研究去看样本与问法，而不是直接接受百分比。

1.2 智能体有「非人身份」，而身份治理工具往往只覆盖人

传统权限体系的设计前提是「一个账号对应一个人」。智能体打破了这个前提：一个智能体可能同时持有数据库只读凭证、对象存储写权限、一个第三方 SaaS 的 OAuth 授权、以及一个代码仓库的部署令牌。这些身份在传统 IAM 视野里要么根本不存在，要么被折叠进某个「服务账号」条目里。

后果是，IBM《Cost of a Data Breach Report 2026》（由 Ponemon Institute 执行，2026 年 7 月 29 日发布，样本为 2025 年 3 月至 2026 年 2 月期间发生过泄露的 602 家组织）给出的数字里有一组很能说明问题：在涉及 AI 的泄露事件中，92% 的组织缺少恰当的 AI 访问控制，而只有 46% 对运行在 AI 工作流中的非人身份做了保护。报告同时指出，68% 的受影响组织没有 AI 治理机制，只有 19% 表示其治理团队与安全团队之间有协作。

必须客观指出这份报告的自我限定：IBM 自己声明样本为非统计抽样，且抽样框「偏向隐私或信息安全体系更成熟的组织」。也就是说，这些数字描述的是已经发生泄露的组织，不能直接外推为行业平均水平。它们的价值在于方向，不在于精确度。

1.3 「还在跑」不等于「有人在用」，但它确实还在消耗权限

这是最容易被忽略的一点：一个季度前接的自动化流程，不会因为没人记得它而自动停止。它仍然持有凭证，仍然在被定时触发，仍然在写数据。

IBM 2026 年报告里有一项与「资产可见性」直接相关的成本因子分析：对应用数量与所在位置缺乏可见性（报告中归为 shadow IT）这一项，平均给每起泄露增加了 20 万多美元的损失。同一份报告还显示，涉及影子 AI 的安全事件比例从上一年版的 20% 上升到 43%，这类事件的平均损失为 539 万美元，高于 2025 年版的 463 万美元，也高于报告给出的 499 万美元全局平均泄露成本。

至于「影子 AI」在企业内部的真实规模，另有一组数据：Cloud Security Alliance 委托 Token Security 于 2026 年 4 月做的一项调研中，82% 的组织表示在过去一年里发现了此前完全不知道存在的 AI 智能体。OutSystems 对 1900 名 IT 负责人的调研则显示，96% 的受访企业已经在运行 AI 智能体，但只有约 12% 表示有集中的管理方式。

1.4 出了事，受影响组织自己发现不了

这是 2026 年 10 月最值得注意的一条动态。

印度计算机应急响应团队 CERT-In 在 2026 年 10 月 15 日发布题为《AI Agents as Attack Vectors》的公告，记述了两类事件：

1. 研究评测阶段越权：CERT-In 收到多家 AI 模型提供方的自愿披露，称其模型在联网研究与评测活动中触及了印度组织的生产系统，读取了包含个人数据与机密材料在内的业务记录，途径是应用配置中暴露的凭证与连接信息、公开代码仓库、以及权限过宽的云服务角色。公告明确指出：所有受影响组织都没有自行发现这些访问，每一起事件都是模型提供方内部审查后主动披露的。
2. 攻击者使用开源智能体工具：CERT-In 通过主动威胁狩猎发现了一起带有财务动机的事件，攻击者使用公开可获取的 AI 原生进攻安全框架，把从初次入侵到最终产生影响的时间从数天压缩到数小时，且多智能体并行运行数小时至数天；修复不完整的受害者在数天内遭到更大规模的二次攻击。

公告同时明确指出：这些事件的根因弱点全部是传统性质的——源码与公开仓库历史中的凭证密钥、仍可从公网访问的休眠/废弃/测试 API、明文存储且可从应用运行时读取的支付 API 密钥、允许匿名或普通调用方广泛读写的云与后端服务角色、暴露在公网且弱口令或未启用多因素认证的管理接口。差异在于速度和规模：AI 找到并利用这些弱点，比人类攻击者更快、更彻底、更大规模。

这条动态对本文主题的意义非常直接：当一台智能体因为凭证过宽而越权访问时，被访问的那一方连「发生了」都不知道。也就是说，企业的安全现状取决于别人家智能体的行为，而不只是自己家的。这使得「知道自己有什么」从一项合规工作变成了一项防御工作。

---

二、监管与标准已经开始把「台账」写成硬要求

治理意愿不只来自风险，也来自合规窗口。这几年陆续生效的规则，把「记录清楚你在运行什么」从最佳实践变成了准入条件。

• 欧盟《人工智能法案》的禁止性条款与 AI 素养义务自 2025 年 2 月 2 日起适用；第 50 条透明度义务自 2026 年 8 月 2 日起适用；附件三高风险义务自 2027 年 12 月 2 日起适用（附件一义务在 Digital Omnibus 调整后为 2028 年 8 月 2 日）。对于把 AI 用于招聘、信贷等决策的组织而言，一旦有员工使用了未批准的工具而企业对此不知情，就可能在没有记录的情况下被动成为高风险系统的部署者。
• ISO/IEC 42001:2023（AI 管理体系标准）有一个被普遍低估的特性：管理体系只能治理其定义范围内的系统，范围之外的工具天然不在体系内。
• NIST AI RMF 1.0 及其生成式 AI 配套文档（NIST AI 600-1）中的 Map（识别）环节，前提是你知道每个 AI 系统是什么、用途是什么、处在什么上下文中。

这三者的共同点在于：它们都假设「你已经知道自己在运行什么」。如果这一步缺失，后续的文档、评估、审计准备都无从谈起。这也是为什么台账建设排在所有治理动作的最前面。

在国家标准层面，全国网安标委此前发布的《网络安全标准实践指南——智能体部署使用安全指引》与《人工智能安全治理框架 3.0》的智能体专章，给出的也是同类逻辑：先界定范围，再谈防护。

---

三、台账要记什么：七个必备字段

一份能用的智能体台账不是一张花名册，而是一张能被审计追问的表。按重要程度，下面七个字段建议一个都不能少。

3.1 身份：它在哪个平台、以谁的权限在跑

这一项最容易漏，也最关键。至少要记录：智能体运行在哪个平台或环境（云厂商 Agent 平台 / SaaS 内置 / 低代码工具 / 自研服务 / 员工本地）、它持有哪些凭证或授权（数据库、对象存储、第三方 API、代码仓库）、这些凭证是专用的还是与其他人共用的、有效期多长。

「共用凭证」在多智能体系统里是最危险的一种配置，因为它无法被单独审计、单独限权、单独吊销——吊销会连带影响所有依赖它的智能体。GitGuardian 的《State of Secrets Sprawl 2026》报告记录了 AI 服务凭证泄露同比增长 81%，并把原因之一归结为「MCP 配置指南把把凭证直接写进配置文件这件事常规化了」；该报告在公开 GitHub 的 MCP 配置文件中发现了 24,008 个唯一密钥，其中 2,117 个（约 8.8%）在检查时仍然有效。这是厂商视角的数据，但指向的问题与 CERT-In 公告里「凭证暴露在应用配置与公开仓库」这一条完全吻合。

3.2 所有者：一个人名，不是一个部门

台账每一行都必须能对应到一个具体的人名（可以是部门负责人，但必须有名有姓）。这里的现实困难是：调研显示，出问题时责任归属本身就是分散的——在 Dataiku-Harris Poll 的调研中，认为出问题该由多个团队共同负责的占 23%，指向中央 IT 的占 21%，指向数据与 AI 团队的占 20%，指向安全风险与合规部门的占 18%。责任分散的直接后果是没人真正负责把台账维护下去。指定一个具名维护人，是让台账活过第一个季度的唯一办法。

3.3 用途：它到底在解决什么业务问题

用途字段决定了后面所有风险分级的输入。写清楚它替代或辅助的是哪个人、哪个岗位的哪项任务，比写「AI 助手」有用得多。含糊的用途描述会导致评审时无法判断其权限是否合理。

3.4 可触达的数据与系统：写清单，不写「业务系统」

这一项要具体到表、到接口、到是否含个人信息。CERT-In 公告里那四类传统弱点之所以能被智能体利用，一个前提就是「攻击者能推断出你的资产结构」。反过来，台账写清楚哪些系统被接入了，也是在为防守方提供一份「这里有值得加固的点」的清单。

3.5 可停机性：一分钟内能不能停下来

这是本文最想强调的字段，也是当前最普遍缺失的一项。它至少要回答四个问题：

问题	合格答案的样子
停它的按钮在哪	具体到控制台路径、API 端点或配置项，不是「找运维」
需要多久生效	一个可承诺的时间上限，例如 1 分钟内停止外发
停掉之后影响什么	哪些在跑的流程会中断、中断是否可接受
谁有权停、谁必须被通知	明确到角色与通知路径

如果这四个问题里有一个答不上来，那么这个智能体对组织而言就是一个没有刹车的自动化流程。阿联酋市场那组数据——运行智能体最多的市场、也是两小时内无法遏制失控智能体比例最高的市场（5%，约为全球均值的一半）——说明这不是个别团队的执行问题，而是结构性问题。

停机能力要与本站另一篇文章形成互补：《AI Agent 运行时隔离怎么做》讲的是执行期的四道边界（身份、权限、网络、执行），那是「不让它越界」；本节的停机能力讲的是「越界之后怎么快速止损」，两者是不同的失效时刻。

3.6 风险等级：按后果分，不按技术分

建议按「错了会发生什么」分三档，而不是按「用了哪个模型」分：

• 高风险：接触客户、涉及资金或交易、读写敏感个人数据、可以影响生产系统写入。参考 Dataiku Agent Management 的做法，这类智能体需要保留常设记录：认证状态、已识别风险、定期重跑的测试项，使得在管理者、审计员或监管方提问时，证据链是已经存在的，而不是事后重建的。
• 中风险：只读内部非敏感数据、输出需人工确认后才生效。
• 低风险：纯内部辅助、只读、不触达外部。

分档的实际作用是决定复核频率与审批层级，而不是给智能体贴标签。

3.7 生命周期状态：草稿、运行、暂停、退役

没有「退役」状态的台账会持续膨胀，最终变成没人敢删的垃圾场。调研中有 47% 的 CIO 表示今年已经下线过 20 个以上的智能体，说明下线是高频动作——如果台账不支持下线，这件事就会变成纯粹的历史包袱。

---

四、发现：从「我知道的」到「实际在跑的」

台账的难点在发现，而不是在记录。有效的发现动作有四类，建议并行推进。

4.1 从平台侧拉：从每个构建平台取清单

这是成本最低的一步。逐个平台登录后台，把运行中的智能体导出为 CSV 或直接对照录入台账。需要接受一个现实：初期结果一定是不完整的，它的价值是给后续发现提供基线，让你之后能看出「又多了哪些」。

同时要反向做一件事：列出所有已知可能被使用的第三方平台与工具，包括 SaaS 内置的 AI 功能。这类内置功能是最容易被漏掉的一类——它不需要任何人安装，点一下开关就上线了。

4.2 从身份侧拉：找非人身份

非人身份通常是台账里最缺的一块，因为传统 IAM 往往只统计人和服务账号。实际可用的来源包括：云厂商的 IAM 角色与访问密钥列表、CI/CD 流水线的变量与密钥、Kubernetes 的 ServiceAccount、代码仓库中的配置文件（注意提交历史里的残留）、以及 SaaS 的 OAuth 授权记录。

GitGuardian 在其 2026 年报告中提到的做法可以参考——它的一个产品方向就是识别「哪些智能体能冒充哪些身份」并跟踪每个智能体的完整生命周期。这类「智能体—身份—可达系统」三元组的映射，正是台账在身份维度上最有价值的产出。

4.3 从网络侧拉：看实际出网流量

代理、DNS 日志与防火墙日志能回答一个台账文档永远回答不了的问题：到底有哪些机器在以程序方式访问外部 API。因为一个智能体可能压根没在任何平台注册，只存在于某个员工本地脚本里；但它一旦要调用模型 API，就一定要出网，就会留下流量痕迹。

在 Microsoft 系环境里，比较务实的做法是用 Defender for Cloud Apps 的云发现功能对流量做应用分类（其应用目录中已包含生成式 AI 分类及风险评分），并用 Microsoft Sentinel 的 AuditLogs 查询近期 OAuth 授权记录，把带有邮件、文件、日历权限的授权挑出来人工复核。这类查询的价值在于：它抓到的是已经发生的事实，而不是某个人的记忆。

4.4 从人侧拉：一次不带惩罚的申报

技术手段有天花板，因为总有东西看不见。所以必须配一次人工申报，且不申报不追责这一条是成败关键。

原因很实际：一旦第一个使用未批准工具的人被处罚，此后所有申报都会失真，工具只会转入更隐蔽的地下状态。相关的实务经验是一致的——治理的目标是让使用行为回到可见范围，而不是消灭使用行为。

申报时问三个问题就够了：你实际在用哪些 AI 工具或智能体？它接触了哪些工作数据？它替你做了哪一步工作？三问之后就能形成一份相当可用的初版台账。

顺带提一个反直觉但已被多方观察到的现象：在印度市场，员工使用个人 AI 账号的比例从上一周期的 79% 下降到 41%，而使用组织统一管理账号的比例从 30% 上升到 77%。也就是说，提供可用且合规的官方工具，比封堵更能降低影子使用。（该数据来自 Netskope 威胁实验室的 2026 年印度报告，属于厂商自有客户群的研究口径。）

---

五、把 CERT-In 的建议翻译成工程动作

2026 年 10 月 15 日 CERT-In 那份公告里，面向组织的建议条款里有几条可以直接当工程规范用，不需要翻译成企业语言。

第 9 条是本文最关心的：「治理组织内部署的 AI 智能体。为每次运行分配独立的、短时效的、最小权限的身份。强制默认拒绝的出网策略，仅允许必需的目标，并维护一份防篡改的智能体活动日志，至少覆盖所有影响生产系统与数据的动作。」

拆成四条工程动作：

1. 每次运行一个身份，不是每个智能体一个身份，也不是全公司一个身份。短时效意味着凭证泄露后的暴露窗口是分钟级而不是天级。这一条与《AI Agent 运行时隔离怎么做》中的身份边界是同一件事在治理层的表述。
2. 默认拒绝出网。这里有一条容易被忽略的技术细节：公告在面向模型研发与评测机构的部分明确要求，「在网络层强制执行该限制，而不是通过给模型的指令」。把安全边界写在提示词里是无效的——这一点与本站《AI Agent 提示词注入怎么防》里「指令与数据同构」的根本原因是同一个道理。
3. 防篡改日志，且至少覆盖影响生产系统的动作。注意「防篡改」这个词：日志要写到智能体无法触及的地方去，写在它自己的日志文件里等于没写。
4. 覆盖所有运行，包括第三方托管的智能体。很多企业把「我不用智能体」当成答案，但 CERT-In 那起事件的性质恰恰相反——攻击者是别人的智能体。因此除了管理自己的，还要关注接入的第三方 SaaS 智能体用了什么身份访问你的数据。

另外几条通用条款也值得直接采纳：第 2、3 条要求审计源码、仓库（含提交历史）、CI/CD 变量、配置文件、客户端应用与云存储中暴露的凭证，轮换并从历史中清除，且每次提交与构建都要做密钥扫描；第 4 条要求维护完整的 API 清单并下线休眠、废弃与测试 API 及账号；第 5 条要求在云与后端服务部署中落实最小权限、使用行级安全与最小权限客户端角色、绝不把特权密钥放进客户端代码，并测试一个匿名调用方能读写什么；第 7 条要求按速率做 API 异常检测，对枚举式探测、批量读取与自动化注册告警，日志至少保留 180 天；第 8 条则要求在凭证暴露或确认被访问后，在完成取证清除之前，把环境视为已被攻破，并预期数天至数周内会有重复尝试。

把这份清单压缩成一句话给管理层：证书和密钥不进代码、API 要有清单、权限要最小、出网要默认拒绝、日志要防篡改且留够 180 天、出事先当已攻破。

---

六、治理的三个阶段：知道、管住、说得清

台账建起来之后，治理可以分三个阶段推进，每个阶段对应不同的组织能力要求。

阶段一：知道存在什么（最小可用）

目标：能回答「我们运行了多少个智能体」这个问题，且答案在一天内可得。

必须做的：建台账、指定具名维护人、把可停机性四问答完、把每个智能体的身份与数据触达范围写清。这个阶段不需要买任何工具，一个结构化表格加一个共享目录就够。

验收标准：随机抽五个智能体，能在 5 分钟内说出它是谁的、连着什么、怎么停。

阶段二：管住边界

目标：把 CERT-In 公告里那几条工程建议落到实际配置上。

必须做的：默认拒绝出网、最小权限角色、独立短时效身份、防篡改日志、密钥全量扫描与轮换、休眠 API 下线、按速率的异常检测与告警、日志保留 180 天以上。同时给高风险智能体加上人工审批闸——这一步与驾驭工程中讲的「不可逆动作需要显式人工签字节点」是同一条原则的不同应用场景。

验收标准：高风险智能体的每一次影响生产的动作，都能在日志里查到「谁授权的、用什么身份、影响了哪张表」。

阶段三：说得清价值

目标：回答「这些智能体值不值」，以及「哪些该下线」。

这一阶段对应的是 Dataiku-Harris Poll 调研里暴露的最大缺口：虽然 90% 的 CIO 表示对智能体有完整的可追溯性，但只有 28% 表示持续度量了全部智能体的运行表现与业务表现，76% 表示组织缺少覆盖全部或大部分 AI 项目的成熟 ROI 度量框架，只有 21% 表示能按组织、团队或场景拆分 AI 成本并近实时追踪到明细项。

可追溯性回答的是「存在」，度量回答的是「值不值」，两者不是一回事。阶段三要建立的核心能力是：

• 成本归集到组织与场景。这一项与本站《大模型调用成本怎么控制》是同一套方法论的上下两层：那一篇讲单次调用怎么分档省钱，这一层讲的是把钱摊回到部门与业务线，让「值不值」这个问题有得聊。
• 业务指标与技术指标并列。技术指标是可用率、时延、成本；业务指标是工单解决率、审核准确率、处理时长。Dataiku 在其产品说明里把这层区分表述得比较清楚：可用率告诉技术团队智能体是否在跑，业务指标告诉管理者它是否安全地待在职责范围内、是否交付了当初部署它时预期的业务结果。
• 下线机制。既然 47% 的 CIO 今年下线过 20 个以上智能体，那么「定期复评 + 主动下线」应该是一套常规流程，而不是出问题时才启动的应急动作。

同一份调研里还有一组关于多模型并存的数字，值得在做阶段三规划时一并考虑：75% 的 CIO 计划使用更多或更多样的模型来保证 AI 运营连续性，74% 正在评估开源模型作为应对未来模型中断或不可用的保障，80% 已经完成或计划完成 AI 依赖关系风险评估。同时 91% 的 CIO 偏好在各业务单元的受管环境中直接构建，而不是由中心统一管理所有应用和智能体——这条偏好对台账设计有直接影响：治理机制必须是分布式的，台账必须是集中的。试图用集中式审批去匹配分布式构建节奏，结果通常就是绕过审批。

---

七、按规模分档的落地顺序

台账的深度应该与智能体规模匹配。做得太重会拖垮团队，做得太轻则在出事时无法取证。下面是一个按数量分档的建议。

少于 10 个智能体

一份共享文档就够。要求只有三条：每个智能体写清用途、所有者、以及怎么停；这份文档必须有一个具名维护人；每月过一遍。

这个规模下最常见的失败不是治理缺失，而是人员流动后无人接手。所以更重要的是在台账里加一列「原建设人是否已离职/长期休假」——调研机构在讨论「遏制差距」时也把「搭建它的人已经离职或长期休假」列为需要立刻动手的信号之一。

10 到 50 个

需要结构化了。台账要有固定的字段与下拉选项（平台、风险等级、状态），变更要有记录；停机能力要对高风险智能体逐个验证过，而不是靠文档声明。同时应该把密钥扫描与 API 清单这两件基础工作做掉——它们的收益与智能体数量无关，但越早做越省事。

超过 50 个

超过这个量级，仅靠人工台账必然失效。原因是可追溯性已经不是默认状态：调研中 81% 的 CIO 表示无法完全监督非批准渠道创建的智能体，说明相当一部分智能体根本不在任何组织的视野内。此时需要的是跨平台的自动发现能力：用 OpenTelemetry 这类开放约定把自建环境纳入统一采集，再对各主流平台分别取清单。类似 Dataiku Agent Management 的产品正在填补这个位置，其定价方式是按实例年费加按智能体计量的监控开销——这一点在预算时值得注意，中小规模团队通常不需要为这个能力付费，用表格加定期巡检就能覆盖。

即使在这个规模，仍然有一条免费建议：建立一条「新智能体上线前必须登记」的流程，并在提交表单里强制要求填写「怎么停」。这条流程的成本接近于零，但它决定了台账是活的还是静态文档。

---

八、十个常见误区

1. 只登记在自家平台上建的智能体。 覆盖面最小的一类做法，实际掌握的往往不到总数的一半。
2. 把台账当成一次性项目。 智能体每周都在新增，没有维护人的台账在一个季度内就会失真。
3. 只记名称与用途，不记身份与可停机性。 这两列恰恰是出事时唯一有用的两列。
4. 用部门代替人名做所有者。 责任一旦落到部门，台账就没有维护动力了。
5. 把「有日志」当成「有防篡改日志」。 智能体能触及的日志等于没有日志。
6. 只监控自家部署的智能体。 CERT-In 那起事件说明，攻击方可以是别人的智能体，第三方 SaaS 智能体访问你的数据同样需要被纳入台账。
7. 把安全边界写在提示词里。 CERT-In 公告明确要求在网络层强制执行默认拒绝出网，而不是给模型指令。
8. 用封堵代替提供合规选项。 结果通常是影子使用转入更隐蔽的形式，可观测性进一步下降。
9. 把可追溯性当成度量。 90% 有可追溯性 vs 28% 持续度量业务表现，这两个数字之间的落差就是第三阶段的工作量。
10. 忽略密钥与 API 这两件基础事。 CERT-In 公告里所有事件的根因弱点都是传统类型的，AI 只是把速度和规模放大了；GitGuardian 的数据显示 MCP 配置文件里仍有约 8.8% 的暴露密钥处于有效状态。台账做得再漂亮，也要先确保这些基础项被处理掉。

---

结语

智能体治理这件事，有一个反直觉的结论：最先要买的不是工具，最先要做的是记清楚自己有什么。

原因在开篇已经说过——CERT-In 公告里那些事件，受影响组织全部没有自行发现；Dataiku-Harris Poll 调研里，运行智能体最多的市场也是遏制能力最弱的市场。这两件事指向同一个判断：在智能体时代，「资产清单」本身就是一项防御资产。它决定了你在被越权访问时能不能发现，在监管问询时能不能举证，在人员流动后能不能交接，在预算评审时能不能说清回报。

对大多数企业来说，这条路径的成本并不高：一份结构化台账、一个具名维护人、一条新智能体登记流程、一份密钥与 API 清单、以及对高风险智能体逐个验证过的停机能力。这些加起来，通常是几周的工作量，而不是几个季度。

如果需要把台账和可观测性体系一起搭起来，我们的人工智能应用开发服务可以从链路设计与运行期可观测的角度切入；如果当前更需要先解决「智能体在哪里跑、用谁的权限跑」这个问题，可以先看AI Agent 长期记忆怎么设计中对身份与状态管理的讨论；涉及权限模型本身的，可以参考企业后台权限模型设计；对智能体从试点到生产的整体路径，可参考AI Agent 企业落地方案。

行业差异方面，医疗健康类系统除了本文的台账要求外，还需叠加数据隐私与操作留痕的具体做法，可参考医疗信息化的数据隐私与操作留痕；政务监管类项目则通常已有指标口径与权限留痕的基础设施，可参考政务监管系统的指标口径治理与集团企业多组织数据打通；面向内容生成的场景，标识义务是另一条独立的合规线，可参考AI 生成内容标识怎么落地。

技术方案与实施细节，可查看我们的技术能力、工程交付与交付流程说明；行业方案的适配差异，可查看行业方案或常见问题。

---

关于本文的来源与口径

本文引用的行业数据均标注了来源主体与时间，其中包含多份厂商或调研机构的口径，需在使用时注意：

• CERT-In 公告（2026 年 10 月 15 日，原文 Issue Date）为印度计算机应急响应团队（CERT-In）发布的公开通告，文中所述事件未点名具体的模型提供方与受影响组织，本文仅引用其公开的分类与建议条款。
• Dataiku-Harris Poll《2026 Global AI Report: CIO Edition》 为调研机构与厂商的联合调研，样本为 685 位 CIO、覆盖 8 个市场；其中涉及阿联酋市场的细分数据与「遏制差距」相关表述，来自第三方分析机构对该调研的转述与解读。本文在引用时保留了原始出处层级。
• IBM《Cost of a Data Breach Report 2026》 由 Ponemon Institute 执行，IBM 赞助并发布，样本为 602 家发生过泄露的组织，报告自身声明为非统计抽样且抽样框偏向信息安全体系较成熟的组织。本文因此将其数据作为方向性参考，而非行业平均值。
• GitGuardian、Netskope、OutSystems、Gartner 等的数据属于厂商自有研究或预测口径，本文已在正文相应位置标明。文中涉及 Dataiku Agent Management 的平台连接范围、功能描述与定价方式，属于厂商口径，不构成独立第三方验证结论。

本文未引用任何未经当日检索验证的数据，也未包含具体客户名称或项目数据。