集成可行性的第一步判断不在模型侧，而在数据侧。先把需要的数据能否稳定取到问清楚，取不到的场景不必写进方案。真正决定项目能否落地的往往是 ERP 厂商是否配合开放接口，而不是用了哪一家的大模型。
企业在 AI 上的第二笔投入，经常是"把已经买好的 AI 接进现有系统"。第一笔买的是工具，第二笔买的是它能不能嵌进日常工作。这笔投入的成败，通常在第一周的接口梳理阶段就已经决定了。
决定成败的是接口不是模型
模型能力在多数业务场景里不是瓶颈。合同要点提取、工单归类、报表初稿生成这类任务，当前主流模型的表现在水平线上。差异出现在别的地方，也就是需要的数据能否从业务系统里稳定取到。
一个典型的分歧是这样的。方案里写"自动提取订单信息并生成对账单"，听起来顺理成章。实际推进时发现 ERP 的订单接口只开放给厂商自己的移动端，第三方调用需要额外申请且按年收费；或者接口存在但返回字段缺少对账需要的明细。到了这一步，方案就得重做。
所以评估顺序应当把接口放在前面。模型选型可以后置，因为它相对容易更换。
接口梳理要确认的四件事
系统提供了什么。 分三类，标准 API、数据库视图或直连、以及只能人工导出。三类的集成成本差别很大，标准 API 最低，人工导出的方式通常只能做低频批处理。
能取到什么字段。 接口存在不等于数据齐全。需要把场景用到的字段逐个核对，确认接口返回中确实包含，而不是想当然认为"系统里有的接口就能取"。
调用频率与限额。 有些接口有频次限制，有些在业务高峰时段响应很慢。如果场景需要实时响应，这一点必须先验证。
谁有权开放。 部分系统的接口开放需要原厂商确认或额外采购，准备周期可能比技术实现更长。这一项常常被漏掉，导致排期表看起来可行、实际卡在流程上。
梳理完这四项，可以形成一份数据来源清单。清单上不存在的场景，直接不进下一轮讨论。
哪些环节适合先接
判断标准可以沿用落地评估的三个口径，数据能拿到、流程稳定、判错代价可控。在这个基础上，有几类环节的适配度普遍较高。
信息提取与归类。 从合同、发票、工单、邮件这类半结构化内容里提取要点，归到对应字段或分类下。这类任务的结果可人工核对，错了容易发现。
建议型辅助。 客服回复草稿、销售跟进话术、工单处理建议。输出是建议而不是执行，人工确认后才发送，风险可控。
初稿生成。 报表说明、月结分析、项目周报的初稿。把整理工作从人工的一小时压到几分钟，人工做的是核对与补充。
检索与问答。 制度查询、历史工单检索、产品资料查询。这类需求通常由内部知识库承接，再嵌到原有界面里。
相对谨慎的是自动写入类操作。让模型直接修改订单状态、审批单据或对外发送内容，一旦判断错误，回退成本高。这类场景建议先做建议模式，运行一段时间后再评估是否放开执行权限。
怎么接才不会动坏业务系统
技术上有两种思路，区别在于是否触碰业务系统本身。
侵入式改造指在 ERP 或 OA 内部增加功能模块。这种方式耦合度高，业务系统升级时容易冲突，出问题也较难定位。
中间层方式指业务系统保持原样，AI 能力通过接口以独立服务的形式接进来。数据流向是单向读取为主，写回操作也经由接口完成。这种方式的代价是部分场景受限于接口能力，收益是业务系统的稳定性不受影响。
对绝大多数中小企业，中间层方式更合适。它还有一个实际好处，也就是每项改造可以独立部署、独立关闭。某个场景上线后效果不理想，直接停掉即可，不影响其他部分。
需要跨系统统一访问的环节，可以复用已有的身份与访问体系，把新服务接进同一套域名与认证里，具体做法参考企业内网系统统一访问方案。
调用要收口
集成做到一定程度，会出现调用凭据分散的问题。有人把 API Key 写在脚本里，有人配在自己的工具上，时间一长没有人说得清总共有多少条调用、费用是多少。
统一调用网关解决的就是这件事。所有调用经由网关转发，凭据集中托管，按部门与用途分配额度，并统一记录调用日志。
这样做带来三个实际收益。费用可以按部门归集，能回答钱花在哪里；模型更换在网关层完成，已上线的业务功能不受影响；调用行为有记录，能对应到具体用途。
额度配置还有个副作用值得说明。它会让用量大的场景浮出来，管理者可以据此判断是业务确实需要，还是某个环节的调用逻辑写得不够经济。
从一个小流程开始
不需要一次接完所有场景。建议选一个数据能拿到、使用人数明确、结果可核对的小流程先做，跑通之后把做法复制到下一个。
第一个流程的价值不只是它本身的收益，更在于它会暴露出一批前期没预料到的问题，例如某个接口的实际响应速度、某个字段的口径与业务理解不一致、某个环节的人工复核应该放在哪一步。这些问题早出现一周，后面的场景就少走一次弯路。
完整的集成环节与架构说明整理在企业 AI 工作流与系统集成方案里，需要内部资料检索能力配合的场景可参考企业私有化 AI 知识库方案。