OpenAI models are coming to Google Cloud. Model choice needs an exit test

THE SIGNAL IN ONE SENTENCE

OpenAI models are moving into Google Cloud. That gives enterprise buyers another place to buy them and one less excuse to build a second billing relationship. It does not automatically give those buyers an exit. On October 21, OpenAI and Google Cloud announced that OpenAI frontier models and Codex agentic workflows are coming to Google Cloud's Model Garden. Customers will be able to purchase access through Google Cloud Marketplace and apply existing Google Cloud spending commitments to the bill. OpenAI says general availability is planned in the coming weeks. Google Cloud is more specific about the first step: GPT-Astra, GPT-6.1 Sol and GPT-6 Luna are rolling out in private preview to selected enterprise customers, with additional availability to follow. The two announcements also describe integrations planned for Google Antigravity and the Gemini agent. OpenAI says Microsoft remains its primary cloud partner. This is a meaningful distribution change. A company that already manages identities, budgets, data controls and workloads in Google Cloud may be able to add OpenAI models without stitching together a separate procurement and governance island. Google says prompts, context and outputs will stay within a customer's designated data perimeter and will not be used to train foundation models. It also says Zero Data Retention options and Confidential Compute are coming soon. The timing words matter. Coming soon is not the same thing as available in the environment a customer is evaluating today. Google also says interactions will use authenticated identities, unified audit logging and VPC Service Controls. Those controls can make a multi-model platform easier to govern. They do not prove that two models behave the same way, produce equivalent records or can replace each other inside a working agent. This is where the model-choice story gets slippery. A marketplace can offer hundreds of models and still create lock-in one layer above them. The customer may avoid dependence on a single model vendor while becoming deeply dependent on the cloud platform's identity system, gateway, logging format, evaluation tools, agent runtime and billing structure. That trade can be perfectly reasonable. Centralization may reduce security work and speed up deployment. But it should be named honestly. A larger menu is procurement choice. Portability is the ability to leave with the meal. The useful test is not whether an administrator can select another model from a console. It is whether a real workflow can move without losing its memory, tools, policies, evidence and emergency controls. Start with a representative workload, not a toy prompt. Pick an agent that reads documents, calls two or three approved tools, writes a proposed action and waits for human approval. Give it a known evaluation set with routine cases, edge cases, malicious inputs and tasks that should be refused. Run that workload through the OpenAI model on Google Cloud. Save the configuration that matters: model and version, system instructions, tool schemas, retrieval settings, identity, region, retention mode, safety controls, retry rules, timeouts and spending limits. Then move the same workload to another supported model. Do not quietly rewrite the evaluation until the replacement passes. Record every change required to make the handoff work. A model may need different prompt wording, tool descriptions, temperature settings or output validation. Those changes are part of the switching cost. Compare more than answer quality. Measure task success, latency, cost, refusal behavior, tool-call accuracy, citation quality and the number of human interventions. Check whether both routes produce logs that investigators can search. Confirm that an administrator can identify which person, agent and model touched a sensitive record. Now test failure. Revoke a tool permission. Feed the agent a malformed response. Exhaust its budget. Simulate a provider outage. Trigger a policy violation. Make sure the workflow stops safely and leaves a useful record instead of wandering into retries until the invoice catches fire. The final step is the actual exit. Export the prompts, tool contracts, evaluation cases, policy decisions, approval history and operational logs needed to reconstruct the workflow elsewhere. Confirm which artifacts belong to the customer, which can be downloaded, which are tied to a proprietary service and which will be deleted after termination. Time the move. Count the engineers involved. Record the features lost. Price the overlap period when two providers must run together. A credible portability claim needs that receipt. This matters most for regulated work. Centralized identity and data governance can make it easier to enforce who is allowed to use a model. But regulated teams also need to know where a request was processed, how long records remain, which subcontractors are involved, what happens during legal discovery and whether the promised privacy option is available in the selected model, region and contract. The announcement does not yet publish a complete matrix of prices, regions, quotas, model features or contractual terms. It does not report independent portability tests. Those are not reasons to dismiss the integration. They are the questions a preview should answer before it becomes a production dependency. There is also a broader competitive question. Google describes itself as the only hyperscale cloud provider offering access to all three leading closed-source language model families alongside more than 200 first-party, third-party and open models. That is a company claim, and categories such as leading and closed source deserve scrutiny. Still, the direction is clear: cloud platforms want to become the control surface above the model layer. For customers, that could be useful. One platform can simplify invoices, access controls, observability and model comparison. It can also decide which models are available, how requests are routed, what metadata is retained and how easily a workload can leave. The best response is not to demand a perfectly neutral cloud. It is to make the switching boundary visible. Procurement teams should require a model exit test before approving a long contract. Security teams should review the identity and audit trail for each route. Developers should keep tool schemas and evaluations in portable formats. Finance teams should measure total workflow cost rather than token price alone. Legal teams should distinguish protections available today from protections listed as coming soon. And executives should resist the comforting sentence that the company is now multi-model. Multi-model is an inventory fact. Portability is an operational capability. Google Cloud is adding an important model family to its shelf. The shelf is not the strategy. The strategy is proving that a working system can change models, survive the handoff and leave when the terms no longer fit.