AI 助手三种部署架构的数据边界

AI 助手从演示走向正式使用，安全评审往往先问：数据到底去了哪里？原文给出三种部署模式：供应商托管的 SaaS、数据面放在客户云账户、连模型都放进客户机房的隔离部署。

这是一份架构选型索引，没有性能测试，也没有成本对照。它值得读的地方，是把讨论从「模型好不好用」拉回到「谁运行系统、什么会越过边界」，并提醒了一个容易漏掉的出口：域名解析。

三种部署模式，分别把什么交给供应商

部署位置决定了数据边界，也决定了谁承担运行责任。

原文的 Pattern 1 是共享服务（SaaS）。供应商运行全部系统，服务位于约定的数据驻留边界内。客户不用自行运行整套系统，但仍需弄清边界的具体范围。原文没有交代区域、日志留存和模型调用路径，不能据此推断这些问题已经解决。

Pattern 2 是控制面与数据面分离（control/data split）。客户在自己的云账户运行完整数据面，也就是实际承载数据处理的部分；供应商只保留签名、许可证和支持。

这里的重点是「完整数据面」。仅把入口服务部署到客户云账户，不能证明后续处理也留在那里。原文没有提供组件清单，具体哪些服务属于数据面，还需要完整架构说明。

Pattern 3 是隔离站点（isolated site）：所有东西，包括模型，都运行在客户自己的机房里，没有通往互联网的路由。它比「服务部署在自己的云上」更进一步，连模型运行环境也收进了本地边界。

这三种模式是不同的责任分配，原文没有证明哪一种普遍更好。

没有互联网路由，为什么还要检查域名解析

作者称，自己分别为三种模式写了参考架构，覆盖架构图、请求逐跳流转、跨边界内容及取舍。不过，当前提供的原文没有展开这些设计，无法核对每一跳的实现。

其中一个具体修正来自读者反馈：没有互联网路由，不代表域名解析不会把数据带出网络。

域名解析（DNS）是把域名转换为地址的过程。查询的域名本身可以携带信息；如果解析请求仍能经由某条路径传到边界外，就可能形成数据出口。只检查业务请求能否访问公网，还不足以证明网络完全隔离。

作者表示，这项修正已经加入全部三份架构。原文没有给出修正配置，因此能拿走的是检查思路，不能直接拿它当作隔离已成立的证据。

我的判断

我认同作者把「数据去了哪里」放在选型前面。对 AI 助手而言，部署标签太粗，逐跳说明请求流转和跨界内容，才便于安全评审判断。

但这篇属于架构讨论，没有生产运行数据，也没有对照实验。它未说明三种模式的成本、维护投入或性能差异，作者也在向生产使用者征集反馈。因此，不能把它解读成某条路线已经得到验证。

SaaS 把系统运行交给供应商；客户云模式要求客户承接完整数据面；隔离站点还要面对本地模型维护。尤其是补丁和模型更新，原文明确提出了问题，却没有给出方案。选隔离部署之前，这个缺口必须补上。

能拿来做什么

• 为团队接入 AI 编程助手时，先要求供应商说明属于 Pattern 1、2、3 中哪一种，再列出请求每一步经过的系统，以及跨边界的数据。
• 评估客户云方案时，核对完整数据面的部署范围，单独确认供应商保留的签名、许可证和支持环节会接触什么信息。
• 检查隔离环境时，把 DNS 查询路径加入网络审查，并要求方案同时说明补丁和模型如何更新；原文没有提供可直接照搬的更新流程。