私有化部署的RPA+AI落地实践：从发票识别到数据不出域

今年上半年，我接到一个老客户的电话，上来就问我：之前建议的云上AI接口，能不能直接把财务发票识别接进来？我说能，但客户财务部的主任在旁边补了一句：这些发票数据不能出公司网络。于是话题从“哪个AI效果好”变成了“私有化部署怎么做”。这个转变几乎是我做RPA+AI项目以来最常遇到的场景。

这篇文章想聊的，就是一套保障数据不出域的 RPA+AI 落地思路，以及我在实际项目中踩过的坑。适合正在做智能自动化选型、准备私有化部署，或者已经被“自动化项目上线即翻车”折磨过的朋友。内容里不会只讲功能清单，更多是讲为什么这么做、实际运行时哪里容易出问题，怎么兜底。

1. 为什么私有化 RPA+AI 不是“保守”，而是企业级落地的前置条件

1.1 数据不出域到底在防什么

很多业务方第一次听到“私有化部署”时，第一反应是IT部门太保守，明明云上的OCR、大模型API用起来更方便，效果也更好，为什么非要搞一套内网服务。但当你真正接触财务、法务、研发、生产这些部门的数据时，会发现“数据不出域”不是一个技术偏好，而是数据权责问题。

举个例子：发票识别。发票上包含企业名称、税号、金额、开户行信息，如果这些数据通过外部API识别，哪怕服务商承诺不留存，企业内部审计也无法证明数据没有外泄。合同信息抽取更敏感，里面经常包含交易条款、客户联系方式、价格策略，这些字段一旦出现在云端日志里，就是说不清的事故。

所以“数据不出域”本质上防的不是某个具体API，而是防“数据流向失控”。私有化部署的价值，是让数据从采集、传输、处理到存储，始终落在企业内部可控的网络边界内。它给企业的是一个可审计的事实，而不是一句口头承诺。

1.2 私有化与SaaS的真实差异：一份选型对照

私有化部署不等于什么都好，它只是更适合一类场景。我见过不少企业，明明业务量不大、数据敏感度也不高，非要自建一套AI服务，最后运维成本压垮团队。做选型前，最好先看下面这张对照表。

我的判断标准是：如果流程涉及核心业务数据、客户隐私或者企业生产经营数据，优先私有化；如果只是处理公开信息、内部测试数据，用SaaS能省很多事。RPA+AI这种组合，通常已经触达了核心系统，所以我更倾向建议私有化。

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当成一个“录脚本”的工具，忽略了调度和控制。实际上，RPA+AI私有化落地的骨架，是控制台怎么调度机器人、怎么把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。这个流程重复度高、规则明确，非常适合RPA+AI。

但并不是整条流程都适合自动化。发票真伪查验、特殊业务场景的判断、跨月红冲发票处理，这些需要财务经验，不适合交给机器。所以我把流程拆成三段：前面是“发票文件获取和预处理”，中间是“关键字段识别和校验”，后面是“人工复核和差异处理”。RPA负责第一段和第三段的自动化，AI负责中间的识别，人工只处理异常。

评估自动化效果不能只看单张处理时间。我更关注两个指标：识别准确率达到多少，人工介入率控制在什么范围。理想目标是准确率95%以上，人工介入率不超过20%。低于这个水平，自动化带来的收益会被人工复核成本吃掉。

3.2 技术链路：RPA+OCR+规则引擎+人工复核

具体技术链路可以这样描述：

1. RPA从指定文件夹或邮件附件中获取发票PDF或图片文件。
2. 转成图片后，调用私有化OCR服务，识别整张票面的文字块。
3. 根据发票版式规则，抽取代码、号码、开票日期、金额、税额、购销方名称等字段。
4. 规则引擎做格式校验：发票号码长度是否为8位或20位、金额是否为数字且大于0、税号格式是否合法。
5. 置信度高于阈值且校验通过的记录，RPA直接登录ERP系统写入。
6. 置信度低于阈值或校验失败的记录，自动进入人工复核队列，在界面上展示原图和识别结果。
7. 人工复核后回填结果，同时更新日志，作为后续模型迭代的样本。

这里有个容易被忽略的细节：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字段的API，RPA工程师却不知道这些字段怎么映射到ERP的录入项。三方开会时各说各话，大家都不在一个频道上。

后来我建立了一个最简单的对齐机制：定义一份“字段映射表”，里面写清楚AI输出字段、业务含义、示例值、对应ERP字段、置信度阈值。所有接口联调时，用一百条真实脱敏数据跑一遍，把结果逐条对给人看。这份表既是验收标准，也是后续迭代的基准。

团队协作这件事，看起来和“私有化部署”这个技术主题没关系，但实际项目中，大部分延误都来自需求理解不一致。把数据协议提前定义清楚，比事后再补文档高效得多。

5. 交付之后，剩下的事才是真正的“稳定期”

5.1 模型持续迭代机制

RPA+AI和传统RPA最大的不同，是AI模型会漂移。发票版式在变，业务流程在变，人员习惯也在变。模型上线时准确率95%，半年后可能掉到85%而没人察觉。

我建议每月固定做一次效果分析：从上月的人工复核记录里抽取错误样本，分类统计错误原因，把新增样本补充到训练集，重新训练并做AB测试。模型版本要和RPA脚本一起放进版本管理，发布时同步更新，避免AI模型换了、RPA解析逻辑还停留在旧版本。

5.2 流程变更管理

流程变更管理不是给业务方增加负担，而是在为自动化稳定性做保护。业务系统任何一次前端升级、字段调整、流程改变，都可能影响RPA脚本和AI输入。我现在的做法是建立一个变更日志：业务方提出变更需求，自动化团队评估影响面，先在测试环境回归，再发布到生产。哪个环节出了问题，可以快速定位到是哪次变更触发的。

5.3 可观测性与一键熔断

自动化的最高原则不是“全自动跑得越快越好”，而是“出错时能及时停下来”。我上线任何一个RPA流程，都会要求包含一个熔断机制：连续失败超过设定次数，机器人自动暂停并通知人工处理。否则机器会用错误数据批量写坏业务系统，后果比人工犯错大得多。

同时要有一块运维看板，至少能看到：每个流程今天跑了几次、成功多少次、失败多少次、人工介入多少次、AI平均响应时间。这些数据是运维判断流程是否健康的依据，也是后续优化的依据。

5.4 长期运营的团队配置建议

私有化RPA+AI项目落地的第一周只是开始，后面拼的是运营。人力配置上，我建议至少要有：一个懂业务流程的人，负责梳理规则和验收效果；一个RPA工程师，负责脚本开发维护；算法工程师可以兼职支持AI模型迭代，但至少要保证0.5人力。

很多企业犯的错误是把自动化项目完全交给IT部门，业务方当“甩手掌柜”，结果流程和需求不匹配，项目慢慢烂尾。正确做法是业务方和IT团队共同负责，每周碰一次数据，看效果，定下一步改进方向。

我在实际项目里还有一个习惯：上线后先让机器人在“影子模式”下跑两周，所谓影子模式，就是机器人照常执行完整流程，但最终不把结果写入业务系统，只生成一份“如果执行会是什么结果”的对比报告。这样可以在不产生脏数据的前提下，验证准确率和流程稳定性，等调顺了再真正接管生产任务。这条经验帮我避开了好几次上线事故，推荐你也试试。