Short answer: it depends entirely which door you walk through. Called through a cloud provider in an Australian region, the request is processed in Australian infrastructure. Called through a consumer chat window, it is not. Same model, completely different answer to the question your CTO is asking, and almost nobody will draw that distinction for you unprompted.

This comes up in every technical conversation we have with a business over about 80 people. Usually nine minutes in, usually from whoever owns risk, usually phrased as "so where does the data actually go". It is the right question and it deserves better than reassurance.

Here is the version we would give you in the room, written down, with the Australian consequences attached.

Where is our data stored when we use Claude?

Three separate questions hide inside that one, and conflating them is where the confusion lives. Answer them in this order.

1. Where the request is processed

Called through a cloud provider such as Amazon Bedrock in an Australian region, inference happens on infrastructure in Australia. The model weights, the computation, and the temporary buffers holding your request and its response.

Anthropic states that regional data residency is available across Europe, the United States, Canada and Asia-Pacific, and names Australia in that Asia-Pacific group, on AWS Bedrock, Google Vertex and Microsoft Foundry. Note what is not on that list: the direct Claude API is not presented as a regional residency option. If residency matters to you, you are going through a cloud provider.

On the AWS side, the region to know is ap-southeast-2, Sydney, which carries the Bedrock control plane, runtime, agents and data automation. Melbourne, ap-southeast-4, appears in AWS's endpoint reference with the control plane only, not runtime, which is a distinction worth checking against your own account before you design around it.

Those pages are the primary sources and they are what you send your security team, rather than an agency summary. Including this one.

2. Where the record of it lives

Different question, and the one people forget. Your prompt and the response usually get logged somewhere: an application database, an observability tool, a CRM record, an error tracker, a support ticket where someone pasted the output.

That copy is yours, and it lives wherever you put it.

We have seen builds where the inference was correctly pinned to an Australian region and the logs went to an overseas monitoring service. The answer to "is our data in Australia" was no, the architecture diagram said yes, and nobody had noticed because the diagram stopped at the model call.

3. What the vendor keeps

Anthropic's commercial products do not use customer conversations to train models by default, and enterprise agreements allow custom retention settings. That is a real protection and it comes from the commercial agreement you are on, which matters for reasons we will come back to.

Can AI requests stay inside Australia?

Yes, if you build for it deliberately. No, if you do not, because every default in this industry points somewhere else.

It is an architecture decision made at four points, and getting three right is the same as getting none right if the fourth leaks.

The inference endpoint

Pinned to an Australian region rather than accepting a global default. This is the one everybody knows about and the only one most people check.

Cross-region routing, which is a choice and not a default

This is the part most people have backwards.

On Bedrock, requests do not wander off on their own. Cross-region routing happens only if you ask for it, by passing an inference profile ID as the model you are calling instead of the plain foundation model ID. Call anthropic.claude-... and you stay in the region you called. Call apac.anthropic.claude-... or a global profile and you have opted into routing.

So the question for your engineer is not "is failover on". It is: "which exact model identifier is in our code?" That single string is your residency policy.

There are two flavours of cross-region profile and the difference matters:

  Geographic profile Global profile
Routes within One geography, such as US, EU or APAC Any supported commercial region worldwide
Data residency Stays inside that geographic boundary No geographic guarantee
Cost Standard Roughly 10% cheaper
Use it when You have residency obligations You are optimising cost and have none

AWS's own recommendation is explicit: choose geographic when you have data residency requirements. The 10% saving on the global profile is exactly the sort of quiet optimisation that gets made by someone who was not in the compliance conversation.

One caveat even on geographic profiles, and it is in AWS's documentation rather than anyone's marketing: your data remains stored only in the source region by default, but prompts and outputs may move outside the source region during routing, and where data is stored for abuse detection it will be stored in the destination region. So "stays in the geography" is accurate. "Never leaves the region you called" is not.

How to prove where it ran

This is the detail that turns a policy into evidence, and almost nobody knows it exists.

CloudTrail logs every cross-region inference request in your source region, and the additionalEventData.inferenceRegion field records where the request was actually processed. That means you can answer "show me that our AI requests were processed in Australia" with a log query rather than an assurance.

If you are going to be asked this by a regulator, an auditor or a customer, wire that query up before you are asked.

Logs and traces

Where the prompt ends up after the answer comes back. Check the observability tool, the error tracker, and anywhere a developer added a debug line during the build and forgot to remove it.

Everything downstream

The vector store, the queue, the cache, the backups. A vector store is a copy of your content in a different shape, and it is still your content.

What a client who actually needs this asks for

Before we design anything, we send five questions. Below is a real set of answers from the Head of Projects at a Queensland business whose inputs are sensitive client measurement data, and it illustrates what "onshore" means in practice better than any explainer we could write.

What we asked What they said What it changed
Does client data have to stay onshore or in-country? "Yes" No default regions anywhere in the build. Pinned from the first line.
Can any client data touch third-party or public AI services, or must everything be self-hosted and closed-loop? "Self-hosted. Inputs are sensitive client data which must not be exposed to public use" Rules out the convenient path, changes the cost model, and we say so before quoting rather than after.
Can the system cache or store data at any point, or must nothing persist beyond processing? "Either or. Storage would be reasonable, as long as it's privately hosted and on-shore" Caching allowed, which made the system materially faster and cheaper.
Who is permitted to see what, and any role-based restrictions? "Depends on data type... it would also be helpful for external teams to access selected data for their own purposes, without the ability to manipulate it, like an API" Surfaced a real feature, read-only external access, that would otherwise have been missed entirely.
Any certifications, or regulator and client contractual obligations the architecture has to satisfy? "Data privacy policies and internal AI usage guidance are the main ones. Otherwise, requirements for internal data structure for the Regulator and auditors" The regulator shapes the output format, not just the security posture. Found in week one instead of month four.

The third answer is the one worth noticing. We expected "nothing persists". They said storage was fine as long as it stayed private and onshore, which made the build faster and cheaper than the version we would have designed if we had assumed the strict answer.

Assumed constraints cost more than real ones. Ask, do not guess.

 

Not sure what your current setup does?

Most businesses have already answered the residency question by accident. See how ready your business actually is

Does Anthropic train on our CRM data?

Not by default on the commercial products.

Now the part worth saying out loud to your team: that protection comes from the commercial agreement you are using, not from the model being polite. Someone pasting a customer list into a free consumer tool is a different arrangement, with different terms, and in most businesses we walk into that is the actual risk. The technical control is real. The human one is where it goes wrong.

The OAIC's guidance on privacy and the use of commercially available AI products, published in October 2024, addresses this directly and comes with a selection checklist you can hand to whoever is choosing tools. Its position on entering personal information into publicly available tools is blunt: don't. There is a companion guide on developing and training generative AI models if you are going further than using someone else's.

You can also fix this at the contract layer, which is stronger than a policy because policies rely on people reading them. In a recent agreement negotiation the wording we landed on was third-party models accessed under zero-retention terms using dedicated, scoped keys for that client specifically. That is a sentence your procurement team can hold a vendor to, and it is worth asking for by name.

API, Bedrock or Vertex, which one for residency?

If Australian processing is a hard requirement, you want a cloud provider route where the region is yours to choose.

Three things the comparison posts leave out.

You are adding a vendor, not removing one. Going through AWS means your data protection story now includes AWS. For most Australian businesses that is a feature rather than a cost, because AWS is already on the approved supplier list and the AI vendor is not. We have seen this single fact unblock a procurement process that had been stuck for six weeks.

Model availability lags. New models usually land on the direct API first. If your build must run in an Australian region, you may be a few weeks behind the newest release, which matters considerably less than every launch blog implies. The model you had last month is not suddenly bad.

Latency from Australia is a number, not a vibe. Measure it from where your users are. A test from an overseas node tells you nothing useful about what your Brisbane sales team experiences at 9am.

Whose key is it running on?

Residency is half the answer. Control is the other half, and it is settled by whose account the thing runs in.

How ours works, and it is worth copying whoever you buy from:

  • During the build, model and API usage runs through our own account and is billed to you on the same terms as the rest of the fees. This keeps the work moving without waiting for procurement to open a new vendor account.
  • On deployment, it crosses to your account. Your own account, with a single dedicated key allocated so that only your traffic goes through that key. Not a shared pool, not our key with your workload on it.
  • After that, usage is prepaid, with the balance and the consumption visible on your own dashboard rather than on an invoice you receive later.

Two reasons this matters more than it sounds. If the relationship ends, the system keeps running, because the credential it runs on is yours. And you can see the running cost of the thing you own, monthly, without asking us. An AI system whose running cost you cannot see is not really yours yet.

If a provider will not put the production workload on your own key, ask why. There are legitimate answers. There are also answers that mean you cannot leave. We wrote the full cost version of this argument in Breeze credits or your own API key.

What happens if it goes wrong

This is where an architecture conversation becomes a board conversation, and it is specifically Australian.

Under APP 11 you must take reasonable steps to protect the personal information you hold. If something goes wrong and you have a suspected eligible data breach, the Notifiable Data Breaches scheme gives you 30 days to assess it and, if it qualifies, notify both the OAIC and the affected individuals.

So an AI feature with read access to every contact record is not just a product decision. It is a new surface with a statutory clock attached to it. That is not an argument against building it. It is an argument for knowing which region it runs in, and who can see it, before you do.

The ASD's Australian Cyber Security Centre published Engaging with Artificial Intelligence, written for medium to large organisations, and its own advice is to apply it alongside the Essential Eight. There is a second publication on deploying AI systems securely.

The practical value of that framing: if your security team already runs the Essential Eight, you have somewhere to put AI controls. Starting a parallel AI framework is how governance becomes a document nobody maintains.

If you are APRA-regulated, add CPS 234 for information security and CPS 230 for operational risk, which commenced on 1 July 2025 and brings material service provider obligations with it.

When your own policy is the obstacle

One case worth sharing, because it is more common than you would think and nobody writes about it.

We reviewed a client's information protection policy during contracting. One section required their information to be stored in a system endorsed by their own IT function, and stated that information processed outside those systems could constitute a breach. Delivering the project meant working in our systems, which had not been endorsed, because how would they have been.

Nobody was wrong. The policy predated the situation.

What we committed to instead: work in our own systems under our own controls, handle personal information in line with their privacy policy and the Australian Privacy Principles, and point their privacy office at our published position covering hosting and data residency, subprocessors, breach notification, and data return or deletion.

If your policy was written before AI vendors existed, expect to have this conversation. Have it in week one, not week nine, and expect the answer to be a documented exception rather than a policy rewrite.

What to do next

Three things, in order, none of which need a budget.

  1. Find out what your current setup actually does. Not what your policy says. Which region, which logs, whose key. Most businesses have already answered this question by accident, when somebody picked a tool and accepted a default.
  2. Ask your vendor the five questions above, in writing, before scope is signed. If they cannot answer all five about their own proposed build, they have not designed it yet.
  3. Put the answers on a diagram with the regions labelled. Every hop, including the logs. If nobody can draw it, nobody knows.

Frequently asked

Is data residency the same as data sovereignty?
Not quite. Residency is where the data physically sits. Sovereignty is about which country's laws can reach it, which also depends on who operates the infrastructure and where that entity is incorporated. For most mid-market builds, residency is the requirement you will be asked to meet and sovereignty is the question behind it.

Does this apply if we are only summarising internal notes?
If those notes contain personal information, yes. Summarising does not change what the data is.

Is a business under the $3 million turnover threshold exempt from the Privacy Act?
The small business exemption is narrower than most people assume, and it is a poor thing to build a strategy on while you are growing. At 60 to 200 people, assume the APPs apply.

Can we just self-host a model instead?
You can, and one of our clients requires exactly that. It solves residency cleanly and it moves the cost from usage to infrastructure and engineering. Do it because your data requires it, not because it sounds safer.

Who should own this question internally?
Whoever owns risk signs off residency and retention. Whoever owns the data signs off access. Whoever owns the outcome accepts the trade-off, because "self-hosted and closed-loop" is a real answer with a real price.

Where to go from here

Our own position, including who at NBH can see what, our subprocessors, and our breach notification commitments, is published in the Trust Centre.

The testing side of this, which is the next question a Validator asks, is how we test an AI agent before it goes near a customer. If you are wiring an agent into HubSpot specifically, the permissions half of that is how to deploy HubSpot AI agents without breaking your data.

And if you want someone to look at what you already have running, check out our AI audit.

One last thing to sit with. Most businesses we talk to have already answered this question without ever deciding to. Someone chose a tool, the default region was the vendor's default region, and that quietly became the policy. Worth finding out what yours says.

 

 

Want the residency question answered about your own stack?

We will map what you have running, and tell you what we would change. 

Get your AI readiness score

Read our own security and residency position or talk to us about a build.

Sources