Why is a model listed in Sydney not enough?
Cloud providers separate storage from processing. Microsoft says data stored at rest stays in the designated Azure geography for every deployment type, while the deployment type decides where prompts are processed. Google says data at rest stays in the location you chose whichever endpoint you call, and that requests sent to a global endpoint may be processed in any Google Cloud location. Amazon Bedrock can route a request made in the Sydney Region to other Regions listed in an inference profile. The region in your resource name tells you where your account and stored data live. It does not tell you where each prompt and answer was computed, so your residency check has to cover the deployment setting and the routing behind it.
- Storage: uploaded files, vector stores, conversation history and logs held at rest.
- Processing: the computation that turns a prompt into an answer, which Google calls ML processing.
- Routing: whether the platform may send a request to another Region for capacity or availability.
Which Azure deployment types keep processing in Australia?
Microsoft Foundry offers Global, Data Zone and geography-based deployment types for models sold by Azure, which include Azure OpenAI models. Global types may process prompts in any Azure region. Data Zone types process within a Microsoft-defined zone, and the zones are the United States, the European Union and Asia Pacific. There is no Australia-only data zone, and Microsoft says the Asia Pacific zone covers multiple Asia Pacific regions. Standard and Regional Provisioned deployments process prompts and responses within the Azure geography you specify, so these are the types to use when processing must stay in Australia. Microsoft also states that new models reach Global types first and geography-based types last, with no committed date.
Microsoft documents an Azure Policy rule that blocks a chosen deployment type, such as GlobalStandard, across a subscription. Applying it stops a developer from creating a Global deployment during testing because it was the default option in the portal.
How does Amazon Bedrock routing work from Sydney or Melbourne?
Bedrock serves some models in-Region and others only through cross-Region inference profiles. A geographic profile keeps requests inside its geography, while a global profile can route to any supported commercial Region. AWS shows how to list AU-prefixed profiles from the Sydney Region, and it also warns against relying on the prefix alone. Its guidance is to call GetInferenceProfile from each source Region you use and check every destination Region in the response, because destinations can differ by source Region. CloudTrail records each cross-Region request in your source Region, and its inferenceRegion field shows where the request was processed. That record is evidence you can give an auditor, which a setting described on paper is not.
AWS also notes that a profile can route requests to opt-in Regions you never enabled in your account, and that prompts and outputs may be stored in those Regions for abuse detection. If a profile can leave Australia, retained copies can leave with it.
What about Google Cloud and the OpenAI API?
Google's Vertex AI documentation says data at rest stays in your chosen location, while ML processing depends on the endpoint. Requests to a global endpoint may be processed in any Google Cloud location and carry no data residency commitment. Google's data residency page lists, model by model, whether ML processing stays in Australia (australia-southeast1), so check the specific model rather than the platform. OpenAI offers data residency controls per API project for eligible customers. Its support table for the Australian region shows storage supported and regional processing not supported, and regions other than the United States require approval for abuse monitoring controls. OpenAI states plainly that support for regional storage does not imply support for regional processing.
How do you prove where processing happened?
A setting chosen at build time can change later without anyone deciding to change it. A developer adds a new model through a global option because it was the default, a library update switches the endpoint, or someone adds a fallback route during an outage. Keep evidence that matches the claim you make to clients or auditors, store it with the system documentation, and check it again whenever a model, library or route changes.
- Record the deployment type, Region and endpoint hostname for every model the application calls, including embedding models.
- Export the platform's own record: Azure deployment SKU names, Bedrock GetInferenceProfile output or the Vertex endpoint in use.
- Check retry and fallback code paths, which often point at a different deployment.
- Re-check after every model upgrade, because a replacement model may not be offered with the same deployment type.
- Review CloudTrail inferenceRegion values, or the equivalent log on other platforms, on a set schedule.
What if no Australian option fits the model you want?
New models often reach global deployment types before they are offered with processing in Australia. You then have three practical choices. You can use an older or smaller model that is available with in-Australia processing and test whether it handles the task. You can run an open-weight model on infrastructure you control in an Australian region or on premises, and accept the operating work that comes with it. Or you can accept offshore processing for low-sensitivity tasks only, with a documented assessment and client consent where your contracts require it. Record the decision with the person who owns the data obligations, so the choice of model does not quietly set your residency position.