Rethinking Multicloud for AI

By: Adriana Estivill

Why enterprise AI architecture needs a stable core across cloud boundaries

In 1960, a group of young Japanese architects introduced a radical idea at the World Design Conference in Tokyo. Buildings and cities, they argued, should not be designed as finished and permanent objects. Instead, they envisioned structures that behaved more like living organisms.

The movement became known as Metabolism.

Its architects imagined cities composed of permanent structural cores and adaptable modules that could be added, removed, or replaced as technology, population, and social needs changed. Rather than resisting change, architecture would incorporate it into its very structure. [1]

More than sixty years later, this idea offers an unexpectedly useful way to think about enterprise AI architecture.

An AI system is not a finished structure. Models will change. Data will change. Retrieval strategies will change. Evaluation criteria will evolve. AI agents and tools will be added or removed. Policies will be revised. Feedback from production will expose weaknesses that were invisible during development.

Architecture must therefore support continuous adaptation without compromising governance, operational integrity, or trust.

For most enterprise AI products, that objective is not best served by a multicloud-by-default design. It is better supported by a coherent primary execution environment, with cross-cloud dependencies introduced selectively when they deliver a distinct business, regulatory, technical, or resilience advantage.

From programmed behavior to adaptive systems

For much of the cloud era, enterprise architecture followed a relatively deterministic logic.

Applications were decomposed into clearly defined functions. Infrastructure components had explicit responsibilities. APIs established predictable contracts. Infrastructure as code made environments repeatable. Microservices separated concerns. CI/CD pipelines moved versioned software through controlled stages.

Conventional software could be extremely complex, particularly when distributed across infrastructure and business systems. But it was generally designed around explicitly programmed behavior and predictable contracts. Its intended responses were encoded by developers.

AI does not eliminate this architecture. APIs, networks, databases, containers, identity systems, observability, and deployment automation remain essential.

However, AI introduces a different class of subsystem.

In an enterprise AI application, part of the decision-making process is delegated to a statistical model whose possible behavior cannot be fully specified in advance.

A request may pass through every technical component successfully and still produce an inaccurate, unsupported, or inappropriate result. The model may interpret equivalent inputs differently, combine retrieved information in unexpected ways, or select an action that is technically permitted but contextually incorrect. These outcomes may not generate an error because the infrastructure and application can function exactly as designed.

This challenge becomes even more pronounced in generative AI systems that rely on Retrieval-Augmented Generation (RAG). Here, model behavior depends not only on the model itself but also on retrieved enterprise knowledge, prompts, orchestration logic, evaluation criteria, and the quality of contextual information supplied during inference.

The reliability of the system therefore depends not on the model alone, but on how the model interacts with retrieved context, prompts, AI agents, tools, policies, evaluation mechanisms, and human oversight. Each component helps constrain, verify, or compensate for behavior that cannot be fully predetermined.

AI must therefore be organized as a compound system rather than as a model attached to an application. [2]

Architects increasingly separate the development and learning plane from the runtime decision plane. The first moves data and models through ingestion, grounding or training, evaluation, and deployment. The second carries a live request through identity, retrieval, inference, tool use, guardrails, response, and feedback.

These planes evolve at different speeds. Development may tolerate batch processing and experimentation. Runtime requires low-latency, reliable controls, and clear accountability. Identity, privacy, policy, evaluation, observability, audit, and cost management must operate across both. [3]

Enterprise AI architecture should therefore be designed not as a static collection of infrastructure components, but as a governed system of continuous adaptation.

This is the connection to Metabolism.

AI changes the requirements of multicloud architecture

Enterprises continue to have valid reasons to use several clouds. These include geographic reach, regulatory requirements, specialized AI models or accelerators, sovereign environments, acquired platforms, independent recovery paths, and the flexibility to adopt emerging AI services.

At the portfolio level, multicloud is already a practical reality.

AI, however, expands the unit of architecture. One product may span infrastructure, data, identity, models, SaaS applications, APIs, and business processes. It may run primarily in one environment, retrieve enterprise data from another, use a specialized model elsewhere, and retain sensitive processing within sovereign infrastructure.

Each decision may be rational on its own.

The risk emerges when those decisions evolve into an accidental cross-cloud system that was never designed to operate as a cohesive whole.

Consider an employee service agent. The application and orchestration layer run in one cloud. It retrieves policies and employee records from another environment while invoking a SaaS business system to initiate a transaction.

The AI agent may produce the correct answer and still fail as an enterprise system. It may retrieve an outdated document, lose the employee's original permissions when invoking the business system, or act through a service identity with broader authority than the person making the request.

Its logs may show that every component functioned correctly while providing no complete record explaining why the final decision was made.

The question is not whether multiple clouds participate. It is whether the complete AI product remains coherent as its models, data, AI agents, tools, and governance policies continue to evolve.

Context, control, and evidence

The risks of an uncoordinated multicloud AI system can be understood through three fractures.

Fragmented context

AI requires more than raw data. It depends on data enriched with business definitions, metadata, lineage, permissions, document versions, conversation history, and governance policies.

In a multicloud architecture, these elements may be distributed across source platforms, vector indexes, model environments, and knowledge repositories. Moving data can introduce latency, egress charges, duplication, sovereignty concerns, and inconsistent permissions. Leaving data in place requires secure cross-cloud access and identity federation.

A system may retrieve the correct information while losing its meaning, freshness, or authorization context.

Fragmented control

Enterprise AI systems must consistently preserve who the user is, what information that person may access, which AI agents and tools can be invoked, which actions require approval, where information may be processed, and which governance policies apply throughout the transaction.

When these decisions span identity providers, cloud IAM platforms, SaaS applications, API gateways, and business systems, inconsistencies emerge.

A service identity may possess broader permissions than the human user. An AI agent may invoke an API without carrying the user's original authorization context. A policy may be enforced at one layer but not at another.

Effective enterprise AI governance depends on maintaining these controls consistently across every environment participating in the application.

Fragmented evidence

Organizations must be able to reconstruct which model and prompts were used, what information was retrieved, which AI agents or tools were invoked, what permissions were applied, what the transaction cost, whether evaluation thresholds were met, who approved the result, and what changed between versions.

Separate logs, traces, lineage systems, evaluation frameworks, cost reports, and security events may make every individual component observable while leaving the end-to-end decision path impossible to explain.

Without that evidence, the system cannot be reliably evaluated, governed, or improved. 

These fractures also impose an economic and architectural tax. Cross-cloud movement can add egress and connectivity costs, duplicate data and tooling, increase latency and failure modes, create additional encryption boundaries and blur support ownership. 

A design can be technically functional but operationally and economically irrational. 

The problem is not multicloud itself. It is multicloud without a mechanism for preserving context, control, and evidence across its boundaries.[2][4] 

A more deliberate multicloud pattern

A more deliberate pattern is emerging.

Organizations should design their enterprise cloud portfolio to take advantage of the strengths of multiple cloud providers while giving each AI product a coherent primary execution environment where identity, orchestration, state management, policy enforcement, evaluation, observability, cost attribution, and operational accountability converge.

This does not require every component to reside within a single cloud provider. Specialized AI models, sovereign processing environments, enterprise data platforms, or industry-specific services may remain elsewhere. However, every external dependency should have clearly defined boundaries, explicit ownership, consistent governance, and end-to-end telemetry.

Cross-cloud dependencies should be introduced selectively when they provide a distinct capability, satisfy a regulatory or business constraint, or create enough value to justify the additional complexity. Appropriate reasons include jurisdictional requirements, specialized AI capabilities, acquired platforms, or independently managed disaster recovery environments.

They should not be introduced simply to demonstrate provider neutrality or architectural sophistication.

This pattern enables organizations to adopt new generative AI models, AI agents, or specialized cloud services without compromising governance, observability, or operational accountability.

Duplicating compute resources across multiple clouds does not automatically create AI resilience when both environments ultimately depend on the same identity provider, enterprise data source, model endpoint, or operations team.

Likewise, disaster recovery should not be considered successful merely because the application remains available.

A recovery environment must preserve not only infrastructure, but also model behavior, Retrieval-Augmented Generation (RAG) indexes, authorization context, AI agent permissions, governance policies, prompts, and evaluation standards required for the system to remain trustworthy.

Enterprise AI resilience should therefore be validated for both service continuity and behavioral integrity across the complete dependency graph. [4][5][6][8]

When modularity is not enough

A stable core does not mean preserving a particular model, database, or cloud provider.

It means preserving the controls, evidence, governance, and operational integrity that allow the system to evolve safely.

Around that stable core, models, prompts, vector indexes, retrieval strategies, AI agents, tools, and infrastructure may continuously evolve.

However, technical modularity does not necessarily create operational replaceability.

An API may separate two components while their prompts, permissions, evaluation criteria, and runtime behavior remain tightly coupled.

Replacing one foundation model may alter retrieval quality, AI agent behavior, downstream tool invocation, or response consistency.

Moving enterprise data may affect latency, cost, data residency obligations, or governance requirements.

Adding a new AI agent or tool may introduce actions that existing policies were never designed to authorize or monitor.

A component is truly replaceable only when an organization can modify it, evaluate the consequences, preserve controls, and evidence and roll back safely when necessary.

Code, models, prompts, data, vector indexes, policies, AI agents, and evaluation datasets should therefore be managed as a unified lifecycle rather than as independent assets.

Enterprise AI architecture must clearly define what remains stable, what is allowed to change, and how confidence is restored after every change. [3][7]

The lesson of the Nakagin Capsule Tower

Perhaps the best-known expression of Metabolism was Kishō Kurokawa's Nakagin Capsule Tower, completed in Tokyo in 1972.

The building consisted of two permanent structural cores supporting 140 prefabricated residential capsules that were intended to be periodically removed and replaced as technology and living requirements evolved.

In theory, the building could continually renew itself while preserving its essential structure.

In practice, none of the original capsules were ever replaced.

Technical limitations complicated removal. Shared utilities created hidden dependencies. Maintenance costs continued to rise. Ownership became fragmented. Collective decision-making proved difficult.

Ultimately, the tower was dismantled in 2022. [9]

Nakagin's capsules were replaceable in theory, but the larger system surrounding them could not sustain renewal.

Enterprise AI architecture faces the same challenge.

The question is not whether individual models, AI agents, cloud services, or infrastructure components can be replaced.

The question is whether the complete enterprise AI system can evolve across cloud boundaries while preserving context, control, governance, evidence, and operational integrity.

That distinction determines whether an architecture remains adaptable over time—or merely appears modular on paper.

Conclusion

For years, multicloud strategies were evaluated primarily through the lenses of cost optimization, vendor diversification, resilience, and infrastructure flexibility.

Enterprise AI expands those requirements.

Modern AI systems are no longer collections of independent infrastructure services. They are adaptive ecosystems that continuously combine models, enterprise knowledge, AI agents, Retrieval-Augmented Generation (RAG), identity, governance, business applications, and human oversight into a single operational capability.

As these systems become more autonomous, architecture must preserve far more than application availability.

It must preserve trust.

Organizations should continue leveraging multiple cloud providers where those providers create measurable business value.

However, each enterprise AI product should maintain a stable execution core that preserves identity, governance, observability, evaluation, operational accountability, and behavioral consistency while allowing models, tools, and cloud services to evolve around it.

Just as the Metabolists envisioned permanent structural cores supporting adaptable modules, enterprise AI architecture should establish stable operational foundations that allow innovation to occur without sacrificing control.

The future of enterprise AI will not belong to organizations that simply operate across multiple clouds.

It will belong to those that can continuously adapt across those environments while preserving context, control, evidence, and trust.

‍Sources

1. Wallpaper — Japanese Metabolism architecture
   Supports the opening discussion of the Metabolism movement and its concept of permanent structural cores with adaptable components.
2. Berkeley Artificial Intelligence Research (BAIR) — “The Shift from Models to Compound AI Systems”
   Strong support for the article's argument that enterprise AI should be viewed as a compound system rather than simply a model attached to an application. (bair.berkeley.edu)
   Read the BAIR article
3. Microsoft Azure Well-Architected Framework — AI Workload Documentation
   Supports the discussion of AI's nondeterministic behavior and the architectural, operational, evaluation, and governance considerations required for AI workloads. (learn.microsoft.com)
   Microsoft AI Workload Documentation
4. Google Cloud Architecture Center — Hybrid and Multicloud Architecture Patterns
   Supports the article's discussion of deliberate multicloud design, distributed workloads, architectural dependencies, and appropriate multicloud patterns. (Google Cloud Documentation)
   Google Cloud Hybrid and Multicloud Architecture Patterns
5. Google Cloud Architecture Center — Deployment and multicloud strategy guidance
   Supports the principle that cloud architecture should begin with specific business requirements and technical objectives rather than multicloud being an objective in itself. (Google Cloud Documentation)
   Google Cloud Multicloud Strategy Guidance
6. Microsoft Azure Well-Architected Framework — Reliability and failure-mode guidance
   Supports the article's emphasis on resilience, operational integrity, testing, and understanding dependencies.
7. Google Cloud Architecture Center — “MLOps: Continuous Delivery and Automation Pipelines in Machine Learning”
   Supports the article's lifecycle argument around continuous integration, delivery, training, and management of changing ML components. (Google Cloud Documentation)
   Google Cloud MLOps Guidance
8. AWS Well-Architected Framework — Disaster Recovery Testing
   Supports the point that resilience requires tested recovery paths rather than simply duplicating infrastructure. (AWS Documentation)
   AWS Disaster Recovery Guidance
9. The Guardian — “Legacy of Japan’s Nakagin Capsule Tower Lives on in Restored Pods”
   Supports the article's Nakagin example, including its 140 modular capsules, eventual dismantling, and the practical difficulty of realizing the building's original replaceability concept. (theguardian.com)
   Read The Guardian article

FAQ

What is enterprise AI architecture?

Enterprise AI architecture is the framework that integrates AI models, enterprise data, identity, governance, applications, infrastructure, and operational processes into a controlled system that can securely deploy, manage, and continuously improve AI capabilities.

Should every AI system use multiple cloud providers?

No. Many enterprise AI applications perform best when they operate within a primary execution environment while leveraging additional cloud services only when they provide clear business, regulatory, resilience, or technical advantages.

What is Retrieval-Augmented Generation (RAG)?

Retrieval-Augmented Generation (RAG) is an AI architecture pattern that retrieves trusted enterprise information during inference, enabling generative AI models to produce responses that are more accurate, current, and contextually relevant.

Why is governance important in enterprise AI?

Enterprise AI governance ensures models, AI agents, data, prompts, permissions, policies, and business actions remain secure, explainable, compliant, and auditable throughout the AI lifecycle.

What is a primary execution environment?

A primary execution environment is the cloud platform where an AI application's identity, orchestration, governance, observability, evaluation, policy enforcement, and operational accountability are centrally managed.

How do AI agents change multicloud architecture?

AI agents increase the importance of preserving identity, authorization, governance, and observability across cloud boundaries because they can invoke tools, access enterprise systems, and perform actions on behalf of users.