私有化部署：让企业数据留在可控环境里

写在前面 "数据不能出内网"是很多企业引入 AI 时的硬约束。这个约束不是技术偏好，通常来自监管要求、客户合同或行业规范。本文讲清楚在这个前提下，方案会发生哪些变化，以及哪些成本是绕不开的。

一、先确认约束到底有多硬

"私有化"在不同企业口中含义差别很大。落地前必须先问清楚：

很多项目在这一步就跑偏了——业务方说"要私有化"，实际需求只是"客户资料不能被第三方拿去训练"。后者用公有云加合同条款就能解决，成本差出一个量级。

先把约束问清楚，再谈架构。

用一句话区分"真私有化"和"伪私有化"

问业务方："如果模型供应商提供了合同保证，保证数据不用于训练、不跨境外传、且可审计——你还需要私有化吗？"

如果对方的回答是"那可以再考虑"——这不是真私有化，是安全感问题。如果对方的回答是"不行，我们必须符合 XX 监管规定"——这是真私有化，按全栈本地部署来规划。

二、模型选型：效果、成本与算力的三角

本地部署意味着你要自己承担推理算力。这里的取舍非常实在：

• 参数量越大，效果越好，硬件成本越高。 一个能跑大参数模型的推理服务器，采购成本不是小数目，还要算上机房、电力和运维。
• 不是所有环节都需要最强的模型。 意图识别、文本分类、结构化抽取这类任务，小模型完全够用，而且响应更快。真正需要强推理的环节往往只占少数。
• 量化会损失效果，但幅度取决于任务。 需要在你自己的业务数据上实测，不能只看公开榜单。

我们的做法是先用企业自己的真实语料做一轮评测，把任务按难度分层，再决定哪些环节用什么规格的模型。"全部用最大的模型"通常是最贵且不必要的方案。

算力选型速查

注意：这里说的是"起步"。随着用户量上升，并发压力会显著增加。私有化环境不能像公有云那样弹性扩缩——规划时按 3-6 个月后的预期用量留余量，而不是按第一天上线的量。

三、业务系统接入：能用数据，但不越权

AI 只有连上业务系统才有价值。私有化环境下的接入原则：

1. 通过既有的 API 和权限体系接入，不要为了 AI 单独开一个"超级账号"绕过原有的权限设计。
2. AI 的数据可见范围 = 当前用户的数据可见范围。 这一点必须在检索层强制，而不是靠提示词约束模型"不要说"。
3. 写操作需要人工确认。 查询可以自动化，但涉及修改业务数据的动作应保留确认环节。

第 2 条是最容易出事的地方。曾经有过这样的设计：知识库用统一账号建索引，检索时不过滤，靠提示词告诉模型"只回答该用户有权限的内容"。这是无效的——模型不是权限系统。

业务系统接入的安全边界

与内部系统对接时，有一条红线：AI 系统对业务系统的访问权限，不应超过它代表的用户本身的权限。 换句话说，AI 是用户的"代理"，不是拥有独立权限的"超级系统"。

如果张三没有权限查看财务部的报表，AI 帮张三查数据时也不应能看到。这个约束在技术上的实现是：AI 调用业务系统 API 时，带上用户身份，由业务系统自己执行权限校验。不要把权限校验的逻辑放到 AI 系统里——权限的正确来源永远是业务系统本身。

四、权限与审计

企业内控和合规检查通常会关心这几件事：

• 账号与角色：谁在用，用什么身份用。
• 访问范围：能查到哪些数据，边界在哪。
• 完整日志：谁在什么时候问了什么，系统检索了哪些内容，返回了什么。
• 可追溯：出问题时能还原完整链路。

我们在自有平台上把 AI 的每一次运行都记录成结构化数据——一次运行、每一个步骤、每一次工具调用分别落表，包含模型调用、检索内容、耗时和报错。这套可观测性设计在私有化交付时会一并提供，它同时服务两个目的：合规审计，以及排查"AI 为什么这么答"。

日志该存多久

法规层面，等保 2.0 和行业监管通常要求审计日志至少保存 6 个月。实际操作层面，我们建议按"至少 12 个月 + 关键操作永久保存"来规划。因为很多合规问题不是上线后立刻暴露的，可能在一年后的一次内部审计中被翻出来。

同时要规划好日志的存储方案——对于中等以上规模的企业，AI 问答日志的增长速度可能超过应用日志，单独规划存储容量。

五、部署形态

常见的三种：

全本地部署

模型服务、向量库、应用层、存储全部在企业内网。适合完全隔离场景，硬件投入最大。

优点是数据完全不离开企业控制，合规风险最低。缺点是初期投入高、弹性差、运维负担重。

混合部署

敏感数据处理和存储在本地，非敏感的通用能力调用外部服务。需要明确划分数据边界，工程复杂度最高，但性价比通常最好。

一个典型的分界：原始文档和用户查询在本地处理，模型推理走外部 API（但需确保 API 调用不存储数据）。这样做的前提是你能向合规部门证明"发送到外部 API 的内容中不包含敏感数据"——这是一个需要技术方案支撑的合规论证。

专有云部署

在企业专属的云环境中部署整套系统。介于两者之间，兼具公有云的运维便利和一定的隔离性。

我们的系统采用容器化部署，各组件（应用服务、文档处理、向量库、图数据库、缓存、对象存储）都可以独立部署在企业指定的环境中，这让三种形态的切换成本不至于太高。

六、长期运维是最容易被低估的成本

私有化项目的真实成本，往往不在初次交付，而在之后的两年：

• 模型和框架在快速迭代，不升级会逐渐落后，升级要重新验证
• 硬件故障、容量扩展、性能调优
• 业务变化带来的知识更新和策略调整
• 企业内部人员流动导致的知识断层

我们建议在项目立项时就把运维方案和责任边界写清楚：哪些由企业自己维护，哪些由我们负责，升级节奏是什么。含糊带过的项目，一年后通常会陷入"没人敢动"的状态。

运维责任划分模板

签合同前把这表填好，比任何"我们会好好维护"的口头承诺都管用。

七、典型交付流程

环境与约束评估  →  模型与算力选型  →  内网部署与联调
     →  权限体系与审计接入  →  试点验证
     →  运维交接与文档移交  →  持续升级

八、一个务实的建议

如果你不确定私有化是否必要，可以先做一个小范围的 POC：用非敏感数据、在受控环境里验证效果和成本。先确认这件事值得做，再讨论怎么把它做得合规。

反过来的顺序——先花几个月搭一套完整的私有化环境，再发现业务效果不达预期——我们见过不止一次。

想评估你的环境约束和落地成本，欢迎联系我们。