大家好,我是金全。

上一篇讲到一个问题:

AI 把事情做对了,也可能不该这样做。

这一篇继续往下问:

企业怎么避免 AI 越界?

我的答案是:

先划清 AI 的行动边界。

但这里有一个很关键的变化:

传统权限管理,管的是“谁能进系统”。

AI 行动边界,管的是“它进去以后,能不能自己做动作”。

一个账号能访问工单系统,不代表 AI 可以关闭工单。

能看运维平台,不代表它可以重启实例。

能读数据库,不代表它可以修改数据。

所以,AI 进入生产以后,

问题不只是“给不给权限”。

而是要把它能做的事分清楚:

哪些只能查。

哪些只能建议。

哪些可以自动执行。

哪些必须人工确认。

哪些永远不能交给 AI。

这件事听起来不新鲜。

但 AI 进入生产以后,它会变得非常关键。

因为 AI 的风险,不只是来自模型。

也不只是来自工具。

而是来自它通过工具做了什么事。

AI 开始进入真实工作流

过去两年,很多企业里的 AI 主要做几件事:

查知识。

写内容。

总结信息。

但最近一年,一个明显变化开始出现。

越来越多 AI 不再只是提供答案。

它开始创建工单。

开始修改代码。

开始触发流程。

开始调用自动化脚本。

开始参与生产处置。

这意味着,企业第一次面对一种新的对象。

它既不是员工。

也不是传统软件。

但它正在影响真实业务结果。

过去企业最怕员工越权。

未来企业还要开始防 AI 越界。

这也是为什么,行动边界开始变得越来越重要。

风险不在工具名里,而在行动边界里

现在很多企业做 AI 项目,都会先证明一件事:

  • AI 能接上系统。

  • 能接知识库。

  • 能接工单平台。

  • 能接运维平台。

  • 能接审批流。

  • 能接数据库。

这当然重要。

但“接上”不是终点。

真正的问题是:

接上以后,AI 到底能做什么动作?

同样是一个工单系统。

查工单,风险不高。

创建工单,已经进入流程。

关闭工单,可能影响服务承诺。

升级工单,可能触发新的责任关系。

同样是一个运维平台。

查指标,是观察。

生成建议,是辅助。

重启实例,是处置。

修改配置,就是生产变更。

所以,企业真正要管的,不是“AI 能不能接入某个系统”。

而是:

AI 在这个系统里,到底能做哪些动作。

 

这个问题,比“接了几个工具”重要得多。

 企业过去给人授权,本来也是在划边界

这件事其实不陌生。

企业过去给人授权,也不是简单说:

你能不能进这个系统。

而是会区分:

你能不能查看。

能不能新增。

能不能修改。

能不能删除。

能不能审批。

能不能导出。

能不能发布。

一个员工可以查看客户资料,不代表可以修改客户信息。

可以提交审批,不代表可以批准审批。

可以查看监控,不代表可以重启服务。

这就是企业管理里最基本的权限常识。

但 AI 进来以后,很多团队反而容易忘了这一点。

因为大家太容易被“Agent 接了什么工具”吸引。

可真正决定风险的,不是工具名。

而是行动边界。

过去企业管理人,核心是权限管理。

AI 进入生产以后,企业第一次需要管理一种新的对象:

一个会自己理解问题、自己选择工具、自己执行动作的新对象。

所以这件事不只是权限设计。

而是企业要重新管理 AI 的行动过程。

边界不是写出来的,是运行时执行出来的

真正难的,不是写一句:

AI 只能建议,不能执行。

也不是在 PPT 里画一条线:

哪些能做,哪些不能做。

生产系统里,边界必须能被执行。

比如,你规定:

AI 只能建议,不能直接执行。

那企业要能证明:

它确实没有绕过人工确认。

你规定:

AI 不能修改数据库。

那企业要能拦住:

它通过工具、脚本或账号绕进去。

你规定:

生产变更必须人工审批。

那企业要能验证:

每一次动作有没有经过审批。

过去传统系统里,这些边界通常由权限系统、审批流、运维规范来执行。

但 AI 进来以后,问题变复杂了。

因为它不是一个简单执行命令的软件。

它会理解问题。

会选择工具。

会生成参数。

会决定下一步动作。

所以,企业不能只给 AI 画边界。

还要让边界在运行时真正生效。

企业需要一套新的运行治理机制。

简单说,就是不能只给 AI 一个账号。

还要管住它每一步能不能做。

换成更具体的话:

要有一个东西,持续决定:

什么能做。

什么不能做。

什么必须确认。

什么必须拦截。

这才是行动边界真正落地的地方。

工具入口,是边界被执行的位置

那为什么还要讲工具入口?

因为 AI 的行动不是凭空发生的。

它每一次查数据、建工单、改配置、跑脚本、推流程,最终都会通过某个工具、账号、流程或接口进入真实系统。

工具入口不是一个技术细节。

它是边界被执行的位置。

入口后面连着什么系统。

允许做什么动作。

动作发生后影响什么结果。

这些才是企业真正要看清楚的。

行动边界,最后要落成一张动作清单

前几篇一直在讲:

AI 进入生产以后,企业需要管它的行为。

但行为不能只停留在概念上。

行为必须拆成动作。

所谓行动边界,最后要落到一张动作清单上。

查询是一类。

建议是一类。

创建是一类。

修改是一类。

审批是一类。

执行是一类。

越往后,风险越高。

越不能只靠模型自己判断。

企业要说清楚:

哪些动作可以自动执行。

哪些动作只能建议。

哪些动作必须人工确认。

哪些动作必须留痕。

哪些动作必须可回滚。

哪些动作永远不能交给 AI。

这不是保守。

这是生产系统的基本常识。

过去人做生产变更,也不是想改就能改。

要有窗口。

要有审批。

要有灰度。

要有审计。

AI 进入生产系统以后,也不能因为它更聪明,就绕过这些东西。

看不见边界是否被遵守,边界就等于没有

我做了十几年生产系统和可观测性,越来越觉得:

生产环境里的规则,不能只靠相信。

必须能看见。

必须能验证。

必须能复盘。

AI 的行动边界也是一样。

你说 AI 只能建议。

那就要看见它有没有执行。

你说 AI 不能改配置。

那就要看见它有没有尝试调用修改工具。

你说高风险动作必须人工确认。

那就要看见确认发生在什么时候、由谁确认、确认了什么。

所以,行动边界最后一定会走向 AI 可观测性。

这里的可观测性,不只是看模型回答了什么。

而是看:

AI 看到了什么。

选择了什么工具。

生成了什么参数。

触发了什么动作。

有没有越过边界。

有没有留下证据。

过去可观测性主要回答:

系统为什么出问题?

 

AI 进入生产以后,企业还要回答:

AI 为什么做出这个动作?

这才是 AI 行为真正需要被观测的地方。

过去我们观测的是:

请求。

服务。

数据库。

今天开始,企业还要观测:

意图。

判断。

工具。

动作。

结果。

系统状态,正在扩展成行为状态。

所以,AI 可观测性不是监控模型本身。

而是在监控 Agent 的行为边界。

最后

过去,很多企业看 AI,先看模型。

模型准不准。

推理强不强。

回答好不好。

这些当然重要。

但 AI 一旦进入生产,真正要先问的是:

它的行动边界在哪里?

因为 AI 出问题,往往不是“接了哪个工具”这么简单。

而是它通过那个工具,做了一个不该自动做的动作。

所以,AI 治理的起点,不只是模型治理。

而是行动边界。

但边界本身并不够。

边界要能被执行。

要能被观测。

要能被审计。

企业第一次需要认真回答:

企业真正要管理的,

已经不是 AI 会不会做。

而是:

哪些事情,永远不能让它自己做。

过去企业管理的是人和软件。

未来企业还要开始管理会行动的 AI。

AI 时代最大的变化,不是 Agent 开始行动。

而是企业第一次需要观测和治理 Agent 的行动。

#AI系统 #AI运行系统 #AI可观测性 #因果AI #AgentOps

推荐阅读

  • 在当今数字化时代,企业的成功与否在很大程度上取决于其应用程序的性能表现。apm应用性能管理服务​因此应运而生,作为一项关键策略,帮助企业实时监测、分析、优化应用程序的性能。

    2023-08-16

  • 随着数字化时代的到来,监控API成为了维持在线业务高可用性和用户体验的关键要素之一。在选择适合自己的监控API时,必须从用户的角度出发,确保满足他们的需求,提高他们的体验质量。本文将重点介绍监控API​的重要性,并以基调听云为例,阐述如何选择适合您的监控API,以保障消费者的满意度和在线业务的顺畅运行。

    2023-10-24

  • 随着微服务架构的兴起,平台微服务中心化治理功能成为了现代软件开发中的热门话题。作为一种集中化管理和控制微服务的手段,它为开发团队提供了一种强大的工具,可以确保微服务的稳定性、安全性和性能。

    2023-06-26

  • 在企业信息化发展的进程中,运维管理的监控平台扮演着至关重要的角色。这一平台不仅是保障企业系统正常运行的基石,更是提高效率、预防故障的得力工具。本文将深入研究运维管理监控平台​,明确其核心特点,为企业在选择和优化监控平台时提供关键指导。

    2023-12-20

  • 观察典型高性能应用程序的延迟情况,我们通常会发现应用的延迟大多会在一个狭窄的范围内变化,但是偶尔会出现非常高的延迟,这对于高性能应用程序的影响可能是巨大的。

    2022-02-08