摘要
- Google Cloud 的企业 AI 主张已不仅仅是调用 Gemini 模型。它所提供的是一个操作界面，将 Gemini Enterprise Agent Platform、Vertex AI 传统、BigQuery、Agent Search、IAM、Cloud Audit Logs、Cloud Run、Workflows 以及容量控制整合到一个受治理的工作流中。
- 被接受的输出是衡量价值的有用分母。模型回答仅仅是其中一个步骤；生产可靠性取决于数据新鲜度、工具权限、评估集、审计日志记录、配额设计、成本控制、异常处理和回滚。
- 公开证据支持 Google Cloud 在控制和需求方面的深度，但并不保证普遍理想的客户成果。Alphabet 的申报文件显示出 Google Cloud 的巨大增长和基础设施投资，而状态事件和文档则说明了客户为什么仍需要本地监督和恢复设计。
关键输出是被接受的受治理工作流，而非令人印象深刻的答案
Google Cloud AI 最令人印象深刻的演示是，利用大上下文窗口回答问题、基于数据生成的摘要、代理调用工具，或者开发人员从自然语言请求快速转为部署代码。这些演示很重要，但它们并非企业买家最终买单的生产单元。真正重要的是被接受的受治理工作流：即一个由模型支持的答案、决策、代码变更、数据结果、客户响应、安全建议或内部操作，企业愿意将其保留、审计并重复使用。
这一分母改变了评判标准。一个模型可以在几秒钟内生成流畅的答案，但如果它引用了过时的企业数据、以错误的身份操作、超出配额、在模型迁移后悄然改变行为、没有留下有用的审计记录，或者产生团队无法撤销的副作用，那么它仍可能在整体工作流中失败。被接受的输出涵盖了从请求到可用结果所需的每一项工作：数据准备、访问设计、检索调优、评估、人工审核、异常处理、监控、成本分配、事件响应以及迁移规划。
Google Cloud 适合这一测试，正是因为其公开主张已超越模型端点。在 Alphabet 2025 年年报中，Google Cloud 被描述为包含基础设施、平台、应用及其他云服务，并提供企业 AI 基础设施、Vertex AI、Gemini Enterprise 等 AI 产品，以及网络安全和数据分析。同一份申报文件指出 Google Cloud 2025 年收入为 587.05 亿美元，而 2026 年第一季度 10-Q 报告显示该季度 Google Cloud 收入为 200.28 亿美元，同比增长 63%。这并非小众开发者 API，而是一个要求客户将反复性工作迁移到其基础设施上的大型企业云业务。
这种规模提高了标准。如果 Google Cloud 希望成为员工、开发者、数据团队和运营团队接受 AI 支持工作的系统，客户就应依据日常重复任务而非前沿时刻来评判它。分析师能否就内部政策提出根基性问题，并获得当前、权限正确且可审计的答案？开发者代理能否在保留源代码控制、测试证据和回滚能力的前提下提出代码建议？客户支持或安全工作流能否将一项建议路由给正确的人，并附带足够的上下文以便接受或拒绝？数据团队能否知道哪个数据集、模型版本和用户请求产生了答案？这些都是生产问题，单靠模型能力无法回答。
法律和品牌边界并非表面功夫
我们所讨论的公司是 Google Cloud，即 Google 运营的云业务，提供基础设施、数据、安全、协作和企业 AI 服务。不应将其与 Google 搜索、消费者 Gemini 应用、DeepMind 研究公告、YouTube、Android 或每个碰巧使用 Google 模型的合作伙伴和客户成果混为一谈。Alphabet 自身的部门划分语言在此很重要：Google Cloud 包括 Google Cloud Platform 和 Google Workspace，而 GCP 服务涵盖基础设施、平台、企业 AI 基础设施、Vertex AI、Gemini Enterprise、网络安全和数据分析。这是本文的操作边界。
这一边界还能避免分析落入一个常见陷阱。Google 拥有世界一流的模型研究，但购买 Google Cloud 的客户并不能直接保证每一次模型突破都能转化为稳定的被接受工作流。研究进展可以提升原始答案质量，但受治理的工作流仍取决于云产品界面：IAM 角色、区域可用性、日志默认设置、数据连接器、配额、模型生命周期通知、支持安排、SLA、计费和变更管理。DeepMind 的模型成果与 Google Cloud 的生产结果相关，但它们并非相同的证据。
反过来，边界也一样。当客户案例提到 Replit 在 Vertex AI 上运行 Claude，或 Fifth Dimension 将 Gemini 和 Claude 推理集中在 Vertex AI 内时，证据部分是关于 Google Cloud 作为托管多模型控制平面的能力，而不仅仅是关于 Gemini。这一区别具有商业重要性。客户可能选择 Google Cloud 是因为能让他们将 Google 模型、合作伙伴模型、BigQuery、Cloud Run 和云安全控制组合在同一个架构中。同时，他们也可能面临转换成本，因为这些控制已成为他们被接受输出过程的一部分。
所以产品问题不在于“Gemini 优秀吗？”，而在于“Google Cloud 是否能让模型支持的工作变得足够可治理，以便企业在核算总成本后仍愿反复接受其输出？”Gemini 的质量是一个输入，云控制界面才是产品。
Google Cloud 出售的是一个控制界面
Google 当前的文档将Gemini Enterprise Agent Platform描述为一个统一平台，用于构建、部署、治理和优化企业级智能体系统和基于模型的解决方案。生命周期概述将生命周期划分为构建、扩展、治理和优化。其中列出了低代码 Studio、代码优先的 Agent Development Kit、Model Garden 访问、托管运行时、会话管理、Memory Bank、独特的代理身份、Agent Registry、Agent Gateway、Gen AI 评估、Cloud Observability 和 Topology。
这份清单意味深长。它表明 Google Cloud 知道企业 AI 不仅仅是推理。托管模型的同一平台还必须回答谁或什么在执行行动、哪些工具被批准、哪些数据在范围内、答案是否经过评估、行动是否可观察、运行时如何部署。因此，有用的比较对象不仅仅是 OpenAI、Anthropic、Microsoft、AWS 或开源模型，更是客户现有的工作流：手工分析师流程、现有 SaaS 工作流、数据仓库和 BI 堆栈、工单队列、自建代理框架，或是选择降低风险而减少自动化的决策。
该平台的各个公开部分自然地对应着生产问题。Agent Registry集中管理已批准的 AI 组件、MCP 服务器和端点，从而避免工具访问分散在不相连的实验之中。Agent Gateway使用注册表元数据、代理身份和策略控制，同时生成交互的可观测性遥测。Agent Identity基于 SPIFFE 为代理提供强证明的身份，文档指出身份默认不在多个工作负载间共享，且不能生成长期有效的服务帐户密钥。
这些控制之所以重要，是因为智能体系统的失效方式不同于聊天机器人。聊天机器人可能在文本上出错。而智能体在出错的同时，还可能阅读数据、调用工具、更新工单、编写代码、触发部署或将指令传递给其他服务。控制界面必须保持建议与行动之间的区别。它还需要在错误前提从语言进入生产状态时，保留一份持久的记录。
Google Cloud 的优势在于，上述许多周边组件已经存在于其云资产中。IAM、Cloud Audit Logs、BigQuery、Cloud Run、Workflows、Cloud Monitoring、VPC Service Controls 和计费并非来自某个独立业余项目的附加品，而是可纳入 AI 工作流的成熟云原语。而劣势也正相同：一旦客户采用集成路线，被接受的输出链条就会继承云平台的复杂性、成本模型和故障模式。
数据根基是首要的可靠性问题
大多数企业 AI 工作在到达模型之前就已失败。数据不完整、过时、权限过高、描述不清、重复、受区域约束，或散布在 SaaS 系统和数据仓库各处。一个单打独斗的强模型，如果检索系统提供了昨天的政策、过时的客户记录、用户不应看到的文件，或一张意义已变更却无沿袭的表格，仍然可能产生无法接受的答案。
Google Cloud 在解决此问题上拥有可信的原始素材。通过 Agent Search 进行根基校对允许 Gemini 通过 Agent Search 连接到网站或文档数据。该页面描述了 IAM 权限、AI Applications 激活和数据存储创建等前提条件，并说明对客户数据的根基校对最多可使用 10 个 Agent Search 数据源。独立的Agent Search 产品页面将该项服务定位为面向企业数据的托管 RAG 系统，描述了引用、链接、数据源控制和连接器。
这显著降低了构建成本。团队可以避免手工装配每个摄取、OCR、分块、嵌入、索引、检索和引用组件。但托管式根基校对并不能免除决定被接受答案应该基于哪些数据的工作。最大数据源数量是一项需要设计的限制。一个连接器在读取 Jira、SharePoint、Salesforce 或文档存储时，依然取决于这些系统的新鲜度、权限和语义。如果正式政策和草案政策都存在于存储中，除非检索层和指令层传达了相应的治理规则，否则模型可能不知道哪一个是权威的。
BigQuery 增添了第二个层次。其数据治理文档描述了 Knowledge Catalog、元数据发现、数据质量、数据剖析、沿袭、IAM、行级和列级访问控制、VPC Service Controls、审计日志、掩码、加密、共享控制、洁净室和使用指标。这些正是数据团队在接受来自数据仓库的模型支持结果之前所需的控制类型。它们也增加了工作量。必须有人定义术语表、所有者、质量规则、掩码策略、访问授权、沿袭摄取和使用监控。这项工作可能比从零开始构建私有数据治理堆栈更便宜，但并非没有成本。
数据治理也是总成本比较变得具体的地方。手工分析师可能花费数小时查找文档，但知道哪个来源是权威的。云根基化代理可能在几秒钟内给出答案，却需要数周的权限清理和数据存储调优，才能使答案安全到足以被接受。问题不在于 Google Cloud 能否检索数据，而在于客户能否在业务常规变化的速度下保持检索面准确且权限正确。
隐私承诺有帮助，但保留和区域仍需设计
Google Cloud 的公开承诺为企业买家提供了比消费级 AI 应用更强的起点。Google Cloud服务特定条款声明，未经客户允许或指示，Google 不会将客户数据用于训练或微调 AI/ML 模型。Agent Search 数据治理页面同样表明，Agent Search 中使用的客户数据不会用于训练基础模型，并且基础模型是冻结的，仅为服务处理输入以提供输出。
这一点很重要。它回答了董事会的首要问题之一：公司的输入请求、检索到的文档和输出是否成为其他人的模型训练数据。它还有助于将 Google Cloud 企业 AI 与管控较少的消费者应用区分开来。
但隐私条款不等于完整的治理设计。零数据保留文档表示，未经许可，Google 不会使用客户数据训练或微调托管模型，同时也描述了滥用监控和根基模式等场景，其中保留行为可能有所不同，客户可能需要申请例外或理解单独的条款。通过 Google 搜索和 Maps 进行根基化有其自己的保留语言。这并不意味着平台不安全，而是意味着客户必须针对其启用的每一项功能，映射其愿意暴露的数据类别以及可能处理这些数据的区域。
区域问题类似。根基化文档提到 AI Applications 可在全球、欧盟和美国多区域使用。受数据存留规则约束的企业不能假设每项 AI 功能、模型、连接器、日志和支持路径都具有相同的地理位置。数据主权很少是一个单一开关，而是一条由模型位置、数据存储位置、日志、支持访问、备份、监控、第三方模型使用以及员工访问构成的链条。
这一链条改变了采购思路。企业在 Google Cloud、其他云提供商、现有 SaaS 的 AI 功能、自有环境中的开源模型，或减少自动化之间进行选择时，应比较数据路径证据，而非口号。Google Cloud 拥有许多正确的控制原语，但买家仍需证明所选功能集符合其所在地、数据保留和审计义务。
权限决定着代理是有用还是危险
从答案到行动的转变取决于身份。只能进行摘要的模型被其文本所限。而模型支持的代理可以阅读私有数据、调用 API、书写工单、修改代码、更改客户记录、启动工作流或触发部署，它需要的权限模型必须比演示时的热情更窄。
Google Cloud 的文档为客户提供了若干有用的原语。Agent Platform IAM 文档指出，访问可以在项目或资源级别进行管理，当团队需要将访问限制在所需权限时，建议使用自定义角色。Agent Identity使代理本身成为主体，而不是将所有操作隐藏在单个共享服务帐户之后。Agent Gateway使用身份和注册表元数据进行授权决策和策略执行。
这些控制只有在客户严格使用的情况下才有价值。任何平台上阻力最小的路径都是在试点期间赋予广泛访问权限：一个服务帐户、一个宽松角色、大量工具，以及稍后再收紧的承诺。这对沙盒环境或许可接受，但对被接受的工作流却是错误的模式。受治理的工作流需要针对不同操作类别的独立身份、遵循用户或任务的数据源权限、与最大可接受爆炸半径相匹配的工具范围，以及能识别代理、用户和目标的日志。
设计还应区分读取、建议和执行。一个阅读政策并起草回复的代理不应自动拥有发送回复的权限。一个建议代码变更的代理不应自动合并。一个将客户问题分类的代理不应自动更改账户记录，除非该操作具有审批规则、后置条件检查和恢复路径。AI 工作流可靠性的关键不在于阻止每一次机器行动，而在于使每一项行动的权限清晰可见且有限。
这正是 Google Cloud 集成资产可以提供帮助的地方。Cloud IAM、服务帐户、资源级策略、VPC Service Controls 和审计日志是云安全团队所熟悉的。但治理对象已经改变：现在主体可能是一个代理，数据可能是检索上下文而非直接数据库查询，输出可能变成业务操作。安全团队应将代理权限视为生产特权，而不是请求写入设置。
评估是一项功能，而非判断的替代品
Google Cloud 值得肯定的是将评估作为平台叙事的一部分。Gen AI 评估服务概述称其支持对生成式 AI 模型及用例进行客观、数据驱动的评估，适用于模型迁移、提示词变更和微调等场景。其中描述了自适应评分标准，类似软件开发中的单元测试，是针对单个请求定制的通过/失败测试。代理评估文档将这一理念扩展到代理完成任务和目标的能力。
这是正确的方向。企业需要停止将 AI 评估视为一次性的供应商比拼。受治理的工作流需要对被接受的输出进行周期性测试：答案是否使用了批准的来源、是否遵守角色边界、是否包含足够证据、在数据缺失时是否拒绝、是否完成工具调用、是否避免不安全的输出格式、延迟和成本是否在目标内，以及是否保留了恢复路径？
但评估工具并不会创建真相集。客户仍需定义什么是好的答案，收集代表性案例，标记边缘案例，决定通过/失败阈值，包含负面示例，测试指令注入，测试过时数据，测试权限不匹配，并在业务变化时更新测试套件。如果一家公司从未书面规定其人工如何判断一份供应商风险摘要是可接受的，那么模型评估服务无法推断出整个策略。它可以在组织提供标准后将测试操作化。
评估成本也随雄心而增长。简单的摘要流程可能只需少量示例和手工抽查。一个编写代码、读取数据仓库、联系客户或更新合规记录的受治理代理则需要更深入的测试。需要针对不同操作的后置条件、跨模型版本的回归检查、对抗性指令、成本和延迟预算，以及在不确定情况下的人工审核。工作流越有价值，验收证据的成本就越高。
但这笔成本通常值得支付。没有评估的人工审核扩展性差，容易遗漏漂移。现有 SaaS 工具可能隐藏自己的模型行为。自建堆栈可能带来更大的评估负担，因为每个组件都需要本地组装。Google Cloud 的评估服务可以减少基础设施工作，但无法免除组织层面决定何为可接受的工作。
审计日志将黑箱转化为记录，但仅在启用并阅读时
可审计性是 Google Cloud 相比独立模型调用最明显的优势之一。Agent Platform 审计日志记录指出，Google Cloud 服务会写入审计日志，以帮助回答谁在何时何地做了什么。管理员活动日志无法禁用。系统事件日志标识修改资源的自动 Google Cloud 操作，也无法禁用。数据访问日志包含对用户提供数据的读取和写入，但文档说明它们必须显式启用。
另一个页面关于启用数据访问审计日志容易忽视却极端重要。其中提到，客户需要启用这些日志，才能获得有关模型端点使用的审计日志，且查看data_access流需要 Private Logs Viewer 角色。通用的Cloud Audit Logs 概述补充说明，除了 BigQuery，数据访问日志默认处于禁用状态，因为它们可能很大并产生费用。
这是一个实际的治理权衡。完整日志记录创造证据，但也带来成本、保留问题、访问控制问题和审查工作。如果团队未启用正确的日志，可能无法重建导致被接受输出的请求、端点、数据源、身份或工具调用。如果毫无节制地启用所有日志记录而没有路由和保留规范，可能会产生大量敏感日志却无人检查。可审计性不是一个勾选框，而是一个数据产品。
对于一个被接受的 AI 工作流，最低记录应包括请求工作的用户或服务、代理身份、模型和版本、检索来源、工具调用、权限决策、评估结果或审核步骤、最终被接受的输出，以及任何下游操作。Google Cloud 为这条链条的多个部分提供了文档，但端到端的记录跨越了产品边界。客户可能需要 Cloud Logging、应用日志、BigQuery 作业元数据、Agent Gateway 遥测、源代码控制记录、工单历史以及业务系统审计跟踪。
商业含义很简单：忽略审计审查所宣称的节省是夸大的。如果模型节省了 20 分钟的起草时间，却需要 10 分钟的证据检查，那么被接受输出的节省就不是 30 分钟。如果日志记录防止了一次代价高昂的错误，经济效益仍可能很好，但核算必须包含审查工作。
版本漂移是一项可靠性成本
AI 系统的变更频率高于传统企业工作流。模型退役、端点弃用、安全过滤器更改、上下文窗口变大、延迟特征变化、价格变化、合作伙伴模型出现或消失。Google Cloud模型版本和生命周期页面的存在，正是因为这是一个现实的操作担忧。它定义了 Gemini 和嵌入模型的生命周期术语，提供了日期，建议升级并指向迁移路径。发布说明记录了生产更新、功能、已知问题和已弃用的功能。
操作问题不在于变更是否发生，而在于变更是否在被接受的工作受损之前可见。一次模型迁移可能改善一般推理能力，却仍会改变语气、拒绝行为、输出模式、引用风格、Token 成本或工具调用频率。一次根基化更改可能提升一个语料库的检索效果，却降低另一个。一次安全过滤器更新可能阻止一个合法的内部安全任务。一份弃用通知可能迫使在繁忙的季度进行迁移。
Google Cloud 可以通过发布生命周期信息和评估工具提供帮助，但客户仍需保持迁移纪律。每个被接受的工作流都应尽可能固定或声明模型路径、配备回归套件、代表性数据集、变更窗口、回滚或降级选项，以及一位关注发布说明的负责人。如果工作流通过 Vertex AI 使用合作伙伴模型，客户还依赖于该合作伙伴的模型生命周期和条款。多模型选择减少了单一模型依赖，但可能增加测试工作量。
这也是被接受输出分母有用的原因之一。单次模型调用可能看起来便宜，但受治理的工作流包含了未来的迁移。如果客户无力测试模型变更，就不应将高后果工作深度自动化。如果工作流价值足够高，周期性评估和迁移规划就成为产品真实成本的一部分。
容量和事件使可靠性成为设计选择
Google Cloud 拥有服务于企业 AI 的基础设施规模，但客户不应将规模与无限容量混淆。Alphabet 2026 年第一季度 10-Q 报告了 4623 亿美元的 Google Cloud 相关尚未履行的履约义务，以及显著的技术基础设施投资。同时提到，2026 年第一季度资本支出为 357 亿美元，且 Alphabet 预计技术基础设施投资将较 2025 年增加。这一规模表明需求和承诺，但也显示 AI 容量是资本密集型的。
在产品层面，Google Cloud 公开了若干消费和容量概念。预置吞吐量概述描述了一种固定费用、固定期限的订阅，通过模型和位置为支持的生成式 AI 模型预留吞吐量。它建议针对实时生产应用、持续高吞吐的关键工作负载、可预测的用户体验以及确定性成本考虑此选项。配额文档列出了区域和模型限制、Agent Runtime 配额、评估配额以及批处理行为。其中提到，Gemini 批量推理使用共享池，在容量紧张时可能排队。
这些细节并非采购琐事，它们决定着一个工作流是否可靠。少数内部员工使用的客户支持代理比面对客户的理赔系统在高峰期的按需付费波动性更容易容忍。每晚运行的评估批处理如果结果明天才需要，可以排队；但如果决定着一小时内的部署，则不行。具有严格延迟目标的工作流可能需要预置吞吐量或降级路径。确定性成本可能与确定性延迟同样重要，因为模型支持的工作可能产生难以在试点期间预测的 Token、检索、日志和审查成本。
状态事件也说明了同样的问题。2026 年 2 月 27 日，Google Cloud 报告了一次Vertex AI Gemini API 事件，持续 1 小时 58 分钟，影响全球端点和美国区域。报告的根因是支持 Gemini 模型的安全过滤服务的配置更改，导致过载错误；修复措施包括回滚、增加容量、强化验证检查点和改进告警。2025 年 7 月 18 日，一次us-east1 多产品事件影响了 Cloud Run、Cloud Workflows、BigQuery、IAM、Cloud Monitoring、Vertex AI Online Prediction 和 VPC 等产品，原因是硬件工作流/控制平面问题。
这些事件并不证明 Google Cloud 格外不可靠，而是证明受治理的 AI 工作流依赖于共享服务：模型 API、安全过滤器、区域、网络、IAM、监控、编排和数据平台。一个具有韧性的工作流需要制定数据过期规则、重试规则、降级模型或队列、降级模式消息、人工紧急工单路径，以及区分平台故障和模型故障的方法。模型可能有能力，但端点被限流；数据可能正确，但工作流执行器在失败；代理可能健康，但 IAM 或网络路径受损。
因此，可靠性一部分是产品特性，一部分是架构选择。Google Cloud 提供 SLA 和容量选项，但客户仍需决定哪些任务值得预留吞吐量、多区域设计、人工降级或较低级别的自动化。
对计算而言，回滚比已接受的业务状态更容易
Google Cloud 为软件基础设施提供了成熟的部署控制。Cloud Run允许团队切分流量、逐步推出版本并回滚到先前版本。文档同时警告，流量更改并非即时，并且进行中的请求在转换期间继续处理。Workflows支持 try、retry 和异常处理结构。
这些对 AI 应用是很有用的控制。团队可以将新代理服务部署给小比例流量，监控错误，并在行为异常时回滚容器。它可以捕获瞬时 HTTP 故障，重试选定的调用，并跳转到异常路径。它可以将失败的工作流路由到工单，而不是假装操作已完成。
但业务回滚比基础设施回滚更难。如果代理起草了一份答案且人工尚未发送，回滚很简单：丢弃草稿。如果代理更新了 CRM 字段、提交了合规表单、更改了政策、发送了消息、批准了退款、开启了支持案例或合并了代码，其副作用存在于模型端点之外。回滚一个 Cloud Run 版本并不会撤回消息或恢复客户的旧认知。如果下游操作不具备幂等性，重试可能使临时故障恶化。
这正是被接受输出测试变得严格的地方。每一类操作都需要后置条件和恢复路径。代码变更工作流需要源代码控制证据、测试、部署回滚和问题归属。数据结果工作流需要查询沿袭、数据集版本、数据质量检查和修正程序。客户操作工作流需要审批阈值，以及在答案后来被发现错误时通知客户的方法。安全或运营工作流需要人工覆盖和移除错误封锁的路径。
Google Cloud 可以提供许多底层控制，但无法定义客户的业务逆操作。平台允许客户构建重试机制；它无法知道重试该操作是否安全。平台可以记录请求；它无法保证下游系统达到了预期状态，除非工作流校验了目标端。负担转移到设计上。
客户案例展示了采用情况，而非通用答案
Google Cloud 的客户案例是有用的市场信号，因为它们显示了买家正在尝试的工作流类型。但不应将其读作独立基准。
FletcherTech报告称，在三周内将 Gemini Enterprise 部署到核心数据，为 222 名员工在三个月内提供了 31,778 个答案，并节省了 2,500 多小时。该故事提及数据连接器、Jira、ServiceNow、SharePoint、自定义 AI 助手，以及一个用于资源、访问和成本治理的专用 Google Cloud 项目。这接近被接受输出的主题：价值不仅在于助手本身，更在于集成到日常系统和控制中。
Fifth Dimension报告称，使用 Vertex AI 集中管理 Gemini 和 Claude 推理，用于文档密集型的商业房地产工作流，技术栈包含 Cloud SQL、Cloud Storage、Cloud Run 和 BigQuery。故事描述了长运行工作流，并报告了 99.9% 的可靠性目标。这是一个将 Google Cloud 用作多模型工作流平台而非仅 Gemini 环境的实用案例。
Replit报告称，使用 Vertex AI 上的 Claude、Gemini、Cloud Run、Compute Engine、Cloud SQL 和 BigQuery，提供 AI 辅助的软件创建和部署。故事提到 Replit 支持超过 3500 万开发者和通过 Cloud Run 运行的 10 万多个应用。再次，其教训在于架构：代理与部署、数据和基础设施相连接。
局限性同样重要。这些故事并未披露完整的异常率、错误接受输出、人工审核分钟数、回滚时间、迁移工作、失败请求、数据清理成本，或端点降级时发生的情况。它们并非无用，因为带有推广性质；若作为采用证据阅读便是有用的。它们表明客户正在将真实工作负载移至 Google Cloud AI 表面，但并不能证明每个企业在计入监督和集成成本后都能省钱。
商业案例取决于减少总工作量
当任务是重复性的、富含证据、权限受限且足够昂贵，使得更好的工具能击败人工劳动时，Google Cloud 的商业案例最强。良好候选包括基于批准来源的内部知识问答、带测试和审查的代码初稿、文档密集的数据提取、支持工单分类、安全信息充实、受治理的分析，以及可被检查后再改变外部世界的工作流路由。
当任务稀有、模糊、高责任、文档匮乏、分散在各难以访问的系统或依赖隐性人工判断时，案例则减弱。这种情况下，模型可能仍有助于起草或研究，但被接受的工作流可能仍以人工为主。减少自动化可以是理性的。一家公司并不需要为一个每月仅发生两次且出错后果严重的任务配备自主代理。
替代方案范围很广。人工工作对平台依赖低，但劳动成本高且证据不一致。现有 SaaS AI 可能拥有更优的领域集成，但跨系统治理或模型选择较弱。其他云/模型提供商可能提供更好的模型性能或生态系统匹配，但需要不同的数据和身份集成。开源可能减少供应商锁定并提升控制力，但增加托管、安全、评估和运营工作。自建堆栈可定制，但需要稀缺的平台工程资源。Google Cloud 的卖点是，其集成了 AI、数据、身份、部署和日志的表面降低了中间路径的成本。
应当从一开始就计入转换成本。如果客户围绕 Google Cloud 构建了数据存储、评估套件、IAM 角色、Cloud Run 服务、Workflows、BigQuery 沿袭、审计路由、仪表板和支持流程，它将获得一致性但失去可移植性。对手模型或许可通过 Vertex AI 或单独提供商调用，但被接受的输出系统不仅仅是模型。它包括日志、权限、评估器、数据契约和部署模式。
这并非回避 Google Cloud 的理由，而是设计退出通道的理由。将评估数据集存储为便携格式。尽可能将业务规则保留在自由格式指令之外。将模型适配器与工作流逻辑分离。跟踪源文档和输出模式。使审计记录可在单一控制台之外读取。最佳客户结果不是零锁定，而是足够的模块化，使 Google Cloud 能通过减少工作来赢得工作负载，而非通过困住流程。
严肃买家应问的问题
购买问题应写为操作测试。对于一项重复任务，什么是被接受的输出，谁接受它，需要什么证据，可以使用哪些数据，可以采取什么行动，以及当它出错时会发生什么？在决定平台前应先完成此陈述。
针对 Google Cloud 的具体情况，买家应询问工作流是否需要 Gemini Enterprise 的面向员工的助手体验、Agent Platform 的构建与治理表面、Agent Search 根基化、BigQuery 治理、Cloud Run 部署、Workflows 编排，或者全部。没有任务定义就购买所有组件会创建平台项目，而非可靠的工作流。购买太少则会产生一个无法治理的模型演示。
买家还应问，哪些数据访问日志将被启用，谁可以查看，保存在哪里，以及何种审核流程将日志转化为监督。应决定哪些操作需要人工审批，哪些可以自动运行，哪些永远不应委派。在第一个模型版本变更前指定模型迁移计划。在试点成功变为繁忙产品之前，定义配额和吞吐量规则。为端点错误和过期检索编写降级策略。测试指令注入和不安全输出处理，因为对将模型输出传入工具的系统来说，OWASP 的 LLM 风险清单并非理论问题。
最后，买家应保持人工分母清晰可见。每周预期产生多少被接受的输出？多少被拒绝？审核需要多长时间？代理请求澄清的频率如何？多少输出在接受后需要修正？数据所有者更新语料库的频率如何？模型迁移和日志记录消耗了多少工程小时？如果不收集这些数字，组织将衡量兴奋度而非生产力。
Google Cloud 为企业提供了用于治理化 AI 工作流的严肃控制界面。它拥有模型、数据资产、身份机制、部署层、日志、评估服务和商业规模。尚未解决的测试是，客户能否利用这些部分在计入监督后减少总工作量。赢家不是在演示中回答最快的平台，而是在经过上百次日常运行后，其被接受的输出依然有用、可解释、权限正确且可恢复的平台。