Data residency tells you where your data is stored and processed. Data sovereignty tells you which governments can compel someone to hand it over. Operational control tells you who holds the keys and who can log in. An AI system in an Australian cloud region can meet the first guarantee and fail the other two. You must test each guarantee separately for prompts, embeddings, logs and training data.
Three separate guarantees
Many vendor pages use “sovereign” to mean “hosted in Australia”, which is a residency claim. Residency is about the location of storage and processing. Sovereignty is about the legal entities and the laws that can reach the data. Operational control is about key ownership and access by people outside your organisation. A regulator, an auditor or a board risk committee will ask about all three, and the evidence for each comes from different documents.
Residency
Residency is a configuration fact, and AI services make it harder to pin down than storage does. A storage bucket stays in one region, but an inference request can move between regions. On Amazon Bedrock, for example, a geographic cross-Region inference profile keeps a request inside a geography, but AWS states that “your input prompts and output results might move outside of your source Region during cross-Region inference”. AWS also says that data it stores for abuse detection is stored in the destination region. The companion article on Bedrock and Azure OpenAI in Australian regions lists which routing options keep processing inside Australia.
For residency, you must make sure that every component stays in Australia: the model endpoint and its routing, the vector database, logs and traces, backups, and any support tooling where provider staff see diagnostics.
Sovereignty and the US CLOUD Act
Sovereignty is about legal reach. The clearest example for Australian buyers is the US CLOUD Act. It added 18 U.S.C. 2713, which requires a provider of electronic communication service or remote computing service to preserve, back up or disclose data in its “possession, custody, or control”. The obligation applies “regardless of whether such communication, record, or other information is located within or outside of the United States.”
The test in the statute is control, and location does not decide it. A provider that is subject to US jurisdiction and controls data in Sydney is inside the scope of that section. Whether a particular provider, subsidiary or contract structure falls inside it is a legal question for your counsel. For the engineering design, an Australian region does not answer the sovereignty question, and a vendor that says it does is confusing residency with sovereignty.
Australian prudential rules make the same distinction. APRA CPS 230 defines offshoring by where the service is performed. The standard says that “Offshoring does not include arrangements where the physical location of a service is performed within Australia, but the service provider is not incorporated in Australia.” A US provider that runs your model in Sydney is therefore not offshoring under CPS 230. It is still a foreign legal entity, and your risk assessment must record that exposure under its own heading.
Operational control
Operational control is about who can technically reach the data. It comes down to two questions:
- Who holds the encryption keys, and can the provider use them without you?
- Which people outside your organisation can access the systems, and what approval do they need?
The large cloud providers publish controls here. AWS says that on its Nitro System “there is no mechanism for any system or person to log in to EC2 Nitro hosts” or to access instance memory. Microsoft offers Customer Lockbox for Azure, which gives your organisation an interface to approve or reject requests from Microsoft engineers to access customer data. Customer Lockbox needs an Azure support plan at Developer level or above.
These controls reduce operator access. They do not change the legal position in the sovereignty section. The statute tests control, and a provider that operates the key service and the hosts has a form of control. The strongest operational control is a deployment where your own staff hold the keys and run the hosts. That is the on-prem AI deployment model, and at the far end it is an air-gapped deployment.
What the Privacy Act requires
The Privacy Act does not ban offshore processing. It makes you accountable for it.
APP 8.1 applies before an APP entity discloses personal information to an overseas recipient. The entity must take reasonable steps to ensure that the recipient does not breach the APPs. Under section 16C, the OAIC guidelines on APP 8 say the entity “is accountable for an act or practice of the overseas recipient that would breach the APPs”. The act is treated as if your organisation did it.
The same guidelines (paragraph 8.14) describe when giving data to an overseas cloud provider is a “use” rather than a “disclosure”. This applies when the entity “does not release the subsequent handling of personal information from its effective control”. The OAIC example is a provider that only stores the data. A binding contract limits the provider to that purpose and binds subcontractors to the same terms. The entity keeps control of access, change, retrieval and deletion. An inference API that processes prompts, runs abuse classifiers and retains flagged content for review does more than store. You must assess it against the full APP 8 test rather than assume the storage example covers it.
APP 11.1 requires an entity that holds personal information to take reasonable steps to protect it. The protection covers misuse, interference and loss, and unauthorised access, modification or disclosure. APP 11.2 requires destruction or de-identification when the entity no longer needs the information. Both apply to every copy that an AI system makes, which includes log stores and vector indexes.
The OAIC also published guidance on commercially available AI products. It says that privacy obligations apply to personal information put into an AI system and to output that contains personal information. It includes inferred or incorrect information about an identifiable person, such as a hallucination. As best practice, it recommends that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools.
APRA CPS 234 and CPS 230
For banks, insurers and super funds, two prudential standards apply to an AI service provider.
CPS 234 covers information security. Where a related party or third party manages information assets, the regulated entity “must assess the information security capability of that party, commensurate with the potential consequences of an information security incident affecting those assets.” A footnote makes clear that this applies to all information assets that third parties manage, not only those under outsourcing agreements. Prompts, retrieval indexes and fine-tuning datasets are information assets, and the AI provider manages them.
CPS 230 covers operational risk and service providers. Material service providers are “those on which the entity relies to undertake a critical operation or that expose it to material operational risk.” The entity must keep a register of them and submit it to APRA every year. Before it enters into a material arrangement, it must assess risks that include “geographic location or concentration of the service provider(s) or parties the service provider relies on”. It must notify APRA before it enters into any material offshoring arrangement. The standard says this includes cases “where data or personnel relevant to the service being provided will be located offshore.”
For an AI service, a global routing option that can process prompts outside Australia can turn an onshore arrangement into an offshoring arrangement. Offshore support staff or offshore abuse reviewers can do the same, even when the model runs in Sydney.
The Hosting Certification Framework
The Hosting Certification Framework (HCF) is an Australian Government framework, administered by the Department of Home Affairs. It applies to Australian Government customers that procure hosting for sensitive government data, whole-of-government systems and systems rated at PROTECTED. Under the framework, those systems must be hosted with certified services. It currently applies only to data centre providers and cloud service providers.
The HCF has three levels. Strategic certification is “only available to Service Providers that allow the government to specify ownership and control conditions.” Assured certification gives safeguards against a change of ownership or control through financial penalties. Uncertified providers offer minimal protections to government.
Private companies do not have to use the HCF. It is still a useful filter, because its tests are about ownership, control and supply chain, which are sovereignty and operational control questions. As of October 2026, the HCF site says the framework is under reform. The Department paused registration of new providers from 3 November 2025.
Prompts, embeddings, logs and fine-tuning data
Each data type in an AI system needs its own answer on all three guarantees:
- Prompts and completions. These are processed at the model endpoint, and some providers retain a part of them for abuse monitoring. Find out where that retained copy lives, for how long, and who can review it.
- Embeddings. An embedding is a list of numbers that a model computes from a passage of text. A common RAG design stores the source passage next to the vector. In that design, the index holds the same personal information as the documents. Apply APP 11 retention and deletion to the index as well as to the source files.
- Logs and traces. LLM tracing tools such as Langfuse record the prompt and the response as part of each trace. If the trace store is a SaaS product in another country, it is an overseas disclosure even when the model is onshore.
- Fine-tuning data and adapters. Training data is a curated copy of your most useful records, and a fine-tuned model can reproduce parts of its training data in its output. Treat both the dataset and the trained weights as information assets under CPS 234. The guide on fine-tuning vs RAG covers when that risk is worth taking.
Guarantee vs what provides it
| Guarantee | Provided by | Not provided by |
|---|---|---|
| Residency of storage | Region selection, storage location clauses, backup location settings | A marketing page that says “Australian hosted” |
| Residency of processing | In-region endpoints or a geography profile limited to Australian regions, checked with the provider’s routing API | Global routing options, or a geography that spans several countries |
| Residency of retained copies | Written retention terms for abuse monitoring and support data, with location stated | The default terms of a service that retains flagged prompts |
| Sovereignty | A provider whose controlling entities are outside foreign compelled-disclosure laws, or infrastructure you own | An Australian region of a provider that is subject to foreign jurisdiction |
| Operational control of keys | Keys you generate and hold in your own HSM, or self-hosted inference | Provider-managed keys, and customer-managed keys inside a key service the provider operates |
| Operational control of access | Your own staff operate the hosts, or approval workflows for provider access with logs you can export | A policy statement without logs or approvals |
| Privacy Act accountability | APP 8 due diligence, contract terms, APP 11 controls on every copy | Assuming storage-only “use” treatment for an inference service |
| APRA compliance | CPS 230 register entry, offshoring notification where required, CPS 234 capability assessment | Treating the AI vendor as a software licence with no service provider assessment |
What to decide next
Start with an inventory of every place your AI system writes data: the endpoint, the retained abuse monitoring copy, the vector index, the trace store, backups and the fine-tuning bucket. For each one, record the location, the legal entity that controls it, and who holds the keys. Then decide which of the three guarantees each workload needs. Some internal workloads need residency and APP 8 diligence only. Workloads with health data, client money records or defence information can need sovereignty and operational control as well. In practice, that means self-hosted models in an environment you run. The private LLM deployment architecture article shows what that environment looks like.
If you want help to map these obligations to a specific system, see our AI strategy and readiness audit.