# What data sovereignty actually requires

> Data sovereignty means patient information stays within Australian jurisdiction across its whole lifecycle — storage, processing, backup and any third-party service it passes through. Claiming an Australian region for the primary database is the easy part. The paths that matter are backups, subprocessors, support access, and, for AI systems, what is sent to a model provider.

*Source: https://getpathways.ai/insights/what-data-sovereignty-requires*

Every health-tech vendor selling into Australia says their data stays in
Australia. Most of them mean it. The claim is still worth interrogating,
because "hosted in Australia" describes where a database sits, and sovereignty
is a property of every path the data can take.

For a procurement officer, the difference between those two things is the
difference between a statement and an assurance.

## The paths that get overlooked

Primary storage is the part everyone gets right, because it is the part
everyone asks about. Underneath it sit four routes that are easier to miss.

**Backups and disaster recovery.** A primary region in Sydney with replication
to a secondary region elsewhere is not sovereign. This is easy to configure
accidentally, because cross-region replication is a sensible default for
durability and is often enabled without a specific decision.

**Processing, not just storage.** Data at rest in Sydney can still be processed
somewhere else — a job queue, a search index, an analytics pipeline. Storage
location and processing location are separate facts and need separate answers.

**Subprocessors.** Error monitoring, logging, session replay, email delivery,
customer support tooling. Each is a service the data passes through, and each
has its own region. A vendor whose own infrastructure is entirely Australian
can still be exporting patient data through a logging provider.

**Support access.** Where an engineer sits when they open a production console
is a jurisdictional question, whatever the region the data is stored in.

None of these is exotic and none implies bad faith. They are the ordinary
consequences of assembling a modern application from services, and they are why
"where is it hosted" is a weaker question than it sounds.

## The path specific to AI systems

Then there is the one that did not exist a few years ago and now dominates the
assessment: what is sent to a model provider.

If a system uses a large language model to conduct an interview, read a
medication photograph, or summarise a history, that content leaves the
application. Where it goes, what is retained, and whether it is used for
training are three separate questions, and a vendor can answer one well while
being vague on the others.

There are two guarantees worth insisting on, because they fail independently:

**Identity.** Is personally identifying information sent to the model provider
at all? De-identifying the content before it leaves means the provider never
receives a named patient record, which changes the exposure from a
jurisdictional problem into a much narrower one.

**Training.** Is the content used to train models? This is a separate
commitment, and it is the one where contractual terms matter more than
architecture — because unlike de-identification, you cannot verify it from the
outside.

## The architectural answer that removes the question

For the parts of a clinical system that matter most, there is a stronger
position available than a good answer about model providers: not involving one.

Safety-critical screening — an unwithheld SGLT2 inhibitor, poor glycaemic
control, an untreated sleep apnoea screen — can be implemented as deterministic,
versioned rules operating on structured findings. Rules of that kind do not
call a model. They execute locally, in the same jurisdiction as the data, and
they produce the same output every time.

That is worth stating plainly because it changes what the sovereignty question
applies to. Models are used where the input is unstructured and brittle rules
genuinely fail: conducting a conversational interview, reading handwriting on a
pharmacy label, turning narrative into structured findings. Their output is an
input to the rules, never a substitute for them.

So the surface area exposed to a model provider is narrower than "the clinical
system", and the part of the system a governance committee is most concerned
about is the part that never leaves.

## Questions worth asking any vendor

Sovereignty is best assessed by asking about paths rather than about location:

- In which region is patient data stored, and where do backups and any replicas
  live?
- Where is it processed, as distinct from stored?
- Which subprocessors touch it, and in which jurisdictions do they operate?
- From where can your staff access production data, and is that access logged?
- Is any personally identifying information sent to a model provider?
- Is patient content used to train models, by you or by anyone you use?
- Which parts of the clinical logic involve a model at all?

A vendor who has thought about this will answer each one specifically. One who
has not will re-answer the first question several times.

## Where Pathways sits

For completeness, the same answers for Pathways: all patient data is stored in
AWS Sydney (ap-southeast-2) and is not transferred outside Australia in
storage, processing or backup. No personally identifying information is sent to
model providers, and patient information is not used to train models. Extraction
and reasoning operate on de-identified clinical content. The safety-critical
screening rules are deterministic and versioned, so they do not involve a model
provider at all, and every output records the rule version that produced it.

The full control set, and the governance pack for procurement review, are on the
[security page](/security).