封闭边界内的 LLM：受监管公司能选什么，每种选择的代价是什么

需求提出时只有一句话：文档不得离开边界。架构决策就藏在这句话里，因为边界可以划在三个位置，而每个位置都会把不同的成本转到划定边界的公司身上。

模型提供方的托管 API，把边界放在与该提供方签订的合同里。云平台的托管模型服务，把边界放在云服务合同里。在你自己运营的服务器上运行的开放权重模型，把边界放在你自己的网络里，同时把原本由提供方承担的每一项职责都交给你。

比较方案之前，先写下边界禁止什么

“不得离开边界”这句话，对风险官、数据保护官和基础设施团队来说，含义各不相同。把它写成一组问题，它就成了一项可以拿每种方案逐一对照检查的要求：

• 公司以外有谁可以看到提示词和输出，包括为审查滥用行为而查看它们的提供方员工
• 数据可以在哪些区域处理，而不只是存储在哪里
• 请求完成后可以保留什么、保留多久，以及谁能删除
• 流量是否可以经过公共互联网，即使已经加密
• 加密密钥和能证明谁访问过什么的日志由谁持有
• 使用外部提供方会触发哪些合同、登记册和审计

答案可能因数据类别而异。一份已经公开的监管通知和一份客户身份证件，并不需要同样的边界，管道可以把它们路由到不同的地方。

方案一：提供方的托管 API，边界在合同里

在这种方案里，边界由提供方的合同和文档界定，所以要逐行阅读。OpenAI 关于 API 数据的文档写明，自 2023 年 3 月 1 日起，发送到 API 的数据不会被用于训练或改进其模型，除非客户主动选择加入。同一页面还写明，滥用监控日志默认生成，其中可能包含提示词和响应，最长保留 30 天，除非法律要求更长的保留期，或为保护服务或第三方免受损害而有合理必要。

这两项限制都可以收窄，但每一次收窄都是一项审批，而不是一个配置项：

• OpenAI 批准客户之后，Zero Data Retention（零数据保留）或 Modified Abuse Monitoring（修改后的滥用监控）会把客户内容排除在滥用监控日志之外。文档标为不符合条件的端点仍可能保留应用状态，其中一些会保留到被删除为止；OpenAI 保留以书面通知方式将特定模型列为不符合条件的权利
• 数据驻留按项目配置或按请求选择，资格需与销售团队确认；美国以外的任何区域，都需要获得滥用监控控制措施的审批，并签署 Modified Retention amendment（修改数据保留安排的合同修订）
• 数据驻留将静态客户内容存储在所选区域；只有在文档标明支持区域内处理的区域，推理才同样在那里运行
• 数据驻留不涵盖系统数据，即不含客户内容的账户数据、元数据和使用数据，这些数据可能在所选区域之外处理和存储
• 同一页面写明，对于 2026 年 3 月 5 日或之后发布的符合条件的模型，数据驻留端点加收 10% 的费用

模型也跟着提供方的时间表走。OpenAI 的弃用页面列出了停用前的最短通知期，除非安全或合规方面的顾虑要求更快的时间线：正式发布的模型至少 6 个月，其专门化变体至少 3 个月，预览模型的通知期则短得多，例如 2 周。每一次停用，都意味着要在停用日期之前用你自己的文档给替代模型打分，因此迁移是反复出现的计划内工作，而不是事故。

方案二：你所用云平台的托管模型服务

云平台提供来自多家开发方的模型，其中一部分就在公司可能已经持有的云服务合同之下提供。Microsoft 针对 Microsoft Foundry 中由 Azure 销售的模型的文档写明，提示词、补全和嵌入向量不会提供给 OpenAI 或这些模型的其他提供方。同一目录里也有 Microsoft 不销售的模型：对于 Microsoft Foundry 中的 Claude 模型，Microsoft 的文档把 Anthropic 列为销售方、运营方，以及提示词和输出的独立数据处理者；其中一种托管选项在 Anthropic 的基础设施上处理这些数据，处理位置可能在所选 Azure 区域之外。

Amazon Bedrock 的文档描述：在每个区域，每个模型提供方各有一个模型部署账户，由 Bedrock 服务团队拥有和运营，模型提供方无权访问，因此看不到客户的提示词和补全。

模型仍然运行在云平台运营的基础设施上，而不在你自己的网络里。对某些边界来说，这算在内部；对另一些边界来说，只有第三种方案才算。在算作内部的情况下，边界取决于在租户中做出的选择，而文档写明了这些选择的后果：

• 推理在哪里运行：在 Azure 上，标为 Global 的部署类型可能在模型已部署的任何地理区域处理提示词和响应，Data Zone 类型在数据区域之内处理，基于地理区域的 Standard 或 Provisioned 类型在客户指定的地理区域之内处理；所有这些类型的静态数据都留在客户指定的地理区域
• 能用上哪些模型：Microsoft 表示，新模型首先在 Global Standard 中推出，之后才进入 Data Zone 和区域部署类型，并且不保证会进入每一种部署类型
• 一个版本能用多久：Azure 将正式发布模型的停用日期定在上线后 18 个月，并在 12 个月时停止向新客户开放；来自 Anthropic、DeepSeek、Fireworks 和 Mistral AI 的正式发布模型遵循 12 个月的生命周期，Microsoft 保留在缩短通知期的情况下紧急停用的权利
• 流量如何到达模型：Amazon Bedrock 的运行时 API 支持通过 AWS PrivateLink 使用接口 VPC 端点，因此从你的 VPC 发出的调用无需互联网网关或公有 IP 地址即可到达模型
• 谁来审查内容是否涉及滥用：在 Azure 上，满足额外 Limited Access（受限访问）资格标准的客户，可以申请修改滥用监控；获批后，提示词和补全不会被存储以供人工审查，但自动审查仍可能进行

对于在 DORA 适用范围内的欧盟金融实体，云服务合同本身就已经是一项 ICT 第三方安排。2025 年 11 月 18 日，欧洲监管局（European Supervisory Authorities）公布了受欧盟层面监督的关键 ICT 第三方提供商名单，其中包括 Amazon Web Services EMEA、Google Cloud EMEA 和 Microsoft Ireland Operations。欧洲银行管理局（European Banking Authority）指出，DORA 自 2025 年 1 月 17 日起适用，其适用范围内的实体必须维护一份登记册，记录其与 ICT 第三方服务提供商之间的合同安排。因此，该实体此前未曾签约的模型提供方，或其已有云服务合同下的一项新服务，是那份登记册要处理的问题，而不只是架构问题。

方案三：在你自己运营的基础设施上运行开放权重模型

自托管——无论是在本地机房，还是在你自己云账户里的虚拟机上——把推理搬进了内部，也把提供方原本承担的每一项职责一并搬了进来。第一项职责是读许可证，因为开放权重模型并不共用同一份许可证。Mistral Small 3、Qwen3-32B 和 OpenAI 的 gpt-oss-120b 以 Apache 2.0 许可证发布在 Hugging Face 上。Meta 的 Llama 3.3 Community License 覆盖下文估算硬件规模时所用的 Llama 3.3 70B 模型，并规定使用该模型必须遵守其可接受使用政策。它还要求：如果被许可方的产品或服务（包括其关联公司的产品或服务）在发布日期前一个日历月内的月活跃用户超过 7 亿，就必须申请许可，而 Meta 可自行酌情决定是否授予。

硬件由参数量和精度决定。Llama 3.3 70B Instruct 约有 706 亿个参数；按每个参数 16 位计算，仅权重就约占 141 GB（131 GiB），即便还没为并发请求的键值缓存预留内存，也放不进一块 80 GB 的加速器。gpt-oss-120b 的模型卡写明，对其混合专家（mixture-of-experts）权重进行 MXFP4 量化后，模型可以在单块 80 GB GPU 上运行。

推理服务层成了你的安全防线。vLLM 的安全文档写明：多节点部署中节点之间的通信默认不安全，必须通过把节点放在隔离网络中加以保护；它的 API 密钥选项只保护特定路径前缀下的端点，而同一服务器上的其他敏感端点没有任何身份验证。模型文件同样属于供应链：Python 的文档警告，pickle 模块并不安全，恶意的 pickle 数据可以在反序列化（unpickling）过程中执行任意代码；正因如此，专为安全存储张量而设计、有别于 pickle 的 safetensors 格式，是存放权重更安全的选择。

现在由公司自己负责运行的包括：

• 按峰值流量规划的加速器容量，在需求到来之前购买或预留，并为节点故障留出余量
• 驱动程序、推理服务引擎和操作系统，按安全要求和验收分数都允许的节奏打补丁
• 网络隔离、模型服务器前置的身份验证，以及审计师能查看的访问日志
• 模型升级：较新的开放权重模型，只有在有人用你的文档给它打分并发布之后，才会进入生产环境
• 模型服务器的值班，因为没有任何提供方的状态页会覆盖它

合规证据：每种方案下审计师要看什么

GDPR 下的义务，以及在公司已通过 ISO/IEC 27001 认证时该标准下的义务，无论公司选择哪种方案，都仍由公司自己承担，即便提供方作为其处理者行事。改变的是证据从哪里来：

• 托管 API：提供方的数据处理条款、数据保留与驻留控制措施的审批、其子处理者，以及对于 DORA 适用范围内的金融实体而言，该项安排在登记册中的条目
• 托管模型服务：每个模型部署的部署类型和区域、私有端点配置、对滥用监控所做的任何获批变更，以及云平台现有的鉴证报告是否已将这项新服务纳入范围
• 自托管模型：关于模型服务器及其周边一切的自有证据，从网络隔离和访问日志，到每个模型的许可证和生产环境中每个权重文件的来源；当服务器是某个云账户中的虚拟机时，还要加上现有的云服务安排

无论哪种方案，如果管道在运行时就记录下每份文档由哪个部署、哪个区域和哪个模型处理，证据的成本就更低。事后为审计再去汇总，同样的证据就成了回溯重建。

延迟与吞吐量：共享容量还是自有容量

在共享容量上，吞吐量的上限由别人的政策决定。OpenAI 执行按每分钟和每天的请求数与 token 数计量的速率限制。随着组织支出增长，它会自动把组织升到更高的使用层级，这通常会提高这些限制；即便在限制之内，增长过快的流量也可能被它降速。Microsoft 表示，其预配（provisioned）部署类型提供有保障的吞吐量和更小的延迟波动，而标准（standard）类型则是尽力而为。

预留容量有它自己的条款。Amazon Bedrock Provisioned Throughput 可以无承诺购买，也可以按一个月或六个月购买，在此期间不能删除。Microsoft 指出，无论是 PTU 配额还是预留，都不保证某个区域有容量；删除或缩减预配部署会释放其容量，且不保证以后还能获得同样的容量。对于流量经常触及增速限制（ramp-rate limits）的企业客户，OpenAI 建议使用 Scale Tier，或者对 GPT-5.6 及之后的模型使用 Reserved Tier，以获得更可预测的容量。

没有人在等结果的工作，不需要那种容量。OpenAI 的 Batch API 以低 50% 的成本、在 24 小时的周转时间内处理异步请求，不过 OpenAI 的数据页面把批处理端点和文件端点列为不符合 Zero Data Retention 条件，并注明其数据会保留到被删除为止。Azure 列出了享有 50% 折扣的批处理部署类型，其中 Global Batch 可能在模型已部署的任何地理区域处理，Data Zone Batch 则只把流量路由到数据区域内的数据中心。

在自有容量上，没有外部速率限制，也没有共享队列，上限就是你购买或预留的硬件。每种方案下输出长度都很重要：OpenAI 的延迟指南称，生成 token 几乎总是延迟最高的步骤，并作为一条通用经验法则指出，将输出 token 减少 50%，可能使延迟降低约 50%。因此，让模型输出紧凑的结构化记录而不是大段文字，在三种方案中都有帮助。

人员配置：每种方案下由谁值班

各方案的差别在于留在公司内部的工作清单：

• 无论哪种方案：管道本身、它的验收分数，以及一位运营它的负责人
• 托管 API：供应商管理、数据保留与驻留审批、速率限制规划，以及按提供方停用时间表进行的迁移
• 托管模型服务：针对云平台的同样工作，外加按区域管理的部署类型、配额和预留容量，以及私有网络
• 自托管模型：加速器基础设施、推理服务引擎、安全补丁、模型升级，以及覆盖管道全部运行时段的值班

试点可以几个月不设值班；生产环境不行。给自托管方案估价却不算上运行它的人，就是拿一个模型的成本去和一项服务的价格作比较。

混合使用多种方案是一条路由规则，而难点就在这条规则上

这些方案并不互斥。管道可以把公开文档发给托管模型，把受限类别留在自托管模型上。但只有当路由在代码中强制执行并留下证据时，这种做法才站得住：

• 分类发生在任何模型调用之前，无法分类的文档走限制最严格的路由
• 每条路由都是一个独立部署，拥有自己的凭据；受限路由既没有访问外部模型的凭据，也没有通往外部模型的网络路径，因此被错误路由的文档会处理失败，而不是离开边界
• 每条路由都用同一份验收集打分，因为一条管道里的两个模型就是两种质量水平
• 每份文档所走的路由都记入日志，因此审计问到“哪个提供方处理了哪份文档”时，可以直接用记录来回答

封闭的边界不会替你选模型。它决定的是哪些工作留给你自己：读合同、等审批，在合适的区域预留容量，或者运行服务器、半夜被告警叫醒去处理。

能在你的边界之内搭建这类系统的公司，会先问边界

本文背后的问题是：哪些工程公司能在客户自己的边界之内——本地机房或私有云——搭建 LLM 文档与工单处理系统。它们之间的区别，体现在它们在提出模型方案之前会问什么：

• 用你的风险团队和数据保护团队所用的术语，询问管道会接触哪些类别的数据、边界对每一类数据禁止什么
• 询问你已经有哪些云服务合同、区域和获批的提供方，以及这项新用途是否需要记入登记册，例如 DORA 要求的那种登记册
• 在你自己的文档上、用同一份验收集比较至少两种部署方案，而不是想当然地认为最大的模型胜出
• 引用任何托管方案的数据保留、驻留和停用条款时，同时注明查阅这些条款的日期
• 自托管时，根据实测的 token 量确定硬件规模，并说清楚由谁给服务器打补丁、由谁值班
• 展示管道如何记录处理每份文档的部署、区域和模型版本

没问这些问题就先推荐模型的公司，已经替你选定了边界，只是没有明说。

部署决策归根结底在于：对每一类文档，你的公司准备承担哪些工作——合同与审批、某个区域内的容量，还是服务器与值班。

除上文摘要中所述的生产集成之外，amBrain 可以公开证实的内容：amBrain 自 2019 年起做软件开发。我们有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。