Which AI models can actually run in Australia

When an AI answers a question, that answer gets worked out on a computer somewhere. Sometimes that computer is in Australia. Often it is not.

Amazon lets you pin it. There is a setting that says: use the servers in Sydney and Melbourne, and nowhere else. Most people building AI never turn it on, because they do not know it is there.

There is a catch worth knowing. Right now, for the newest models, Melbourne can do the whole job on its own. Sydney cannot. That surprises most people, so it is worth checking before someone tells you their setup is hosted in Australia.

We check it. We write down which model, which setting, and the date we checked, because it changes every few months. The rest of this page is that working.

Bedrock calls these inference profiles. AWS documents three kinds. In-Region "keeps requests within a single Region for strict compliance". Geo Cross-Region "routes across Regions within a geography (such as US, EU, and APAC) while respecting data residency". Global Cross-Region "routes anywhere worldwide when there are no residency constraints". AWS model card ↗

The Australian geography was added in October 2025. It covers two regions: Sydney, which AWS names ap-southeast-2, and Melbourne, which is ap-southeast-4. AWS states that with a geo profile, "inference processing stays within the geography boundaries of the specified GEO", and that traffic "flows exclusively over the AWS Global Network without traversing the public internet". AWS blog, 31 October 2025 ↗

You get the Australian geography by calling the model through a profile ID that starts with au. So the Australian profile for Claude Opus 4.8 is au.anthropic.claude-opus-4-8. Call the same model without that prefix and you are on whichever profile the SDK defaults to, which is usually the global one.

A profile ID beginning apac is a different thing and is not Australian residency. There is more on that below the table.

Microsoft defines its deployment types in one paragraph, and the wording carries the whole answer. For Standard and Regional deployments, "Azure OpenAI processes prompts and responses in the region associated with your deployment". For Data Zone deployments, Microsoft processes them "anywhere within the specified data zone", where Asia Pacific means "data processed within any Asia Pacific nation". For global deployments, Azure OpenAI "can process prompts and responses in any Azure region where you deploy the model". Microsoft Learn ↗

So the Asia Pacific data zone is the same trap as the APAC profile on Bedrock, sold by a different vendor. It is a residency tier that is not Australia.

The practical reading is short. On pay per token, the newest model you can run with processing inside Australia East is GPT-4o dated 20 November 2024, plus GPT-4.1-mini. A GPT-5 family model inside an Australian region needs Regional Provisioned Managed, which means committed capacity rather than metered usage. The pay-per-token route to GPT-5 is the Asia Pacific data zone, and Microsoft's own definition of that is any Asia Pacific nation.

One more line worth having. Microsoft offers global training for fine-tuning in Australia East and states plainly that it does not offer data residency. Microsoft Learn ↗

OpenAI offers regional storage in Australia. Regional processing is a separate control, and OpenAI supports it in the United States and Europe, with limited processing in the United Arab Emirates for specific models. Against Australia, the processing column reads none. The documentation also says OpenAI "may also process and temporarily store Customer Content outside of the Region to deliver the services". OpenAI docs ↗

Anthropic's own API has two residency controls. The inference geography, which sets where the request is processed, accepts only "us" and "global". The workspace geography, which sets where data rests, accepts only "us" and cannot be changed after the workspace is created. Both are available on Claude 4.6 and later models. Anthropic docs ↗

As at 8 August 2026, the route we can verify for running a current frontier model with processing confined to Australia is Amazon Bedrock with an Australian geo profile, in Sydney or Melbourne. That is the claim we will make in writing, with the model name and the date beside it.

Send personal information overseas and Australian Privacy Principle 8 applies. Before an entity "discloses personal information about an individual to an overseas recipient, the entity must take such steps as are reasonable in the circumstances to ensure that the recipient does not breach the APPs in relation to that information". oaic.gov.au ↗

Taking those steps does not end your exposure. Under section 16C of the Privacy Act, an act by the overseas recipient that would breach the APPs is treated as a breach by you, even where you took reasonable steps. oaic.gov.au ↗ You can reduce the surface with a contract. You cannot sign the accountability away.

The Office of the Australian Information Commissioner puts the same point to anyone choosing a cloud-hosted AI product: consider "where the servers are located and whether personal information could be disclosed outside of Australia". oaic.gov.au ↗

Keeping the request inside Australia is one control among several. It is the cheapest one, it takes an afternoon to configure, and it stops the harder questions from arising at all.

If you sell to government, one more fact is useful. Amazon Bedrock appears on the AWS list of services in scope for IRAP at the PROTECTED level, excluding Bedrock Marketplace. aws.amazon.com ↗ An IRAP assessment is not a certification. Each agency still makes its own authorisation decision.

• Claude on Google Cloud, from an Australian region. Anthropic's own documentation lists multi-region endpoints for the United States and the European Union, and no others. Anthropic docs ↗ Google's per-model region tables would not load for us across several attempts, so we cannot say whether australia-southeast1 or australia-southeast2 serves any Claude model. Treat it as unavailable until you have read the model's own page.
• Destination regions for Opus 5 and Sonnet 5. Both cards give an Australian profile and say inference stays within Australian regions. Neither publishes the source-to-destination table that the older cards publish. We have marked those cells not verified rather than assume they match Opus 4.8.
• Claude 3.5 Haiku's status. Its card shows an end of life date of 19 June 2026, which has passed, while the model index still lists it as legacy. That looks like documentation lag, but we have not confirmed which of the two is right.
• Client library support. We have seen a report of an SDK rejecting a profile ID with the au prefix. GitHub issue ↗ We have not tested every library and every version. Test yours before you build a residency commitment on top of it.
• IRAP status of Microsoft's AI services. We checked the AWS position and not the Azure one. Do not read the AWS line above as saying anything about Microsoft.
• Everything here has a shelf life. Claude moved from Opus 4.5 to Opus 5 in about nine months, and Australian residency behaviour changed at nearly every step. Anything on this page could be wrong by next month. That is why the date is at the top and the bottom.

Every Bedrock row above was read directly from the individual AWS model card on that date. The Azure figures came from the Microsoft Learn region availability page, which carried a page date of 24 July 2026. We re-check this page monthly and move the date whether or not anything changed, so you can tell current from forgotten.

If you found something here that is out of date, tell us and we will fix it and say so.