Why sovereign AI requires control beyond data residency

Sovereign AI is a dependency-control decision

The key infrastructure question for sovereign AI is which dependencies an organisation can permit outside its own environment. Data may need to remain local even when some software operations stay connected to a provider. At the strictest end, the environment may need to be air-gapped: physically or logically isolated from external networks, including the public internet.

Google argues that three risks are driving these choices:

Google says these pressures matter particularly in government, defence, healthcare, finance and critical infrastructure, where loss of access or control can have serious consequences. The company has a commercial interest in this framing because it sells infrastructure intended to address sovereignty requirements.

These requirements create a spectrum of architectures. Moving AI onto customer-controlled hardware can provide local execution while preserving dependencies on provider software, updates or lifecycle management.

Hybrid AI divides workloads by control requirements

A Google survey of more than 1,400 senior IT leaders found that 52% of organisations use a hybrid-cloud approach to AI, combining on-premises systems with multicloud environments. It also found that 48% prioritise infrastructure with data-residency controls to support compliance with local data-security laws. Google has a commercial interest in demand for hybrid-cloud infrastructure because it sells such infrastructure.

Among Google’s respondents, mixed deployment and data residency are current priorities. For executives, they point to two separate architecture decisions: where sensitive data sits and is processed, and which workloads can use external infrastructure and AI services.

A hybrid deployment can separate workloads based on those requirements. A regulated workload can stay within a controlled local environment, while another can use remote resources when its requirements allow. Infrastructure policy can then be set at the workload level.

Some sovereignty requirements demand a stricter boundary.

The sovereignty spectrum includes full isolation

Google Distributed Cloud illustrates the difference between local infrastructure connected to a provider and infrastructure designed for isolation. Google sells both deployment models and therefore benefits commercially from organisations adopting either approach.

Google describes its connected deployment as running on a customer’s existing hardware with a Google-managed software lifecycle. This supports local execution while retaining a provider connection for lifecycle operations.

Google describes its air-gapped deployment as fully disconnected from Google Cloud and the public internet. The company says the on-premises environment provides infrastructure for AI workloads, access to Gemini models and open models, and inference services.

This distinction matters for organisations that must operate without public-internet connectivity. A connected installation retains network and operational dependencies that Google’s air-gapped design is intended to remove.

Google also says its air-gapped system cannot be remotely shut down by the company. This is Google’s claim about a product it sells. Governments and other organisations concerned about dependence on overseas technology providers should state the required level of provider control in procurement, then test whether contractual and technical controls meet that requirement.

Local deployment can retain supplier dependencies

Physical location answers only part of the sovereignty question. An AI system running inside a private data centre may still depend on a supplier for software, models, lifecycle management, updates or support.

The terms describe different properties. “On-premises” means infrastructure runs at the customer’s location. “Air-gapped” means the environment is isolated from external networks. “Sovereign” describes the controls an organisation requires over its data and systems. “Independent” implies a broader ability to operate without critical reliance on an outside supplier.

These distinctions change procurement. Executives need to specify which data may leave the environment, which network connections can exist, who performs lifecycle operations, how updates enter controlled systems and what controls remain available to the provider.

Those requirements should be testable. An organisation focused on domestic data-residency rules may permit provider-managed lifecycle services. An operator whose threat model includes prolonged loss of external connectivity may require the system to keep operating in isolation. An organisation concerned about external provider control should identify which technical and contractual mechanisms allow a supplier to alter, disable or update deployed systems.

Key executive takeaways

• Define acceptable AI dependencies: Sovereign AI requires more than local data. Leaders should specify which external dependencies, including provider software, updates, lifecycle management and network access, their risk model permits.
• Separate workloads by control requirements: Hybrid AI lets organisations keep regulated workloads in controlled environments while using remote resources elsewhere. Set data-residency and infrastructure policies at the workload level.
• Match isolation to the threat model: Connected on-premises and air-gapped AI provide materially different levels of control. Organisations that must withstand internet loss or limit provider access should require and verify isolation capabilities.
• Test supplier dependence in procurement: On-premises infrastructure can still rely on an external supplier for models, software, updates and support. Procurement should define and test who can access, change, update or disable systems and how they operate when disconnected.