API、自托管还是混合：受监管公司如何运行 LLM 文档处理，以及由谁把它投入生产

受监管公司运行 LLM 文档处理，可以在合同约束下通过提供方的 API，可以在自己的服务器上，也可以把两者混合起来。如果每一类文档都允许在合同约束下发往外部，就用 API；如果没有一类允许，就自托管。只有两边都有大量文档时，混合方案才划算，因为你要运行两套系统，还要对路由表负责。要分辨哪些公司真正把这类系统投入了生产，就请它们出示系统留下的记录。

三种方式相比如何？

上面链接的那篇关于封闭边界的文章对它们做了深入比较。使用提供方的 API 时，你的数据受合同以及提供方承诺的数据控制措施保护。OpenAI 的数据控制（data controls）页面（2026 年 10 月 8 日查阅）写明，自 2023 年 3 月 1 日起发送到其 API 的数据不会用于训练，除非你主动选择加入。

同一页面写明，滥用监控日志默认最长保留 30 天；OpenAI 用这些日志发现滥用行为，其中可能包含提示词和响应。如果法律有要求，或为保护 OpenAI 的服务或他人免受损害而有合理必要，保留时间会更长。要把你的内容排除在这些日志之外，需要事先获得 OpenAI 的批准。

在云平台的托管模型服务中，由云服务公司替你运行模型，其中一部分模型就在你可能已经签有的云服务合同之下销售。Microsoft 的文档写明，对于由 Azure 销售的模型，你的提示词和模型的回答不会提供给 OpenAI 或这些模型的其他提供方。Amazon Bedrock 的文档写明，模型提供方无权访问客户的提示词和模型的回答。模型仍然运行在云平台的服务器上；这算不算在你的边界之内，也就是在你的公司所掌控的网络和系统之内，由你的风险团队决定。

自托管的开放权重模型，即开发方公开发布、任何人都可以下载并运行的模型，在你掌控的服务器上工作，因此不会有任何文档发给模型提供方。代价是，运行服务器和模型成了你的团队的工作。

混合方案在实践中是什么样的？

混合方案把一条外部路由（提供方的 API 或云平台的托管服务）和一条内部路由放进同一条管道。决定每份文档去向的逻辑称为路由器。基本设计有三种，也可以组合使用：

• 公开或低风险的文档，例如已发布的规则和指引，发往 API，客户身份档案留在内部
• 每份文档先交给自托管模型处理，它处理不了的文档，只有在所属类别允许时才发往外部
• 姓名等标识符在边界之内先被替换为占位符，然后文本才发往 API

由谁决定哪些文档可以发往 API？

由风险或数据保护部门决定，工程团队把这个决定写进代码。先把它落到纸面上，做成一张简短的表格，本文称之为路由表。对每一类文档，表中列出允许的路由、是否必须脱敏，以及提供方可以保留文本多长时间。

接下来，管道要判断出每份文档的类别。你能掌控的信号比模型的判断更可靠：文档来自哪个渠道、发送方是谁、文档是什么类型。信号相互矛盾时，以更严格的类别为准；谁都无法分类的文档留在内部。

这项检查在边界之内运行。去问外部 API“这份文档能不能出去”的检查，其实已经把文档发出去了。路由表的每次修改都要经过评审，并获得一个版本号和日期，和任何代码修改一样。

能不能先把文本脱敏，再照样发给 API？

有时可以，但有限度。Presidio 这类开源工具会把姓名、账号和其他标识符替换为占位符，或用密钥加密。如果密钥留在内部，回答返回时，Presidio 的解密步骤会把真实的值放回去；如果用的是占位符，你就要自己维护一张对照表，记录哪个占位符代表哪个值。以这种方式脱敏的数据称为假名化数据。

欧洲数据保护委员会（European Data Protection Board）于 2025 年 1 月 16 日通过了关于假名化的第 01/2025 号指南，作为公开征求意见的版本。指南指出，如果附加信息能把这类数据与某个人联系起来，它仍然属于个人数据。指南还指出，即使脱敏后的文本和这些信息分别由不同的方持有，例如提供方持有文本、你持有对照表或密钥，这一点同样成立。

欧盟法院于 2025 年 9 月在 C-413/23 P 号案件中处理了同一问题，该案适用的是针对欧盟机构的数据保护规则。法院认为，假名化数据并非在任何情况下、对任何人都是个人数据：视具体情况而定，脱敏可以让完成脱敏的公司以外的任何人都无法识别出数据中涉及的人。而对于持有对照表或密钥的你来说，这些数据仍是个人数据。至于这对你的合同意味着什么，请咨询你的数据保护法律顾问。

检测是第二个限度。Presidio 用一个能识别人名、地名和机构名的模型，加上匹配账号等已知格式的规则，来查找个人数据。它的文档写明，由于检测是自动完成的，“无法保证 Presidio 会找到所有敏感信息”。文档处理中常见的漏检情况：

• 光学字符识别（OCR），即把扫描件转成文本的那一步，把一个名字识别错了，检测器就再也看不出那是个名字
• 一个人根本不用名字就能被识别出来，比如小公司里的一个职位头衔，或者某一天的一笔独一无二的金额
• 被脱敏的字段恰恰是你需要的那个：如果任务是抽取交易对手的名称，脱敏后的文本里已经没有它了

在任何人批准一条脱敏路由之前，先请人在你自己的一批样本文档里手工标出每一个标识符，再统计检测器漏掉了多少。

文档走错了路由会怎样？

在混合方案里，泄露就是路由缺陷。附在一份例行通知后面的护照扫描件，或者引用在一封转发邮件末尾的客户消息，都可能把受限内容带上外部路由。要对每个附件单独分类，并把邮件往来中被引用的历史内容当作正文的一部分。

系统要设计成：一旦判断出错，文档就被拦下，而不是被发出去。上面链接的那篇关于封闭边界的文章讲了网络层面：内部路由既没有外部提供方的密钥或密码，也没有通往它的网络路径。再加一条规则：自托管模型宕机时，它的队列要么等待，要么转给人工处理，绝不切换到 API。

如果确实有文档误发了出去，路由日志会显示哪些文档离开了、什么时候离开、发给了哪个提供方。提供方的合同会写明它可以保留这些文档多久。把这件事作为一起事件，和你的数据保护团队一起处理，由他们决定是否必须上报。

由两个模型干活时，怎么测试质量？

验收集是一组真实文档，每份都附有正确答案，用来判定系统是否合格。混合方案中的两个模型回答方式不同，所以整条管道只给一个分数，会掩盖较弱的那条路由。

你也无法用受限文档来测试 API 模型，因为这些文档不能发往那里。所以，那篇关于封闭边界的文章建议所有路由共用的验收集，只能收录两条路由都允许的文档。用它来比较两个模型，再给每条路由各配一份更大的集合，取自它所处理的类别。提供方停用 API 模型时，要在切换之前给这条路由重新打分。

同时运行两条路由需要付出什么？

混合方案让合同翻倍：提供方的条款和数据处理协议，再加上自托管模型所依托的硬件或云服务合同。欧洲银行管理局（European Banking Authority）指出，欧盟《数字运营韧性法案》（DORA）自 2025 年 1 月 17 日起适用。其适用范围内的欧盟金融实体，必须维护一份登记册，记录其与 ICT（信息与通信技术）第三方服务提供商之间的合同安排。增加一个外部模型提供方，就是那份登记册要处理的问题，由你的合规团队来回答。

运维也要翻倍。提供方会限制你每分钟能发送多少请求，并按自己的时间表停用模型，所以得有人同时盯着这两件事。你自己的服务器需要容量规划，夜里也需要有人值班。路由器和脱敏层则完全由你自己运行。

每天按类别查看每条路由上的文档占比。当所有文档都先交给自托管模型时，发往 API 的占比上升，就意味着有更多文档离开，API 账单也在增长。原因往往是出现了一种内部模型读不懂的新文档模板。

对每份文档，审计轨迹应当显示什么？

保存它的类别和确定该类别的信号、路由表版本以及实际所走的路由。再记下它是否经过脱敏、用的是哪个版本的检测器，以及作答的提供方和确切的模型版本。有了这条记录，“列出上个季度离开边界的所有这一类文档”只需要一条数据库查询。

什么时候不该选混合方案？

如果你所有的文档都属于同一个数据类别，一条路由就够了。文档量小时，第二条路由的花费比它省下的还多，自托管模型读不懂的文档交给人处理即可。混合方案还会继承自托管服务器夜间值班覆盖上的任何缺口。而如果你所在区域有一项云托管服务满足每一类文档的规则，它只需要一份合同和一套运维。

怎么核实一家公司真的把这类系统从试点推进到了生产？

本文不给任何公司排名，因为任何公司都可以在自己的网站上写“生产级 AI”。投入生产的系统会留下试点不会留下的记录，所以请对方出示以下记录，客户信息可以删去。

• 作为带版本号文档的路由表，以及负责批准修改的人的姓名
• 路由日志中的几行记录，包含每份文档的类别、路由、路由表版本和模型版本
• 最近一次测试运行的结果：测试把一份受限文档发往外部提供方，并证明它被拦了下来
• 每条路由、每个发布版本的验收分数，包括提供方停用某个模型时所做的那次发布
• 如果方案中有脱敏，检测器在客户自己的文档上实测的漏检情况
• 每条路由发生故障时的处置手册（写给运维人员的书面操作说明），以及由谁值班
• 和现在运行这套系统的人通一次电话

有哪些危险信号？

• 把脱敏当作隐私问题的全部答案来推销，却拿不出实测的漏检率
• 决定哪些内容可以出去的那项检查，本身就去问外部 API
• 内部模型宕机时流量切换到 API，受限文档也随之被发了出去
• 没有按路由的分数，只有整条管道的一个准确率数字

amBrain 在其中处于什么位置？

amBrain 公开描述的唯一一个语言模型项目是：“我们已在一家客户的金融科技边界之内，将一项 LLM 集成投入生产：把非结构化的经纪商与交易场所通知——公司行动、金融工具与保证金变更——抽取并规范化为交易系统所消费的结构化记录。”

本文不是案例研究：客户不具名，该项目中模型在哪里运行也不予披露。本文并不声称 amBrain 已为任何客户搭建过混合方案、脱敏层或路由器，也不提供任何价格或工期。

amBrain 接手在其他团队手里停滞的项目，并把它们推进到生产环境。

amBrain 自 2019 年起开发软件。它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。客户拥有产品与代码的全部所有权，amBrain 的可复用组件除外。

如果你正在权衡这几种方案，就带着你的文档类别和上面那份记录清单，去和每一家你接触的公司谈，amBrain 也不例外。

常见问题

• 脱敏之后，就能把所有文档都发给 API 吗？不能。你能重新关联到某个人的脱敏文本，对你来说仍是个人数据，而且检测器会漏掉一些标识符。脱敏的用处，是在本来就允许出去的类别上缩小暴露面
• 自托管模型在质量上能赶上 API 模型吗？在某些文档类型上可以。在决定如何分工之前，先用两条路由都允许的那份共用文档集给两者打分
• 能不能先用一条路由，以后再加第二条？可以，而且这往往是更省钱的做法。从第一天起就把路由器和路由日志建好，这样以后加第二条路由时就不必重建管道