OpenAI on Google Cloud: Private Preview Is Not Zero Data Retention

OpenAI models are entering Google Cloud’s Model Garden in private preview, with purchasing through Google Cloud Marketplace and drawdown against cloud commitments. That changes the procurement route—not every data-control requirement. Google explicitly describes Zero Data Retention and Confidential Compute as coming soon. For an enterprise workload that requires either control, the current announcement is a reason to investigate, not permission to migrate.

What changed, and what is available

OpenAI’s announcement, dated 21 October 2026, describes an integration bringing frontier models and Codex workflows to Google Cloud. It says general availability is planned in the coming weeks. Google Cloud’s announcement specifies private preview for selected enterprise customers and names GPT-6 Astra, GPT-6.1 Sol and GPT-6 Luna. Its live page and publication metadata showed 21 October when checked on 23 October; an extracted version showed 22 October. This review uses the earlier date rather than presenting the story as newer than verified.

The useful distinction is between an announced distribution agreement and an enabled service in your project. Google says eligible customers can use its APIs and connect local Codex CLI and Desktop workflows to its platform for inference. Access is requested through an interest form. Neither announcement establishes unrestricted availability for every customer, model or region. OpenAI models in Google Antigravity and Google’s business product remain described as forthcoming.

This article is a source-based engineering review, not a hands-on test of the private preview. Descriptions of model quality, cost efficiency and security are vendor claims. No workload benchmark or contractual assessment was performed here.

What cloud purchasing changes—and what it does not

Both organizations describe purchases through Google Cloud Marketplace that can draw down Google Cloud commitments. Google additionally says usage counts toward Flexible Savings Plans across model providers. This can be useful when an enterprise already has committed cloud spend: procurement can evaluate a new inference route without assuming a separate payment channel is necessary.

It does not establish a lower effective price. The reviewed announcements do not provide a model-by-model token price schedule, a German-region availability matrix, preview quotas or an SLA. Obtain the actual offer and verify which charges qualify for your agreement. Compare model usage, retries, network charges, logging, evaluation and operating effort. Do not substitute a direct OpenAI API price for an unverified Google Cloud offer.

A commitment drawdown is also not a software license for self-hosting model weights. The announcement describes a hosted access path. Your release decision still needs the exact service terms, enabled capabilities and operational responsibilities. Use the existing AI supplier control-plane pattern to record the approved model, endpoint, region and configuration rather than granting approval to a provider name.

The retention distinction that matters

Google states that prompts, context and outputs remain within the designated data perimeter and are not used to train foundation models. It separately says Zero Data Retention options are coming soon. Those statements answer different questions. “Not used for training” describes a permitted use; it does not specify that no request content is stored. Likewise, infrastructure isolation does not establish the retention behavior of application traces, client logs or connected tools.

Google also states that models run on dedicated Google Cloud infrastructure, while Confidential Compute is coming soon. Do not record the forthcoming feature as enabled. Its announcement describes authenticated identities, VPC Service Controls and unified audit logging; buyers should verify the exact preview configuration and supported paths rather than treat a launch-page statement as a completed control test.

The sources reviewed do not establish a specific German or EU serving-region guarantee for this preview. A designated perimeter and an EU-only processing requirement are not interchangeable specifications. Request the actual regional endpoint, failover behavior, support access arrangements, retention periods and deletion process. Have your privacy and legal teams review contractual and transfer questions. This is engineering guidance, not legal advice.

This is distinct from the earlier OpenAI Agents API self-hosting boundary. That article concerns the separation between a managed agent harness and its execution environment. This announcement concerns a new inference hosting and purchasing route. Do not transfer either product’s residency or retention properties to the other merely because both can be used with agent workflows.

A practical migration decision

Consider a German engineering team that wants to use Codex on an internal maintenance application. This is an illustrative scenario, not a deployment report. Moving inference billing into its existing cloud account may simplify purchasing. It does not establish what repository content leaves a workstation, which tools can read production credentials, or whether local logs preserve sensitive inputs.

Separate the review into three boundaries: model inference, the Codex client and its tools, and the organization’s own telemetry. Draw the actual data path for each. Approve only the combination you tested. A local client connected to a cloud model is still a networked workflow; its tool permissions need their own restrictions.

Test the endpoint, not just the model name

Start with synthetic or otherwise approved non-sensitive inputs. Record the exact model identifier, endpoint, region evidence, client version and configuration. Run the same evaluation cases against the current approved deployment and the proposed preview. Check German-language task accuracy, structured-output handling, tool behavior, latency under representative load, quota failures and actual usage charges. No universal pass threshold follows from this announcement; agree workload-specific acceptance criteria before testing.

Then exercise negative cases. Deny the intended identity and confirm the request fails. Attempt a disallowed network path in a controlled test and inspect the resulting audit evidence. Check whether application instrumentation captures prompts despite an infrastructure-level policy. Where a control cannot be demonstrated, record it as unverified—not as passed because the normal request succeeded.

For an outage, use only a separately approved fallback. A router that silently sends failed preview requests to another provider can invalidate the boundary you just reviewed. The production model-routing decision plane explains how to reject an ineligible fallback rather than trade away a hard requirement for availability.

The next procurement artifact

Before approving a pilot, create a short evidence record containing the enabled model and endpoint, access status, permitted data classes, regional and retention evidence, price offer, quota behavior, test results and an accountable owner. Keep “announced,” “contracted,” “configured” and “tested” as separate states. Revisit the record when ZDR, Confidential Compute or general availability is actually documented for the service you intend to use.

If your team needs a concrete migration decision, AI implementation consulting can scope the data-path review and acceptance tests around one workload. The immediate deliverable should be an auditable go/no-go decision—not a blanket declaration that a familiar cloud account makes every model workflow production-ready.