Defining sovereign cloud
Sovereign cloud is a hosting and governance arrangement. It means your data, and the compute that processes it, are held within a specific jurisdiction, under the legal authority of that jurisdiction, by an entity that is accountable under that jurisdiction’s laws.
Three criteria define it: physical location, legal entity, and governance structure.
Data must be stored on infrastructure physically located within the chosen jurisdiction. The operator must be a legal entity in that jurisdiction, or a foreign entity operating under an Australian-governed contractual arrangement with clear jurisdictional commitments. The governance of the arrangement, contracts, support, compliance obligations, and audit access, must operate under the applicable local legal framework.
For Australian organisations, a sovereign cloud arrangement means data stored in Australia, operated by an Australian legal entity, with contracts governed by Australian law and support provided by staff subject to Australian legal accountability.
Sovereign cloud solves a specific problem: it closes the gap that opens when data is stored or processed on foreign infrastructure subject to foreign laws. The US CLOUD Act is the most cited risk. An Australian organisation storing data with a US-headquartered cloud provider is subject to CLOUD Act reach regardless of where the data centre sits. Sovereign cloud removes that exposure by ensuring the controlling legal entity is in Australian jurisdiction.
Common sovereign cloud use cases include regulated data storage for healthcare, financial services, and government; backup and disaster recovery for critical data; and general compute for sensitive workloads that must remain onshore under Privacy Act or sector-specific obligations.
Defining sovereign AI
Sovereign AI begins from the same foundation as sovereign cloud, locally governed infrastructure and data storage, but extends control further up the stack to the AI layer itself.
That extension covers three additional areas that sovereign cloud does not address.
Models. Which AI models are processing your data? Are they open-weight models run locally on infrastructure you govern, or are they proprietary models accessed through a foreign API? A sovereign AI arrangement runs models within the jurisdiction, so that inference requests and outputs do not leave Australian infrastructure. Using an offshore AI API endpoint, even if the data feeding it is stored locally, breaks the sovereignty chain at the inference layer.
Training data. If your organisation is fine-tuning or training models on proprietary or sensitive data, that training process must be local. Training data, including any regulated or sensitive information used to adapt a model, cannot be transferred to an offshore training environment without creating both sovereignty and compliance exposure under the Privacy Act and sector-specific rules.
Inference pipelines. Every query sent to an AI model at runtime, including the prompt, the contextual data, and any user-provided inputs, must remain within the jurisdiction during processing. If your AI application sends customer data to a foreign inference endpoint and receives a response, that data has left Australian jurisdiction at the point of inference, regardless of where it was stored beforehand.
Sovereign AI is therefore a more comprehensive requirement than sovereign cloud. It requires everything that sovereign cloud requires, plus local model hosting, local training capability where applicable, and local inference infrastructure.
Where they overlap
Sovereign cloud and sovereign AI share a common foundation. Neither works without it.
Both require locally governed data centres. The physical infrastructure, racks, power, cooling, network interconnects, must be located in Australia and operated by entities subject to Australian law. There is no sovereign cloud without local data centres, and there is no sovereign AI without the same local foundation. The two concepts share infrastructure at the base of the stack.
Both rely on the same compliance frameworks. The Privacy Act 1988, the Security of Critical Infrastructure Act 2018, APRA’s CPS 230 prudential standard, and sector-specific regulations all apply to data storage and to AI workloads. The legal obligations that sovereign cloud helps satisfy are the same obligations that sovereign AI must satisfy, extended across a more complex technical stack. Compliance is not a separate concern for each; it is a shared requirement that runs through both.
Both require transparent, auditable governance. Data centre certifications such as ISO 27001, auditable access controls, AUD-denominated contracts with Australian legal entities, and locally accountable support teams are prerequisites for both sovereign cloud and sovereign AI. The governance infrastructure that a reputable sovereign cloud provider has built is a component of any credible sovereign AI arrangement. There is no sovereign AI without the underlying governance that sovereign cloud establishes.
This is why the choice is not binary. Sovereign cloud is a necessary layer within sovereign AI. The question is whether your requirements stop at the data layer, or extend up to the AI layer.
Where they diverge
The divergence begins the moment AI is introduced into a workload.
Sovereign cloud does not govern what happens when an AI model processes your data. If your data is stored in a compliant Australian facility but inference runs through a foreign AI API, your data leaves Australian jurisdiction at the point of inference. The storage arrangement is sovereign. The AI arrangement is not. They are not the same thing, and compliance frameworks are beginning to distinguish them.
Sovereign cloud also does not address model governance. Which models have access to your data? Under what legal terms? What does the model provider do with inference inputs, and where does that processing occur? These questions are outside the scope of a sovereign cloud arrangement. They become in-scope the moment AI enters the stack, and regulators are starting to ask them explicitly.
Sovereign AI diverges from sovereign cloud in three specific ways.
Model control. Sovereign AI requires models to be run under your governance, in your jurisdiction, whether that means on-premises, in a locally governed colocation facility, or through a local AI infrastructure provider running open-weight models such as Meta Llama, Mistral, DeepSeek, or Qwen. Using an offshore model API violates this requirement regardless of where the underlying data is stored.
Training data control. If your organisation is training or fine-tuning models, that process must be local. This is an infrastructure and data governance requirement that sovereign cloud does not address. Training on sensitive data via an offshore provider creates cross-border disclosure risk under the Privacy Act and potentially constitutes a reportable data breach depending on the dataset.
Inference data control. This is a runtime requirement. Every prompt, every contextual payload, every input processed at inference time must remain within Australian jurisdiction. This changes how AI applications are architected, not just where they are deployed.
| Dimension | Sovereign cloud | Sovereign AI |
|---|---|---|
| Physical location | Data stored and processed in Australian data centres | Same requirement, plus inference and training must also run on Australian infrastructure |
| Legal entity | Provider operates under Australian jurisdiction, with no foreign compelled-disclosure exposure | Same requirement, extended to the model provider and any AI infrastructure layer |
| Model control | Not addressed. Sovereign cloud says nothing about which AI models touch your data | Models must run under your governance and jurisdiction; offshore model APIs are out of scope |
| Training data | Not addressed | Training and fine-tuning must happen on local infrastructure; offshore training creates cross-border disclosure risk |
| Inference | Not addressed | Every prompt and output must stay within Australian jurisdiction at runtime |
Which one does your business need first?
For most Australian organisations, the answer is sequential: sovereign cloud first, then sovereign AI when AI workloads are operational.
If you are not yet running AI workloads, or if AI is at the experimental stage with non-sensitive data, sovereign cloud is the appropriate immediate priority. It addresses the most significant risk for most organisations: offshore data storage and the compliance exposure it creates under current Australian law. Establishing a sovereign cloud foundation also positions you to extend to sovereign AI without rebuilding your infrastructure layer from scratch.
If you are already running AI workloads, or planning to deploy AI in a regulated context within the next twelve months, sovereign AI is the framework you need to evaluate now. The question to answer is: at which point in your AI stack does control leave Australian jurisdiction? Model access, training pipelines, and inference environments all need to be assessed against sovereign requirements, not just data storage arrangements.
A practical decision guide by workload type:
Data storage and general compute: sovereign cloud is sufficient.
Regulated data with no AI layer: sovereign cloud is the requirement.
AI workloads at experimental or internal stage: sovereign cloud as foundation; begin assessing local model hosting options.
AI workloads that are customer-facing or touch regulated data: sovereign AI requirements apply. Local model hosting and local inference infrastructure are needed.
AI training or fine-tuning on sensitive or regulated data: the full sovereign AI stack, including local training infrastructure, is required.
The boundary between these categories is not fixed. As AI capabilities expand and regulatory guidance matures, the definition of a regulated AI workload will broaden. Organisations that have established sovereign cloud foundations and are beginning to assess sovereign AI requirements are better positioned to respond to that evolution than those building from scratch under compliance pressure.
Sovereignty is not a sticker. It is the architecture. And it extends as far up the stack as your AI does.
Related reading: What is sovereign AI? A guide for Australian businesses and How sovereign data centres support AI compliance.
Frequently asked questions
If our data is already stored in a sovereign Australian cloud, is our AI automatically sovereign too? No. Sovereign cloud only covers the storage and compute layer. If your AI application sends prompts or data to a foreign model API at inference time, that data leaves Australian jurisdiction at the point of inference, regardless of where it was stored beforehand.
Does using an open-weight model like Llama or Mistral automatically make an AI deployment sovereign? No, not on its own. The model needs to be run on infrastructure within your jurisdiction, under your governance. An open-weight model accessed through an offshore-hosted API endpoint carries the same inference-layer exposure as a proprietary model.
Do we need sovereign AI if our AI use is purely experimental and touches no regulated data? Not immediately. Sovereign cloud is the appropriate priority at that stage. Sovereign AI requirements become relevant once AI workloads are customer-facing, touch regulated data, or involve training or fine-tuning on sensitive datasets.
What’s the practical difference between sovereign cloud and sovereign AI in an audit? A sovereign cloud audit checks where data is stored and who operates the infrastructure. A sovereign AI audit goes further, checking which models process the data, where training occurs, and where inference requests and outputs travel at runtime.
