ERP接入AI和一体化企业AI的区别 从数据权限和受控动作看清楚

直接回答：区别不在有没有对话窗口，而在 AI 能不能拿到带权限的业务数据、能不能在权限内发起动作。一体化企业 AI 通过面向 AI 调用的接口取得业务信息，返回数据按调用者的功能权限与数据权限过滤，动作经执行审批并留审计日志；外挂式 AI 只基于给定资料作答。适用于已上 ERP、想在现有流程里加 AI 的企业，前提是接口已开放。

一、一个熟悉的经营困惑

不少企业这两年都给系统加了 AI：能问答、能写摘要、能生成报表说明。演示的时候很顺，真到业务上就卡住。问它「华东区上个月那三张订单为什么延期」，它答不上来，因为订单在 ERP 里，它读不到；再问「能不能把其中一张的交货期改到下周三」，它更做不到，因为改交期要改订单、要过审批。

老板的疑问就来了：同样是加了 AI，为什么有的能干活，有的答不上来？

二、这和开车有点像

给车装一块大屏，能显示导航、车况和油耗；但大屏不能替你踩刹车，也不能改变动力输出。差别在于：屏上看到的数字是不是来自整车本身的状态，屏上的操作是不是真的接到了车的控制系统。

三、先看一组演示数字

假设一次业务查询要过 4 个对象：客户、订单、库存、价格。每个对象要按 2 类条件过滤：能不能看（功能权限）、能看哪些范围（数据权限）。一次查询就是 8 项判断。

这 8 项，外挂式 AI 一项都做不了，因为对象不在它手里；一体化 AI 做得了，因为对象本来就在同一套系统里，判断由系统按调用者身份自动完成。

四、原来怎样处理

1. 准备资料（谁做：IT 或行政；依赖：有人把手册、制度、历史报表整理成文档）
2. 提问（谁做：使用人；依赖：问题写得够不够准）
3. 核对答案（谁做：使用人；依赖：自己对业务熟不熟，能不能逐项比对）
4. 落地（谁做：使用人；依赖：还要再走一遍系统里的原有流程）

这条链路里，AI 从头到尾没有接触业务库，给的是基于资料的分析；核对和落地仍然压在使用人身上。

五、现在怎样处理

取得信息。业务接口封装为面向 AI 调用的用户级 API，智能体在 YonWork 等智能场景发起调用。调用不采用 AK/SK 方式，改由友户通 Token 加用户分身完成身份校验；接口返回的数据，按该用户的功能权限和数据权限过滤，看到的范围与本人登录系统时一致。

封装与调用。MCP 服务管理把已有的开放 API 协议转换为 MCP 协议，封装成标准服务供智能应用调用。原厂提供系统级服务，客户也可按自己的接口自定义，每个服务有独立访问地址。

调用受控。调用经过网关，含身份鉴权、授权管理、限流控制、IP 黑白名单与防重放，链路追踪与集成日志可查。

发起动作。智能体的动作有工具执行审批并留下审计日志。分析发现风险后，智能体在业务对象上调用动作，生成协同任务或采购工单，由业务系统回写处理状态并刷新风险等级，保留「洞察—动作—结果」的链路。

六、为什么不是把软件全换成智能体

流程执行型软件负责按规则执行和精确计算，正式记录、规则校验与审批链仍在其中完成；智能体负责跨系统的查证、整理与发起。两者在同一底座上协同。换一种说法：AI 拿到的是受控的业务事实边界与操作边界，不是把数据库直接打开。

需要说明的是，预测、预警和自动提醒在传统软件里早已有之。这一轮的变化不是从无到有，而是这些能力开始与具体的业务任务连起来。

七、实际工作需要准备什么

1. 接口清单——哪些业务对象要开放给 AI 调用，接口是否已经发布
2. 权限口径——谁调用就按谁的权限返回，功能权限与数据权限是否已梳理
3. 动作范围——允许 AI 发起哪些动作，哪些必须由人来点
4. 审批与留痕——哪些动作需要审批，日志保留多久、谁有权查
5. 语义口径——业务对象的名称、关系与计算口径是否有统一定义

八、软件在其中能帮助什么

用友BIP 6 与 YonSuite 提供面向 AI 调用的接口能力与 MCP 服务管理，把业务能力以受控方式开放给智能体；YonWork 侧提供统一身份认证、工具执行审批与审计日志。具体可用范围按版本和配置条件启用，启用前需确认接口清单与权限口径。