大多数 AI 已经进了系统,但还没有拿到决策权。问题不在模型聪不聪明,而在出了事以后能不能说清楚。

 

企业真正害怕的,

从来不是AI 犯错

而是:

AI 出了问题以后,

没人能说清楚,

它为什么这么做。

 

这两年,我和不少金融、运营商、政企客户交流 AI 落地,明显感觉到一个变化:

大家已经不太问“AI 能不能用”了。

因为它已经在用了。

客服在用,知识库在用,运维在用,审批辅助在用,数据分析也在用。

很多企业内部已经有一批 AI 应用跑起来了,有的效果还不错。

但聊到最后,真正卡住大家的,往往不是“能不能用”,而是另一个问题:

这件事,能不能让 AI 自己决定?

 

我的判断是:

大多数 AI 已经进了系统,但还没有拿到决策权。

 

不是因为模型不够聪明。

而是因为一旦出事,企业还回答不了三个问题:

为什么这么判断?

谁批准它这么做?

出了问题谁负责?

 AI 在流程里,不等于 AI 被授权

今天的企业 AI,很多已经不是 Demo 了。

银行、保险、证券行业,

AI 已经进入客服、营销、风控辅助、知识管理和运维场景。

运营商政企客户里,

AI 也开始参与告警分析、工单推荐、知识检索、审批辅助和数据分析。

但你如果继续往里看,会发现它大多数时候还是“辅助”。

它可以给建议。
可以写总结。
可以找资料。
可以帮人判断优先级。

但一到授信、理赔、交易风控、客户承诺、核心运维处置、生产变更这些场景,企业立刻会谨慎很多。

原因很简单:

这些地方不是“答错一句话”的问题。

一旦错了,就是客户问题、合规问题、生产问题,甚至是管理责任问题。

所以,AI 在系统里,不等于 AI 被授权。

授权也不是一个简单开关。

企业真正关心的是:

  • AI 只能给建议,还是可以参与判断?

  • 它能不能触发流程?

  • 它能不能调用工具?

  • 它能不能自动执行?

  • 它能不能影响最终业务结果?

 

今天很多 AI 拿到的是建议权

 

少数开始拿到判断权


真正拿到执行权的很少。


拿到最终决策权的,就更少。


企业不是不用 AI。

 

而是不敢轻易把权力交出去。

 

核心业务怕的不是 AI 犯错,而是错了说不清

很多人讨论 AI 进核心业务,第一反应是模型准确率还不够、幻觉还没解决、成本还要降。

这些都对。

但在核心业务里,更要命的不是 AI 有没有一次答对。

而是它答错、做错、判断错以后,企业能不能说清楚。

传统系统也会出问题。

分布式系统、缓存、消息、配置、依赖、网络、变更,哪一个都可能出故障。

但传统系统有一套相对成熟的处理方式:

有日志,有指标,有链路,有告警,有变更记录,有权限审批,有故障复盘,也有责任分工。

出了问题,大家至少知道从哪里查。

哪个接口异常?
哪次变更引入了问题?
哪个依赖拖慢了链路?
哪个团队负责修?

不一定每次都查得很快,但这条责任链是存在的。

AI 麻烦的地方在于,结果错了以后,很多时候你不知道该查哪里。

是模型判断错了,还是依据本来就错了?
是提示词没写清楚,还是业务规则没有放进去?
是上下文带偏了,还是客户状态理解错了?
是知识库版本不一致,还是检索出来的证据就不该用?
是工具调用越界,还是本来就缺少人工复核?

如果这些问题回答不了,企业就不敢把关键决策交给 AI。

因为核心业务里,没人能用一句“可能是模型幻觉”把事情交代过去。

 真正的压力,经常发生在事后

AI 风险最难的地方,不一定是输出那一刻。

很多时候,真正的压力在事后。

客户投诉了。
内审介入了。
监管要求说明依据了。
事故复盘开始了。

企业开始进入“追责模式”。

这时候企业必须回答:

当时 AI 用的是哪个模型版本?
用了哪一版提示词?
查了哪份知识?
参考了哪些客户信息?
命中了哪条业务规则?
调用了哪个工具?
谁批准了这个动作?
哪个环节放行了结果?

这些如果说不清,AI 就很难进入高责任业务。

举几个很现实的例子。

  • 客服 AI 错误承诺了费用减免、理赔范围或产品收益,后面可能就是客户投诉和监管风险。

  • 风控 AI 放过了一笔高风险交易,或者误伤了正常客户,问题就不只是模型效果,而是客户权益和合规责任。

  • 运维 Agent 在一次核心交易系统告警里建议重启缓存节点,但真正原因其实是上游数据库连接池耗尽。如果它自动执行,可能会把小故障放大成二次事故。

这时候,企业不会只问:

“AI 当时是不是很聪明?”

企业会问:

“它为什么这么判断?”

“谁授权它执行?”

“执行错了怎么回滚?”

“责任到底落在哪个环节?”

这几个问题回答不了,AI 就只能停留在辅助。

 决策权要分级,不能一把放出去

企业不能简单问:

“要不要让 AI 自动执行?”

这个问题太粗了。

真正要问的是:
在哪些场景、哪些系统、哪些时间窗口、哪些风险等级下,允许 AI 做什么?


同一个 AI Agent,在不同环境里的权限应该完全不同。

在测试环境,它可以多做一点。
在非核心生产系统,它可以有限执行。
在核心交易链路,它可能只能给建议。
到了数据库、网络、权限系统这些地方,就必须强审批。

动作本身也要分级。

查询、分析、通知,风险相对低。
重启、扩缩容、限流、切流,风险就上来了。
配置变更、数据修改、权限变更,这些更不能随便交给 AI。

所以授权不是“给不给 AI 权力”。

而是要把边界说清楚:

  • 它能看什么?

  • 能建议什么?

  • 能触发什么流程?

  • 能调用哪些工具?

  • 哪些动作必须人工审批?

  • 哪些事情永远不能让它做?

这些边界如果不清楚,AI 越强,风险越大。

因为能力越强,越可能把错误放大。

企业缺的不是一堆日志,而是一条能追到底的链

过去我们做 APM 和可观测性,追的是一次请求怎么走。

从网关到服务,从服务到缓存、数据库、外部依赖。
请求慢在哪里,错在哪里,谁影响了谁。

AI 也需要被追踪。

但它要追的不只是调用链。
一次 AI 判断,最好能追到:

  • 用户当时问了什么

  • 系统给它拼了哪些上下文

  • 它查了哪些知识和证据

  • 用的是哪个模型版本

  • 命中了哪些业务规则

  • 调用了哪些工具

  • 工具返回了什么

  • 谁批准了动作

  • 最后影响了什么业务结果

这不是为了多存几条日志。

而是为了出事以后能回答:

它到底做了什么?
它为什么这么做?
错是从哪里开始的?
下一次应该改哪里?

这就是我理解的 AI 可观测性和传统可观测性的区别。

传统可观测性更多回答:
服务是不是健康?
请求是不是异常?
性能是不是变差?

AI 可观测性还要回答:

这次 AI 的结果,是由哪些输入、知识、上下文、模型、工具和规则一起推出来的?

企业真正需要的,不是事后看到一堆日志。

而是能判断:
到底是哪一个因素导致了错误结果。


这一步,就是从“看见”走向“归因”

 模型更强,也不会自动解决责任问题

很多人会说,等模型再强一点,这些问题自然会少。

我不这么看。

模型变强,当然会让很多场景更好用。

但它不会自动建立责任链。

如果检索到的证据错了,更强的模型可能只是把错误证据讲得更顺。
如果上下文被污染,更强的模型可能只是更自然地沿着错误方向推理。
如果工具权限没有边界,更强的 Agent 可能执行更复杂的错误动作。
如果业务规则没有进治理体系,更强的模型也不知道企业真正不能越过哪条线。

模型越强,错误有时候越难发现。

因为它错得不粗糙。

它会错得很像真的。

这对核心业务来说更危险。

系统看起来正常。
回答看起来合理。
流程看起来完整。

但业务结果已经偏了。

 技术负责人真正要问的 6 个问题

如果你是 CTO、CIO、AI 平台负责人,或者负责架构、运维、可观测性的负责人,我建议不要只问:

我们接了哪个大模型?
准确率提升了多少?
提示词优化得怎么样?

真正要问的是这 6 个问题:

每一次 AI 建议、判断和动作,有没有完整记录和审计留痕?

 

模型版本、提示词版本、知识库版本、检索证据、工具调用和用户上下文,能不能回放?

 

结果错了以后,能不能判断问题来自模型、数据、知识、检索、规则、权限、流程,还是人工复核?

 

AI 在哪些系统、哪些动作、哪些风险等级下可以自动执行,哪些必须审批,哪些永远不能执行?

 

AI 结果变成客户承诺、审批、交易、理赔、处置或生产动作前,有没有复核、校验、灰度、拦截、降级、熔断和回滚?

 

出错以后,能不能把规则、知识、提示词、权限、流程和责任分工一起改掉,让下一次风险下降?

 

这 6 个问题如果没有答案,AI 就还不适合接管关键决策。

不是因为它不够聪明。

而是因为它还不可负责。

 从能用到被授权,中间差的是治理

企业 AI 的下一步,不是简单的模型升级。

而是从“能用”走向“可信”,再走向“可授权”。

能用,解决的是效率问题。
可信,解决的是解释问题。
可授权,解决的是责任问题。

运维负责人来说,AI Agent 能不能进入生产处置,不取决于它能不能分析告警,而取决于它能不能被纳入现有的权限、审批、变更、回滚和复盘体系。

金融行业来说,AI 能不能参与关键业务,不取决于它能不能生成一个看似合理的答案,而取决于它能不能经得起监管、内审、客户投诉和业务连续性的追问。

 AI 平台负责人来说,平台的下一步也不只是模型网关、提示词管理和知识库接入。

更重要的是,能不能把 AI 的每一次判断和动作说清楚、查清楚、管起来。

这件事,我更愿意把它叫做 AI 的运行时治理

它管的已经不是模型本身。
而是 AI 在生产环境里的真实行为

如果用一个英文词,就是 AI Runtime Governance

具体一点说,就是 AI 每一次理解、判断、调用、执行和被追责的过程。

过去治理的是系统状态。
现在治理的是 AI 行为。

过去追的是故障链路。
现在追的是行为链、证据链和责任链。

 不被信任的 AI,永远拿不到决策权

前两篇我讲了两个判断:

AI 不可控,问题不在模型,而在整个 AI 运行系统。
AI 失控不是偶然,而是系统结构导致的必然风险。

这一篇我想补上第三个判断:

AI 拿不到决策权,不是因为企业保守,而是因为责任链还没有闭合。

企业真正要的不是一个会回答问题的 AI。
而是一个出了问题以后能解释、能归因、能控制、能追责的 AI 运行系统。

这也是我为什么持续讲“因果 AI”。

因果 AI 不是为了再造一个概念。

它要解决的是一个很朴素的问题:

什么原因导致了什么判断?
什么证据支撑了什么动作?
什么边界阻止了什么风险?
哪个环节变了,最后结果才会变?

这些问题回答清楚,AI 才可能从辅助工具变成被授权的生产能力。

不可控的 AI,只能做工具。
可负责的 AI,才可能获得授权。

不被信任的 AI,永远拿不到决策权

 

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

推荐阅读

  • 作为一名运维工程师,我深知运维数据对于业务的重要性。它可以帮助我们了解业务的健康状况、性能指标和故障情况,从而及时采取措施保证业务的正常运行。但是,运维数据往往是非常庞大和复杂的,如果不能有效地处理和管理,很容易导致信息的混乱和失控,甚至给业务带来严重的影响。

    2023-05-30

  • 网络性能监控​在当今数字化时代的企业运营中变得至关重要。随着企业依赖网络进行日常业务的增加,确保网络畅通、稳定运行成为了一项关键任务。本文将深入研究监控网络性能的重要性以及实施监控的关键步骤和方法。

    2023-12-21

  • 网站用户体验分析成为评估和改进网站用户体验的关键过程。它通过深入了解用户的行为、感受和需求,揭示用户体验中存在的问题,并提出改进建议。为了创造出令人满意和愉悦的用户体验,网站需要关注多个方面。

    2023-06-28

  • 随着网络技术的快速发展网络性能监控变得越来越重要。网络性能监控是对网络设备、服务器、应用程序等进行监控和管理的过程,以确保网络的稳定性和可靠性。网络性能监控基础​包括以下四个方面。

    2023-10-20