The Great Cloud Rebalancing: Why AI Costs, Cybersecurity Risks, Data Sovereignty, and Infrastructure Economics Are Driving Enterprises Toward Private and Hybrid Clouds

For more than a decade, many organizations followed a cloud-first strategy. New applications were placed in public clouds, existing systems were migrated, and internal data centers were reduced or closed. Public cloud platforms delivered extraordinary benefits, including rapid deployment, elastic capacity, global availability, advanced managed services, and access to specialized computing resources. Artificial intelligence is now changing the calculation. AI systems consume large amounts of compute, storage, networking capacity, and data. Their usage can be continuous, unpredictable, and difficult to estimate. Training workloads may need enormous bursts of specialized hardware. Inference workloads may run continuously after deployment. Retrieval systems repeatedly move data between databases, vector stores, models, applications, and users. AI agents may make thousands or millions of automated requests without the natural usage limits associated with human-operated software. These patterns can make public cloud infrastructure extremely valuable during experimentation while making it expensive for mature, stable, high-volume production workloads. Security is creating a second pressure. Enterprise AI frequently requires access to confidential documents, customer information, internal communications, source code, intellectual property, operational systems, and regulated data. When this information moves through external models, APIs, public clouds, SaaS platforms, plugins, agents, and third-party integrations, the organization’s attack surface expands.

A third pressure comes from sovereignty and compliance. Companies increasingly need to know where data is stored, which jurisdiction governs it, who can access it, how it is processed, and whether a critical cloud service can be replaced during an outage, contractual dispute, cyberattack, or geopolitical disruption. Cloud repatriation is therefore becoming a workload-placement strategy rather than a wholesale rejection of public cloud computing.

Organizations are increasingly using:

Public cloud for experimentation, global distribution, managed services, elastic demand, and short-term capacity. Private cloud for controlled enterprise environments and predictable workloads. Colocation facilities for dedicated infrastructure without building an entire corporate data center. Sovereign cloud for regulated or jurisdiction-sensitive data. Edge infrastructure for low-latency AI applications. Hybrid cloud to connect all of these environments. Multicloud architectures to reduce concentration risk and gain access to specialized services. The strongest enterprise strategy is no longer “cloud first” or “on-premises first.” It is workload first.

The Cloud Era Is Entering Its Second Major Phase The first major phase of cloud adoption was driven by migration. Companies wanted to escape slow hardware procurement, underused corporate servers, costly data centers, lengthy application deployment cycles, and limited geographic reach. Public cloud providers allowed businesses to rent infrastructure on demand instead of purchasing it years in advance. This model transformed enterprise technology. A startup could launch a global application without building a data center. A retailer could increase computing capacity during holiday demand. A pharmaceutical company could temporarily access high-performance computing. A media platform could store and distribute massive content libraries. A bank could create development environments within minutes rather than waiting weeks for hardware. The public cloud did not merely reduce infrastructure ownership. It changed the speed at which companies could experiment. But many cloud strategies eventually moved beyond selective adoption. “Cloud first” was often interpreted as “cloud by default,” and in some organizations it became “cloud regardless of workload.” Applications were migrated without being redesigned. Databases were moved without analyzing data-transfer patterns. Old systems were placed inside cloud virtual machines, recreating the same architecture on more expensive rented infrastructure. Teams provisioned resources without ownership controls. Different departments purchased overlapping services. Development environments remained active when they were no longer needed.

The cloud remained useful, but cloud usage became harder to govern. The Dark Reading article published on June 25, 2025, described this shift as organizations moved toward more hybrid arrangements rather than simply returning everything to traditional on-premises infrastructure. The article identified security, compliance, performance, cost management, and predictable resource use as leading reasons companies were evaluating AI workload repatriation. The change should not be interpreted as proof that the original cloud movement failed. It shows that enterprise buyers are becoming more sophisticated.

The first phase asked:

How quickly can we move into the cloud?

The second phase asks:

Which environment should operate each workload, and why?

What Cloud Repatriation Actually Means Cloud repatriation is the movement of applications, data, storage, computing workloads, or supporting infrastructure from a public cloud environment into another operating model.

That destination could be:

A company-owned data center. A managed private cloud. A dedicated hosting provider. A colocation facility. A sovereign cloud environment. An industry-specific cloud. An edge computing facility. A hybrid architecture combining public and private systems. The term can therefore be misleading. It creates an image of companies moving backward from modern cloud platforms into old server rooms. That is rarely the complete picture. Modern repatriation may involve dedicated GPU clusters in a professionally operated colocation facility, connected through private networks to public cloud services. It may involve Kubernetes environments that can run across several infrastructure providers. It may involve company-controlled object storage connected to cloud-based AI models. It may involve keeping confidential data inside a private environment while using public cloud capacity for temporary model training. Cloud repatriation is better understood as infrastructure reallocation.

The business is moving a workload from an environment that no longer provides the best economic, technical, security, or regulatory fit into one that does.

AI Is Changing the Economics of Cloud Computing Artificial intelligence workloads behave differently from many traditional business applications. A conventional enterprise application may have relatively predictable activity. Employees log in during business hours, perform a limited number of actions, retrieve records, and log out. Capacity needs may increase gradually as the organization grows. AI systems can generate far more intensive demand.

An enterprise AI platform may include:

Model training. Model fine-tuning. Real-time inference. Batch inference. Retrieval-augmented generation. Embedding creation. Vector database searches. Data preparation. Data labeling. Model evaluation. Safety testing. Monitoring and logging.

Agent orchestration. Synthetic data generation. Long-term storage of model outputs. Continuous synchronization with enterprise systems. Every layer consumes infrastructure. An AI assistant answering employee questions may need to retrieve records from multiple repositories, convert documents into embeddings, search a vector database, submit context to a model, inspect the response, apply security policies, store logs, and send the answer through an application interface. One user request may trigger multiple infrastructure operations. An autonomous agent can multiply those operations further. Instead of waiting for a human to initiate a single request, the agent may monitor conditions, search systems, call APIs, generate documents, update databases, communicate with other agents, and repeat a process continuously. The economics of “pay for what you use” become less attractive when machine-generated usage grows faster than human-generated revenue.

The Difference Between AI Training and AI Inference AI infrastructure decisions should distinguish between training and inference. Training Training creates or substantially modifies a model. It can require large numbers of GPUs or other accelerators operating together for a limited period. Public cloud can be attractive for training because organizations may need enormous capacity temporarily. Purchasing all of that hardware would require significant capital and could leave expensive equipment underused after the training cycle ends.

Cloud infrastructure may also provide:

Immediate access to accelerator clusters. Managed distributed-training tools. High-speed storage. Preconfigured AI development environments. Access to multiple model families. Easier experimentation. Geographic availability. Specialized engineering support. For occasional training, public cloud flexibility may outweigh the cost. Inference Inference occurs when a trained model processes new requests. Once an AI service reaches production, inference may operate continuously. A customer-service model, recommendation engine, fraud system, industrial vision platform, document processor, or enterprise assistant may handle requests every second of every day.

Stable inference workloads often have:

Predictable demand. Consistent hardware requirements. High utilization. Long operating periods. Large data-transfer volumes. Strict latency requirements. Sensitive information flows. These characteristics can make owned or dedicated infrastructure more economically attractive.

A simple principle is:

Cloud rental often works best for uncertain or temporary demand. Dedicated infrastructure may work better for stable, heavily utilized demand. This does not apply universally. It depends on hardware pricing, utilization, electricity, staffing, software, facilities, financing, maintenance, and the value of flexibility. But it explains why AI inference has become an important repatriation candidate.

Why AI Cloud Bills Become Difficult to Predict Cloud bills become unpredictable because AI demand is influenced by many variables simultaneously.

Costs may depend on:

The model selected. The number of input tokens. The number of output tokens. The size of the context window. GPU type. GPU availability. Processing time. Storage capacity. Retrieval frequency. Data transfer. Number of users. Agent activity.

Monitoring requirements. Redundancy. Regional deployment. Backup policies. Security inspection. API calls. Reserved-capacity commitments. A product team may believe it is paying for an AI model when the total cost actually includes many connected services.

For example, an enterprise knowledge assistant might generate charges for:

Document storage. Data ingestion. Optical character recognition. Embedding creation. Vector database capacity. Search operations. Model inference. Application hosting. Identity verification. Security logging. Monitoring. Backup storage.

Cross-region replication. Network traffic. Data egress. The model bill may be only one part of the system’s total cost. Flexera’s 2026 State of the Cloud research found that hybrid architecture remained dominant, with 73 percent of surveyed organizations operating hybrid estates. It also estimated that wasted IaaS and PaaS spending had risen to 29 percent as AI and new cloud services increased cost complexity. This helps explain why cloud financial management is moving earlier into system design. Companies can no longer build an AI application first and ask the finance team to optimize it later. Unit economics need to be included before the production architecture is approved.

The Role of FinOps in AI Infrastructure FinOps is the practice of bringing engineering, finance, operations, procurement, and business teams together to manage technology spending. Traditional IT budgeting was largely centralized. A company purchased servers, software licenses, networking equipment, and support contracts through planned capital or operating budgets. Cloud computing decentralized spending. A developer could provision infrastructure with a few clicks. A product team could start a database without asking procurement. A business unit could subscribe to a SaaS product using a corporate card. An AI team could test several models and generate consumption charges before a centralized review occurred. This speed supported innovation, but it separated technical decisions from financial consequences. FinOps attempts to reconnect them.

For AI systems, effective FinOps should measure:

Cost per model request. Cost per completed business task. Cost per customer served. Cost per document processed. Cost per agent workflow. Cost per generated lead. Cost per fraudulent transaction detected. Cost per software feature created. Cost per revenue-producing outcome. Infrastructure cost as a percentage of product revenue. Marginal cost as usage grows. The important question is not simply whether a cloud bill increased.

The important question is whether the additional spending created proportionate business value. An AI service costing $2 million per year may be economically excellent if it creates $20 million in additional margin. A service costing $200,000 may be wasteful if it produces no measurable outcome. Flexera reported that organizations are increasingly measuring cloud success through business value and unit economics rather than relying only on cost savings. The same research found broader adoption of centralized cloud governance and FinOps teams as companies responded to growing complexity.

Security Is Becoming an Infrastructure-Placement Question Public cloud platforms can provide highly advanced security capabilities.

They offer:

Encryption. Identity and access management. Hardware security modules. Security monitoring. Distributed denial-of-service protection. Automated patching. Compliance certifications. Threat detection. Private networking. Data-loss prevention. Backup and recovery. Security analytics.

For many companies, a hyperscale cloud can be more secure than a poorly maintained private data center. Cloud repatriation should therefore not be based on the simplistic belief that “on-premises is secure” and “public cloud is insecure.” Security depends on architecture, configuration, governance, staffing, identity controls, monitoring, response capabilities, and operational discipline. However, AI creates security concerns that go beyond the underlying cloud platform. AI systems need data.

The more useful an enterprise AI system becomes, the more access it may require to:

Customer records. Financial information. Employee communications. Legal documents. Product designs. Source code. Contracts. Medical information. Research data. Operational systems. Manufacturing processes. Corporate strategy.

Authentication systems. Payment infrastructure. This creates a difficult relationship between capability and exposure. A model with no access to enterprise data may be safe but not very useful. A model with extensive access may be useful but dangerous if its permissions, behavior, or integrations are not properly controlled.

AI Agents Expand the Attack Surface The security problem becomes more serious when AI systems act rather than merely answer questions. An AI chatbot generates information.

An AI agent may:

Send email. Access cloud storage. Create software. modify databases. Place orders. approve transactions. communicate with customers. operate machinery. access financial accounts. schedule meetings. manage credentials. trigger business workflows.

Every permission creates a potential path for misuse.

An attacker may attempt to manipulate an agent through:

Prompt injection. Malicious documents. Compromised websites. Poisoned training data. Fake tool responses. Stolen credentials. Excessive permissions. Vulnerable plugins. Insecure APIs. Supply-chain attacks. Social engineering. Model extraction.

Data exfiltration. The traditional network perimeter already weakened as companies adopted SaaS, remote work, public cloud, mobile devices, and third-party integrations. AI agents weaken it further because they operate across many systems simultaneously. The Dark Reading article describes an enterprise environment in which applications, databases, cloud services, edge systems, managed providers, clients, and agents create a rapidly expanding attack surface. It argues that organizations must apply security consistently across hybrid environments rather than assuming that a single perimeter can protect them.

Shadow AI Is Becoming the New Shadow IT Shadow IT refers to technology that employees use without formal approval from the organization. Shadow AI is its modern equivalent. Employees may paste company data into public AI chatbots, connect unapproved assistants to corporate accounts, install browser extensions, use AI meeting recorders, upload documents to summarization tools, or authorize agents to access email and cloud storage. These actions often happen because approved enterprise tools are unavailable, inconvenient, or slower than consumer services.

But the consequences can include:

Confidential information entering third-party systems. Unknown data-retention policies. Intellectual-property exposure. Regulatory violations. Unapproved model training. Weak identity controls. Inability to audit outputs. Uncontrolled plugins and integrations. Incorrect information entering business processes. A Cloudian-commissioned 2026 survey of 203 enterprise IT decision-makers reported that 93 percent had repatriated some AI workloads, were in the process of doing so, or were evaluating repatriation. In the same survey, 91 percent said they would favor on-premises, private-cloud, or hybrid infrastructure for AI involving sensitive company data, while 74 percent identified shadow AI as a critical or significant security concern. The sample is limited and the research was commissioned by an infrastructure vendor, so its percentages should not be treated as a universal measurement of the entire global market. Nevertheless, the findings illustrate a real strategic concern: organizations want the productivity of AI without losing control of their data.

Data Sovereignty Is Moving From Legal Fine Print to Infrastructure Strategy Data sovereignty means that information is subject to the laws and governance requirements of the jurisdiction in which it is stored or processed. For years, many companies treated data location as primarily a compliance issue. AI is making it an operational and strategic issue.

An enterprise may need to determine:

Where prompts are processed. Where model outputs are stored. Whether data crosses national borders. Whether a provider retains customer inputs. Whether subcontractors can access the data. Whether foreign legal authorities can compel access. Whether encryption keys are controlled by the customer. Whether model training uses customer information. Whether logs contain confidential data. Whether deleted data is removed from backups. Whether the system can be moved to another provider.

These questions are especially important in:

Government. Defense. Healthcare. Banking. Insurance. Telecommunications. Energy. Critical infrastructure. Legal services. Education. Scientific research. Data sovereignty can lead organizations toward sovereign cloud, domestic providers, private cloud, or company-controlled infrastructure.

The goal is not necessarily physical ownership of every server. It is verifiable control over data location, access, encryption, operations, and legal exposure.

Cloud Concentration Is a Board-Level Risk Cloud computing has created extraordinary scale, but much of the digital economy depends on a small number of providers. Concentration creates several risks. Operational concentration An outage at a major cloud provider can affect thousands of companies simultaneously. Security concentration A vulnerability affecting a widely used identity, storage, management, or networking service may expose many customers. Commercial concentration A provider can change prices, product terms, discount programs, service availability, or licensing requirements. Technical concentration Applications built deeply around proprietary services may become difficult and expensive to move. Regulatory concentration

Governments may determine that dependence on a small number of technology providers creates systemic risk. Geopolitical concentration Cross-border conflicts, sanctions, trade restrictions, or national-security policies may affect service access. Cloud repatriation and multicloud strategies can reduce concentration, but they do not automatically eliminate it. A company using three clouds may still depend on one identity provider, one security platform, one telecommunications network, or one data-management system. Resilience requires mapping all critical dependencies, not merely counting cloud vendors.

Egress Fees and Data Gravity Influence Workload Placement Data gravity describes the tendency of applications and computing workloads to move toward large concentrations of data. A company with petabytes of information in a particular environment may find it easier to move computing closer to that data than to move the data repeatedly. AI increases data gravity because models require access to large datasets.

If data is stored in one cloud while the model runs in another environment, the company may face:

Data-transfer charges. Higher latency. Security inspection requirements. Duplicate storage. Synchronization complexity. Regulatory concerns. Network bottlenecks. These costs can become substantial in data-intensive systems. The issue is not limited to a one-time migration fee. An architecture that continuously transfers information between clouds, regions, data centers, and AI services may create permanent network spending. This means that data location can determine the economic center of an AI architecture.

Before deciding where a model should run, companies should identify:

Where the source data currently lives. How often the data must move. How much data each request uses. Whether results must be stored elsewhere. What latency the application can tolerate. Which jurisdiction governs each transfer. What happens when network connectivity fails.

Performance and Latency Can Push AI Toward the Edge Not every AI workload belongs in a centralized public cloud. Some applications must respond within milliseconds.

Examples include:

Autonomous vehicles. Industrial robots. Medical devices. Fraud detection. Manufacturing inspection. Smart-city infrastructure. Defense systems. Telecommunications networks. Retail checkout systems. Energy-grid controls. Security cameras. Drones.

Augmented-reality devices. Sending all data to a distant cloud region may introduce unacceptable latency. It may also create bandwidth costs and operational risk when connectivity is unreliable. Edge AI processes data closer to where it is generated. A factory may analyze camera feeds inside the facility. A hospital may process sensitive medical images locally. A retailer may run computer vision at the store. A robot may use an embedded model for immediate decisions while connecting to the cloud for updates and deeper analysis.

The resulting architecture may include:

Edge inference. Private data storage. Public cloud model training. Centralized monitoring. Cloud-based software updates. Local failover. Periodic synchronization. This is another reason the future is likely to be hybrid.

Colocation Is Becoming an Important Middle Ground Building a private data center is expensive and slow.

It requires:

Land or building space. Power infrastructure. Cooling. Backup generators. Network connectivity. Physical security. Fire protection. Hardware maintenance. Compliance systems. Operations staff. Long-term capacity planning. Many organizations do not want to recreate that responsibility.

Colocation offers a middle ground. A colocation provider operates the facility, power, cooling, physical security, and network connections. The customer installs or leases dedicated infrastructure inside that facility.

This can provide:

Greater hardware control. Predictable capacity costs. Access to high-density power. Specialized cooling for GPUs. Direct connections to cloud providers. Lower deployment time than building a new data center. Physical separation from public-cloud tenants. Flexible hybrid networking. The Dark Reading article noted that companies evaluating AI repatriation were considering colocation facilities at levels similar to their own data centers, partly because established facilities may already have the power and cooling required for resource-intensive AI hardware. As GPU infrastructure becomes denser and more power-hungry, access to electricity and cooling may become as strategically important as access to the processors themselves.

Repatriation Can Fail When Companies Ignore Hidden Costs Moving workloads out of public cloud does not guarantee savings. Private infrastructure introduces costs that may be absent or less visible in cloud pricing.

These include:

Hardware purchases. Financing costs. Depreciation. Spare capacity. Hardware failures. Refresh cycles. Software licensing. Facility fees. Electricity. Cooling. Networking. Security tools.

Backup systems. Disaster recovery. Engineers. On-call operations. Compliance audits. Insurance. Vendor support. Supply-chain delays. A public cloud invoice may appear expensive because most infrastructure costs are visible in one bill. Private infrastructure may appear inexpensive because costs are distributed across payroll, facilities, procurement, capital budgets, software agreements, and support contracts. A fair comparison must calculate total cost of ownership. It should also consider opportunity cost.

A company might save money on servers but lose product velocity because engineers are maintaining infrastructure rather than improving the product.

Cloud repatriation is most likely to succeed when the organization has:

Stable workload demand. High infrastructure utilization. Strong technical expertise. Sufficient scale. Long planning horizons. Predictable growth. Clear security requirements. A realistic operating model.

Which Workloads Are Strong Repatriation Candidates?

A workload may be a strong candidate when it has several of the following characteristics:

Stable, continuous demand The system runs constantly and uses predictable capacity. High utilization Dedicated hardware would remain busy rather than sitting idle. Heavy data movement The workload generates substantial egress or cross-region traffic. Sensitive information The system processes intellectual property, regulated records, or confidential enterprise data. Low-latency requirements The application needs to operate close to users, devices, factories, or data sources. Specialized hardware requirements The organization can achieve better economics using dedicated accelerators.

Long operating life The workload is expected to run for several years. Limited dependence on proprietary cloud services The application can move without a complete redesign. Predictable software architecture The system is mature and no longer changing rapidly. Strong internal or managed operational capability The organization can maintain the environment securely and reliably.

Which Workloads Should Usually Remain in Public Cloud?

Public cloud may remain the better choice for:

Experimental AI projects The company does not yet know which models, hardware, or scale it will need. Highly variable demand Usage changes dramatically and unpredictably. Short-duration workloads The system needs large amounts of capacity temporarily. Global applications The product must operate across many regions. Small teams The organization lacks staff to maintain infrastructure. Disaster recovery Temporary cloud capacity may be activated during an emergency.

Managed-service-heavy applications The system depends deeply on proprietary databases, analytics, security, or AI services. Fast-growing startups Preserving capital and product velocity may be more important than minimizing long-term infrastructure cost. Early-stage AI training The team needs rapid access to different accelerator types. Applications where infrastructure is not a competitive advantage Operating dedicated systems may distract from the core business.

A Practical Workload-Placement Framework Every significant application should be evaluated across seven dimensions.