聊“AI落地”，最容易被低估的一关是“和系统打通”。很多Demo在笔记本上跑得飞起，一接到真实业务就哑火——因为模型根本取不到CRM里的客户、读不了ERP里的订单、写不回工单系统。本文从工程视角讲清，AI能力怎么顺着企业已有的系统血管流动起来，而不是另起炉灶。

先想清楚：AI是“挂”在系统上，不是“替”系统

一个常见误判是把AI当成新系统，要把业务搬过去。正确认知是AI作为能力层，挂在现有ERP、CRM、OA之上：读它们的数据、调它们的接口、把结果写回它们的字段。这样改动最小、风险最低、员工不用换习惯。落地原则：能调API就别导Excel，能增量同步就别全量拷贝，能写回原系统就别新建数据库。尊重现有系统的“主权”，AI才进得去生产环境。

接口打通的三条路：API、Webhook、RPA

优先用系统开放的标准API，最干净也最稳；系统不支持实时但支持事件通知的，用Webhook触发AI任务（如“新工单创建即触发分派模型”）；实在没接口的老系统，用RPA模拟界面操作兜底，但RPA脆弱、维护贵，能不用就不用。选型顺序是 API > Webhook > RPA。一家制造企业先靠RPA爬MES数据，后来推动厂商开放API，稳定性从七成提到九九成，运维人力减半。接口方式定了，数据流转的可靠性才有了地基。

中台还是直连：什么时候该建一层

单场景直连最省事；当AI要同时吃CRM、ERP、工单、知识库四套数据时，每次都点对点接会乱成蜘蛛网。这时建一层轻量“AI中台/数据网关”：统一鉴权、统一字段映射、统一调度，各系统只跟中台对接一次。中台不等于大而全的平台，先解决“数据能进来、结果能出去、权限管得住”三件事即可。等场景超过五个再考虑重投入，前期用低代码拼一个够用就好，别未富先重。

数据流转的权限与脱敏红线

打通系统必然碰敏感数据。落地时同步做权限矩阵：AI服务账号只能读必要字段，写回要留审计日志；客户手机号、身份证等PII字段默认脱敏，模型只在必要环节用令牌化ID。某金融客户要求所有流经AI的个人信息走脱敏网关，原始数据不落地，既满足合规又让模型照常跑。权限和脱敏不是落地之后的补丁，而是接通第一根线之前就要画进架构图的东西。

字段映射：最无聊也最致命的一步

系统A叫“cust_id”，系统B叫“customer_no”，语义还不完全一样——字段映射是打通里最磨人却最决定成败的环节。建议建一张“数据字典”，把各系统关键字段的中英文、类型、口径统一登记，AI取数前先过字典。一家零售企业因“下单时间”在ERP取支付时间、在OMS取创建时间没对齐，导致预测模型偏差两成，返工一周才查清。字典建好，这类低级坑能提前填掉。

把结果写回业务系统形成闭环

只出建议不写回，AI价值折半。最好的闭环是：模型给出分派建议→调度员确认→结果自动写回工单系统并通知技师；给出预警→自动建跟进任务→进入CRM待办。闭环让AI从“看板上的字”变成“业务里的动作”。落地时和原系统负责人确认写回字段和触发时机，避免和现有自动化规则打架。闭环跑顺，业务部门才会真把AI当生产工具而非玩具。

常见坑：Demo很美、生产很痛

典型坑：只在测试库跑通就宣布成功，上生产发现接口限流、数据延迟、字段缺失；忽视鉴权过期，服务账号密码三个月一变导致AI半夜停摆；不监控接口健康，等老板发现AI不干活才去查。对策：打通即上监控（接口成功率、时延、错误码看板），账号用长期凭证并设到期提醒，生产环境先做影子运行再切真流量。和系统打通是苦活，但它是AI落地从演示到生产的那道门。

AI落地能不能从PPT走进车间和办公室，关键看它和现有系统通不通得顺。守住“挂而不替、API优先、中台按需、权限先行、字段对齐、闭环写回”六条，把接口这关老老实实啃下来，后面的场景复制才会有稳定的数据血液可流。