AI 连接业务系统从哪里开始：先把只读这一段做扎实

只读这一段的价值，是它能给出可对照的证据：同一批单据，AI 查出来的结果与原系统对得上，数据范围和员工账号一致，查不到的时候能说清是没权限还是没数据。这些证据没拿到就把写操作打开，后面返工的概率更高。星云 PLUS AI 系统连接器的定位是连接现有系统，不换系统、沿用员工权限、关键操作人确认、调用审计。

为什么建议先把只读这一段做出来

不同团队的起点差别很大，验证目标和风险也不一样。有的先从知识库问答入手，让 AI 读制度、产品资料和 FAQ；有的直接要写操作，上来就想让 AI 改单据、发起审批；还有的先把已有数据读通，让 AI 回答跨系统的问题。

只读换来的东西很具体。只读调用本身不写入业务数据，但错误答案仍可能影响后续判断，因此仍要拿原系统记录逐项对照核验。业务人员可以在原系统对照字段和记录；对照样本应由双方事先确认，是否需要测试环境还要结合目标系统条件决定。此外，员工能看什么、能改什么这两个问题，放在同一个方案里讨论，通常会纠缠不清，只读这一段刚好把它们分开。

能靠只读解决的问题本来就不少。订单走到哪一步、库存够不够、这笔付款对上了没有，这类问题的答案就在已授权的数据里，查询本身就能解决。写操作要做的是把结果接回原来的流程，属于后面的扩展。

从只读开始并不适合所有问题。如果某个业务问题必须办理完才算闭环，只读这一段就要提前和责任人约定什么时候进入写入，避免这一段做完了，业务侧却觉得没什么变化。

只读不等于把数据库摊开：读什么、读多细

省事的做法有两种：给 AI 一个数据库账号，或者把整套接口一次性接上。两种做法都会让只读这一段失去意义。「只读」指的是不写业务数据，跟访问范围要开多大，是两个问题。

只读能力的范围要按业务问题来定：先看要回答什么，再看需要用到哪些单据和字段。顺序反过来，很容易一路铺开。有四件事需要逐个定下来。

方式怎么选要看系统条件。接口完整的系统走查询接口，规则清楚也便于日后扩展；只有数据库、缺少接口的系统，可以用受限的只读账号或只读视图，把可访问的表与字段圈住；页面比较成熟的系统，可以让 AI 在原页面里查询，员工看到的就是他本来就熟悉的界面。取数口径需要固化下来的场景，可以把口径写成 Skill 承载，避免每次都由模型临时组织。这几类属于数据库与只读 SQL、RESTful 接口、业务页面、Skill、Agent 五类接入方式中的常见组合，具体选哪几种、能开放到什么范围，以项目评估为准。

字段这一层容易被忽略。价格、成本、供应商报价、身份证号和银行账号进入对话上下文后，是否会出现在会话记录、输入输出摘要或调用日志中，要结合系统记录与脱敏配置核对。先在数据源头限定字段，可以缩小处理范围。

只读调用同样要授权、留痕、可撤回

「只读风险低」这句话在权限这一层不成立。员工在原系统看不到的客户、订单和科目，AI 也不该查得到。如果只读能力背后是高权限账号，就可能绕过原系统的权限范围。只读调用不写入业务数据，但数据暴露仍有实际影响，因此不能只按“有没有写操作”判断风险。

只读能力的发放方式与其他能力没有区别，按员工、用户组或组织授权。连接器这一层决定员工能否调用某项查询能力，功能权限与数据权限仍由目标系统按其账号规则作最终判断。AI 沿用员工个人账号访问目标系统，支持自定义认证，数据范围不会因为走了 AI 而放大。同一套查询能力发给不同岗位，返回的范围本来就应该不同；这一点在只读阶段就该验证，等到写操作上线再补，改动面会大很多。

记录同样要从调用这一层留起。只读调用进入审计的内容与其他调用一致：员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果以及输入输出摘要，支持查询与导出，审计保存期限由企业自行配置。查询类的记录有一个实际用途，有人问某条数据是谁看到的，答案要能从记录里找出来。

撤权要落到服务端才作数。调用前重新校验授权，撤权后禁止后续调用并中止尚未完成的那次调用；客户端界面上的可见性不参与这个判断，即使客户端还缓存着旧的工具列表，已撤权的查询请求同样会被拦下。只读能力也需要版本与发布记录，表结构或字段含义变了，要能追出是哪次变更影响了哪些回答。

只读阶段能对齐哪些证据

只读阶段要交出去的是一组能反复使用的对照样本。能不能查到只是其中一句结论；样本、对照和记录才是可以被复核的部分。业务负责人提供样本和正确答案，技术侧记录实际返回，双方看同一批数据。

同一条结论最好能看出处。带上来源单据与查询时间，业务人员复核时可以直接跳回原系统核对，不用再问一遍 AI 是从哪拿的。这一步做扎实，后面扩到更多系统时，沿用的是同一套核对方式。

缺失要写明，不能留白。员工权限之外的客户、订单或科目，查询结果里应当标注该部分证据缺失，由有权限的人补充。把「没查到」和「不该查到」分开记录，两种情况混成一个空白，后面很难判断是数据问题还是权限问题。

什么时候可以进入写入

只读跑顺之后要不要马上开放写入，取决于四件事是否已经具备，与只读阶段运行了多久关系不大。

权限和确认是两件事，不能互相替代。员工被允许调用某项能力，仍然要由目标系统判断他能看哪些数据；员工确认了预填内容，也仍然要读最终回执，页面预填不等于提交成功。把人工确认当成权限校验的替代品，等于把两类风险混在一起处理，出了事两边都说不清。

写入类能力开放到什么程度，各家企业的内控要求不同。哪些高风险动作纳入首轮、哪些能力可以配置成自动执行，都要在项目里逐项确认，不能沿用默认值。

只读阶段容易踩的几个坑

这几条省的都是当下的工，代价会在写入阶段出现。

结语

只读这一段做得扎实，交付的是一组可对照的样本、一条说得清的权限边界和一份查得到的调用记录。等到要打开写入时，讨论就有基础：哪些动作必须停在人手上、哪些可以配置成自动执行、出错之后怎么回到原系统。选一个价值明确、权限清楚、结果能核查的真实业务问题作为起点，把只读这一段的证据攒住，再按结果、权限、确认、审计、异常逐项验收，扩展系统的时候就不需要推翻前面做过的事。

常见问题

相关阅读

• 企业 AI PoC 怎样选首个可验收场景
• AI 最小权限怎么发：能力按角色收敛，数据边界归原系统