AI 怎么接入 ERP 和 OA：接口、权限与数据边界

AI 接入 ERP 和 OA，最稳妥的做法不是一上来让它自动改数据，而是按读取、建议、写回、自动执行四级逐步放权。每升一级，都要补上更强的身份校验、审批、日志和回滚；系统越接近真实业务动作，错误代价越高。

所谓「接入」也不只是拿到一个 API 地址。它意味着 AI 成为业务链上的一个参与者：可能看见订单、合同与员工信息，可能生成建议，也可能改变单据状态。项目开始前，先按自动化之前的工作流梳理方法画清数据从哪里来、由谁确认、最终写到哪里，再讨论模型和接口。

先把「接入」拆成四个风险等级

读取是最低风险级：AI 通过受限接口查询订单、库存或审批状态，只在会话中回答，不改变源系统。只读不等于无风险，过量读取、跨部门查询和把敏感字段带进不合适的模型环境，仍可能造成泄露；但业务记录本身不会被它改坏，故障也较容易隔离。

建议是在读取之后生成一份待确认结果，例如给采购员提示补货候选、给审批人摘要差异、给销售生成跟进草稿。建议必须与事实字段分开显示，标明依据、时间和数据来源，不能用一段流畅文字掩盖缺失信息。人在这个级别拥有决定权，AI 不替人点击确认。

写回是把人确认后的结构化结果写入 ERP 或 OA，例如补充备注、创建草稿单、回填分类。此时风险从「答错」变成「数据被改错」，接口必须验证字段、状态和版本，记录确认人，并能识别重复提交。自动执行则允许系统在满足条件时直接提交、流转或触发后续动作；它只适合规则明确、影响可逆、异常可及时拦截的窄场景。

四级不是成熟度勋章，也不是所有项目都必须走到终点。很多高风险流程长期停在建议级，价值仍然成立；涉及付款、用印、员工处分或对外承诺的动作，即使技术上能自动做，也可能更适合保留人工批准。选择工作流还是更自主的 Agent，可结合AI 工作流与 AI Agent 的选型方法判断，但权限不能因架构名称而放宽。

从业务事实反推接口，而不是把数据库全开放

集成设计先确定「事实归谁」。订单金额、供应商状态、审批结论等正式记录仍由 ERP 或 OA 负责，AI 只能消费或提议变更。不要为了开发省事，让模型直接连业务数据库、自己拼查询或绕过系统校验；一旦表结构调整、软删除规则变化或权限逻辑迁移，直连很容易读到不完整的事实，也会绕开原系统已有的审计。

更可控的做法是按业务能力暴露窄接口，例如「查询本人待办」「获取某订单的可见摘要」「创建报销草稿」，而不是开放「任意查询订单表」。接口返回的字段只包含当前任务所需内容，写入接口也只接受允许变更的字段。这样，业务规则留在业务系统里，AI 无法靠提示词越过必填、额度或状态机约束。

接口清单要带上业务语义：调用目的、数据负责人、允许调用者、输入输出、刷新时点、超时行为、异常去向和停用方式。尤其要区分实时事实与缓存摘要。AI 如果拿到的是昨晚同步的库存，就必须显示数据时间，不能把它说成当前可用量。接口能返回数据，只说明连接成立；返回的数据是否足以支持这次判断，是另一项验收。

身份要一路传递，不能用一个超级账号替所有人办事

接入常见的捷径，是给 AI 服务一个权限很大的公共账号，让所有员工共用。这样开发快，却回答不了三个关键问题：这次请求是谁发起的，他原本能不能看这条记录，动作发生后该记在谁名下。更稳妥的设计同时保留用户身份、服务身份和审批身份，各自承担不同责任。

用户登录后，平台根据他的部门、角色和当前任务建立请求上下文；AI 服务用自己的受限凭证调用接口；需要人工批准时，再把批准人的身份和批准版本写入记录。OAuth 2.0 等授权框架提供了委托访问的通用思路，但采用哪种机制要服从现有身份体系。关键不是协议名称，而是令牌短期有效、范围足够窄、可以撤销，且后端仍会重新判断权限。

NIST 的零信任架构强调，不应只因请求来自内网或公司设备就默认可信。落到 ERP、OA 集成里，就是每次访问都根据主体、资源和上下文做判断，而不是「进了 AI 门户就什么都能查」。数据敏感度如何分层，可先参考管理者使用 AI 前要划定的数据边界；集成层再把边界落实为字段、记录范围与调用条件。

建议变成写回前，要经过可验证的窄门

建议级最容易出现一个界面误区：把 AI 生成的内容直接填进正式字段，只等用户按下保存。用户看到表单已经填满，往往会把「浏览」当成「审核」。更好的交互是并列展示原始事实、AI 建议、变更差异和依据，让确认者明确知道哪些字段将被修改；关键字段缺少依据时，保存按钮应保持不可用。

写回接口需要做确定性校验，而不是再次询问模型。类型、长度、必填、枚举值、金额关系、单据状态都由代码和源系统规则检查。提交时附带记录版本；如果审批人在查看期间原单已被他人修改，系统应提示冲突并重新确认，不能用旧建议覆盖新事实。对于重复点击、网络重试和消息重复投递，要用幂等键保证同一业务意图只生效一次。

人工确认也要分级。普通备注可以由业务人员确认，影响价格、付款或对外承诺的变更则需要相应岗位批准；生成内容的复核深度可参考AI 产出分级复核清单。批准对象必须是一个冻结版本：人批准的是眼前这份内容，后端不能在批准后让模型悄悄重写，再提交另一个版本。

自动执行的门槛，是错误可控而不是模型看起来聪明

自动执行适合边界窄、规则稳定、结果可逆的动作，例如在信息齐全且规则命中时创建一张待审核草稿，或把低风险待办路由到确定队列。它不适合把开放式判断直接连到高影响动作。输入能被外部人员操纵、模型需要猜测缺失事实、执行结果不可撤销、错误会批量扩散，只要其中一项成立，就应降回建议或人工处理。

执行器与模型要分开。模型提出结构化意图，策略层检查用户权限、动作白名单、字段约束、频率、单次影响范围和审批要求，通过后才调用业务接口。这样即使模型输出越界指令，真正能做的动作仍被确定性规则限制。把安全全部写进提示词不够，因为提示词不是权限系统，也不能替代后端校验。

每次执行都要留下可重放的证据链：谁发起、使用了哪些输入与数据版本、模型给出什么建议、哪条策略放行、调用了哪个接口、源系统返回什么、是否发生人工接管。日志不能只记一句「执行成功」，也不能把完整敏感正文无差别复制进去；应记录调查所需的标识、摘要和版本，同时遵循保留与访问规则。

回滚不是撤销按钮，而是一条事先演练过的业务路径

读取和建议级的回退相对简单：关闭入口，用户回到原页面。写回和自动执行则可能已经产生新单据、触发审批或通知下游，不能只把 AI 服务关掉。项目必须逐类定义补偿动作：草稿可删除，错误字段可用旧版本恢复，已进入审批的单据要撤回，已经通知的人要收到更正；无法自动补偿的动作，要明确由谁接手。

回滚还包括数据对账。停机期间哪些请求成功、哪些超时但实际已落库、哪些进入消息队列尚未处理，必须能从业务编号和幂等键核清。否则团队会在恢复服务后再次提交，制造重复单据。旧流程要保留到新路径通过观察期，并定期演练切换；只在文档里写「必要时回退」，不算具备回退能力。

从集成试验走到生产环境，还要补齐监控、责任人与异常值班等工作，AI 项目从试点到正式上线的差距有更完整的生产化清单。系统集成的判断标准不是演示时成功写入一张单，而是在真实异常出现时，团队仍知道怎样停、怎样查、怎样恢复。

用一张集成验收表决定能不能升到下一级

每次升级前，业务、IT 与安全负责人共同核对六类证据：业务范围是否写清；接口是否只暴露必要字段和动作；用户、服务、审批身份是否可追溯；正常、越权、缺字段、重复提交、超时和冲突输入是否都测过；日志能否还原一次请求；停用、补偿与对账是否演练过。这里的六类是项目检查框架，不是通过率指标，企业应按动作影响补充自己的门槛。

验收必须用真实但受控的例外，而不只测标准样例。让无权限员工请求跨部门订单，让同一写回消息重复到达，让源单在确认期间被修改，让下游接口超时，再看系统是否拒绝、降级或转人工。只有团队看过失败路径，才知道控制措施不是纸面设计。

AI 与 ERP、OA 的连接，本质上是把自然语言判断接到正式业务记录上。正确顺序是先确定系统事实与责任，再开放读取；先让建议可核验，再允许写回；先证明异常可拦截、动作可补偿，才讨论自动执行。能调用接口只是技术起点，能在错误发生时限制影响并恢复业务，才算完成集成。