本地 vs 自托管 vs 离线：为敏感数据选择正确的 AI 部署
本地、自托管和离线经常被互换使用——但它们含义不同且提供不同的合规保证。以下是如何为敏感 AI 数据工作负载选择正确的部署模型。
有三个词反复出现在供应商文档、采购清单和架构评审里：本地部署、自托管、物理隔离。它们常被当成同义词使用，但不该如此。每一个描述的都是一种实质不同的部署模型，各自有不同的合规影响、不同的运营成本，以及对你的数据究竟去 了哪里的不同保证。
这种含混之所以要紧，是因为供应商会利用它。一个宣称「兼容本地部署」的工具，可能指的是跑在 AWS 上的 Docker。一个「自托管选项」可能仍然要求供应商的许可证服务器在启动时联网回调。「支持物理隔离」可能只是说二进制文件不联网也能跑，但它的配置文档默认更新时是有网络的。
本文精确定义每个术语，说明各部署模型在合规上的含义，并根据你所处的监管环境给出选择建议。
精确定义
本地部署（On-Premise）
本地部署指软件运行在你的组织自有或租赁的硬件上，且位于你掌控的物理场所：你的楼、你的机房、你的数据中心。硬件是你的，物理空间是你的，网络流量不出你的边界。
关键特征是：数据中心归你所有，服务器归你所有（或以你掌控的方式租赁）。你不是在向云服务商租算力。无论你对配置有多大的控制权，AWS、Azure 和 GCP 上的部署都不算本地部署。
这一点之所以重要，是因为某些监管框架中的数据主权要求，关心的正是物理基础设施的所有权和司法辖区，而不只是逻辑上的访问控制。
自托管（Self-Hosted）
自托管指由你的团队负责部署的管理工作，包括安装、配置、升级和维护。它与本地部署的关键区别在于：自托管完全没有说基础设施在哪里。跑在 AWS EC2 上的 Docker 是自托管，跑在 GKE 上的 Kubernetes 是自托管，Hetzner 上的一台 VPS 也是自托管。这些都不是本地部署。
自托管意味着运维责任，而不是基础设施所有权。是你的团队在运行软件，不是供应商。但物理硬件可能归 Amazon、Microsoft、Google 或另一家云服务商所有，机房也可能在任何司法辖区。
供应商术语造成的伤害在这里最大。很多工具把自己包装成「自托管」，仿佛这就自带本地部署的隐私保证。并不是。部署在云服务商上的自托管方案，意味着你的数据落在该服务商的硬件上，受该服务商的数据协议约束，并可能在该辖区的法律程序下被调取。
物理隔离（Air-Gapped）
物理隔离指运行时没有任何网络连接。系统在物理上或逻辑上与外部网络隔绝，包括互联网 、供应商更新服务器和许可证校验端点。数据无法通过网络连接进出该系统，因为运行期间根本不存在网络连接。
物理隔离是限制最严格的部署模型，也是防止数据经网络通道外泄的最强保证。它在部分国防、情报和关键基础设施场景中是硬性要求，并且在医疗和金融领域也越来越相关，因为那里数据的敏感度足以抵消运维上的复杂度。
需要注意：物理隔离不代表永远没有网络，而是指在处理敏感数据的运行期间，网络是缺席或被隔离的。更新、打补丁和初次安装通常在另一套网络上进行，或通过物理介质（U 盘、光盘）在受控流程下完成。
供应商为什么要把这些概念混在一起
营销上的动机很直白：对没有仔细区分过的买家来说，「自托管」听起来就像「本地部署」，而自托管比真正的本地部署或物理隔离软件更容易做、也更容易卖。
真正的本地部署软件必须在没有任何云依赖的情况下工作：没有许可证服务器，没有遥测，没有更新检查，没有托管在 CDN 上的静态资源。它必须能被打包用于内部分发，能安装在完全没有互联网的网络上，并且在供应商无法访问该基础设施的前提下仍可维护。这样做成本更高。
物理隔离软件还要更进一步：在运行的任何时刻 都不假设有网络连接，不做 DNS 查询，不发起外部 API 调用，不含写死的 CDN 地址，也没有会尝试联网的后台服务。许多号称支持物理隔离的软件在实践中失败，原因是技术栈里某一处依赖仍在试图访问外部端点。
评估供应商说法时，该问的是：
- 软件在运行期间会发起任何网络调用吗？这一点你能验证吗？
- 许可证校验是否需要连接到供应商的服务器？
- 软件是否会传输遥测、错误报告或使用数据？
- 在完全没有互联网的情况下，软件能否连续 90 天正常运行且无需人工干预？
- 当它连不上更新服务器时会怎样，是降级还是直接失败？
各部署模型的合规含义
GDPR 与数据跨境限制
GDPR 第五章限制向未获充分性认定的第三国（欧盟／欧洲经济区以外）传输个人数据。把负载跑在 AWS EU-West-1（爱尔兰）也许能满足 GDPR 的数据驻留要求，但那是自托管，不是本地部署。数据落在 AWS 的硬件上，而 AWS 是 一家总部位于美国的公司，受《云法案》等框架下的美国法律程序管辖。
这是否可接受，取决于你的具体数据、法务团队的解读，以及组织的风险容忍度。但它绝不等同于处在你物理控制之下的本地存储。
对于适用比 GDPR 基线更严格的国家数据主权要求的组织，比如德国 BSI 规定、法国 SecNumCloud 要求，或某些政府机构的强制规定，「自托管在欧盟云上」可能仍不达标。只有处于你物理控制下的硬件才满足这些要求。
HIPAA：受保实体与业务伙伴
在 HIPAA 之下，当你使用云服务商存储或处理 PHI 时，该服务商就成为业务伙伴，必须签订业务伙伴协议（BAA）。BAA 的存在本身就说明数据流向了该服务商：他们对此负有合同义务，但他们确实收到了数据。
自托管在提供 BAA 的云上（AWS、Azure 和 GCP 都提供）满足 HIPAA 的 BAA 要求。但数据仍然存放在云服务商的硬件上。云服务商仍可能依据美国法律收到调取数据的要求，其员工（在严格管控下）仍可访问你数据所在的基础设施。
本地部署意味着 PHI 从未抵达任何云服务商的基础设施。没有第三方处理者，也就没有 BAA 需要谈判。对于最敏感的临床数据，尤其是患者隐私至上的研究场景，这是一个实质不同的姿态。
物理隔离的本地部署更进一步：不存在任何网络路径能让 PHI 外泄，连意外外泄也不可能。对敏感度最高的临床研究环境，这才是合适的模型。
欧盟《人工智能法案》第 10 条：训练数据治理
《人工智能法案》第 10 条对高风险 AI 系统的要求，覆盖训练数据全生命周期的数据治理义务。法规要求提供者记录数据采集、准备、标注和质量保证的过程。
严格说这并不是一条部署模型要求，而是文档与治理要求。但部署模型会影响你满足它的能力。如果训练数据的准备发生在共享基础设施的云平台上，那么重建一条完整的数据处理决策审计链路，会比整条流水线都跑在你自己掌控并完整记录的基础设施上要困难得多。
对于在欧盟构建高风险 AI 系统的组织，把数据准备流水线（而不只是模型训练那一步）部署在本地，会让第 10 条的文档义务更容易达成。
金融服务：FCA、DORA 与数据驻留
英国（FCA）、欧盟（DORA）和美国（OCC、FINRA）的金 融监管机构，对金融数据可以存放在哪里、运营连续性必须如何维持，各有不同要求。DORA 专门针对 ICT 风险管理，要求金融机构对其关键 ICT 依赖保持控制。
在多数框架下，金融服务使用云部署是被允许的，但需要特定的合同条款、退出策略和运营韧性文档。而对最敏感的数据，比如交易算法、信用模型、客户财务记录，一些机构会选择本地部署，以保持不含糊的控制权。
物理隔离的硬性场景：国防与关键基础设施
国防承包商、情报界供应商，以及关键基础设施（电网、供水系统、医疗系统）的运营方，可能被要求在涉密或敏感隔离环境中运行 AI 系统。这类环境在设计上就与非涉密网络物理隔绝。
在这些场景中，「自托管在政府云上」（GovCloud、C2S 等）并不是物理隔离，它仍然是联网的基础设施。真正的物理隔离意味着系统跑在没有外部网络连接的硬件上，数据通过受控的物理介质、在有文档记录的保管链流程下转移。
声称支持这类环境的软件必须经过实测，而不是靠信任。常见的失败模式包括：启动时的激活或授权校验、试图联网回传并超时的遥测，以及会做 DNS 查询的依赖库。
对比表
| 维度 | 本地部署 | 自托管（云上） | 物理隔离 |
|---|---|---|---|
| 硬件所有权 | 你的组织 | 云服务商 | 你的组织 |
| 数据驻留保证 | 有（物理控制） | 取决于服务商的区域 | 有（物理控制） |
| GDPR 跨境合规 | 强 | 取决于充分性认定 | 强 |
| HIPAA（PHI） | 无需 BAA | 需与云服务商签 BAA | 无需 BAA |
| 云服务商可否接触数据 | 否 | 是（按其条款） | 否 |
| 搭建复杂度 | 高（需采购硬件） | 中等（DevOps） | 很高（安全后勤） |
| 维护负担 | 高（你的团队） | 中到高（你的团队） | 很高（你的团队，且隔离） |
| 是否需要互联网 | 否（通常） | 是（运行期间） | 否（按定义） |
| 适合 | 受监管行业、数据主权 | 技术能力强、无硬性主权要求的团队 | 国防、涉密、最高敏感度 |
按监管环境给出的实务建议
处理 PHI 用于 AI 训练的 HIPAA 受保实体： 自托管在有 HIPAA BAA 的云上技术上合规，但意味着 PHI 抵达了云服务商的基础设施。本地部署更干净。对最敏感的研究数据，物理隔离的本地部署才合适。
受 GDPR 和《人工智能法案》约束的欧盟组织： 对非主权类数据，自托管在欧盟区域的云上能满足大部分要求。对涉及国家安全的场景，或数据主权要求更严的行业（医疗研究、政府 AI 系统），本地部署更合适。
有模型风险管理要求的金融机构： 在多数监管框架下，配齐合同与运营韧性文档的云部署是可接受的。对竞争敏感度极高的自有模型，本地部署更优。
有涉密要求的国防承包商与政府机构： 只能物理隔离。自托管和联网的本地部署环境，都不等同于涉密设施的要求。
法律服务（特权与保密）： 自托管在自有基础设施上往往已经够用。本地部署能提供更干净的特权主张（数据从未离开律所的物理控制）。物理隔离很少被要求，但在国家安全相关的法律场景中确实存在。
该向供应商问什么
当供应商告诉你他们的工具支持你的部署模型时，请追问：
- 「软件在运行期间会发起任何出站网络连接吗？」要一个明确答案，而不是「它可以配置成离线运行」。
- 「许可证校验是否需要连接你们的服务器？」如果需要，那就是对供应商基础设施的依赖。
- 「你们能否提供软件会联系的所有外部端点的文档？」安全团队可以用网络监控来核实。
- 「这套软件是否在经过认证的物理隔离环境中部署过？能给个参考案例吗？」声称支持物理隔离，和已验证的物理隔离部署，是两回事。
- 「你们的数据遥测政策是什么？软件会传输哪些数据、传到哪里？」这应当写在隐私政策或 DPA 里，而不只是口头保证。
这些问题的答案会揭示一个工具真正支持哪种部署模型，无论营销材料上怎么写。
相关阅读
- 面向合规的本地 AI 数据准备：为什么部署模型的选择是受监管行业 AI 团队的地基
- 欧盟《人工智能法案》第 10 条：训练数据要求：高风险 AI 系统具体的数据治理义务
- 符合 HIPAA 的 AI 训练数据指南：HIPAA 对 AI 训练数据流程究竟要求什么
- 物理隔离的机器学习流水线：在无网络环境中运行 ML 流水线的实务考量
- 企业 AI 中的数据主权（2026）：数据主权要求如何塑造企业的 AI 部署决策
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
网络安全团队如何在气隙环境中构建 AI
网络安全团队处理最敏感的组织数据。以下是如何构建永不触及互联网的 AI 数据准备和训练管道——包括使用本地 LLM 进行合成数据生成。
受监管行业里，云端数据准备的真实成本（2026）
云端数据准备工具需要走合规审批，代价是 5 万到 15 万美元、6 到 18 个月。本地方案把这些成本全部抹掉。这是受监管行业需要看到的总拥有成本对比。
隐私优先 AI 意味着数据层的隐私——而不仅仅是推理层
大多数'隐私优先 AI'讨论关注的是模型在哪里运行。更大的隐私风险在于训练数据在哪里准备。如果你的数据准备在云端进行，你的隐私保证就是表演。