Insights · Platforms
Where your AI data can live.
Most residency requirements are written as one sentence and cash out as four different architecture decisions. Here is what the law actually asks, and where AI breaks the usual answers.
Almost every Australian data platform project hits a sentence like "our data must stay in Australia." It arrives from legal, or from a board paper, or from a customer contract, and it is treated as a single constraint with a single answer: pick the Sydney region.
It is not one constraint. It is at least four, they have different legal bases, and AI workloads break the usual answers to three of them. Untangling it early is cheap. Untangling it after the platform is built is not.
The four questions hiding inside "data residency".
- Where is it stored? Which region the bytes sit in at rest. This is the one everybody means, and the easiest to satisfy.
- Where is it processed? Where compute runs against it, which is not automatically the same region, particularly for managed services with global control planes.
- Who can access it? Whether vendor support staff overseas can reach it during an incident. This is the one that fails audits, because the answer is often yes and undocumented.
- Whose law applies? Which jurisdiction can compel disclosure, which follows the provider's corporate nationality rather than the data centre's postcode.
The first is residency. The fourth is sovereignty. They are routinely conflated, and an organisation that has satisfied the first while believing it has satisfied the fourth has a gap it cannot see.
What Australian law actually requires.
Less than most people assume, with sharp exceptions.
The Privacy Act does not mandate onshore storage. Australian Privacy Principle 8 takes a different approach: if you disclose personal information to an overseas recipient, you remain accountable for their handling of it unless a narrow exception applies. The obligation is accountability, not location. You may store personal information overseas, and you carry the consequences of how it is handled there.
APRA does not mandate onshore either, and does require you to know. CPS 234 obliges regulated entities to maintain information security capability commensurate with vulnerabilities and threats, including where information assets are managed by third parties, and to notify APRA of material information security control weaknesses. CPS 230 extends the obligation to operational risk and service provider management more broadly. Neither says "keep it in Australia." Both make an unmapped offshore dependency a reportable problem. Our CPS 230 guide covers the service provider side.
Some regimes are absolute. My Health Record data must not be held or taken outside Australia. Certain Commonwealth and state government classifications impose onshore hosting and onshore personnel requirements, and several state jurisdictions add their own layer on top of the Commonwealth position. The Victorian layer in particular catches organisations that assumed the Commonwealth answer was the whole answer, which we have written about in data governance in Melbourne.
Your contracts may be stricter than the law. In practice this is the binding constraint more often than legislation. Customer agreements, particularly with government and financial services buyers, frequently impose onshore storage and onshore support. Read them before you design, because they are the requirement you cannot argue with.
Where AI breaks the usual answers.
A conventional data platform can satisfy residency by choosing a region. AI workloads introduce four paths that leave it, and three of them are easy to miss.
Inference is a disclosure. If a prompt containing personal information is sent to a model hosted overseas, that is a cross-border disclosure of personal information, and APP 8 applies. Whether the provider retains the prompt is a separate question about training and retention, and it does not undo the disclosure. Australian-region model endpoints exist across the major providers, but not every model is available in every region, and teams default to whichever endpoint is convenient.
Embeddings and vector stores are personal information. An embedding derived from a customer record is not anonymised by being a vector. Treat the vector store as holding the underlying data class, and site it accordingly. This is the most common gap we see in retrieval-augmented systems built quickly.
Fine-tuning moves the data twice. Once when the training set is transferred, and again in the sense that the resulting model weights are derived from it. Where the tuned model is hosted, who can access it, and what happens to it at contract end are all residency questions.
Logging leaks. Prompt and response logs, evaluation traces, and monitoring telemetry routinely go to a different service from the one processing the data, often in a different region, often configured by default. The model inference was compliant and the observability stack was not.
What this means for the platform.
Residency is a data-class decision, not a platform decision, and the platform has to be able to express it.
- Classify before you architect. Three or four classes is enough for most organisations: personal information, regulated or contractually restricted data, commercially sensitive data, and everything else. Each class gets an explicit residency and sovereignty position, written down.
- Make the boundary a property of the data, not of the environment. A platform where restricted data is identifiable and its movement is controlled by policy will survive a new requirement. One where restriction is enforced by "that data lives in the other account" will not, because the classes always end up needing to be joined.
- Pin regions explicitly, everywhere. Storage, compute, model endpoints, vector stores, logs, backups, and the disaster-recovery copy. The DR copy is the classic miss: the primary is onshore and the replica is wherever the default put it.
- Document support access. Which vendor staff, in which countries, can reach production during an incident, and under what break-glass process. If you are APRA-regulated you will be asked. If you are not, your largest customer will be.
- Log the crossings. Every deliberate cross-border flow, with its legal basis and the mechanism relied on. This is the artefact that turns a claimed control into a demonstrable one, which is the distinction in asserted versus observed compliance.
The sovereignty question, honestly.
Storing data in an Australian region of a US-headquartered cloud satisfies residency. It does not make the data immune from US legal process, because that follows the provider's nationality rather than the data's location. For most commercial organisations this is an acceptable and widely accepted position, and saying so plainly in your risk register is better than implying a protection you do not have.
For the narrow set of workloads where it is not acceptable, the options are sovereign-certified offerings, Australian-owned providers, or on-premises, and each costs materially more and offers a narrower service catalogue, which in practice means fewer AI services. That is a real trade and it should be made deliberately for the specific data class that needs it, not applied across an entire platform because one class demanded it.
The expensive mistake is not choosing the wrong side of that trade. It is applying the strictest class's constraint to everything, which is how organisations end up unable to use the tooling their competitors use for data that never needed the protection. More on the governance side is on data governance consulting.
General information only, not legal or regulatory advice. Current as at September 2026.
