Every route to an AI model is now a supplier. Map your model supply chain before a policy change does it
In one week, OpenAI's models reached a new cloud, OpenAI put AI gateways under its approval and ServiceNow moved agent revocation toward the network card. Reaching a model is now a chain.
Listen to this article · 5 min
AI-generated narration of the full article.

Ask an enterprise architect where the company’s AI models come from and the answer is usually a list of names: OpenAI, Anthropic, Google, a couple of open-weight models. Ask how each request actually reaches a model, and the answer gets longer. The model was built by one company, is hosted by another, bought through a third’s marketplace, routed by a fourth’s gateway, and wrapped by a fifth’s agent runtime before your application ever sees it.
Each of those parties now has its own rules, and this week three of them changed theirs.
- OpenAI’s models are arriving on Google Cloud, purchasable through its marketplace against existing commitments, with some data controls still “coming soon.”
- OpenAI said that from November 20, services offering direct access to its models, such as routers and AI gateways, need its approval.
- ServiceNow put a personal agent into general availability and announced that revoking an agent’s permissions will be enforced in the runtime and, later, in the network card.
Read together, they describe something enterprises have not managed as such: a model supply chain.
The chain, layer by layer
The parties between your application and a model
Your application or agent
- Prompts, skills, memory
You
Your control layer
- Identity, budgets, logging, routing policy
You, if you built one
Gateway or router
- Third-party or internal
May now need the model maker's approval
Marketplace and billing
- Cloud commitments, reseller terms
Hosting cloud and runtime
- Region, data retention, confidential computing
Model maker
- Usage policies, model versions, retirement dates
Every layer can change what you get. The model maker retires a version or tightens a policy. The cloud ships a control later than the direct API. The marketplace changes how commitments count. The gateway loses approval. The runtime adds an enforcement point, or lacks one.
Why “supplier” is the right word
Regulated industries already know how to manage a chain like this; they just have not applied it to models. US banking agencies’ 2023 interagency guidance on third-party relationships expects banks to manage risk across the lifecycle of a relationship, including the subcontractors behind a provider. Europe’s Digital Operational Resilience Act has applied similar expectations to financial entities’ ICT providers since January 2025. A gateway that can stop serving a model on the date a policy takes effect is precisely the kind of dependency those frameworks were written for.
Most companies manage the model maker as a vendor and treat everything else as plumbing. This week showed that the plumbing has its own rules. When OpenAI asks gateways for approval, a router your team chose for convenience becomes a supplier with a material dependency on another supplier’s decision.
Five questions per route
For each production workload, record the route, not just the model, and answer five questions:
- Who can cut it off? List every party whose decision could stop this workload: model maker, cloud, marketplace, gateway. For each, what notice do you get?
- Whose data terms apply? The direct API, the cloud path and a router may have different retention and processing terms for the same model. Name the one that governs this workload.
- Where does the request run? Region and hosting matter for data residency, and they can differ by path, as they did for the same Claude model on Azure and AWS.
- What is the fallback? Another path to the same model, or another model that passed the same evaluation. A fallback that was never tested is a hope.
- Where is the evidence? Which log shows which route served which request, with model and version. Without it, an incident review cannot reconstruct what happened.
What you should own in the chain
The pattern of the last year, which we described in our model portfolio framework, is that companies should own the layers that let them change suppliers: evaluation sets, routing policy and the record of what ran where. The supply chain view adds one more: the control layer itself. Databricks built its own gateway because it could not manage cost without seeing every request. The same layer is where you see dependencies, enforce fallbacks and keep evidence.
Interface standards help. The Agentic AI Foundation’s new Open Responses specification, for example, aims to make the call to a model look the same across providers. A common interface makes switching routes cheaper. It does not tell you which routes you depend on. Only a map does.
Our expectation, and it is a view rather than a fact, is that by next year model routes will appear in third-party risk inventories next to cloud providers, with the same questions about concentration, exit and notice. Companies that draw the map now will find that conversation short.