AI Data Sovereignty for Australian Government
Australian AI policy covers where data rests. Where inference runs is the gap. What crosses a border in a RAG call, and how to ask a supplier.
Jake Tracey3 August 2026AIGovernmentSecurity
Almost every sovereignty conversation in Australian government technology is a conversation about storage. Which data centre. Which cloud region. Which certification the facility holds. That question is well covered, well regulated, and largely settled.
The question that is not settled is where the model runs.
An agency can hold every document in a Sydney region, encrypted, on a certified platform, and still send the contents of those documents to a GPU in Virginia several hundred times a day. Retrieval-augmented generation works by pulling your content into a prompt and shipping that prompt to a model. If the model endpoint sits offshore, your sovereign storage is a filing cabinet with an international courier attached.
This page is about that gap: what the Australian rulebook actually says, what physically crosses a border during a single AI query, and the questions that separate a supplier who has thought about this from one who has not.
The rulebook covers rest, and it is starting to cover runtime
The instruments that Australian agencies work under were mostly written for hosting. A few have caught up.
| Instrument | What it governs | Does it reach where inference runs? |
|---|---|---|
| Hosting Certification Framework | Data centre providers and cloud service providers hosting sensitive government data | No. It applies only to those two categories, and certification registration has been paused since 3 November 2025 pending reform |
| ISM, Guidelines for procurement and outsourcing | Supply chain and service provider contracts | Yes. Control ISM-1572 requires that "the regions or availability zones where data will be processed, stored and communicated" are documented in the contract |
| DTA technical standard for government's use of AI | The full AI lifecycle, from design to decommission | Yes. Criterion 46, a recommended criterion under the data supply chain statement, asks for "data sovereignty controls and considerations including legal implications for geographic locations for data (including its metadata and logs) when at rest, in transit, or in use" |
| Agentic AI addendum, Statement AGT.4 | Routing and data flow management between agents | Yes. Criterion AGT.4.1 is a mandatory criterion, and the mechanisms it lists include "ensuring classifications and sovereignty controls are incorporated into agent-to-agent data exchange" |
| OAIC guidance on commercially available AI products | Personal information entered into, or generated by, an AI system | Indirectly, through APP 8 on cross-border disclosures |
| OVIC, AI and privacy obligations | Victorian public sector handling of personal information | Yes. IPP 9 limits transfer of personal information outside Victoria, and OVIC notes that cloud used to run AI systems may require personal information to be sent overseas |
Two of those deserve a closer read.
The ISM chapter is unusually direct about AI. It states that "outsourced artificial intelligence applications or cloud services may be located offshore and subject to lawful and covert data collection without their customers' knowledge", that offshore services carry jurisdictional risk because foreign laws can change with little warning, and that foreign-owned suppliers operating in Australia may still be subject to a foreign government's lawful access. It also requires under ISM-1073 that your systems are not administered by a service provider without a contractual arrangement, with the narrative noting the elevated concern when that access comes from outside Australian borders.
The DTA phrase to underline is "or in use". Data at rest and in transit are the familiar two states. In use means the moment the model is reading your prompt. That is inference. The standard also asks you to account for metadata and logs, which is where most real leakage happens.
Sitting above both, the Policy for the responsible use of AI in government version 2.0 took effect on 15 December 2025 and applies to all non-corporate Commonwealth entities, with some exceptions. It mandates accountable officials, an internal use case register, and a risk-based AI use case impact assessment commencing at design stage. It does not tell you where the model must run. It tells you that somebody has to be named as accountable for having answered the question. The national framework for the assurance of AI in government plays the same role across jurisdictions.
What actually crosses a border in a RAG call
Retrieval-augmented generation is not one movement of data. It is six or seven, and they can land in different countries.
| Step | What leaves your boundary | Commonly overlooked because |
|---|---|---|
| 1. Query embedding | The user's question, sent to an embedding model | The embedding model is often a different service, in a different region, to the chat model |
| 2. Vector search | The query vector, matched against your index | Managed vector databases default to a region chosen at signup, not at design |
| 3. Retrieval | Nothing yet, if the index is local | This is the only step most sovereignty claims actually cover |
| 4. Prompt assembly and inference | The retrieved source text plus the question, in full, to the model | This is the largest single disclosure in the whole pipeline |
| 5. Response | Generated text, which may contain personal information newly created by the model | OVIC treats generated content as a new collection of personal information |
| 6. Safety and abuse detection | Prompts and outputs, retained by the provider | Retention here is governed by the provider's terms, not your contract |
| 7. Logs, traces and evaluations | Prompt and response payloads in observability tooling | SaaS observability vendors are almost never in the sovereignty assessment |
Agentic systems multiply this. As the UK Government Digital Service sets out in its AI Insights note on agentic RAG, an agent plans, reflects, and issues follow-up queries until it is satisfied. Each iteration is another inference call carrying another slice of your corpus. A single user question can become a dozen border crossings. That is precisely why the DTA's agentic addendum asks for sovereignty controls inside agent-to-agent exchange rather than only at the system edge.
In-region is not the same as in-country
Here is the detail that most procurement documents miss, and it is documented by the vendors themselves.
Amazon Bedrock offers two forms of cross-region inference. Geographic inference profiles keep processing inside a geographic boundary such as US, EU or APAC. Global inference profiles route to "any supported AWS commercial Region worldwide", and AWS notes they are roughly ten per cent cheaper. The AWS documentation is explicit that with geographic routing, "by default the data remains stored only in the source Region, but your input prompts and output results might move outside of your source Region during cross-Region inference", and that where data is stored for abuse detection, prompts and outputs "will be stored in the destination region".
Read that against an Australian obligation. APAC is a geography, not a country. The APAC profile for Claude Sonnet 4, to take one published example, lists Tokyo, Seoul, Osaka, Mumbai, Hyderabad, Singapore, Sydney and Melbourne as destination regions, so a request made from Sydney can be processed in any of them. A system configured for APAC residency is not an Australian system. A system on a global profile is not a regional system at all. Both will be described in a proposal as "hosted in Australia", because the storage genuinely is.
Newer models narrow the choice rather than remove it. Claude Sonnet 4.5 carries an AU geography whose destination regions are Sydney and Melbourne, sitting in the same table as a global profile that is not bounded at all. Two strings in a configuration file, two very different answers to a residency question.
The other providers have equivalent mechanics under different names. The question is the same in every case: name the profile, and name every destination region it can reach.
Seven AI data sovereignty questions to put to a supplier
Ask these in writing, before shortlisting. The quality of the answer tells you more than any certification logo.
- Which region executes the model forward pass, for every request, including overflow and failover paths? A good answer names a region code and a routing profile. A weak answer names a country.
- Is the routing profile single-region, geography-scoped, or global? If the supplier cannot answer this in one sentence, they have not configured it deliberately.
- Where do prompts and outputs land for abuse detection, safety filtering or trust and safety review, and for how long? This is set by the model provider's terms, so the supplier has to have read them.
- Where does the vector index sit, and where does the embedding model run? These are frequently different regions to the chat model, and frequently different vendors.
- Where do logs, traces and evaluation datasets go, and who can read them? ISM-1573 requires contractual access to all logs relating to your data and services. Ask who else has that access.
- Which subprocessors can touch a request, and from which country do their staff administer the platform? ISM-1073 requires a contractual arrangement before a service provider administers your systems, and ISM-1576 requires that you are notified when that access happens without authorisation.
- What happens when the Australian endpoint is unavailable? A supplier who fails over offshore during an incident has a sovereignty posture that only holds on good days. A supplier who fails closed has made a real choice and should say so.
Then put the answers in the contract. The ISM already asks for this under ISM-1572, and the DTA's AI model clauses on BuyICT give Commonwealth buyers drafted terms covering approved AI use, underlying model transparency and restrictions on buyer data. In Victoria, Navigating AI in procurement goes further and recommends a schedule of permitted AI uses plus terms preventing suppliers from introducing new AI without approval. Our supplier guide to the VPS AI Assurance Framework covers what buyers will be asking you to evidence.
How we run it
Noice runs its own AI workloads on Amazon Bedrock in ap-southeast-2, the Sydney region, scoped to Australian inference rather than a global profile. We made that call for the reason above: it is the configuration where we can name the regions that execute the forward pass, and all of them are in Australia.
We are currently building the Knowledge Sharing Platform for the Victorian Collaborative Centre for Mental Health and Wellbeing, and we run the managed service behind the National Cancer Screening Register. Both sit in environments where the residency question is asked properly, by people who know the difference between storage and processing.
None of this makes offshore inference automatically wrong. Plenty of low-sensitivity use cases will never justify the cost of an in-country endpoint, and ASD's guidance on deploying AI systems securely is clear that mitigations should be adapted to the use case and threat profile. What is wrong is not knowing, or presenting sovereign storage as though it settles the question.
Where to go next
This page is part of our guide to agentic RAG for Australian government. If you are earlier in the process, start with RAG for government agencies for how retrieval works and where it fails. For the controls that sit around a deployed assistant, see securing AI assistants in government, and for the content side, AI knowledge management in government.
If you want the residency question answered against a specific architecture rather than in the abstract, that is what our AI for government practice does.
