受监管行业的本地 AI 部署理由

受监管行业选择本地 AI，理由主要不在理念，而在结构。对于很大一类受监管数据来说，把它发送给第三方云服务这个动作本身，无论有多少合同保护，都会带来合规敞口，而本地部署可以把这个敞口消掉。

这不是偏好问题。在某些情况下，它是通向生产环境的唯一路径。

合规的现实

HIPAA 与受保护的健康信息

HIPAA 受保实体只有在有效的业务伙伴协议（BAA）之下，才能把 ePHI 传输给第三方。主流云 AI 服务商都提供 BAA。这有时被说成已经解决了 HIPAA 问题。并没有完全解决。

BAA 把某些泄露情形下的责任转移给了业务伙伴。它并不能解决数据驻留、训练用途、审计权和泄露通报时限等问题。具体来说：

训练用途：服务商是否会用 API 的输入去训练模型？如今多数企业协议已排除这一点，但该政策必须被明确确认并写进合同。一旦允许并实际发生，你的 PHI 就已经被吸收进一个你无法控制的系统。

数据驻留：数据存放和处理在哪里？HIPAA 并未强制只能在境内处理，但部分州法规和一些医疗合同有此要求。跨区域的云服务商可能在你的 BAA 未曾预料到的辖区处理数据。

审计权：HIPAA 要求受保实体能够审计其业务伙伴的安全实践。而在现实中，大型云 AI 服务商提供的是 SOC 2 认证，而不是直接的审计权限。你能核验那份认证，却无法核验其底层控制措施。

泄露通报时限：HIPAA 要求在发现泄露后 60 天内通报。你的 BAA 需要确保服务商的通报义务从他们发现之时起算，而不是从你发现之时起算。

BAA 能覆盖其中一部分。本地部署则把数据留在你自己的安全边界内，从而把这些问题全部消掉。

GDPR 与跨境数据传输

GDPR 第 44 条规定，只有在能保证充分保护的情况下，才可以把个人数据传输至第三国（欧盟／欧洲经济区之外）。美国并未获得充分性认定。向美国云服务商的传输依赖标准合同条款，或欧美数据隐私框架。

这两种机制都曾在欧洲法院反复受到挑战（Schrems I、Schrems II）。欧盟到美国的数据传输，其法律基础仍然面临政治和司法风险。对处理欧盟个人数据的受监管企业而言，这是一项实质性的持续敞口。

在欧盟境内做本地部署，等于彻底消除了跨境传输这个问题。数据从不离开该辖区。

欧盟《人工智能法案》对高风险系统的要求

《人工智能法案》为被归类为高风险的 AI 系统设定了额外要求，涵盖用于招聘决策、信用评分、医疗器械、关键基础设施和执法的 AI。高风险 AI 系统需要：

• 关于训练数据的技术文档，包括其特征与局限
• 足以事后追查决策过程的日志
• 人工监督措施
• 准确性、鲁棒性与网络安全方面的要求

这些要求同时适用于部署者和提供者。如果你把第三方 AI 模型部署到高风险场景中，你就承担了相应的合规义务，而履行这些义务需要拿到模型文档，那些文档你未必能从提供者处获得。

法律特权

由第三方系统处理过的文档，可能不再保有法律特权。「共同利益特权」原则的适用范围很窄，而法院对于为处理目的分享给云 AI 供应商的文档是否仍受特权保护，判决并不一致。

对律所和法务部门来说，这构成了敏感事务上采用云 AI 的结构性障碍。受特权保护的文档，必须在整个分析流程中保持这种状态。本地 AI 把处理过程留在了特权边界之内。

四类云 AI 根本无法进入的环境

除了监管框架之外，还有一些部署环境，无论合同保护多完备，云 AI 在结构上就不可能：

物理隔离的国防系统：这类系统在设计上就不与外部基础设施连通。涉密系统、武器系统网络和敏感政府基础设施都存在这样的隔离。云 AI 不是架构选项之一，因为根本没有通往那个 API 的网络路径。

涉密的政府环境：未经特定授权并满足架构要求，涉密数据不得传输给商业云服务商。多数商业 AI 服务商没有接收涉密数据的资质。涉密系统的运行授权（ATO）流程需要数年。

没有互联网连接的受监管临床系统：一些临床环境，尤其是较老或较专门的系统，出于设计或组织政策的原因完全不联网。放射科系统、临床试验数据库和老旧的 EHR 部署，可能运行在隔离网络上。

数据外传本身即构成违规的系统：在某些情况下，合规问题不在于数据存在哪里或受到怎样的保护，而在于只要把数据传出去就已经构成违规。某些合同保密义务、商业秘密保护和数据治理框架，无论接收方有何种保护措施，都禁止数据外传。

云 AI 服务商提供什么，以及不提供什么

主流云 AI 服务商通常提供：

• 面向 HIPAA 受保实体的 BAA
• 用于 GDPR 合规的数据处理协议
• SOC 2 Type II 认证
• 私有部署选项（VPC、专用实例）
• 面向企业客户的不用于训练承诺

而他们通常不提供：

• 在你自己硬件上的本地部署
• 你的员工对基础设施的物理访问权
• 超出第三方认证之外的直接审计权
• 模型不会变更的保证
• 让数据完全不经过公共互联网的网络架构

私有部署选项（VPC、专用云实例）能缓解部分顾虑，但不是全部。数据仍然在服务商的基础设施上，仍然受制于他们的安全事件、他们的员工访问政策和他们的业务连续性。

自托管 AI 的 DevOps 门槛

云 AI 的显而易见的替代方案是自托管：在自己的基础设施上跑一个开源模型。这条路走得通，但它带来的 DevOps 负担，在受监管企业里会衍生出新的问题。

自托管一个 AI 模型，通常意味着 Docker 容器、Kubernetes 编排、GPU 驱动、CUDA 版本管理、模型服务基础设施和监控栈。这需要相当可观的基础设施专业能力。对于那些把 AI 当作工具而非核心产品的企业来说，维护这套基础设施就是与团队主业争夺资源的额外开销。

更实际的问题是：受监管企业往往对可安装的软件和可搭建的基础设施有严格管控。为了给一个语言模型提供服务而拉起一个 Kubernetes 集群，可能需要数月的安全审查和基础设施审批，这就把「在 AI 上快速推进」的初衷抵消掉了。

原生桌面应用为什么能解决自托管 Web 应用解决不了的问题

一个原生桌面应用，比如用 Tauri 或 Electron 构建的，安装方式和任何企业软件一样。安装包走的是与其他应用相同的审批流程。IT 可以用标准的软件管理工具（SCCM、Jamf、Intune）分发它。AI 模型跑在本机上，直接使用硬件，不暴露网络，也没有服务器基础设施需要维护。

这与自托管 Web 应用是实质不同的部署模型，后者需要：

• 一台服务器来托管应用
• 网络配置，让用户能够访问
• 一套认证系统
• 一套备份与恢复策略
• 一支 IT 团队来维护

原生桌面应用绕开了以上全部。它是工作站级别的部署，任何 IT 部门用标准工具就能管理。

对受监管行业的领域专家而言，比如放射科医生、律师、金融分析师，这也更容易上手。他们整天都在用桌面应用。一个装在本机上的 AI 工具能自然融入这个工作流。而自托管 Web 应用要求他们记住并访问某个网址、管理会话状态，出问题时还可能得去找 IT。

经济账：云 AI 在受监管场景中的隐藏成本

本地 AI 的前期成本更高：硬件、安装、配置和后续维护。云 AI 前期成本更低，但有持续的订阅费，并且在受监管场景中还有一项可观的隐藏成本，那就是合规审批。

在一家大型受监管企业里，让一个云 AI 工具走完合规审查流程，可能需要 12 到 18 个月。安全评估、供应商风险管理审查、BAA 谈判、数据分级审查、法律分析，每一步都要时间，而且往往是串行的。

而一个不把任何数据处理到组织安全边界之外的本地部署，合规审查路径要短得多。数据从不离开，外部风险面接近于零，审查范围收敛到应用本身，而不是一段第三方供应商关系。

对于需要在监管环境中从「评估 AI」走到「AI 上生产」的企业来说，本地部署往往比云方案更快到达生产，而不是更慢。

各行业汇总

Ertas Data Suite 是一个原生桌面应用，基于 Tauri 2.0 构建，在架构上即为物理隔离，没有任何数据外传。它在你自己的硬件上、在你的掌控下运行完整的 AI 数据准备流水线（摄入 → 清洗 → 标注 → 增强 → 导出）。每一次操作都会记入合规日志。欧盟《人工智能法案》第 11 条和附件 IV 所要求的技术文档可直接从平台导出。

预约与 Ertas 的沟通 →

相关阅读：生产环境中的 AI 模型治理介绍了本地部署所支撑的更完整的治理框架。