Data Gravity in AI: Why It Matters Now

Overview

In 2010, software architect Dave McCrory published a blog post that would quietly become one of the most enduring metaphors in modern infrastructure design. He called the phenomenon "data gravity": the observation that as datasets grow in size and importance, they begin to exert a pull on the applications, services, and additional data that orbit around them. By 2012, McCrory had formalized the concept with an initial formula, and over the following decade, the idea migrated from a useful mental model into a central architectural constraint. In 2026, with AI workloads dominating enterprise computing budgets, data gravity is no longer a peripheral consideration. It is the lens through which infrastructure decisions are being made, evaluated, and reversed.

The core insight is straightforward: moving data is expensive, slow, and increasingly regulated. As a result, compute is moving toward data, rather than the reverse. This single inversion is reshaping the AI infrastructure landscape, pulling inference workloads away from centralized hyperscale clouds and toward edge devices, on-premises data centers, and hybrid topologies. This post examines the evidence for this shift, identifies the forces driving it, and outlines what the practical implications look like for organizations building AI systems in 2026.

To ground the discussion, consider a representative example: a multinational manufacturing firm operating thirty factories across Europe, North America, and Southeast Asia. Each facility generates roughly two terabytes of sensor data per day from production lines, robotics, and quality-control cameras. Historically, this data was streamed to a centralized cloud for analytics. By 2025, the firm discovered that only four percent of the raw data needed to leave the factory floor, yet network egress costs had grown to seven percent of total IT spend. In 2026, the company deploys compact inference appliances inside each plant, running computer-vision defect detection and predictive-maintenance models locally. The four percent of "interesting" events still flows to the cloud for cross-plant learning, but the gravitational center of the workload has decisively moved to the edge. This pattern, repeated across industries, illustrates why data gravity is no longer theoretical.

The Origin and Definition of Data Gravity

Data gravity describes the tendency of large datasets to attract applications, services, and additional data, creating self-reinforcing accumulation in a particular location. Multiple independent sources, including CrowdStrike, Dremio, Tableau, and PhoenixData, converge on this definition. As Tableau noted in 2017, the principle is intuitive: as data grows in size, so does its pull. McCrory's contribution was to name the phenomenon and to propose a way of quantifying it, giving architects a shared vocabulary for reasoning about a problem they had long observed empirically.

A concrete illustration helps. Consider a regional bank's transaction-monitoring system. The core ledger dataset, originally a few hundred gigabytes in a single relational database, has grown over fifteen years to exceed eight petabytes of historical records, audit trails, and behavioral analytics artifacts. Fraud-detection models, originally external services that queried the ledger, have been progressively pulled inward. Today, fraud inference runs on infrastructure co-located with the ledger, not because the bank prefers on-premises in principle, but because the dataset's gravitational pull made any other arrangement impractical. New analytic services, such as credit-scoring models and customer-segmentation engines, naturally cluster around the same data, reinforcing the pattern.

The practical implication is that data location decisions are strategic and often irreversible. Once a dataset accumulates in a particular cloud, region, or on-premises environment, the cost and complexity of relocating it grows non-linearly. Egress fees, regulatory review, downtime risk, and application refactoring each compound the further the dataset must travel. This makes early architectural decisions about where data resides disproportionately consequential. In an AI era where models are increasingly trained on and inferred against massive datasets, those early decisions now propagate through every layer of the stack. Organizations that treated data residency as an afterthought in 2018 are now paying for it in 2026, either through costly migration projects or through permanent hybrid complexity that could have been avoided.

The 2026 Shift Toward Edge and On-Premises Inference

Multiple 2026 sources document a meaningful shift in where AI inference workloads run. Rack2Cloud reports that edge deployments are outpacing cloud in latency, cost, and data gravity considerations. Nutanix describes a "quiet reversal" from cloud-only architectures toward on-premises plus edge AI, noting that inference often works better closer to where data originates. Gigaom observes that running models close to data and users is now a cost and latency requirement rather than a niche optimization.

The drivers behind this shift are concrete, and each has identifiable real-world manifestations. Latency-sensitive applications cannot tolerate the round-trip cost of cloud inference. Autonomous-vehicle stacks, for example, must complete perception and planning inference in under fifty milliseconds. Even with optimal cloud proximity, network round-trips typically exceed one hundred milliseconds, ruling out centralized inference for safety-critical functions. Industrial IoT deployments face similar constraints: a robotic welding cell adjusting parameters in response to real-time sensor feedback cannot wait for a hyperscale region to return a prediction. In healthcare, patient-monitoring systems analyzing continuous ECG or EEG streams must flag arrhythmia events within seconds to be clinically useful; sending each sample to the cloud introduces both latency and potential failure modes that bedside devices eliminate.

Data movement costs compound quickly when inference workloads process high-volume streams. Retailers using computer vision for in-store analytics illustrate the point. A large grocery chain with two thousand stores generates continuous video from ceiling-mounted cameras. Sending every frame to the cloud for analysis would consume bandwidth orders of magnitude beyond what is economically or technically feasible. Edge inference devices, often small form-factor appliances mounted near the camera clusters, process the streams locally and forward only metadata: the count of customers in an aisle, the dwell time at an endcap, the detection of a safety incident. The raw video never leaves the store, which incidentally addresses privacy concerns as well.

The operational complexity of moving terabytes or petabytes of data to centralized compute has become prohibitive for many enterprises. A genomics research consortium working with sequencing data from hospital partners across multiple jurisdictions encountered this directly. Each sequencing run produces hundreds of gigabytes of raw data, and aggregating these for centralized analysis would require both substantial transfer budgets and extensive compliance review. Instead, the consortium deployed a tiered architecture: preprocessing and variant-calling models run on local compute attached to each sequencing facility, with only summary statistics and de-identified variant calls flowing to a central repository for cross-cohort analysis. The result is faster turnaround for clinical teams, lower data-transfer costs, and a compliance posture that aligns with the data's actual sensitivity.

The result of these forces is that inference, which once defaulted to the cloud almost reflexively, is now distributed across a portfolio of locations selected for each workload's specific characteristics.

This does not mean cloud inference is disappearing. Cloud remains attractive for batch processing, model training, and workloads where operational simplicity and economies of scale dominate. Foundation-model training, which requires coordinated access to thousands of accelerators, continues to favor hyperscale regions. Batch-scored retail recommendations produced overnight and embedded into a customer database by morning remain a cloud workload by default. Cost-sensitive inferencing for non-real-time applications, such as document classification for back-office automation, often remains in the cloud for operational simplicity. But the default assumption that inference belongs in the cloud is no longer tenable for a growing class of applications.

Data Sovereignty as an Architectural Driver

Among the forces shaping AI infrastructure in 2026, data sovereignty has emerged as one of the most powerful. S&P Global reports that data sovereignty and privacy regulations continue to drive demand for local data centers and edge deployments, with some governments offering direct incentives for in-jurisdiction infrastructure. Deloitte identifies data sovereignty, latency, intellectual property protection, and resilience as primary architectural factors, distinct from and sometimes overriding pure cost considerations.

The regulatory landscape is broad and increasingly specific. The European Union's GDPR, in force since 2018, restricts cross-border transfer of personal data through adequacy decisions, Standard Contractual Clauses, and binding corporate rules. The EU AI Act, whose high-risk provisions became enforceable through 2025 and 2026, layers additional requirements on AI systems used in employment screening, credit scoring, biometric identification, and critical infrastructure. These rules do not merely recommend local processing; in many cases they require it. A French hospital deploying a diagnostic-assistance model must keep both the inference and the underlying imaging data within EU jurisdiction, and increasingly within French jurisdiction specifically. A German automotive supplier using AI to screen job applicants must conduct that screening on infrastructure located in Germany, audited by German authorities.

Beyond Europe, jurisdictions have developed their own frameworks. China's Cybersecurity Law and Data Security Law impose strict localization requirements on data collected within Chinese borders, particularly for organizations in critical sectors. India's Digital Personal Data Protection Act of 2023 introduced consent-based restrictions that, in practice, have pushed many multinational firms to deploy India-resident inference infrastructure rather than route Indian user data offshore. Brazil's LGPD, Saudi Arabia's Personal Data Protection Law, and a patchwork of U.S. state-level privacy statutes in California, Virginia, Colorado, and others create a mosaic that enterprises must navigate carefully. Some of these frameworks, notably GDPR and the EU AI Act, include provisions that apply extraterritorially, meaning that a U.S.-based cloud provider serving European users is subject to the same rules as a European one.

For organizations operating across jurisdictions, these rules are not peripheral legal concerns; they are primary architectural constraints that determine where compute must physically reside. The practical reality is that a multinational firm may operate a dozen or more distinct inference deployment footprints, each tailored to the regulatory environment of the region it serves. In some cases, this means deploying AI infrastructure in specific regions or on-premises even when cloud alternatives would be cheaper and operationally simpler. The compliance burden can be substantial: data-protection impact assessments, audit trails, lawful-basis documentation, and cross-border transfer mechanisms each require ongoing investment. For many firms, the cleanest response is to keep the data and the model that processes it in the same jurisdiction, accepting the resulting infrastructure fragmentation as a cost of doing business in regulated markets.

The implication is that for regulated industries, including finance, healthcare, government, and any organization handling personal or sensitive data, AI architecture must be designed with compliance as a first-class constraint. The cost calculus that historically favored cloud must be re-evaluated against the legal and operational risks of non-compliance. Fines under GDPR can reach four percent of annual global turnover, and reputational damage from a public compliance failure often exceeds the financial penalty. Regulated entities increasingly treat data-locality requirements as non-negotiable constraints rather than optimization problems, and their infrastructure choices follow accordingly.

The On-Premises Reality

One statistic stands out in the 2026 data: Verinext reports that nearly 40% of enterprise data still resides on-premises. This figure, drawn from a single source and not independently corroborated, nonetheless reflects a widely observed reality. Many enterprises have substantial investments in on-premises data centers, and the gravitational pull of that data is significant. Rather than migrate these established datasets to cloud AI services, a growing number of organizations are choosing to bring AI to their existing infrastructure.

Specific sectors illustrate why on-premises remains dominant. Financial services firms, particularly large global banks, often maintain primary trading and risk systems in on-premises data centers for performance, predictability, and regulatory reasons. These environments generate petabytes of market data, transaction records, and counterparty information every day. Deploying AI inference for fraud detection, anti-money-laundering screening, and trading analytics on the same infrastructure that houses the underlying data eliminates the network hop entirely, reducing latency from tens of milliseconds to under one. The cost savings on data egress, in some documented cases, reach eight figures annually. Healthcare systems face similar dynamics: hospital PACS archives, electronic health record databases, and imaging repositories often remain on-premises for both compliance and performance reasons, and AI applications ranging from radiology assistance to clinical-decision support increasingly run on the same infrastructure.

Government and defense agencies represent another significant on-premises constituency. Air-gapped networks, classified data handling requirements, and procurement rules that favor domestic infrastructure make cloud adoption impractical for many workloads. In these environments, AI is being deployed entirely on-premises, often on specialized hardware designed for classified environments. Telco operators, with their network function virtualization infrastructure and subscriber data residency requirements, are also substantial on-premises AI consumers, using inference for network optimization, anomaly detection, and customer-experience applications that must run close to the network edge.

This "quiet reversal" reflects the practical limits of cloud migration. Moving large, regulated, or operationally critical datasets to the cloud is expensive, risky, and time-consuming. The migration of a typical enterprise data warehouse to cloud, even when technically straightforward, often spans eighteen to thirty-six months and consumes significant operational attention. When the alternative is to deploy inference models on-premises or at the edge, leveraging existing data gravity rather than fighting it, the economics often favor staying put. Cloud providers are responding by offering hybrid and edge-enabled services, but the underlying data gravity remains. The result is a continuing on-premises footprint that, while no longer growing as fast as cloud, is not shrinking either, and is increasingly augmented with on-premises AI capabilities.

The Hybrid and Tiered Architecture Consensus

The strongest convergence across 2026 sources is on a single architectural conclusion: the winning AI design is hybrid or tiered, combining cloud, on-premises, and edge components rather than committing exclusively to any one. LinkedIn explicitly states that the winning architecture in 2026 is a tiered system. Nutanix and Mirantis describe infrastructure spanning all three locations. Gigaom identifies the "AI-defined edge" as a key architectural pattern. Rack2Cloud documents the same tiered approach in practice.

The reasoning is that different workloads have different requirements. Training large foundation models favors cloud, where access to specialized accelerators and economies of scale are decisive. A frontier-model training run requires coordinated operation of thousands of accelerators with high-bandwidth interconnects, a configuration that only hyperscale facilities can economically provide. Once trained, however, those models are increasingly deployed for inference in environments that may include cloud regions for batch scoring, on-premises clusters for latency-sensitive enterprise use cases, and edge devices for real-time field applications.

A representative tiered architecture in practice might look as follows. At the cloud tier, an organization maintains a foundation-model training cluster used to develop and fine-tune models on aggregated, de-identified data drawn from across the enterprise. At the on-premises tier, inference servers co-located with the organization's primary data warehouses serve low-latency enterprise applications such as real-time recommendations, fraud detection, and predictive maintenance. At the edge tier, compact inference appliances operate in retail stores, factory floors, vehicles, or remote sites, processing data locally and connecting intermittently to the higher tiers for model updates and aggregated insights. Each tier has distinct operational characteristics, security requirements, and update cadences, but together they form a coherent system in which data movement is minimized and each workload runs in its optimal location.

Real-world examples are multiplying. Logistics firms deploy edge inference in sorting facilities to read labels, detect damage, and optimize routing in real time, while aggregated shipment data flows to cloud systems for network-wide optimization. Energy companies run inference at wellheads and pipeline stations for leak detection and equipment monitoring, with summary telemetry flowing to centralized analytics platforms. Retailers operate edge inference for in-store analytics, cloud inference for cross-portfolio personalization, and on-premises inference for legacy point-of-sale integrations that cannot easily be migrated. In each case, the tiered architecture reflects the gravitational distribution of the underlying data and the latency requirements of the workload.

The trade-off is operational complexity. Hybrid architectures introduce challenges in orchestration, security, governance, and observability. Managing multiple environments requires deliberate investment in tooling and process. Model lifecycle management becomes more complex: a model may need to be packaged for a cloud region, an on-premises Kubernetes cluster, and a constrained edge device, each with different runtime requirements. Security policies must be applied consistently across environments with different threat models. Observability requires correlating signals across tiers to understand end-to-end behavior. Monitoring, deployment, and update processes must work reliably in environments with intermittent connectivity. For organizations without that operational maturity, the simplicity of a single-environment approach may still be appealing. But for those able to manage the complexity, the tiered approach offers meaningful advantages in latency, compliance, cost, and resilience.

Moving AI to Data Rather Than Data to AI

SUSE frames the core architectural choice explicitly: when faced with the data gravity problem, organizations can either move AI to data or move data to AI. The benefits of the former are substantial. Lower latency, faster inference, reduced data transfer costs, and simpler compliance posture. The benefits of the latter are concentrated in scenarios where compute resources are scarce at the data location or where centralized training on aggregated data is essential.

The data gravity principle strongly favors moving AI to data. This is not always feasible. Some models require compute resources that cannot be deployed at the edge, and some workloads genuinely benefit from aggregation. Training a recommendation model across the full user base of a global platform, for example, requires aggregated data that no single edge node possesses. But the default should be to bring models to where data already lives, using techniques like federated learning, edge inference, and on-premises deployment to minimize data movement.

Federated learning offers a particularly compelling approach to reconciling these requirements. In a federated learning setup, a shared model is trained across many distributed nodes, each holding local data that never leaves its jurisdiction. Instead of aggregating raw data, the system aggregates model updates, which can be exchanged in a privacy-preserving manner. Healthcare consortia have used federated learning to train diagnostic models across hospitals in different jurisdictions without ever pooling patient data centrally. Financial institutions have applied similar techniques to fraud-detection models that benefit from cross-institution learning without sharing sensitive transaction records. Edge deployments of consumer devices, most famously smartphone keyboards, use on-device learning to improve personalization from individual user behavior while transmitting only anonymized aggregate updates to the model owner.

Edge inference takes a different approach. Rather than training at the edge, it deploys already-trained models to edge locations for inference. The model may have been trained in the cloud, but the inference runs close to the data. This is the pattern most commonly discussed in 2026 industry literature, and it is the one most directly shaped by data gravity. Practical applications include industrial computer vision, in-store retail analytics, on-device voice assistants, vehicle perception systems, and embedded medical diagnostic devices. In each case, the inference workload is brought to where data originates, the data itself remains in place, and only summaries or aggregated insights flow outward.

On-premises deployment is the third variant, applicable when the data resides in a fixed location with sufficient compute resources to host inference. Large enterprises with established data centers often find this the simplest deployment model, as it requires no fundamental change to existing infrastructure patterns, only an addition of AI inference capacity. The model is deployed to servers co-located with the data warehouse, and inference requests are served locally.

These approaches are not mutually exclusive. A typical mature AI architecture uses all three: federated learning for cross-silo training, on-premises inference for enterprise workloads, and edge inference for field-deployed applications. The unifying principle is that data should move as little as possible, and the default architectural choice should reflect that.

Cloud's Evolution in Response

Cloud is not being abandoned. It is being reworked. LinkedIn reports that cloud environments designed primarily for elasticity are being adapted to address latency sensitivity, data gravity, and regulatory constraints. The major hyperscalers have introduced edge nodes, local zones, and sovereign cloud offerings that attempt to combine the operational benefits of cloud with the data-locality advantages of edge deployment.

These offerings take several forms. Local zones and wavelength services extend cloud presence into metropolitan areas, reducing network distance to milliseconds rather than tens of milliseconds. Outposts and dedicated hosts place cloud-managed hardware inside customer-owned data centers, providing cloud APIs and operational tooling while keeping data on-premises. Sovereign cloud offerings, available from multiple major providers, operate cloud regions within specific jurisdictions under local governance and staff, addressing data residency and access-control requirements. Edge networking services provide managed connectivity from edge devices to cloud backends, with consistent identity, security, and observability.

These offerings are not yet a complete solution. They introduce their own complexity: pricing models that differ from standard cloud SKUs, feature parity gaps relative to primary regions, and operational nuances that vary across providers. Some workloads remain awkward to deploy on these distributed footprints, particularly those requiring highly specialized hardware or tight integration with regional cloud services. But they represent meaningful progress toward reducing the trade-offs that have historically forced binary cloud-versus-edge decisions.

For organizations evaluating cloud providers, monitoring the evolution of these distributed offerings is increasingly important. The cloud of 2026 is not the cloud of 2020, and the trajectory is clearly toward greater distribution. Providers that invest in local presence, sovereign offerings, and edge integration are likely to capture more of the inference market than those that rely primarily on centralized regions. Procurement teams evaluating cloud strategies should weigh not only current capabilities but the trajectory of each provider's distributed cloud roadmap.

Practical Recommendations

The evidence supports several concrete recommendations for organizations building AI systems in 2026.

First, audit data location before designing architecture. Map where your data resides, understand the regulatory constraints on moving it, and identify the gravitational centers that will anchor your infrastructure decisions. This audit should cover production databases, data warehouses, data lakes, archives, and any data generated at edge locations such as factories, stores, vehicles, or field equipment. The output should be a clear inventory of data residency, sensitivity classification, and the regulatory regimes that apply to each dataset.

Second, adopt a tiered inference strategy. Do not default to cloud or edge based on habit. Evaluate each workload individually against criteria including latency sensitivity, data sensitivity, regulatory requirements, and cost characteristics. Route accordingly. A useful exercise is to classify each inference workload along a latency-versus-data-volume grid: high-volume, latency-sensitive workloads almost always belong at the edge or on-premises; low-volume, latency-tolerant workloads are usually best in the cloud. Workloads in between require more nuanced analysis.

Third, design for data gravity. Assume that data will stay where it is and bring models to the data rather than planning large-scale migrations. Use federated learning, edge inference, and on-premises deployment to minimize data movement. Where data movement is unavoidable, architect for it explicitly: design aggregation points, summarize data before transfer, and build the cost of movement into the application's economic model rather than treating it as an afterthought.

Fourth, monitor cloud provider evolution. Distributed cloud offerings are maturing rapidly, and the trade-offs that once forced binary decisions may narrow over time. Build flexibility into your architecture so that workloads can be relocated as provider offerings improve. Avoid lock-in to deployment patterns that assume a particular provider's distributed footprint will remain static.

Fifth, validate with pilots. The available evidence is strong on direction but weak on specifics. Public benchmarks comparing edge and cloud inference for representative workloads are scarce, and named case studies with measured outcomes are rare. Run your own comparisons before committing to an architecture. Pilots should measure not only technical performance but also operational cost, regulatory posture, and the engineering effort required to maintain the chosen deployment pattern over time.

Sixth, invest in operational tooling for hybrid environments. The complexity of tiered architectures is real and ongoing. Investment in orchestration, observability, model lifecycle management, and cross-tier security pays dividends over time. Organizations that treat hybrid operations as a strategic capability, rather than an ad hoc response to individual workload constraints, will be better positioned to adapt as requirements evolve.

Seventh, engage compliance early in architecture design. Sovereignty and regulatory constraints are easier to satisfy when considered at the design stage than when retrofit onto a deployed system. Involve legal, compliance, and security teams in architectural decisions from the outset, and treat their requirements as architectural inputs rather than review gates.

Closing Thoughts

Data gravity has evolved from a conceptual metaphor into a practical architectural framework shaping AI infrastructure decisions. The shift toward edge and on-premises inference in 2026 is driven by latency requirements, data sovereignty regulations, the cost of data movement, and the practical reality that nearly 40% of enterprise data still resides on-premises. The hybrid and tiered architecture has emerged as the consensus approach, combining the operational benefits of cloud with the data-locality advantages of edge deployment.

The evidence is not without gaps. Quantified cost comparisons, performance benchmarks, and named case studies with measured outcomes are largely absent from public sources. The direction is clear, but the specifics remain for each organization to determine through its own pilots and measurements. What is beyond dispute is that the era of defaulting to cloud for AI inference is ending, replaced by a more nuanced, workload-by-workload approach that respects the gravitational pull of data.

For practitioners, the immediate implication is that architectural decisions made in 2026 will shape infrastructure trajectories for years to come. Choosing where data lives, and therefore where inference must follow, is among the most consequential decisions an organization makes in its AI strategy. The metaphor that Dave McCrory introduced in 2010 has matured into an operating principle: design for data gravity, and the rest of the stack will follow.