How can an Australian regulated enterprise run AI while keeping data onshore and under Australian jurisdiction?
Run AI in a deployment you control - on-premises, in a private cloud in an Australian region, in Kubernetes or air-gapped - so prompts, outputs, embeddings and logs stay physically in Australia (data residency) and remain governed only by Australian law and courts (data sovereignty), instead of being disclosed to a foreign-hosted model. Onshore storage alone is not enough: a US-controlled provider can be compelled under the US CLOUD Act regardless of where the servers sit, so true sovereignty depends on who controls the system, not just where the disk lives.
Two concepts are routinely conflated and must be separated. Data residency answers where data is physically stored and processed - for example, in an Australian cloud region or your own data centre. Data sovereignty answers whose laws and courts govern that data, and which foreign governments can compel access to it. Data hosted in Sydney but operated by a foreign-controlled entity has Australian residency but contested sovereignty, because the US Clarifying Lawful Overseas Use of Data (CLOUD) Act, enacted in March 2018, lets US authorities compel US-based providers to produce data they hold or control "regardless of whether" it is stored inside or outside the United States. For a deeper treatment see what data residency for AI means.
The compliance stakes are concrete. Under Australian Privacy Principle 8 (APP 8) and section 16C of the Privacy Act 1988, an APP entity that discloses personal information to an overseas recipient is generally accountable for the recipient's acts and practices as if it had done them itself. Routing personal data to a US-hosted large language model is therefore not a neutral technical choice - it is a cross-border disclosure that imports APP 8 liability. For Australian government workloads, the Australian Signals Directorate's Information Security Manual (ISM) and the Protective Security Policy Framework (PSPF) add explicit data-residency and sovereignty expectations, assessed through the Infosec Registered Assessors Program (IRAP).
This page is the operational guide for CISOs, CIOs, government CTOs and Data Protection Officers: it separates residency from sovereignty, sets out the legal exposure, walks the deployment spectrum from public SaaS to air-gapped, and shows how a privately deployable secure AI control plane such as Areebi keeps the entire AI data path inside Australian jurisdiction - without overclaiming what any single product can certify.
What is the difference between data residency and data sovereignty for AI?
Data residency is a question of geography; data sovereignty is a question of jurisdiction and control. An AI deployment can satisfy residency while failing sovereignty, and for regulated Australian data the sovereignty test is the one that determines real exposure.
- Data residency - where data physically lives. An AI service has Australian residency if prompts, model outputs, vector embeddings, fine-tuning data and logs are stored and processed in Australian-based infrastructure (for example, an Australian cloud region or an on-premises data centre).
- Data sovereignty - whose law governs it and who can compel access. Data is sovereign to Australia when it is subject only to Australian law and Australian courts, and is not reachable by a foreign-government access power exercised against the operator.
The gap between the two is the heart of the sovereign-AI problem. A hyperscaler region in Sydney gives you residency. But if the operating entity is subject to the US CLOUD Act, a US warrant can compel production of data that entity holds or controls, even though the bytes never leave Australia. The CLOUD Act also created a framework for bilateral data-access agreements, and the Australia-United States CLOUD Act Agreement, signed in December 2021, formalises cross-border requests for serious-crime investigations. None of this is unlawful - it simply means foreign-government access is a live risk that residency alone does not extinguish.
For AI specifically, the data that must stay sovereign is broader than most teams assume. It includes the prompt (which often carries the most sensitive context an employee can paste), the completion/output, the embeddings and vector store built from your documents (embeddings can be inverted to reconstruct source text), any fine-tuning or training data, and the interaction logs. If any of these flows to a foreign-controlled model endpoint, you have made a cross-border disclosure of everything they contain. Keeping all five inside a deployment you control is what makes an AI deployment genuinely sovereign rather than merely onshore.
How does Australian Privacy Principle 8 (APP 8) apply when you send personal data to an overseas AI model?
Sending personal information to an overseas-hosted AI model is a cross-border disclosure under APP 8, and section 16C of the Privacy Act 1988 then makes you - the disclosing entity - accountable for the overseas recipient's handling of that information as if you had done it yourself. A foreign LLM provider's breach becomes your breach.
The mechanics, per the OAIC's APP Guidelines Chapter 8 (updated October 2025):
- APP 8.1 - the reasonable-steps obligation. Before an APP entity discloses personal information to an overseas recipient, it must take steps that are reasonable in the circumstances to ensure the recipient does not breach the APPs in relation to that information.
- Section 16C - the accountability rule. Where an entity discloses personal information overseas, an act or practice of the overseas recipient that would breach the APPs "is taken to have been done by the APP entity and to be a breach of the APPs by that entity" (s 16C(2)). You remain liable even if you took reasonable care.
- Disclosure vs use. APP 8 bites on disclosure - releasing information from your effective control. Where you retain effective control (for example, the data stays inside infrastructure you operate and govern), the activity is closer to a use, which does not trigger the cross-border accountability rule in the same way. Self-hosting is precisely the architecture that keeps an AI workflow on the right side of that line.
- The 'Australian link' and other exceptions. Accountability under s 16C does not apply where the recipient has an "Australian link" (so the Privacy Act covers it directly), or where a listed APP 8.2 exception applies, including binding informed consent or a substantially similar overseas law with enforceable rights. Consent is narrow and must be specific - it is not a scalable basis for routine AI use.
The reform direction reinforces this. The Privacy and Other Legislation Amendment Act 2024 introduced a statutory tort for serious invasions of privacy and strengthened enforcement, and tougher cross-border and automated-decision rules continue to move through the reform program - see automated-decision transparency obligations under the Privacy Act and Australia's AI governance landscape. The practical CISO takeaway is unchanged: the cleanest way to manage APP 8 exposure for AI is to not disclose personal information offshore at all, by keeping the model and the data inside an Australian deployment you control.
What do the ISM, PSPF and IRAP require for AI data residency in Australian government workloads?
Australian government and government-adjacent AI workloads must run in environments that meet ISM and PSPF data-residency and sovereignty expectations and are assessed under IRAP - which in practice means keeping classified and sensitive data, including AI prompts, outputs and logs, in approved onshore environments under Australian control. A public, foreign-hosted AI endpoint will not meet these expectations for protected-level workloads.
The Information Security Manual (ISM)
The ASD Information Security Manual is the cyber-security framework government systems are built and assessed against. Its controls address where data may be stored and processed, who may access it, and the assurance required before sensitive or classified information is handled in cloud or third-party services - directly engaging the residency and sovereignty of any AI service in scope.
The Protective Security Policy Framework (PSPF)
The PSPF (Release 2025) sets what Commonwealth entities must do to protect people, information and assets. Information-security policy under the PSPF governs classification and handling, including constraints on offshore storage and access to sensitive and classified information - constraints that an AI deployment must inherit rather than bypass.
The Infosec Registered Assessors Program (IRAP) and hosting certification
IRAP, administered by ASD, endorses assessors who evaluate systems against the ISM and PSPF; the IRAP program is how government gains assurance that a cloud or on-premises service - including an AI platform - meets the controls for a given classification, with the IRAP Common Assessment Framework v1.0, released in April 2025, standardising the assessment methodology. Hosting and data-residency assurance is reinforced by the Hosting Certification Framework, which helps agencies source providers meeting enhanced privacy, sovereignty and security requirements. Where data storage and processing services support government, the Security of Critical Infrastructure Act 2018 (SOCI) can also apply; the SOCI amendment Act that received Royal Assent on 29 November 2024 clarified that data storage systems holding business-critical data form part of a critical infrastructure asset, bringing risk-management-program obligations to that data.
For AI, the consequence is that the model, its inference endpoint, the vector store and the logs all fall inside the assessed boundary. Running them in an IRAP-assessable, ISM/PSPF-aligned, Australian-resident environment - rather than calling out to a public foreign API - is what keeps a government AI deployment within policy. Sibling guides cover Australia's AI governance landscape and the Voluntary AI Safety Standard in more depth.
What is the deployment spectrum from public SaaS to air-gapped, and where does data leave Australian jurisdiction?
AI deployment runs on a spectrum of decreasing data exposure - public SaaS, then private cloud in an Australian region, then on-premises, then air-gapped - and the perimeter your data crosses gets smaller at each step. The choice is a direct trade-off between convenience and sovereignty, and regulated data generally belongs from the private-cloud step rightwards.
- Public SaaS AI (data leaves your perimeter). Prompts, outputs and often training signal are sent to a provider-operated, frequently foreign-controlled endpoint. This is the highest-exposure pattern: it can be a cross-border disclosure under APP 8, may breach ISM/PSPF residency expectations for government, and exposes data to foreign-government access powers such as the CLOUD Act. It is also where most shadow AI lives - employees pasting sensitive data into consumer tools the organisation never approved.
- Private cloud in an Australian region. The AI stack runs in your own tenancy in an Australian-resident cloud environment. This delivers residency and materially better control, but sovereignty still depends on the operator's jurisdiction and contractual access terms - assess foreign-government access risk explicitly.
- On-premises. Models and the control plane run in infrastructure you own and operate in Australia. Data residency and sovereignty are both strong because you control the hardware, the network boundary and the access path; foreign-government compulsion has no domestic operator to target.
- Air-gapped. The AI environment has no connection to external networks. This is the maximum-assurance pattern for the most sensitive classified, defence or critical-infrastructure workloads, where even outbound telemetry is unacceptable.
Self-hosted / sovereign deployment spans steps 2 to 4. Running the AI control plane and models via Docker, Kubernetes, on-premises or private cloud in Australian regions keeps prompts, outputs, embeddings and logs within Australian jurisdiction by design - nothing is disclosed to an external model unless you explicitly choose it, under policy. This is the architecture that converts the legal requirements above into an operating reality, and it is the deployment model Areebi is built for.
Why is sovereign AI now a national priority in Australia (2025-2026)?
Sovereign AI moved from a procurement preference to a national-strategy priority in 2025-2026, as Australia published a National AI Plan focused on sovereign compute and attracted record sovereign-AI infrastructure investment - giving regulated enterprises both the policy direction and the onshore capacity to keep AI workloads in-country.
On 2 December 2025 the Department of Industry, Science and Resources released the National AI Plan, its most comprehensive AI strategy to date. The Plan explicitly backs smart infrastructure, national data-centre principles and sovereign compute capability, signalling that large AI users may be encouraged to locate compute in Australia to meet sovereignty and security expectations, and consolidating more than A$460 million in existing AI-related funding alongside a new AI-focused Cooperative Research Centres round. Importantly, the National AI Plan confirmed that Australia will rely on its existing laws and sector regulators rather than introduce the previously proposed mandatory AI guardrails - Australia has not legislated mandatory, AI-specific guardrails. The Government separately published national expectations for data centres and AI infrastructure developers on 23 March 2026, foregrounding national security and data sovereignty.
The private-sector build-out is on the same trajectory. Microsoft announced a A$25 billion investment to expand AI and cloud infrastructure in Australia by the end of 2029, including new Azure AI capacity and deeper collaboration with the ASD (announced 23 April 2026), and Amazon committed A$20 billion to Australian data centres over 2025-2029. This is why sovereignty is now achievable in practice: the onshore compute exists. The strategic point for a CISO is that keeping AI sovereign no longer means sacrificing capability - and aligning to this direction now is both a compliance posture and a procurement advantage. See the macro analysis in Australia's AI governance landscape.
How does Areebi help an Australian enterprise deploy sovereign, self-hosted AI?
Areebi is a secure AI control plane that you deploy entirely inside your own Australian environment - via Docker, Kubernetes, on-premises or private cloud - so prompts, outputs, embeddings and logs stay in Australia and under Australian jurisdiction, while DLP, policy, guardrails and immutable audit are enforced at the inference boundary. It is the architecture that makes the residency and sovereignty requirements above operational, rather than aspirational.
Because Areebi is privately deployable and model-agnostic, the same control plane governs self-hosted open models and any external API you explicitly permit - so you can keep the highest-sensitivity workloads fully in-jurisdiction while still using commercial models under policy where the data classification allows. Nothing is disclosed to an external model unless your policy says so. The honest control mapping:
- Private, sovereign deployment (Docker, Kubernetes, on-premises, private cloud in Australian regions) keeps the entire AI data path - prompts, outputs, embeddings, logs - resident in Australia and under your control, directly addressing APP 8 cross-border disclosure and ISM/PSPF residency expectations.
- Real-time DLP inspects prompts and responses to stop personal and sensitive information leaving the perimeter via inference, reducing the cross-border-disclosure surface even when an external model is permitted. See what AI DLP is.
- The policy engine applies machine-readable rules at the point of use - for example, blocking classified or personal data from any non-sovereign destination.
- Guardrails defend the inference boundary against prompt injection, jailbreaks and unsafe output.
- Shadow-AI discovery and inventory surfaces unsanctioned public-SaaS AI use so you can move it onto the sovereign path.
- Access control governs who can reach which model and data set.
- Immutable audit logging keeps a tamper-evident, in-jurisdiction record for assurance, IRAP assessment and incident response.
On assurance, accuracy matters: Areebi is currently progressing SOC 2 readiness and is not yet certified, and we make no claims of named customers, audited metrics, IRAP assessment or certifications we do not hold. Areebi provides the architecture and controls; your own IRAP assessment, privacy impact assessment and accreditation remain yours to complete. Explore the platform overview, the government solution, or book a demo to see a sovereign deployment.