Sovereignty by design: hosting and the Privacy Act

The most frequent question we get from clinic directors isn’t about the AI, it’s about where the data lives. The answer is short: in the country where the clinic operates, on infrastructure that physically cannot cross borders.

The setup

• Australian clinics → sovereign Australian infrastructure
• United States clinics → US-based infrastructure
• United Kingdom clinics → UK-based infrastructure

Each country runs an independent deployment. There is no central data plane. There is no “sync to primary”. Logs, backups, recordings, transcripts: all stored in the same country. Hosting location is one claim; who can read the data, and from where, is a separate one, and both are set out below.

Enforced by infrastructure

This isn’t a policy we ask engineers to remember. The deployments are operationally separate: isolated accounts, separate networks, separate trust boundaries. A service running in the Australian region does not have credentials to read from the US region and vice versa. There is no path by which an engineer could move data across regions even if they wanted to.

When a customer provisions a new clinic, the region is fixed at provisioning. To move it would require an explicit data-migration request that triggers a documented procedure with the customer’s consent at every step.

What the Privacy Act actually requires

Australian Privacy Principle 8 governs the cross-border disclosure of personal information. Healthcare information attracts particular scrutiny under the Notifiable Data Breaches scheme (Part IIIC). A practical, defensible implementation is to ensure cross-border flow simply cannot occur, which is what our infrastructure topology guarantees.

”Hosted in Australia” is not the same claim

Worth separating two things that often get said as though they were one.

Hosted in region means the servers are here. Sovereign means nothing about the architecture permits data to leave, including for administration, backup, analytics or support. Plenty of platforms are the first while quietly failing the second: an Australian database, a US-based support console, and an engineer in another timezone with read access to both.

The question worth asking a vendor is not where the data is stored. It is who can read it, from which country, and what would have to change for that to stop being true.

Where residency usually leaks

In our experience the database is rarely the problem. The leaks are at the edges.

Telephony and SMS. A call has to traverse a carrier, and a message has to traverse a gateway. If either is offshore, the content of a patient interaction has left the country before your application ever sees it.

Support tooling. Error trackers, session replay, log aggregation and helpdesk software routinely ship payloads to wherever the vendor happens to run. This is the most common accidental breach of a residency promise, because nobody thinks of a stack trace as patient data until it contains one.

Model inference. For an AI platform this is the obvious one. If a transcript is sent to a model endpoint in another country, the residency claim ends there regardless of where the recording is filed afterwards.

What we do not claim

We do not claim residency makes a system secure. It addresses one specific risk, cross-border disclosure, and it addresses nothing else. Access control, retention, encryption, audit and breach response are separate problems, and a practice should ask about each of them separately. Ours are set out on the security and compliance page.

We also do not claim residency is sufficient for compliance. APP 8 is one principle among thirteen. Meeting it well does not discharge the rest.

What about vendor processors?

Every processor that touches the data, telephony carriers, SMS providers, payment processors, is contractually bound to the same residency requirement, and we will not engage a vendor that cannot meet it. The list is short on purpose.