Data sovereignty for Australian AI projects: the questions to ask

Data sovereignty is an easy phrase to say and a hard one to pin down. On an Australian AI project it can mean physical hosting, or legal jurisdiction, or vendor access, or where the support staff sit, or backups, or logs, or model training, or what the contract actually lets the vendor do. So “Is it sovereign?” isn’t a useful question. These are.

Before the questions, a word on why the vagueness is dangerous rather than just annoying. “Sovereign” has become a checkbox word: it appears on the vendor’s slide, the buyer nods, and both sides move on having agreed to nothing specific. Meanwhile the actual obligations Australian businesses carry are specific. The Privacy Act and the APPs care about cross-border disclosure of personal information and who’s accountable for it. Client contracts, especially with government, defence-adjacent industries, health and finance, often name where data may be processed and who may touch it. Professional bodies have their own expectations for privileged material. When something goes wrong, none of those frameworks will ask whether the vendor’s slide said “sovereign”. They’ll ask where the data went and who could access it, and “we assumed” is the answer that turns an incident into a finding.

Where is the data processed?

Start with location. Does the prompt, document, image or record leave Australia at any point? Does it route through another country to get processed? Where do the backups live? Are the logs stored somewhere separate from the main data? The answer might be perfectly fine. The problem is when nobody actually knows it.

AI systems make this harder than ordinary SaaS, because the pipeline has more stops. A single “ask a question about this document” feature can involve the app vendor’s servers in one region, an embedding service in another, a model provider in a third, and a logging platform in a fourth, and the vendor’s own sales team may only know about the first hop. Ask for the full processing chain, every subprocessor, every region, in writing. “Hosted in Australia” frequently means the application is hosted in Australia while the AI calls go to a US endpoint, and that distinction is precisely the one your obligations care about. If the vendor can’t produce the chain, that’s not a neutral fact. It means they haven’t traced it either.

Who can access it?

Access isn’t just your staff. It’s the vendor’s staff, their subcontractors, their support teams, and the automated systems in the pipeline. Ask how access gets approved, how it’s logged, how it’s reviewed, and whether support access can be limited or switched off when you don’t need it. On a sensitive project the access model can matter as much as which region the data sits in.

Here’s the scenario that makes it concrete. Your data sits in a Sydney region, tick, sovereign. The vendor’s support team works out of Manila and their engineers out of California, and both can pull production data to debug a ticket. Physically the data lives in Australia; practically, it’s readable from two other countries whenever someone raises a support case. Whether that’s acceptable depends on your obligations, and it might be fine. But it’s a different fact from the one on the slide, and you want to know it before signing, not during an incident review. Under some contracts, foreign-national access is itself the line, regardless of where the disks sit.

Is the data used for training?

Most vendors now say customer data isn’t used to train their public models. Don’t take that on faith. Read the terms, check whether a setting has to be flipped to make it true, and check whether prompts, outputs, files and feedback are all treated the same way or not. If the project touches confidential records, get the answer in writing.

The details hide in the seams. Some products exclude prompts from training but treat thumbs-up feedback and corrections as fair game. Some apply the protection at the enterprise tier but not the tier your team actually signed up for. Some route requests through a third-party model whose terms differ from the vendor’s own. And retention is a separate question from training: data kept 30 days “for abuse monitoring” is still data sitting on someone else’s infrastructure, discoverable and breachable, whether or not a model ever learns from it. Ask for training, retention and deletion answers separately, per data type. A vendor with real answers can give them in a page.

What metadata is captured?

Even when the content itself is protected, the logs and metadata around it can give plenty away. User names, document titles, request patterns, customer identifiers, IP addresses, workflow details. Work out whether that kind of metadata is sensitive in your context, because AI systems throw off a surprising amount of operational exhaust and it all needs somewhere to go.

Think about what an outsider could reconstruct from titles alone: “Project Kestrel acquisition brief v3”, “Smith v Harrold settlement position”, “redundancy list draft”. A law firm’s document names can breach privilege without a single document body leaving the building. If your matter names, client codes or project titles are themselves confidential, the logging pipeline needs the same treatment as the content, and it rarely gets it unless someone asks.

What are the alternatives?

Some projects run fine on cloud AI with the right controls in place. Others need a private cloud, self-hosted models, or on-prem hardware. Which one is right comes down to how sensitive the data is, how good the output has to be, and how much vendor dependency the business can stomach. We’ve broken the four deployment models down in what private AI actually means; the short version is that “private” runs from a contractual promise at one end to hardware you own at the other, and the right point on that line differs per workload, not per company.

Our private AI work usually kicks off with exactly this sorting exercise. Don’t default to the most locked-down option because it feels safest. An air-gapped build for marketing copy wastes money that should have gone to the workload that actually needed it, and the overcautious version has a subtler cost: teams route around systems that are too hard to use, and the shadow tools they route to have no controls at all. Match the architecture to the actual risk.

Who should own the answers

One organisational note before the wrap-up: these questions need a single owner, not a committee. In most SMEs and mid-sized firms the honest answer to “who checked the vendor’s data handling?” is that everyone assumed someone else did, IT thought legal signed off, legal thought IT had, and the person who bought the tool thought the brand name was the diligence. Put one name on it, give them the question list above as their checklist, and route every AI purchase, including the free trials, through that one desk. It’s an hour per vendor, and it’s the difference between answers that exist and answers that were assumed.

Make sovereignty operational

A sovereignty decision should end in rules the project can actually follow: which data classes are approved, where things have to be hosted, what gets logged, what the vendor is and isn’t allowed to do, who can access what, and when it all gets reviewed. Once those rules are written down, AI projects get a lot easier to sign off. The team knows what’s allowed to go where, and the system gets built around it from the start.

The written version has a second payoff: it converts every future vendor conversation from philosophy to checklist. Instead of relitigating “is it sovereign?” per product, someone holds the vendor’s answers up against your rules and gets a yes, a no, or a short list of gaps to negotiate. Pair the rules with a one-page AI policy for staff and you’ve covered both ends: the systems are placed deliberately, and the people know what goes where.

If you’re partway through an AI project and realising nobody has asked these questions yet, or a vendor has answered all of them with the word “enterprise”, bring us the proposal and the data it touches. We’ll map it against the questions above and tell you plainly where it stands, including when the cloud option with decent controls is honestly enough.