今年上半年我接到一个老客户的电话上来就问我之前建议的云上AI接口能不能直接把财务发票识别接进来我说能但客户财务部的主任在旁边补了一句这些发票数据不能出公司网络。于是话题从“哪个AI效果好”变成了“私有化部署怎么做”。这个转变几乎是我做RPAAI项目以来最常遇到的场景。这篇文章想聊的就是一套保障数据不出域的 RPAAI 落地思路以及我在实际项目中踩过的坑。适合正在做智能自动化选型、准备私有化部署或者已经被“自动化项目上线即翻车”折磨过的朋友。内容里不会只讲功能清单更多是讲为什么这么做、实际运行时哪里容易出问题怎么兜底。1. 为什么私有化 RPAAI 不是“保守”而是企业级落地的前置条件1.1 数据不出域到底在防什么很多业务方第一次听到“私有化部署”时第一反应是IT部门太保守明明云上的OCR、大模型API用起来更方便效果也更好为什么非要搞一套内网服务。但当你真正接触财务、法务、研发、生产这些部门的数据时会发现“数据不出域”不是一个技术偏好而是数据权责问题。举个例子发票识别。发票上包含企业名称、税号、金额、开户行信息如果这些数据通过外部API识别哪怕服务商承诺不留存企业内部审计也无法证明数据没有外泄。合同信息抽取更敏感里面经常包含交易条款、客户联系方式、价格策略这些字段一旦出现在云端日志里就是说不清的事故。所以“数据不出域”本质上防的不是某个具体API而是防“数据流向失控”。私有化部署的价值是让数据从采集、传输、处理到存储始终落在企业内部可控的网络边界内。它给企业的是一个可审计的事实而不是一句口头承诺。1.2 私有化与SaaS的真实差异一份选型对照私有化部署不等于什么都好它只是更适合一类场景。我见过不少企业明明业务量不大、数据敏感度也不高非要自建一套AI服务最后运维成本压垮团队。做选型前最好先看下面这张对照表。维度SaaS/云API私有化部署上线速度通常当天可用需要机器、网络、模型部署周期从一周到一个月不等数据边界数据发送到服务商服务器数据全程留在内网迭代频率模型由服务商持续更新需要自己处理模型版本更新运维成本服务商承担企业几乎为零内部团队要负责部署、监控、告警、修复安全审计依赖服务商的合规承诺可以输出本地操作日志、访问记录弹性扩容云端资源可快速扩展需要提前规划GPU、CPU资源我的判断标准是如果流程涉及核心业务数据、客户隐私或者企业生产经营数据优先私有化如果只是处理公开信息、内部测试数据用SaaS能省很多事。RPAAI这种组合通常已经触达了核心系统所以我更倾向建议私有化。2. 方案选型阶段我按这四个维度锁定了技术栈2.1 RPA主体自研、商用还是开源RPA是整个自动化流程的“手”它负责模拟人的操作把业务流程串起来。选型时先不要被“国产”“开源”“大厂”这些标签带走要看三件事是否支持私有化部署、是否支持复杂流程编排、是否提供足够的异常处理机制。商用RPA通常是最省心的选择比如影刀、金智维、UiPath都支持私有化部署而且本身带有调度控制台、审计日志、机器人管理界面。这类工具适合业务团队没有太多开发资源、但希望快速落地的场景。以影刀为例它的中文生态和组件市场做得不错很多常见的Excel、浏览器操作可以直接用现成指令。如果你所在的企业有较强的开发能力也可以考虑开源方案比如Robot Framework、TagUI。开源的优点是成本低、可定制性强但缺点也很明显没有成熟的控制台无法统一监控几十个机器人AI结果和RPA流程之间的数据协议也要自己定义。我在早期项目里试过用开源RPA接AI做到后面发现十个流程就要维护十套异常处理逻辑非常痛苦。最终我给的选型建议是业务流程复杂、涉及大量人员协作的优先商用RPA只有少数几个自动化场景、团队能写代码的再考虑开源。2.2 AI能力选型OCR、NLP与大模型私有化场景里的AI能力可以拆成几类一是OCR负责把图片、扫描件里的文字捞出来二是NLP/实体抽取负责从文本中提取需要的字段三是大模型推理比如对长文档做摘要、对客服会话做语义理解。OCR选型最典型的是PaddleOCR开源、可私有化部署中文识别效果不错同时支持分类模型适合做发票、合同扫描件的结构化识别。如果只是简单场景Tesseract也能用但对复杂版式和倾斜文字的效果要差一些。NLP这块传统的命名实体识别可以用BERT系模型部署在CPU上也能跑。如果要做更开放的问答、摘要、分类就需要考虑开源大模型私有化部署。大模型落地不是简单下载一个权重文件就完事要规划GPU资源做量化处理甚至要准备微调样本。这里的核心建议是不要试图用一个万能模型解决所有流程。发票识别、合同抽取、工单分类最好拆成独立模型服务各自维护训练数据和版本。这样某一个模型效果不好不会拖垮整个RPA流程。2.3 调度与控制层把人和机器放在同一个流程闭环里很多项目把RPA当成一个“录脚本”的工具忽略了调度和控制。实际上RPAAI私有化落地的骨架是控制台怎么调度机器人、怎么把AI结果送给人工审核、怎么在异常时熔断。我在设计中一般会有一层“人机协同”的任务队列。RPA跑完流程AI给出结果和置信度如果置信度达标就自动写入业务系统如果置信度不够或者规则校验失败就推给人工处理。调度层负责分配任务人工处理完后反馈结果再回流到RPA执行下一个节点。这样设计的原因很简单现在的AI还没法做到百分百准确尤其是面对长尾数据。与其让AI直接写坏业务数据不如设置一档人工兜底把自动化率做到70%-90%而不是追求不可能的100%。2.4 网络与算力规划一套最小可落地的拓扑私有化部署不是把软件装在内网就叫部署网络隔离和算力规划必须提前做。我常用的拓扑是三块业务区、RPA执行区、AI推理区。业务区就是财务系统、ERP、OA这些目标系统RPA执行区放机器人客户端它要能访问业务区和AI推理区的服务端口AI推理区放模型服务只对RPA执行区开放不直接暴露到业务网段。访问关系用防火墙策略或安全组控制这样即使某个机器人中毒了也无法直接摸到模型服务的管理端口。算力方面轻量OCR和实体抽取模型8核16G的服务器可以跑但并发高时需要横向扩展。大模型私有化则要准备一台带GPU的服务器至少32G内存起步推荐用量化后的模型降低显存占用。我见过一个项目把大模型部署在普通虚拟机上结果一个请求要几十秒流程直接超时后来换了GPU服务器才解决。3. 一个实际流程的交付实录发票信息自动录入3.1 需求拆解与流程评估讲完选型用一个真实交付过的场景拆解财务部门每个月要处理几百张发票人工把发票代码、号码、金额、税额、购买方、销售方录入ERP。这个流程重复度高、规则明确非常适合RPAAI。但并不是整条流程都适合自动化。发票真伪查验、特殊业务场景的判断、跨月红冲发票处理这些需要财务经验不适合交给机器。所以我把流程拆成三段前面是“发票文件获取和预处理”中间是“关键字段识别和校验”后面是“人工复核和差异处理”。RPA负责第一段和第三段的自动化AI负责中间的识别人工只处理异常。评估自动化效果不能只看单张处理时间。我更关注两个指标识别准确率达到多少人工介入率控制在什么范围。理想目标是准确率95%以上人工介入率不超过20%。低于这个水平自动化带来的收益会被人工复核成本吃掉。3.2 技术链路RPAOCR规则引擎人工复核具体技术链路可以这样描述RPA从指定文件夹或邮件附件中获取发票PDF或图片文件。转成图片后调用私有化OCR服务识别整张票面的文字块。根据发票版式规则抽取代码、号码、开票日期、金额、税额、购销方名称等字段。规则引擎做格式校验发票号码长度是否为8位或20位、金额是否为数字且大于0、税号格式是否合法。置信度高于阈值且校验通过的记录RPA直接登录ERP系统写入。置信度低于阈值或校验失败的记录自动进入人工复核队列在界面上展示原图和识别结果。人工复核后回填结果同时更新日志作为后续模型迭代的样本。这里有个容易被忽略的细节OCR服务返回的结果不能只给“识别文本”还要给每个字段的置信度。RPA要根据置信度决定是自动提交还是转人工。阈值我一般先设0.92但具体要看模型在测试集上的表现不能拍脑袋。3.3 试点期观察到的效果和意外情况试点跑了两周处理一张发票从原来人工4分钟缩短到机器人40秒算上人工复核时间综合效率提升大概60%。但前两周并不顺利大约有12%的票据进入人工复核主要原因有三个扫描件倾斜导致文字错位、发票专用章遮挡关键字段、部分电子发票版式和老版不同。倾斜问题通过OCR前增加图像矫正解决印章遮挡比较麻烦我后来让算法团队收集了被印章遮挡的样本微调了一版模型版式变化则暴露了一个更核心的问题AI模型不能只部署一次就完事它必须跟随数据变化持续迭代。试点期的另一个意外是RPA登录ERP后偶发页面加载慢导致脚本找不到输入框。后来我在RPA执行流程里增加了页面元素等待机制错误率才降下来。这个问题的根因不是RPA不行而是业务流程里本身存在系统响应波动自动化必须把这些波动当作正常现象来处理。4. 私有化落地最容易踩的五个坑以及我的排查链路4.1 GPU资源估算偏差推理延迟把流程拖死第一个坑来自算力。当时我们的OCR服务部署在一台CPU服务器上测试时单张识别只要2秒看起来很理想。结果上线后财务集中提交月末发票并发一上来单张识别变成15秒RPA脚本不断超时重试任务队列堆成山。排查链路是这样的先看监控面板发现CPU使用率没满但请求队列在不断堆积说明不是算力不够而是并发处理能力不足。后来查代码发现OCR服务默认是单进程模式一次只能处理一张图片。解决方案很简单服务改成多进程加了一个请求队列和超时重试机制再把模型换成了压缩版本。处理后单机并发能力提高了四倍月末高峰也没再出问题。这个坑给我的经验是算力评估不能只看“单次推理耗时”还要看“最大并发数”和“响应时间要求”。上线前一定要做一次压测用三倍于日常峰值的请求量去打服务。4.2 元素选择器被前端改版一夜击穿第二个坑更经典。某天早上业务方反馈所有RPA脚本都挂了原因是业务系统前端升级按钮的DOM结构变了旧的选择器全部失效。RPA之所以操作页面依赖元素选择器本质和手工找按钮一样前端一改按钮位置脚本就找不到路。排查后发现开发人员偷懒选择器用了很长的绝对路径比如html body div div div button中间任何一个节点变化都会失败。修复方案是把选择器全部改成基于按钮ID、名称或稳定的业务属性同时对关键操作增加“元素不存在”的兜底逻辑。更重要的是我和业务方约定了一条流程变更管理规则前端UI升级必须提前通知自动化团队并且在测试环境上先跑一遍RPA回归。经历了这次事故后我意识到RPA项目的稳定性不只是技术问题更是变更管理问题。4.3 RPA与AI服务之间的身份认证和审计缺失第三个坑比较隐蔽。初期为了方便调试RPA脚本里直接写死了AI服务的访问地址没有加任何认证服务端口在内网裸奔。后来安全审计时发现任何能访问内网的人都可以直接调用OCR服务而且没有任何调用记录出了问题根本不知道是谁调的。处理方案分三部分一是给AI服务加上基于token的认证调用前先申请临时token二是限制来源IP只允许RPA执行服务器的IP访问三是在AI网关层增加请求日志记录调用者、时间、请求参数和数据量。RPA脚本里也改成从配置中心读取密钥不写在脚本源码里。这个坑想提醒大家数据不出域不包括“内网所有服务互相裸奔”。就算物理隔离做得再好服务之间也需要有身份认证和操作审计。尤其在RPA这个场景里机器人是用真实账号操作业务系统的账号权限必须最小化不能给管理员权限。4.4 “物理隔离”挡不住日志泄密第四个坑是我最想分享的。某个项目的AI推理服务会把每次请求的输入和输出写到日志文件里方便调试。结果日志文件被采集到统一日志平台包含完整的发票信息甚至有合同的摘要字段。表面上看服务部署在内网数据没有出域但日志平台是所有研发人员都能访问的这等于数据被内部大范围扩散。我后来的做法是AI服务的日志必须做脱敏处理身份证号、手机号、金额这类字段要打码日志保留周期控制在30天以内如果确实需要保留完整请求数据用于模型迭代那就把原始数据放到独立的存储空间显式授权后才能访问。这个坑说明一个道理数据不出域是一整套机制不是单一技术手段。物理隔离、网络隔离、日志脱敏、权限管控少了哪一环都可能让前面的努力白费。4.5 业务团队和算法团队语言不通需求反复返工第五个坑来自“人”而不是“技术”。业务方说“把发票识别出来”算法团队给了一个返回一堆JSON字段的APIRPA工程师却不知道这些字段怎么映射到ERP的录入项。三方开会时各说各话大家都不在一个频道上。后来我建立了一个最简单的对齐机制定义一份“字段映射表”里面写清楚AI输出字段、业务含义、示例值、对应ERP字段、置信度阈值。所有接口联调时用一百条真实脱敏数据跑一遍把结果逐条对给人看。这份表既是验收标准也是后续迭代的基准。团队协作这件事看起来和“私有化部署”这个技术主题没关系但实际项目中大部分延误都来自需求理解不一致。把数据协议提前定义清楚比事后再补文档高效得多。5. 交付之后剩下的事才是真正的“稳定期”5.1 模型持续迭代机制RPAAI和传统RPA最大的不同是AI模型会漂移。发票版式在变业务流程在变人员习惯也在变。模型上线时准确率95%半年后可能掉到85%而没人察觉。我建议每月固定做一次效果分析从上月的人工复核记录里抽取错误样本分类统计错误原因把新增样本补充到训练集重新训练并做AB测试。模型版本要和RPA脚本一起放进版本管理发布时同步更新避免AI模型换了、RPA解析逻辑还停留在旧版本。5.2 流程变更管理流程变更管理不是给业务方增加负担而是在为自动化稳定性做保护。业务系统任何一次前端升级、字段调整、流程改变都可能影响RPA脚本和AI输入。我现在的做法是建立一个变更日志业务方提出变更需求自动化团队评估影响面先在测试环境回归再发布到生产。哪个环节出了问题可以快速定位到是哪次变更触发的。5.3 可观测性与一键熔断自动化的最高原则不是“全自动跑得越快越好”而是“出错时能及时停下来”。我上线任何一个RPA流程都会要求包含一个熔断机制连续失败超过设定次数机器人自动暂停并通知人工处理。否则机器会用错误数据批量写坏业务系统后果比人工犯错大得多。同时要有一块运维看板至少能看到每个流程今天跑了几次、成功多少次、失败多少次、人工介入多少次、AI平均响应时间。这些数据是运维判断流程是否健康的依据也是后续优化的依据。5.4 长期运营的团队配置建议私有化RPAAI项目落地的第一周只是开始后面拼的是运营。人力配置上我建议至少要有一个懂业务流程的人负责梳理规则和验收效果一个RPA工程师负责脚本开发维护算法工程师可以兼职支持AI模型迭代但至少要保证0.5人力。很多企业犯的错误是把自动化项目完全交给IT部门业务方当“甩手掌柜”结果流程和需求不匹配项目慢慢烂尾。正确做法是业务方和IT团队共同负责每周碰一次数据看效果定下一步改进方向。我在实际项目里还有一个习惯上线后先让机器人在“影子模式”下跑两周所谓影子模式就是机器人照常执行完整流程但最终不把结果写入业务系统只生成一份“如果执行会是什么结果”的对比报告。这样可以在不产生脏数据的前提下验证准确率和流程稳定性等调顺了再真正接管生产任务。这条经验帮我避开了好几次上线事故推荐你也试试。
