Article reader Listen + reading controls
Article reader
Preparing the reader…
Reading settings
An AI Buyer Must Map the Cloud Behind the Model¶
The FTC’s inquiry into partnerships between AI developers and major cloud providers was a competition investigation. It also surfaced a practical enterprise-architecture problem.
Organizations often select a model as though it were a separable service. In reality, the decision can commit them to a chain of cloud infrastructure, identity, data platforms, safety controls, networking, application tooling, commercial terms, and strategic relationships. The model endpoint is the visible interface to a larger dependency system.
For public-sector and regulated buyers, architecture diligence should begin by mapping the cloud behind the model.
The FTC’s January 2024 orders sought details about cloud–developer partnerships, including technical and input dependencies, product decisions, governance rights, and competitive consequences. Its later staff report provides later evidence about structures that buyers should consider in their own risk analysis.
The Supplier Is a Graph, Not a Name¶
A model service can depend on:
- a developer and its subcontractors;
- one or more cloud regions;
- accelerator supply and capacity allocation;
- identity, content-filtering, and monitoring services;
- external data and retrieval sources;
- model-routing or orchestration providers;
- software libraries and open-source components;
- and a strategic cloud partner with governance or commercial rights.
The buyer should identify which party controls each dependency and which failures can interrupt the service or change its behavior.
A contract with the model developer may not create recourse against a critical cloud change. A multi-model application may still route every request through one cloud or identity provider. Supplier diversity at the first tier can mask concentration below it.
Portability Has Several Layers¶
“We can switch models” is credible only if the organization can move the surrounding system.
Portability includes:
- prompt and policy portability: system instructions, guardrails, and business rules are not trapped in provider-specific formats;
- knowledge portability: embeddings, indexes, metadata, and access policies can be recreated or exported;
- tool portability: agent actions and integrations use stable contracts rather than proprietary function APIs;
- evaluation portability: the same test suite can compare candidate models;
- observability portability: traces, feedback, and incident evidence remain usable;
- data portability: interaction and tuning data can move lawfully and practically;
- infrastructure portability: latency, security, accreditation, and cost remain acceptable elsewhere.
An abstraction layer can help but can also conceal important provider differences. The organization should preserve a common contract while documenting model-specific capabilities and limitations.
Model Substitution Should Be Exercised¶
Continuity plans often assert that an alternative model exists. Teams should test substitution regularly.
A substitution exercise can measure:
- time to deploy the alternate;
- functional regressions;
- prompt and retrieval changes;
- differences in safety and refusal behavior;
- performance across the organization’s evaluation set;
- latency and cost;
- security and data-flow changes;
- and user impact.
The exercise may reveal that the application is overfit to one model’s behavior or that a provider-specific feature has become mission critical.
This is not an argument for lowest-common-denominator design. Some applications should exploit differentiated capability. Leaders should know where that differentiation creates intentional dependency and price it accordingly.
Correlated Risk Belongs in the Architecture Review¶
If several business units use different AI applications backed by the same cloud–model partnership, an outage, vulnerability, policy change, or capacity constraint can affect them together.
Portfolio governance should aggregate dependencies across products:
- total workloads by cloud, model family, identity provider, and region;
- shared data and orchestration services;
- concentration of technical skills and support contracts;
- correlated security or model failures;
- and contractual termination or pricing events.
The organization can then decide where concentration is efficient and where redundancy is justified.
Redundancy is not free. Running multiple clouds or model stacks increases cost and complexity. The decision should be based on mission criticality, recovery time, data sensitivity, and credible failure modes rather than a generic multi-cloud doctrine.
Data Rights Determine Learning Rights¶
AI products improve through interaction data, feedback, evaluations, and incident evidence. Contracts should clarify:
- which party owns prompts, outputs, feedback, and traces;
- whether data can train provider models;
- how long it is retained;
- which subcontractors receive it;
- whether the buyer can export it in usable form;
- and whether the provider can use aggregated behavior to compete with the buyer or its suppliers.
Government-generated evaluation and operational data is particularly important. If it remains locked inside a provider dashboard, the agency loses the learning needed to compare suppliers and govern the next system.
The right to export evidence is as important as the right to export content.
Strategic Relationships Can Change Product Risk¶
A cloud provider’s investment in a model company may affect roadmap, availability, integration, and pricing. It may also affect the provider’s incentives during a dispute, incident, or capacity shortage.
Buyers should monitor changes in:
- ownership and governance rights;
- exclusivity or preferred-provider terms;
- revenue-sharing and pricing;
- model availability across clouds;
- product bundling and defaults;
- intellectual-property disputes;
- and regulatory or litigation constraints.
Third-party risk management should not freeze the supplier picture at contract award. Strategic dependencies evolve even when the API remains stable.
Public Procurement Can Preserve Options¶
An agency can require:
- disclosure of material subservice and infrastructure dependencies;
- model and service version identification;
- notification of material partnership or control changes;
- government ownership and export of configurations, evaluations, and operational evidence;
- stable interfaces at model, knowledge, tool, and telemetry layers;
- independent testing;
- substitution and continuity exercises;
- and transition assistance.
The agency should also avoid allowing cloud credits or bundled pricing to determine long-term architecture without accounting for switching cost. A low initial price can purchase future dependency.
The Strategic Inference¶
The cloud–AI partnerships examined by the FTC are not only an antitrust subject. They reveal how the modern AI supply chain is being assembled.
Enterprise buyers need to understand that choosing a model can choose an ecosystem. The relevant diligence covers technical portability, commercial rights, governance influence, correlated infrastructure risk, data and evidence ownership, and continuity under strategic change.
The objective is not dependency-free AI; complex systems always depend on suppliers. It is intentional, observable dependency with credible options.
An architecture is resilient when the organization knows which relationships it relies on—and can still act when one of them changes.
This essay was substantially revised in July 2026 to replace a second, duplicative inquiry summary with a distinct buyer-focused architecture and procurement analysis. It incorporates the FTC report issued after the original post.
For practical work on cloud, AI platform, and vendor strategy, visit Xendev Labs or my broader portfolio.
References¶
- Federal Trade Commission, “FTC Launches Inquiry into Generative AI Investments and Partnerships,” January 25, 2024.
- Federal Trade Commission, Partnerships Between Cloud Service Providers and AI Developers, staff report following the Section 6(b) study.
- Rebecca Heilweil, “Federal Trade Commission announces market inquiry between AI developers and cloud service providers,” FedScoop, January 25, 2024. This report was the historical prompt for the original post.