In June we published the Canadian version of this question, where the answer was that every prompt crosses the border and the best a Canadian firm can do is minimise and document the hop. Australia has an in-country option, documented by both vendors, and the interesting part is what it does and doesn't cover.
Two lines of vendor documentation, quoted as written
For a month we wouldn't assert Clio's Australian region in writing, because clio.com blocked our fetches and every source we had was secondary. On 26 August 2026 we got it from Clio's own developer documentation. The API reference says: "The API is available in four distinct data regions: Australia (au.app.clio.com), Canada (ca.app.clio.com), EU (eu.app.clio.com) and US (app.clio.com)."
On the Claude side, Anthropic's "Claude in Amazon Bedrock" page lists the AWS regions Claude is served from, with the endpoint types available in each. The two Australian rows:
| AWS region | City | Endpoint types (per Anthropic's page) |
|---|---|---|
ap-southeast-2 |
Sydney | Global, AU |
ap-southeast-4 |
Melbourne | Global, AU, In-region only |
The endpoint type is the part that matters for residency. A global endpoint lets AWS route the request to whichever region has capacity. A regional endpoint, in Anthropic's words, "resolves to the single AWS region you specify, for data-residency requirements", and the same page says regional endpoints carry a 10% pricing premium over global ones. So "Claude runs in Sydney" is true only if the integration asks for the AU endpoint on purpose. Left on the default, the request can be served from anywhere Claude runs.
Where the file sits, and how our own connector got it wrong
The Clio region is the hostname the integration calls. It was fixed when the Clio account was created, no integration toggles it afterwards, and firms don't always know which one they're on. Every Australian build starts with the same two-minute check with Clio: is this account on au.app.clio.com or somewhere else. Everything downstream depends on the answer, from the OAuth flow to the sentence you'd put in front of a client.
We ship an open-source Clio connector for Claude, and this is the part that costs something to write. Until now its region switch read the CLIO_REGION variable, recognised eu, and sent every other value to https://app.clio.com. The README said the accepted values were us or eu, and the code agreed with the README. An Australian firm that set CLIO_REGION=au, which is the obvious thing to type, was silently pointed at the US server. We haven't reproduced what happens next against a live Australian account. The likely outcome is a dead OAuth handshake, since the credentials belong to a different server, and the certain outcome was a connector described as regionally flexible that didn't know Australia existed. The next release adds au and ca as first-class values, and the README table changes with it.
Why we're telling you this: the whole post is about the gap between what a vendor says about regions and what its software does. If you're evaluating any connector or AI product for an Australian firm, ask to see where the region is chosen, then ask what happens when someone picks a value the software doesn't know.
Where the thinking happens: three kinds of vendor
To draft a clause or summarise a contract, the model has to read the text. Any product that claims its AI reads your documents without the content going anywhere is either running on hardware in your office or isn't describing itself accurately. So the useful question is where the reading happens and who can reach it, and the answer sorts every vendor into one of three groups, each asking you to trust something different.
Hardware in your own office. An open-weight model on a server the firm owns. This is the only setup where the content literally stays inside the firm's walls, and the only one that answers the jurisdiction question below. What you're trusting is your own IT: patching, backups, physical security, and the fact that locally run models sit a step behind the hosted ones. It costs more per drafting task than any cloud option, and it's the right answer for a small number of firms with a specific reason. We wrote that architecture up in the on-prem privilege stack. The slogan version of this question gets its own test: we published "nothing leaves your servers", then deleted it.
In-country cloud, inside the firm's own account. Claude on Bedrock pinned to Sydney or Melbourne is the example this post is built around; the equivalent exists on other clouds. The request leaves the office and lands on an AWS machine in Australia, inside the firm's own account boundary. What you're trusting is Amazon's documentation and contract, plus whoever configured the account. Anthropic's page describes the setup as "AWS-managed infrastructure with zero operator access (Anthropic personnel have no access to the inference infrastructure)" and says "Data handling for this offering is governed by Amazon Bedrock", so the model vendor's consumer terms don't apply here. Your follow-up asks: is the regional endpoint pinned, is the model pinned, is logging off or written into our own account, and who holds the keys.
A vendor-hosted product. Clio's own AI features, Harvey and its competitors, a Copilot or Claude subscription used in the browser, and most legal AI products on the market. The content goes to the vendor's infrastructure and the vendor decides where it's processed and by which sub-processors. We haven't verified where any specific product in this group processes Australian firms' content, and we won't guess in print. This group's residency story is contractual, so the questions are which region, which sub-processors, whether the region is a commitment or a current arrangement, what's retained, and whether anything is used for training. A vendor that answers those cleanly is fine. The red flag is a vendor that answers "it's secure" and moves on.
One distinction most evaluations skip, and it applies to all three groups. Firms ask "is it stored?" and stop there. Storage is what happens to the content after the request. Access is whether the model read it at all. For privileged material, being read is the exposure, and a no-storage promise does nothing about that. So the second question for any vendor, us included, is what exactly the model sees per task and whether it could be narrower. A well-built integration sends the clause or the matter field the task needs. Sending the whole file is usually just the easier thing to code.
What's kept afterwards
On the in-country cloud option, the retention answer comes from AWS rather than from us, which is why it's worth quoting rather than paraphrasing. The Amazon Bedrock abuse detection page:
"Amazon Bedrock uses a zero operator access (ZOA) data security model. This means no operators of the service can access model input or output. Also, Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs."
And the Bedrock data protection page, on the model vendor's side of the fence: "Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions."
Logging is the piece firms tend to assume is on. AWS's model invocation logging page says "Model invocation logging is disabled by default" and, when you do turn it on, "Only destinations from the same account and Region are supported." Nothing is written down unless the firm wants a record, and if it does, the record lands in the firm's own account in the same Australian region. That's the sentence you can put in writing for a client, because every clause of it points at a vendor document someone can check.
The model exception, and a test you can run on anyone
Everything above holds by default, and the default isn't the same for every model. The same AWS abuse detection page carries an exception for one current Anthropic model, as of August 2026 the newest and most capable one: "inputs and outputs will be retained for up to 30 days", and to use it you "must opt in to sharing retained traffic with Anthropic for abuse detection and potential human review". Two more lines from the same page matter for an Australian deployment. "If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions", which is a second reason to pin a regional endpoint rather than accept global routing. And "eligible customers may request full ZDR through their AWS account team", which is worth asking for on any legal deployment before you assume the default is the ceiling.
We're not printing model names here because they change, and a stale version number in a compliance record is worse than none; the zero data retention model ceiling post carries the current list with a verification date. The rule that survives the churn: pin the model deliberately, write down which one and why in the firm's AI record, and re-check the vendor's page every time a new model ships. A firm that reasonably picks "the best model" off a dropdown would quietly undo the no-storage posture and have no idea it happened.
That turns into a test for any vendor, in any of the three groups above. Ask which exact model version their product calls and what that specific version does with your data. If they can tell you, you've learned something about their engineering. If they can't, they haven't answered the data question yet, whatever the brochure says.
What Sydney doesn't settle
Running in Sydney answers where the data is processed. A second question sits underneath, whose law can reach the data, and Sydney leaves that one open. Amazon is a US company, and the US CLOUD Act lets American authorities compel a US provider to produce data it controls, wherever that data physically sits. The same applies to Microsoft and Google. Nobody selling cloud AI can make that go away, and we'd rather you hear it from us than from the firm's own lawyer after reading a confident email that skipped it.
The only architecture that removes the CLOUD Act from the picture is the first group above, hardware in your own office. For most firms the honest weighing is that the practical exposure is small, the cost of running models locally is large, and in-country cloud in the firm's own account with no storage by default is the reasonable trade. Some clients and some matters will sit on the other side of that line, so decide it up front, per client if necessary, and record the decision.
One question for the firm's advisers
The Privacy Act's small business exemption is the reason many Australian firms treat privacy as someone else's problem. It stops applying to a business that handles health information, and that phrase gets read broadly. A wills and estates practice sees capacity assessments and medical certificates as a matter of routine. Whether that pulls a particular firm inside the Act regardless of turnover is a question for the firm's own advisers; we build software, and the legal conclusion stays with them. We raise it because a firm that assumes the exemption covers it will design a looser data path than one that knows it doesn't, and the AI integration is where that difference shows up first.
The route, written so a client could read it
Put the pieces together and the in-country path for an Australian firm on Clio looks like this. The right-hand column is what goes into the firm's own record; the software is what makes the record true.
| Piece | Where it happens | What the firm writes down |
|---|---|---|
| System of record | Clio, Australian region (au.app.clio.com), confirmed with Clio |
Which region the account is on, and the date it was confirmed |
| What the model sees | The clause, the field, the single document a task needs | Per workflow, the fields sent and the fields withheld |
| Inference | Bedrock, AU regional endpoint pinned, in the firm's own AWS account | Region, endpoint type, model version, and the date each was last re-checked |
| Retention | No storage by default; logging off, or on into the firm's own account | Logging state, log destination, and whether full ZDR was requested from AWS |
| Output | Written back into the Clio matter as a draft | Who reviewed it, when, and that nothing was relied on before review |
| Jurisdiction | AWS is a US company; the CLOUD Act reaches data it controls | The firm's decision on that risk, and any clients or matters excluded from the workflow |
The disclosure that falls out of that table is one paragraph: matter data stays in Clio's Australian region; AI processing happens on Amazon Web Services in Sydney, inside the firm's own account, with no storage of inputs or outputs by default and no access by the model vendor; a named model version is pinned and re-checked on every release; a solicitor reviews every output before it is used; and AWS is a US company whose data can be reached by US law, a risk the firm has considered. Every clause in it points at a document or a decision. That's a stronger thing to hand a client than anything a brochure can say.
The solicitor's review at the end is what makes the rest of the record credible. The obligations to the client stay with the solicitor whichever of the three vendor groups the firm picks, and the recorded review is the evidence that they did.
So, build it or skip it?
For an Australian firm on Clio's Australian region, the in-country path is real and it's better documented than the Canadian one. The Clio side stays in Australia. The Claude side can stay in Australia too, on a pinned regional endpoint inside the firm's own AWS account, with no storage by default and a model chosen for its retention terms rather than its benchmark score. What's left over is the CLOUD Act, the health-information question for your advisers, and the discipline of re-checking the vendor pages every time something ships, and those are the parts of the record a firm keeps for itself.
Want a second opinion on your Clio + Claude data path?
We built the open-source Clio MCP server and MyCase MCP server, and we've worked through the Australian version of this question against real vendor documentation. If you're wiring Claude into Clio and want someone to pressure-test where the privileged content actually goes, including the parts that don't flatter the plan, book a 30-minute call. No pitch deck, just the architecture.
Book a 30-minute architecture call →Frequently asked questions
Does Clio have an Australian data region?
Yes. Clio's developer documentation states that the API is available in four distinct data regions: Australia (au.app.clio.com), Canada (ca.app.clio.com), EU (eu.app.clio.com) and US (app.clio.com). The region is the base URL an integration calls, fixed when the account is created. Confirm with Clio which region your account is on before anyone builds against it; an integration pointed at app.clio.com is talking to the US server whatever the firm assumes.
Can Claude run in Australia?
Yes, through Amazon Bedrock. Anthropic's Claude in Amazon Bedrock documentation lists ap-southeast-2 (Sydney) with Global and AU endpoint types and ap-southeast-4 (Melbourne) with Global, AU and In-region only. A regional endpoint resolves to the single AWS region you specify, for data-residency requirements, at roughly a 10% price premium over global routing. Inference runs inside the firm's own AWS account, and Anthropic's documentation states its personnel have no access to the inference infrastructure.
Does Amazon Bedrock store prompts and outputs sent to Claude?
By default, no. AWS documentation states that Amazon Bedrock uses a zero operator access and a zero data retention data security model, meaning that by default it does not store model inputs or outputs, and that model providers have no access to Bedrock logs or to customer prompts and completions. Invocation logging is disabled by default and, when enabled, writes only to the customer's own account and region. One exception as of August 2026: for the newest and most capable Anthropic model, inputs and outputs are retained for up to 30 days and you must opt in to sharing retained traffic with Anthropic for abuse detection and potential human review. Pin a model that sits under the default, and re-check on every vendor release.
Does running Claude in Sydney settle data sovereignty for an Australian law firm?
It settles location only. Amazon is a US company, and the US CLOUD Act lets US authorities compel a US provider to produce data it controls wherever that data physically sits. No cloud AI vendor can remove that. The only architecture that does is hardware in the firm's own office, which is a real option and a more expensive one. Decide that trade up front for the clients and matters where it matters, write it into the firm's AI record, and keep a solicitor reviewing every output before it is relied on.
