One AI marketplace is not one control plane.

Google Cloud put more AI models behind one familiar door last week. Anthropic-managed Claude is now generally available there, and OpenAI models are entering Model Garden.

Procurement gets simpler. Accountability does not.

The same cloud project can now present several routes to a model, each with its own processor, terms, controls and feature schedule. A consolidated invoice is useful. It is not evidence that the underlying arrangements are interchangeable.

What changed

On October 21, Google Cloud announced that OpenAI models were rolling out in private preview through Model Garden, with general availability planned for the coming weeks. Customers will be able to buy the models through Google Cloud Marketplace, apply eligible cloud commitments and use Google Cloud identity and audit controls.

Google says prompts, context and outputs for that offering remain inside the customer's designated data perimeter and are not used to train foundation models. It also says zero data retention and Confidential Compute are coming soon. Those last two words matter. A control on a roadmap is not a control available to approve today.

Two days later, Google added a second way to use Claude on its cloud. The new Anthropic-managed option and the existing Google-managed option have the same pricing, access to current models and Google Cloud billing. They do not have the same operating arrangement.

With the Anthropic-managed route, Anthropic is the data processor under its commercial terms. Customers still authenticate with Google Cloud IAM and retain Cloud Audit Logging, while receiving immediate access to Claude platform features such as managed agents, skills and code execution.

With the Google-managed route, Google is the data processor under the customer's Google Cloud agreements. That path includes VPC Service Controls, customer-managed encryption keys and data residency options in the United States, European Union and Asia-Pacific. New Claude platform features arrive after Google integrates them.

One catalog can hide several materially different trust decisions.

Anthropic's own data-retention documentation makes the distinction explicit. Its direct API arrangements do not govern Google-operated Claude. For that route, customers must use the cloud provider's retention and compliance controls instead.

Why this matters

Model marketplaces encourage a reasonable engineering habit: test several models and select the best one for each task. The danger is treating the deployment route as a purchasing detail after that choice has been made.

An AI request can contain customer records, internal documents, source code and instructions for tools that can act. The organization processing that request matters. So do the contract governing it, the region where it runs, the available retention setting, the logs your team can inspect and the network boundary around the endpoint.

Those facts can change while the model name and cloud invoice stay the same.

This is especially easy to miss when a proof of concept becomes production. A developer enables the fastest route to a new feature. The security review records "Claude on Google Cloud." Procurement sees an approved marketplace vendor. Finance sees an existing commitment. Nobody records whether Anthropic or Google is processing the data, or whether the required controls exist on that specific route.

The result is not necessarily an insecure deployment. It is an unmade decision presented as an approved one.

What we would decide before deployment

Name the route, not just the model. Record the provider, cloud service, endpoint, operating party and exact model identifier for every production workload. "OpenAI" or "Claude" is not enough to reproduce the arrangement.
Classify the work before comparing models. State what data enters the request, what data can be retrieved, which tools the system can call and what business consequence can follow. A public drafting assistant and an agent reading client files should not share an approval standard.
Build a route-level control matrix. For each option, document the data processor, governing terms, retention, training use, supported regions, encryption controls, network perimeter, identity model, audit logs and incident path. Mark controls that are in preview or announced as coming soon. Do not score them as present.
Verify the controls in your own tenant. Confirm the region, logging destination, service account, key configuration and network policy with a real request. Save the evidence with the architecture decision. A product page describes an offering; it does not prove your configuration.
Separate model quality from route approval. Evaluate capability, latency and cost across the models that meet the control requirements. A better benchmark result does not compensate for an unacceptable data-processing arrangement.
Pin the approved route in production. Restrict who can add models or change endpoints. Alert on calls to unapproved services. A shared marketplace makes switching easy, which means governance cannot depend on someone remembering why the first route was chosen.
Review every feature expansion. Managed agents, code execution and new tools change more than convenience. They can introduce new actions, data flows and logs. Reapprove the workload when the route gains a material capability or when a promised control becomes available.