“私有 AI”一词被用来表示从“我们在 SaaS 账户中关闭了训练”到“我们在自己的基础设施上运行开放权重模型”等各种情况。这些情况并不属于相同的控制边界。
对于中小型企业（SMEs）而言，合适的私有AI架构取决于数据、任务、质量要求以及团队运维基础设施的能力。最私有的选项并不总是最佳选择。最强大的选项并不总是适用于数据。最便宜的选项如果需要持续的工程投入，可能会变得昂贵。
本文提供了一个决策框架。应将其与主要的 GDPR 文本、NIST AI 风险管理框架、供应商合同、数据控制文档以及所选推理服务引擎的安全指南（如 vLLM 安全指南）结合使用。
从数据分类开始，而不是模型偏好。在正确的隐私边界中使用一个能力较弱的模型，也比让前沿模型处理不应接收的数据更好。
五种部署模式
| 模式 | 定义 | 适用场景 | 主要限制 |
|---|---|---|---|
| 企业 SaaS | 带有管理员、SSO、数据保留和不用于训练选项的商业层级 | 大多数常规公司工作 | 数据仍然会离开你的环境 |
| VPC 或私有云 | 在受控云边界内运行的托管模型端点 | 需要更强隔离的机密工作负载 | 成本更高且设置复杂 |
| 自托管推理 | 在你自己的基础设施上运行开放模型 | 受限数据、自定义模型、规模经济 | 运维负担 |
| 本地设备模型 | 模型在笔记本电脑、工作站或边缘设备上运行 | 离线、敏感、低延迟的窄任务 | 模型较小且设备限制 |
| 混合路由 | 将每个用例路由到匹配的边界 | 混合敏感度组合 | 需要分类纪律 |
个人消费者账户通常不提供组织集中管理的身份、保留、连接器、合同和审计配置。公司政策应明确是否允许使用此类账户，以及允许处理哪些数据。
组织可能需要采用一种模式或受控的组合方案。目标是为每个批准的使用场景选择并重新验证边界，而不是将某个产品标签视为永久的保障。
首先对数据进行分类
以下四个分类仅作为初步示例。请根据组织实际的信息分类体系和法律要求调整名称和处理规则：
| 数据类型 | 示例 | 默认AI边界 |
|---|---|---|
| 公共 | 网站内容、已发布文档、公开研究 | 在完成权利、真实性、提示注入和条款检查后，使用批准的工具 |
| 内部 | 工作流程笔记、匿名示例、非敏感草稿 | 企业SaaS |
| 机密 | 客户数据、合同、源代码、财务信息、战略信息 | 带有控制措施的企业SaaS、VPC或自托管 |
| 受限 | 健康数据、受法律特权保护的信息、人力资源调查、受监管记录 | 法律/安全审查；可能需要使用批准的本地部署、VPC、自托管或无AI方案 |
这种分类方式可以避免一个常见错误：由于使用方便，将同一助手用于公开博客草稿和机密客户记录。
凭证、私钥、认证令牌和恢复代码不属于模型路由分类。应将它们排除在提示、检索语料库、遥测数据和模型可访问的工具之外；如果确定性集成需要凭证，应使用密钥管理器和范围狭窄的运行时注入。
模式 1：企业 SaaS 作为默认选项
企业 SaaS 可能是操作复杂度最低的候选方案。产品名称、计划权益和合同条款会变化；需对每个短名单中的计划进行验证：
- 合同中的数据使用和模型训练条款。
- 管理员控制功能。
- 单点登录（SSO）和访问管理。
- 数据保留控制。
- 审计日志。
- 安全文档。
- 供应商支持。
这些控制措施可能支持批准的工作，但购买计划本身并不表示特定数据类别或工作流程是合法或安全的。
关键在于配置。购买团队计划是不够的。需要设置数据保留、共享、连接器访问、批准的工作区和数据规则。
模式 2：VPC 或私有云
当数据可能离开应用程序但必须保留在定义的云和合同边界内时，VPC/私有云模式是候选方案。“位于 VPC 内”并不能证明所有控制平面、模型服务、日志、支持或备份路径都保留在该区域内；请绘制并测试完整的数据流。
- 处理机密工单的客户支持助手。
- 基于敏感文档的内部知识助手。
- 合同或发票的文档提取。
- 在需要比 SaaS 更强数据隔离的特定领域中使用助手。
需要验证的潜在优势：
- 在所选服务设计下更强的隔离性。
- 对网络和日志的更多控制。
- 可能满足定义的采购要求的证据。
- 与完全自托管不同的运营分工。
需要评估和测试的潜在限制：
- 该工作负载的定价可能超过共享的 SaaS 计划。
- 需要额外的集成和平台工作。
- 可选的模型范围可能较窄。
- 你仍然依赖于提供商的基础设施。
请将此视为一个折中方案，而非中小企业默认的选择。
模式 3：自托管推理
自托管意味着由你运行模型运行时，例如 vLLM、TGI、SGLang、llama.cpp、Ollama 或其他服务技术栈。在以下情况下这样做是有意义的：
- 数据不能离开你的环境。
- 你需要一个定制或微调的开放模型。
- 推理量足够高，足以证明基础设施投入的合理性。
- 延迟或可用性需求要求直接控制。
- 你有具备相应运维能力的人员。
不要仅仅因为自托管看起来更“纯粹”就选择它。运营成本是真实的：GPU 容量、监控、升级、安全补丁、模型评估、扩展和事件响应。
自托管对于合适的组织来说是一个强有力的选择。但对于没有机器学习基础设施经验的小型团队而言，它可能会变成一个脆弱的附属项目。
模式 4：本地设备模型
当整个设备、更新、遥测、备份和访问边界都受到控制时，本地模型可以作为隐私敏感的个人工作的候选方案：
- 总结本地笔记。
- 从私有文档中起草内容。
- 对内部片段进行分类。
- 离线现场工作。
- 对延迟敏感的边缘计算工作流程。
质量权衡因任务和模型而异。应通过具有代表性的摘要、分类、提取或起草任务来评估本地模型，而不是假设其性能与云端模型相等或劣于云端模型。
只有在本地模型通过任务评估且完整的本地边界获得批准时，才应使用本地模型；“在设备上运行”本身并不能证明隐私性。
模式 5：混合路由
混合候选方案可以通过批准的数据类别来路由工作负载：
- 公共和低风险任务将路由到企业级 SaaS。
- 机密检索在私有 RAG 系统内部进行。
- 受限提取在完整数据流审查后，仅使用特定批准的本地、VPC、自托管或无 AI 路由。
- 最终起草可能在敏感字段被移除后使用前沿模型。
- 日志和评估结果决定每条路由是否有效。
混合路由可以将不同记录匹配到不同的批准边界。它需要可执行的策略，而非仅依赖提示分类：
- 路由前的数据分类。
- 在可行情况下对敏感信息进行遮蔽。
- 明确的模型/工具白名单。
- 记录使用了哪个边界的日志。
- 私有模型无法完成任务时的回退机制。
决策框架
提出六个问题：
- 进入模型的数据是什么？ 公共数据、内部数据、机密数据、受限数据。
- 输出会产生什么影响？ 草稿、建议、决策、面向客户的操作。
- 需要什么质量？ 定义任务特定的准确性、安全性、延迟、拒绝率和人工审核目标，而不是使用如“专家级”这样的标签。
- 需要什么延迟？ 交互式、批量处理、实时、离线。
- 现有的运维能力如何？ 没有基础设施团队，还是有应用团队、平台团队或机器学习运维团队？
- 客户或监管机构需要什么证明？ 供应商文档、日志、数据驻留、审计追踪、隔离。
然后选择满足数据和质量需求的最低复杂度模式。
现在不要这样做
在测量工作负载和质量要求之前，不要自行托管。
不要将受限数据发送到消费者工具。
不要假设“开源”意味着私有。只有在部署、日志、访问和数据流均为私有时，才算是私有。
在未实施基于身份、由策略强制执行的数据分类以及默认拒绝路由的情况下，不要部署AI网关。集中式网关可以实施策略，但前提是必须对绕过机制、回退方案、日志记录和故障行为进行测试。
不要忽视评估。即使数据是私有的，但若结果错误，仍然是错误的。
一个实用的中小企业（SME）起点
以下是一种可供中小企业（SME）参考的起步流程，具体做法仍需根据实际情况审查：
- 批准一个企业级SaaS助手用于一般性工作。
- 编写一条数据分类规则。
- 除非经过审核，否则阻止访问受限数据。
- 为最有价值的机密使用场景构建一个私有RAG或VPC工作流。
- 在质量可接受的情况下，使用本地模型处理狭窄的敏感任务。
- 仅在隐私、定制化或成本明显合理的情况下，才重新考虑自托管。
这会产生一个分阶段的决策路径。通过设计和默认设置保护隐私，仍然需要记录目的、数据最小化、访问、保留、删除、处理者、传输和安全决策（欧洲委员会指南）。
架构与数据、风险和运营相匹配
私有 AI 的架构应与数据、风险和运营相匹配。可能需要一个组合方案，但每条路径都需要一位明确的责任人和经过验证的边界。
选择应基于数据、影响、质量、延迟、运营和证据。
