私有化 AI 与公有 API 的混合架构

混合架构，指的是按数据敏感度与任务类型，把请求分流到私有环境、外部服务或边缘设备上处理。它在多数企业里比纯私有更现实，原因很直接：完全私有化要独自承担全部算力与运维成本，完全依赖外部又要面对数据边界问题，而真实业务的敏感度分布本来就是分层的

为什么很少有真正的纯私有

纯私有意味着所有推理、所有模型更新、所有配套工具链都在内部闭环。它能成立，但需要两个前提同时满足：数据边界不允许任何外发，且企业有能力长期承担这套环境的运维。

多数企业的真实情况是：一部分数据绝对不能出域，另一部分只是公开信息。对后者也按最高等级处理，付出的是效率与成本；对前者放松要求，付出的是合规风险。混合形态的价值就是把这两类分开处理，而不是统一按最严或最松的口径走。

三条分流规则

• 按数据定红线：核心知识产权、客户隐私与监管敏感数据只能在私有环境内处理，这条不设例外审批。
• 按任务定路由：通用理解、翻译、摘要这类不依赖专有知识的任务可以走外部服务；涉及内部口径与专有知识的任务必须留在私有侧。
• 按后果定复核：输出会直接影响客户、资金或合规结论的，无论走哪一侧都要保留人工复核环节。

三条规则的顺序不能调换。先划红线，再分任务，最后排复核 —— 如果从任务出发，很容易在效率压力下把敏感请求挪到外部侧，而这类调整在事后往往找不出是哪一次决定的。

四种部署形态怎么对比

• 公有服务：起步快、弹性好，适合通用任务与试验阶段，代价是数据边界受制于外部条款。
• 私有部署：数据与形态完全可控，代价是算力周期与运维投入，适合高敏感场景。
• 混合形态：按规则分流，需要额外承担编排层与一致性维护的成本。
• 边缘与端侧：推理发生在设备本地，适合低延迟与离线场景，受限于设备算力与模型规模。

形态之间没有优劣，只有适配。同一条业务链路上出现两种形态也很正常，关键是有没有一条规则说明为什么是这个组合。

分流靠什么真正执行

规则写在文档里不会自动生效，需要落到编排层的三件事上：请求入口的标签、路由的判定条件与日志。

• 入口打标：请求进入时先判定数据级别与任务类型，标签由系统给出，不依赖调用方自觉声明。
• 网关受控：两侧之间的数据交换经过受控网关，避免明文传输敏感字段。
• 日志同源：无论请求走哪一侧，调用记录都落在同一处，便于事后还原完整链路。

边界与验收

混合架构最大的风险不是技术实现，而是一致性：同一份知识在两侧出现不同版本，同一类请求因规则模糊而时左时右。验收要能证明规则真的在生效

• 抽样核对请求：随机取一批真实请求，确认路由结果与规则一致，异常请求有记录与解释。
• 越界证据：出现过被规则拦下或改道的请求，而不是所有请求都恰好符合预期。
• 口径一致：两侧引用的同一份知识出自同一来源，版本时间差在约定范围内。
• 责任清晰：每一类请求的负责人、复核点与升级路径都已指定，而不是默认由平台团队兜底。