企业 AI 选云服务还是私有部署：先画清数据流、留存与降级边界

用一件真实任务把每个对象走一遍，记录谁发送、谁存储、谁能访问和何时清除。图中暂时无法确认的节点应标待核实，不能用“企业级”三个字替代证据。

云托管适合希望复用模型运维与容量的平台条件，但要核对产品、功能和部署类型的数据处理说明。混合部署把业务系统或检索留在受控环境，同时调用外部推理；需要明确哪些内容允许出站。自托管把推理与主要组件放在自己的环境，但硬件、更新、安全补丁、备份与值班责任会增加。

这些模式没有统一优胜者。关键业务要求与团队维护能力不一致时，应调整任务范围或数据处理方式。采购前让同一业务题在候选方案中运行，记录质量、延迟、故障处理和长期维护成本，不用产品演示代替生产验收。

微软当前的 Azure 模型数据说明分别讨论输入输出、上传数据和有状态功能的存储。这说明“是否用于基础模型训练”“提供服务如何处理”“可选历史如何保留”是不同问题。其声明适用指定的 Azure 产品和功能，不能推及所有供应商、模型市场或个人账户。

逐项取得当前产品说明、合同约定与实际配置。存储区域、处理区域、人员访问和删除时间可能有不同边界，尤其要核对全局部署、跨区路由和可选状态功能。文章提供技术盘点方法，具体合同与适用法规应由企业负责人员核实。

抓取网络目标时不输出凭证。需要进一步确认服务器端处理位置时，应以供应商当前说明和合同为依据，网络目标域名或 IP 本身无法证明全部后台处理都在某个地区。

例如企业约定只允许发送匿名产品问题，那么演练中应故意放入假联系人、订单号和合同片段。验证请求在进入外部端点前被脱敏或拒绝，并检查异常日志是否仍保存了原字段。正常路径通过后，再模拟备用模型、批处理上传和会话恢复，核对每条路径都遵守同一规则。

脱敏应有可以检查的输入输出样本，不能只在界面提示“已处理”。如果无法确认某条路径实际发送了哪些字段，就暂停该路径并记录未知项；不能把暂时没有观察到泄露解释为完整数据边界已经通过。

主要端点超时后，系统可能自动选择另一个模型、地区或工具。每条候选路径应同时检查模型能力、授权、数据分类和处理约束。没有允许的备用路径时，进入等待或人工处理，不为保持“总能回复”而绕过规则。

失败任务的提示、工具结果与日志也不能无限保留。重试和恢复需要稳定意图标识，防止已经执行的业务动作再次发生。数据出站失败、生成失败和业务执行失败分开记录；它们需要不同的补救方法。

除推理机器，还要考虑驱动与依赖、模型文件来源、版本更新、容量余量、备份恢复、监控脱敏和访问管理。自托管并不让这些责任消失。交付前安排恢复演练，确认另一位维护人员能按记录接管，而不只由最初搭建者操作。

如果流量明显有峰谷，比较闲置成本与峰值排队。云服务有配额与实际容量的区别，自托管有显存与任务耗时的限制。验收报告应写明测试负载、允许等待时间和超过范围后的行为，不能把一次低并发演示当作容量承诺。

最终记录允许的数据分类、各节点的存储与处理位置、调用身份、留存与清理、备用路径、备份恢复，以及企业和供应商各自负责的事项。未知项需要决定人和核实时间。

试点先处理可脱敏任务，保留完整数据流和评测记录。新增上传格式、连接器、有状态功能或备用模型时重新核对，不沿用最初选型的一句承诺。部署方案只有和实际任务、配置及运行证据对应，才方便后续验收和维护。