Healthcare data sovereignty in Australia and New Zealand
What regional cloud actually unlocks for clinical AI
Most "is our AI compliant" conversations in Australian and New Zealand healthcare are answered too quickly. Someone asks where the data lives, gets told it's in an in-country region, and the project moves on. That answer is necessary, but it is not sufficient. Clinical AI does not have a single sovereignty decision. It has four, and each one needs its own answer before a regulator, an accreditor, or an Indigenous data governance body will be satisfied.
This post walks through those four layers, what's changed now that hyperscale cloud and foundation models both run in-country across ANZ, and where most projects under-invest.
The shift that makes this conversation urgent
For most of the last decade, "AI in the cloud" effectively meant "data leaves the country." That trade-off is now optional. Australia has had in-country AWS, Azure, and Google Cloud regions for years. New Zealand's AWS Auckland region (ap-southeast-6) launched in 2024, with Azure following. Foundation model services, FHIR-native data stores, and embedding APIs increasingly run in those same regions.
That sounds like a clean win, and in many ways it is. But the move from "no in-country option" to "multiple in-country options" surfaces a harder question: what does sovereignty actually mean for a generative AI workflow that spans storage, retrieval, inference, embedding, and audit, each of which could in principle be in a different jurisdiction?
In Australia, the answer matters under the Privacy Act 1988 and the Australian Privacy Principles (APPs), the My Health Records Act, and the Therapeutic Goods Administration's evolving treatment of AI as software as a medical device. In New Zealand, it matters under the Privacy Act 2020, HISO standards, and the Te Mana Raraunga principles of Māori Data Sovereignty. In both countries, the regulatory direction is the same: more scrutiny, more documentation, more accountability for where data goes and who can see it.
The four sovereignty layers
Layer 1: Storage residency
Where do the patient records physically live?
This is the layer most teams answer correctly. The FHIR store, the object storage holding clinical documents, the database holding identifiers: all of these should be in a region inside the country whose patients you serve. AWS HealthLake is one example of a managed, HIPAA-eligible FHIR-native store that can be deployed regionally. The Australian and New Zealand regions both qualify.
The question to ask is not just "is the primary copy in-country?" but "are all replicas, backups, and disaster recovery copies in-country, and can we prove it?" Replication policies that quietly span regions are a common failure mode.
Layer 2: Inference residency
Where does the foundation model run when it processes that data?
This is the layer most teams answer incorrectly, or do not answer at all. A FHIR store in Sydney does not mean much if every clinical summary request sends the patient context to a model endpoint in Virginia. The data has, for all practical purposes, left the country.
Inference residency depends on which models are available in which regions. Foundation model availability moves fast, and what was true six months ago is often no longer true. Before signing off an architecture, confirm that the specific models you intend to use are available in the same region as the FHIR store, and that fallback or burst capacity does not silently route requests offshore.
Layer 3: Embedding residency
Where are vector embeddings generated, and where are they stored?
Embeddings are derived data, but for clinical content they retain enough signal to be considered protected health information under most reasonable interpretations of privacy law. If a patient's clinical notes are vectorised by a service in another region, those vectors are an extract of the original record, sitting outside the jurisdiction of the source data.
The vector database itself is also part of this layer. Many open-source and managed vector stores can be deployed in-country, but some default deployment patterns place them in the closest available region, which is not always the right one.
Layer 4: Audit and logging
Where do the prompts, responses, and access logs land, and who can read them?
Every clinical AI workflow generates logs: the question the clinician asked, the context retrieved, the response generated, the user who triggered it. These logs are often more revealing than the underlying data, because they reveal not just what was in the record but what someone wanted to know about it.
Logs frequently land in the same region as the service that generated them, which means they can end up offshore even when the patient data did not. They are also frequently accessible to support staff and platform operators who sit in yet another jurisdiction. Both points deserve explicit attention in an architecture review.
The Indigenous data sovereignty layer that sits underneath all four
In New Zealand, none of the four layers above are sufficient on their own. Te Tiriti o Waitangi and the Te Mana Raraunga principles of Māori Data Sovereignty treat Māori data as a taonga (a treasure) that requires Māori governance and partnership. Te Whatu Ora Waitematā has published a working AI governance framework that embeds Māori Data Sovereignty principles into model development, validation, and ongoing oversight, with consideration of individual and collective benefits and respect for Māori knowledge and protocols.
What this means in practice: residency alone does not satisfy MDS. A foundation model running in Auckland that was trained on data and assumptions from elsewhere may still produce outputs that are inappropriate, biased, or culturally unsafe. Sovereignty in the NZ context includes who governs the model, who validates its outputs, and whether Māori communities have meaningful input into how their data is used.
Australia has parallel considerations under the CARE Principles for Indigenous Data Governance (Collective benefit, Authority to control, Responsibility, Ethics), particularly for any AI workflow touching Aboriginal and Torres Strait Islander health data. These are not optional considerations to address later. They shape the architecture and the governance from the start.
What this means for an architecture review
A useful exercise: take any proposed clinical AI workflow and answer four questions before approving the design.
Storage: Where is the patient data, including all replicas and backups? Can we prove it stays there?
Inference: Where does the model that processes this data run? Is that region locked, or could it shift under load?
Embeddings: Are vectors generated and stored in the same region as the source data? Is the vector store in-country?
Logging: Where do prompts, responses, and access logs land? Who can read them, and under whose jurisdiction?
If any of the answers are uncertain, the architecture is not finished. For New Zealand workflows, add a fifth question: how does this design honour Te Tiriti and Māori Data Sovereignty principles, and who has been consulted?
The opportunity hiding inside the constraint
Sovereignty requirements are often framed as friction. They are, in fact, an advantage for ANZ healthcare providers and the technology partners who serve them. Offshore platforms targeting Australian and New Zealand clinicians cannot easily satisfy all four layers without significant re-architecture. In-country builds, designed properly from day one, can.
The opportunity is to treat sovereignty as a design principle rather than a checkbox. Get the four layers right, document them clearly, and the result is an AI system that can be presented to a hospital board, a privacy commissioner, a TGA reviewer, or a Māori Data Sovereignty governance group with confidence.
That is what regulator-ready AI looks like in the ANZ healthcare market. Not a marketing claim, but a stack.
Easycoder is an AWS Advanced Partner working with regulated industries across Australia and New Zealand on cloud, AI, and regulatory technology. If you are designing a clinical AI workflow and want a second pair of eyes on the sovereignty stack, get in touch.
