在云平台上选大模型，采购人员过去常问三个问题：有没有最新版本、价格是多少、能否接入现有账单。Google Cloud 10月22日宣布的Claude新部署方式，恰好提醒企业还要问第四个问题：谁实际处理我的数据？新方案已经正式可用，但它不是把原有Claude入口换个名字。Google管理和Anthropic管理两条路径并存，模型、标价与Google Cloud计费保持一致，数据处理主体、可用的平台功能和治理边界却不同。对一个用模型处理客户资料、内部代码或财务文件的团队来说，这种差别并不比模型跑分小。
两条路径卖的是不同的控制权
按照Google Cloud的官方说明，新推出并达到一般可用状态的是“Anthropic-managed”部署选项。模型运行于Google Cloud基础设施，但Anthropic负责运营相应技术栈并作为数据处理方，适用Anthropic的服务条款。企业仍能使用Google Cloud身份与访问管理、云审计日志，并将费用纳入既有Google Cloud账单及符合条件的采购承诺。该方案强调Claude新版本的首日访问，以及Claude Managed Agents测试版、skills和代码执行等Claude平台功能。这里必须分清“部署方案一般可用”和“其中某项功能仍处测试版”：前者不能替后者作成熟度担保。
原有的“Google-managed”路径继续提供Claude最新模型，但由Google Cloud担任数据处理方，并沿用客户现有协议。Google突出的是VPC Service Controls、客户管理的加密密钥，以及美国、欧盟、亚太的数据驻留选择。Claude平台的新功能也会逐步整合进这条路径，因此两种方案并非功能完全同步。若企业目前最看重受控网络边界和既有合规协议，原有路径仍有吸引力；若更在意Anthropic平台功能尽快可用，新路径则提供另一种取舍。
这不是一个“哪条更安全”的简单选择。身份管理和审计日志可以帮助记录谁调用了服务，却不能自动回答合同中的数据角色、留存与删除、跨境处理、事故通知由谁承担。加密和数据驻留同样要落到具体服务、地区及合同条款，不能因为页面写着一个地区就推断所有请求、日志和支持流程都永远不离开当地。采购和法务应把两种部署的服务条款、数据处理附录、产品可用区与功能清单放在同一张表里逐项核对，而不是只看模型名称。
真正的迁移成本藏在应用周围
对于开发团队，切换模型入口似乎只需改配置；对于已经运行的业务系统，入口背后还有密钥轮换、权限授权、预算归集、调用追踪、日志存放、故障应急和内部审批。Google强调两条路径可使用同一批前沿模型、相同定价和相同账单体系，这会降低采购障碍，却不会让治理差异消失。企业尤其要确认，已经在Google-managed路径建立的网络限制和加密控制，切换到Anthropic-managed后是否仍以同样方式生效。官方描述列出的控制项并不完全相同，不能把一个入口的配置效果直接复制成另一个入口的合规结论。
还有功能上线的时间差。Anthropic运营的方案可以较早接入Claude平台的新能力，Google运营方案则需要逐项整合。如果企业正准备把代理、代码执行接入核心流程，功能可用只是第一道门，随后还要做最小权限、执行环境隔离、数据输入分级和结果复核。尤其是代码执行一类能力，模型能生成并运行步骤，并不意味着企业可以省去沙箱、出站限制或人工批准。真正上线前，需要用自己的数据和实际工作负载验证效果、成本与失败模式。
更值得关注的是云市场竞争方式的变化。模型供应商和云平台不再只争论谁有独家模型，而是在同一云账单里提供不同运营责任的服务。客户可以保持统一采购入口，同时选择更接近模型提供方的功能节奏，或保留云平台管理的数据边界。这对多模型企业有价值：它让技术团队试新功能的路径更短，也迫使风险团队把“同一云上”与“同一责任主体”区分开来。
因此，这次公告最重要的不是Claude又出现在一个模型目录，而是部署责任被明白地摆到台面上。Google Cloud已正式提供Anthropic管理的选项；Claude Managed Agents仍是测试版，其他新功能也需逐项看可用性。企业不妨从低敏感、可回滚的工作流做对照测试，记录延迟、单次任务总成本、审计可追溯性和权限变化，再决定哪些应用适合迁移。模型能力相同，不等于服务边界相同；把这句话写进采购清单，可能比追一个新的性能数字更有用。