What data sovereignty actually means
Data residency is a question of geography: which physical data centre holds the bytes. Data sovereignty is a question of law: whose legal system, and whose courts, can compel access to those bytes and govern how they are handled.
They are related, but they are not the same, and the gap between them is where most vendor answers quietly fall apart. Data can sit in a Sydney data centre and still be reachable by a foreign legal process if the operator, its parent company, or a subprocessor is subject to another country's jurisdiction. Equally, data can leave Australia lawfully and still be well protected — Australian law does not ban offshore processing, it makes you accountable for it.
Residency answers where the data sits. Sovereignty answers who can reach it, and under whose law. A vendor who only answers the first has not answered your question.
Sovereignty is therefore a stack of things, not a single tick: the storage region, the processing region, the corporate structure of the vendor and its subprocessors, the contractual commitments in place, and the technical controls — encryption, key custody, access logging — that determine who could read the data even if they obtained it.
What Australian law actually requires
The Privacy Act 1988 (Cth) and its 13 Australian Privacy Principles (APPs) are the core instrument. The OAIC describes the Act as regulating how Australian Government agencies and organisations with an annual turnover of more than A$3 million, and some other organisations, handle personal information; those entities are collectively known as "APP entities" (OAIC, The Privacy Act).
Note what the Act does not say: there is no general legal requirement that personal information about Australians be stored in Australia. Some sector-specific regimes do impose onshore-storage requirements — the My Health Records Act 2012 (Cth) restricts holding or taking those records outside Australia, and various government frameworks impose their own conditions — so check the rules for your sector — but for most Australian businesses the obligation is not "keep it onshore". It is APP 8.
APP 8: cross-border disclosure
APP 8.1 reads, in the words of the principle itself: "Before an APP entity discloses personal information about an individual to a person (the overseas recipient) … the entity must take such steps as are reasonable in the circumstances to ensure that the overseas recipient does not breach the Australian Privacy Principles (other than Australian Privacy Principle 1) in relation to the information" (OAIC, Read the Australian Privacy Principles).
The teeth are in section 16C. The OAIC's guidance states that "an APP entity that discloses personal information to an overseas recipient is accountable for any acts or practices of the overseas recipient in relation to the information that would breach the APPs (s 16C)" (OAIC, APP Guidelines Chapter 8, updated 3 October 2025).
In plain terms: if your AI vendor's overseas processing mishandles your customers' information, that is your breach as well as theirs. You cannot contract the accountability away by choosing a vendor and looking away.
Three points from Chapter 8 matter especially for software:
- An overseas office of the same entity is not an "overseas recipient." The OAIC notes that "where an APP entity in Australia sends information to an overseas office of the entity, APP 8 will not apply as the recipient is the same entity" — but a related body corporate outside Australia is a different entity, so APP 8 does apply.
- Routing is usually a "use", not a "disclosure." Chapter 8 says that "routing personal information, in transit, through servers located outside Australia, would usually be considered a 'use'." Transit alone is generally not the trigger; the trigger is the overseas party being able to access or modify the information.
- Handing data to an overseas contractor usually is a disclosure. "Where an APP entity engages a contractor located overseas to perform services on its behalf, in most circumstances, the provision of personal information to that contractor is a disclosure" — and where subcontractors may be engaged, reasonable steps extend to them too.
The exceptions
APP 8.2 lists the circumstances in which APP 8.1 does not apply. The two that a software buyer meets most often are the "substantially similar" test — where the entity reasonably believes the recipient "is subject to a law, or binding scheme, that has the effect of protecting the information in a way that, overall, is at least substantially similar to the way in which the Australian Privacy Principles protect the information", and that there are mechanisms the individual can access to enforce it — and informed consent, which requires the entity to expressly tell the individual that consenting means APP 8.1 will not apply, before they consent (APP 8.2, OAIC). Both are narrower than they sound, and neither is satisfied by a line in a privacy policy nobody reads.
Where the reform sits
The Privacy Act has been under reform for several years, so any statement about it needs a date attached. As at 23 August 2026, the OAIC's own History of the Privacy Act page carries this notice: "The OAIC is updating this page to reflect changes made by the Privacy and Other Legislation Amendment Act 2024, which affect the coverage of the Privacy Act 1988 and our privacy functions. Those changes commence on various dates set out in s 2 of the Amendment Act, with the majority of the amendments to the Privacy Act that are within the Information Commissioner's remit having commenced on 11 December 2024" (OAIC, History of the Privacy Act). The OAIC also notes on the Privacy Act page that "the Australian Government is conducting a review of the Privacy Act". Further tranches have been flagged; check the OAIC before relying on any summary, including this one.
Alongside the Act, the Notifiable Data Breaches scheme obliges covered entities to notify affected individuals and the Commissioner about eligible data breaches — which is the practical reason the sovereignty question is worth asking before an incident rather than during one.
Why AI tools make the question sharper
Traditional software has one obvious moment where data crosses a border: storage. You ask where the database lives, you get an answer, you move on. AI adds a second, far less visible moment — inference.
Every time an AI feature answers a question, summarises a document, transcribes a call, or generates a reply, the relevant content is sent to a model for processing. That model may run in a completely different region from the application, operated by a completely different company, under a completely different contract. The hosting region of the app tells you nothing about where the model runs.
A product can be honestly described as "hosted in Australia" while:
- calling a model API in the United States on every single request;
- using an Australian-hosted primary model but failing over to an offshore region when the local one is busy or a particular model is not yet available in-region;
- sending audio offshore for speech-to-text even though the transcript is stored onshore;
- routing a "small" side task — content moderation, embeddings, reranking, translation, safety classification — to a different provider entirely;
- shipping prompts and completions to a third-party observability or evaluation tool hosted overseas.
Each of those is a potential cross-border disclosure to an overseas recipient in the APP 8 sense, and under s 16C the accountability lands with the entity that disclosed. Retention compounds it: some model providers retain prompts for abuse monitoring for a period, which means the data is not merely passing through but sitting in an offshore system for days.
The regulator has noticed. The OAIC's guidance on commercially available AI products advises that "given the significant and complex privacy risks involved, as a matter of best practice it is recommended that organisations do not enter personal information, and particularly sensitive information, into AI chatbots" (OAIC, Guidance on privacy and the use of commercially available AI products). The same guidance stresses due diligence before adoption — whether the product has been tested for the intended use, how human oversight is embedded, and who will have access to personal information input into or generated by the product.
Which is exactly why the vendor conversation needs to get more specific than a hosting region.
Nine questions to ask any AI vendor
Ask all nine, in writing, and keep the answers. A vendor who can answer them quickly and specifically is a vendor who has thought about it. Vague answers here are the finding.
-
In which region is our data stored at rest — and is that the same region for every data type?
Databases, file storage, backups, logs, search indexes, and analytics often live in different places. "Australia" for the database and "US" for the logs is a common and unremarked split.
-
In which region does model inference run, and which company operates that model?
This is the question the hosting region does not answer. Ask for the provider name and the deployment region, not just the model name.
-
What happens when the in-region model is unavailable — does the request fail, queue, or fail over offshore?
Silent offshore failover turns a sovereign architecture into a non-sovereign one under exactly the load conditions where nobody is watching.
-
Which subprocessors touch our data, in which countries, and where is that list published?
Transcription, embeddings, moderation, email, telephony, error tracking, and analytics are all subprocessors. Under APP 8 the accountability for their handling can flow back to you.
-
Is our content used to train, fine-tune, or evaluate any model — yours or a third party's?
Distinguish a contractual commitment from an account setting. Settings can be changed; commitments have to be renegotiated.
-
How long are prompts, completions, and audio retained by each party, including the model provider?
Abuse-monitoring retention at the model provider is a separate clock from your retention policy, and it is usually the one nobody has read.
-
Who holds the encryption keys, and can you read our data if you choose to?
Provider-managed keys mean the provider can technically decrypt. Customer-managed keys change who can be compelled to hand over readable data.
-
Which foreign legal processes could compel disclosure, given your corporate structure and your subprocessors'?
This is the residency-versus-sovereignty question made concrete. An Australian data centre operated by a foreign-parented entity is a different legal posture from an Australian-parented one.
-
What do we get in writing — a DPA with residency terms, a subprocessor list, breach-notification timelines, and deletion evidence?
APP 8.1 requires “reasonable steps”. The OAIC’s Chapter 8 guidance discusses entering into enforceable contractual arrangements as one way an entity may take those steps; what is reasonable depends on the circumstances.
How NeoMind answers the nine
We publish our own answers because we think you should hold every vendor, including us, to the same nine questions. NeoMind is our AI teammate platform for Australian businesses.
-
1 · Storage region
NeoMind runs on Microsoft Azure Australia East (Sydney). Knowledge bases, conversation logs, and embeddings are stored in-region.
-
2 · Inference region and provider
Language models are run through Azure OpenAI Service — OpenAI's models operated by Microsoft inside Azure — with model inference run through Azure regions including Australia East.
-
3 · Failover behaviour
Where a specific model is not yet available in Australia, we route to the nearest geographically bound region with explicit data-residency commitments. We would rather tell you that plainly than claim an absolute that no AI platform can honestly make today. Ask us which models this currently affects.
-
4 · Subprocessors
Microsoft Azure is our infrastructure and model provider. Ask us for the current subprocessor position for the specific NeoMind teammates and channels you plan to use — telephony and messaging channels bring their own providers.
-
5 · Training on your data
Your content is read for retrieval, never used to train shared models. Azure OpenAI's commitment that customer data is not used to train models is contractual on Microsoft's side, not a toggle.
-
6 · Retention
You can export documents and conversations at any time. After cancellation, data is retained for 30 days, then permanently deleted from primary storage and backups.
-
7 · Encryption and keys
TLS 1.3 in transit and Azure-managed encryption at rest, with credentials held in Azure Key Vault. Customer-managed keys are available on the Enterprise plan.
-
8 · Legal posture
Neomeric Pty Ltd is an Australian company, registered and operated from Melbourne, with data, support, and operations in Australia. Our infrastructure provider, Microsoft, is US-parented — which is the honest answer to question eight, and the reason Enterprise customers can deploy NeoMind inside their own Azure tenant or on their own infrastructure instead.
-
9 · What you get in writing
Enterprise customers receive a Data Processing Agreement covering data residency, subprocessors, breach-notification SLAs, deletion procedures, and audit rights.
More detail on how NeoMind is built and hosted is on the NeoMind platform page, and our broader security posture is on our security page.