“私有AI”可以指“已禁止SaaS服务使用账户数据训练模型”，也可以指“在隔离网络中的自有GPU上运行开放模型”。两者并不是一回事。
对于中小企业而言，正确的私有AI架构取决于数据、任务、质量要求和团队的基础设施运营能力。隐私保护最强的选项未必总是最佳选择。最强大的选项未必总是符合数据要求。最便宜的选项如果需要持续的工程关注，可能变得昂贵。
本文提供实用指南。
应从信息分类开始，而不是从模型偏好开始。在正确安全边界内运行能力稍弱的模型，优于让更先进的模型接触其不应处理的信息。
五种部署模式
| 模式 | 定义 | 最佳适用场景 | 主要限制 |
|---|---|---|---|
| 消费者级SaaS | 个人ChatGPT/Claude/Gemini账户 | 公共或个人低风险任务 | 企业控制能力弱 |
| 企业级SaaS | 提供管理员控制、SSO、数据保留策略和禁止训练条款的企业账户 | 大多数常规企业工作 | 数据仍会离开组织环境 |
| VPC或私有云 | 受控云边界内的托管模型端点 | 需要更强隔离的机密工作负载 | 成本和设置更高 |
| 自托管推理 | 在自有基础设施上运行开放权重模型 | 受限数据、自定义模型、规模经济 | 运维负担 |
| 本地设备模型 | 模型在笔记本电脑、工作站或边缘设备上运行 | 离线、敏感或低延迟的限定任务 | 模型规模和设备能力受限 |
大多数公司需要多种模式。目标不是永远选择一种模式。目标是将每个用例路由到正确的边界。
首先进行数据分类
使用四个分类级别：
| 数据类型 | 示例 | 默认AI边界 |
|---|---|---|
| 公共 | 网站内容、已发布文档、公开研究 | 任何批准的工具 |
| 内部 | 工作流程笔记、匿名示例、非敏感草稿 | 企业级SaaS |
| 机密 | 客户数据、合同、源代码、财务、战略 | 带控制的企业级SaaS、VPC或自托管 |
| 受限 | 健康信息、受法律特权保护的信息、人力资源调查、受监管记录、身份凭证 | 法务与安全审查；通常采用本地、VPC，或完全不使用AI |
这种分类可避免一个常见错误：仅图方便，就让同一个助手同时处理公开博客草稿和机密客户记录。
模式1：企业级SaaS作为默认选择
对于许多中小企业，企业级SaaS是合适的默认选择。ChatGPT Enterprise/Business、Claude for Work、Microsoft Copilot、Gemini for Workspace等工具通常提供：
- 合同明确约定客户数据不用于模型训练。
- 管理员控制。
- SSO和访问管理。
- 数据保留策略。
- 审计日志。
- 安全文档。
- 供应商支持。
这足以满足大量工作：写作、摘要、研究、会议记录、内部分析和经批准的客户上下文使用。
关键是配置。购买团队计划并不足够。需设置保留、共享、连接器访问、批准的工作区和数据规则。
模式2：VPC或私有云
当数据可能离开您的应用程序但必须保留在受控云边界内时，VPC/私有云模式很有用。示例包括：
- 通过机密工单的客户支持助手。
- 在敏感文档上的内部知识助手。
- 合同或发票的文档提取。
- 需要比SaaS更强数据隔离的领域特定助手。
优势：
- 更好的隔离。
- 对网络和日志的更多控制。
- 更容易向安全要求严格的客户说明采购与安全依据。
- 比完全自托管的运营负担更少。
限制：
- 比SaaS更昂贵。
- 集成工作更多。
- 模型选择可能更有限。
- 仍依赖提供商基础设施。
对于许多成熟的中小企业系统，这是实用的中间选择。
模式3：自托管推理
自托管意味着您运行模型运行时：vLLM、TGI、SGLang、llama.cpp、Ollama或其他服务堆栈。当以下情况适用时有意义：
- 数据不能离开您的环境。
- 需要自定义或微调的开放权重模型。
- 推理量高到足以抵消自建基础设施的成本。
- 延迟或可用性需求需要直接控制。
- 有能够运维该系统的人员。
不要只因为自托管看起来更“纯粹”就选择它。运营成本真实存在，包括GPU容量、监控、升级、安全补丁、模型评估、扩缩容和事件响应。
对具备相应能力的组织而言，自托管是有力的选择；对缺乏机器学习基础设施经验的小团队而言，它可能演变成脆弱的附属项目。
模式4：本地设备模型
本地模型在隐私敏感的个人工作中被低估：
- 汇总本地笔记。
- 从私有文档起草。
- 分类内部片段。
- 离线现场工作。
- 延迟敏感的边缘工作流。
权衡是质量。小型本地模型可能足够用于摘要、分类、提取和初稿。它在复杂推理、复杂写作或广泛工具使用方面无法与前沿托管模型匹配。
当任务范围明确，并且保护边界比追求最先进的模型质量更重要时，使用本地模型。
模式5：混合路由
成熟的模式是混合：
- 公共和低风险任务发送到企业级SaaS。
- 机密检索在私有RAG系统内进行。
- 受限提取在本地或VPC中运行。
- 最终起草可能在敏感字段删除后使用前沿模型。
- 日志和评估决定每条路由是否有效。
混合路由让您使用强模型而不将每条记录视为相同。它需要纪律：
- 路由前的数据分类。
- 在可行时对敏感字段进行脱敏。
- 明确允许使用的模型和工具清单。
- 记录使用了哪个边界的日志。
- 私有模型无法完成任务时的回退。
决策框架
提出六个问题：
- 哪些数据进入模型？ 公共、内部、机密、受限。
- 输出影响是什么？ 草稿、建议、决策、面向客户的操作。
- 需要什么质量？ 足够好、专家级、前沿推理。
- 需要什么延迟？ 交互式、批量、实时、离线。
- 组织具备哪些运维能力？ 无基础设施团队、应用团队、平台团队、机器学习运维团队。
- 客户或监管机构需要哪些佐证材料或审计证据？ 供应商文档、日志、数据驻留、审计轨迹、隔离措施。
然后选择满足数据和质量需求的最低复杂度模式。
目前不要这样做
在测量工作负载和质量需求前不要自托管。
不要将受限数据发送到消费者工具。
不要假设“开放模型”就意味着私有。只有部署、日志、访问和数据流均处于私有边界内，系统才是私有的。
不要在没有数据分类的情况下构建一个巨大的AI网关。它会错误地路由敏感数据。
不要忽略评估。私有但错误仍然是错误。
一个实用的中小企业起点
对于大多数中小企业：
- 批准一个企业级SaaS助手用于常规工作。
- 编写数据分类规则。
- 除非经过审查，否则阻止受限数据。
- 为最有价值的机密用例构建一个私有RAG或VPC工作流。
- 对范围明确且质量要求可满足的敏感任务使用本地模型。
- 仅当隐私、定制化或成本明确证明时才重新考虑自托管。
这样既能形成隐私保护内建的实施路径，也不必假定每个AI用例都需要GPU集群。
总结
私有AI的核心是让架构与信息相匹配。正确答案很少是“全部SaaS”或“全部自托管”，通常需要组合使用：企业级SaaS处理常规工作，私有环境或VPC处理机密工作流，本地模型处理范围明确的敏感任务，仅在规模或控制确有需要时采用自托管。
根据数据、影响、质量、延迟、运营和证明进行选择。这是平淡的版本。它也是能经受生产考验的版本。
