企业AI智能体先别放权：上线前要过四道治理检查

企业AI智能体接入真实业务前，应依次通过四道治理检查：责任是否落实到人、工具和数据权限是否受限、安全防线能否通过可复现测试、异常发生后能否停止并追溯。判断依据不是演示效果，而是每项控制都有负责人、配置记录、测试结果和明确的阻断条件。

NIST AI风险管理框架 是自愿使用的风险框架，旨在把可信性考虑纳入AI产品、服务和系统的设计、开发、使用与评估。企业可在这一风险管理逻辑之上设置四道上线闸门：只有证据与实际后果相匹配，智能体才能获得相应范围的生产权限。

先按后果分级，再设置放行门槛

风险等级不应由模型规模或项目预算决定，而要看一次错误动作可能造成什么后果。评审至少要记录智能体接触的数据、能够调用的工具、动作是否可逆、影响对象、单次和累计影响，以及人工发现并纠正错误所需的时间。

新加坡IMDA于2026年1月22日发布的 智能体AI治理框架 要求部署方预先评估并限定风险，限制智能体的自主程度及其对工具和数据的访问，并在重要节点设置人工批准；智能体可能接触敏感数据或改变外部环境，例如更新客户数据库或发起支付，因此权限和动作后果必须直接进入风险评估。

• 低风险：只处理公开或低敏感度信息，不能修改业务系统，输出经人工审阅且错误容易撤回。可采用基线控制，但仍需指定责任人并保存调用记录。
• 中风险：处理内部或个人数据，能够写入业务系统，或输出会影响客户、员工和业务流程。应增加独立复核、关键动作人工确认、独立服务身份和持续告警。
• 高风险：涉及资金、关键基础设施、安全控制、重大权益决定，或错误难以逆转。原则上不开放完全自主执行；确需部署时，应采用逐项批准、严格限额、隔离环境和可立即启用的停止机制。

以上三级是企业内部的放行建议，不替代所在地法律、行业监管或合同义务。无法判断后果或可逆性时，应先按较高等级评审，再根据证据缩小控制范围。

第一关：把责任落实到有决策权的角色

上线申请首先要回答“出问题时谁能决定”，而不是只列出项目组名称。至少应明确业务责任人、技术运营者、安全批准者和事故处置决策者；小型团队可以由一人兼任多个角色，但批准关系、利益冲突和替补安排仍要写清。

业务责任人批准用途、影响对象和残余风险；技术运营者维护模型、系统提示、工具连接和版本；安全批准者审查权限与测试证据；事故决策者有权暂停任务、撤销凭据并启动处置。采购第三方方案时，还要划清供应商与企业各自承担的控制责任，并规定模型、工具或依赖项变化后由谁发起重新验收。

这一关的最低证据是一份责任矩阵，列出关键决定的执行者、批准者、咨询对象和通知对象，并附升级路径、替补人员与响应要求。没有业务责任人、安全评审无权阻断、事故发生后无人能停机，或者供应商与企业之间存在责任空白，都应阻止上线。

第二关：按任务切分权限，不给通用身份

智能体只能获得完成已批准任务所需的最小权限。企业应分别配置它能读取哪些数据、调用哪些工具、对哪些对象执行何种动作，以及单次和一定周期内的操作上限，避免交付员工完整账号、长期密钥或通用管理员权限。

权限控制必须落在身份、网络、工具接口和业务系统边界，不能只写进提示词。生产环境应采用独立服务身份、短期凭据、工具白名单、参数校验和作用域限制；读取信息、生成建议、创建草稿、提交变更和最终执行应尽可能拆成不同权限。付款、删除、大批量修改或外发敏感信息等高后果动作，应在执行前触发人工批准。

验收时要让智能体实际尝试越权，包括访问未授权数据、调用白名单外工具、修改范围外对象、绕过人工确认和重复执行同一动作。合格证据应包括权限策略、被阻断的测试记录、凭据有效期和权限所有者；只要越权能够成功，或日志无法识别实际使用的身份，就不能进入生产环境。

第三关：用可复现测试验证防线

测试应覆盖正常任务、可预见误用和主动攻击，而不是抽查少量对话。输入材料、模型与提示版本、工具配置、预期结果、实际结果和判定标准都要保存，使另一名评审者能够重复测试并得到可比较的结论。

2026年6月24日发布的 OWASP AISVS 1.0 提供可验证、可测试、可实施的AI系统安全要求，覆盖从数据收集、模型训练到部署、监控与退役的生命周期；其三个验证等级分别对应所有AI系统的基线控制、处理敏感数据或重大决定的系统，以及面对复杂威胁的高保证环境。

企业可以把这些安全要求转成具体用例，但不能把达到某个等级视为无条件通行证。针对智能体，还应测试提示注入、恶意工具返回、敏感数据泄露、记忆污染、任务劫持、循环调用、重复交易、跨租户访问和依赖项失效。每项测试都要预先定义通过条件；修复后必须回归测试，模型、系统提示、工具、权限或关键数据源发生实质变化时也要重测。

低风险场景至少应验证基线控制和关键越权路径；中风险生产系统宜采用适用于敏感数据和重大决定的验证深度，并由开发者之外的人员复核；高风险场景则应采用最高保证深度，再补充行业特定测试和独立保证。这是企业放行门槛的建议映射，最终范围仍取决于实际后果和适用规则。

第四关：上线前验证停止、监控与审计

监控不能只看模型是否报错，还要识别动作是否偏离批准用途。日志至少应关联请求来源、智能体与配置版本、使用的身份、工具和参数、读取或修改的对象、人工批准、执行结果及失败原因；日志包含敏感数据时，也要设置访问控制和保留期限。

上线前应实际演练暂停新任务、终止运行中任务、撤销服务凭据和断开工具连接。停止后还要确认队列中的延迟任务不会继续执行，尚未提交的动作不能绕过审批，并能依据审计记录确定受影响对象。只有停止按钮，却没有执行权限、值班责任人和演练记录，不构成有效控制。

告警信号可以包括越权尝试、工具调用异常增加、重复动作、失败率突变、敏感字段外发和人工否决增加。达到预设阈值后，系统应按风险进入降权、只读、转人工或完全停止状态；恢复服务由谁批准、需要哪些修复和复测证据，也应预先写入运行手册。

最终放行只看证据包是否闭环

上线评审应围绕一个可追溯的证据包作决定：风险分级及依据、责任矩阵、数据与工具清单、权限策略、测试用例和结果、未解决风险、监控指标、停止演练记录、供应商依赖与变更计划。每项材料都应标明所有者、版本和批准记录，产品演示或模型准确率不能替代这些证据。

1. 四道检查全部通过，且残余风险落在业务责任人书面批准的范围内，才能按限定权限上线。
2. 控制已经配置但证据无法复现，应退回补测，不能用口头条件换取放行。
3. 高后果动作缺少人工节点、权限无法收窄、关键攻击测试失败或停止机制未经演练，应直接阻断。
4. 上线后若模型、提示、工具、权限、数据源、供应商或用途发生实质变化，应重新分级并重跑受影响的检查。

四道检查把“认为安全”变成可审计的答案：谁承担责任、系统如何限制权限、测试怎样证明控制有效、异常如何停止。智能体获得的自主权越大，企业要求的证据应越具体，初始放行范围也应越窄。