A year ago, clients asked me what an AI agent could do. Now the first question in almost every meeting is different: "Where does our data go when an agent reads it?"
It's the right question. An agent that drafts a follow-up email has to read the contact record, the deal notes and sometimes the last few emails. That text gets sent to a model. So where does the model run, who can see the request, and what happens to it afterwards?
This post is my plain answer for how we run agents at DigiKat, and the questions I'd ask any vendor, including us.
Our client agents use Claude, Anthropic's model, through Amazon Bedrock. Bedrock is AWS's service for calling AI models inside an AWS account. There are three ways a Bedrock call can be routed, and they matter a lot for residency.
The simplest setup calls the model directly in the AWS Asia Pacific (Sydney) region, ap-southeast-2. The request is handled in that region. The catch is model availability: not every model is offered in-region in every AWS region, and newer models are often served only through inference profiles.
au. geographic inference profileAWS also offers geographic cross-region inference profiles. These spread load across a fixed set of regions within one geography. The Australian profile uses an au. prefix. AWS's launch post explains that requests from Sydney are routed to either Sydney or Melbourne, and requests from Melbourne go to either of those two regions. Traffic stays on the AWS network.
A few honest caveats:
GetInferenceProfile from each source region you use and checking every destination region in the response. We do that when we set up a client.apac. and global. are differentThe apac. profile routes across Asia Pacific regions, which can include regions such as Tokyo, Singapore and Seoul. The global. profile can route to any commercial AWS region in the world. Both are useful for capacity. Neither keeps processing in Australia. If a vendor tells you "we use Bedrock in Sydney" but their code calls a global. model ID, your prompts can be processed overseas.
One more detail from the Bedrock data protection page: model providers don't have access to customer prompts and completions. Anthropic doesn't see your CRM text when you call Claude through Bedrock.
Here's the flow for a typical agent we build:
au. profile.That last point is a design choice. An agent that quietly builds its own database of your customers is a second CRM you didn't ask for, and a second thing to secure.
I'm careful with one claim, though. I won't tell you "your data never leaves Australia," because the model call is only one part of the picture. Your CRM is the other part. HubSpot offers regional data hosting, including Australia, and the location is generally set when the account is created. HubSpot's data hosting FAQ also notes some processing can happen outside the hosting region. So check where your CRM is hosted. In HubSpot, it's under Settings, Privacy & Consent, Data Hosting.
Every model call costs money. A busy agent reading long email threads costs more than one tagging new leads. That cost is real, and it varies with volume.
So we keep it visible. On our pricing page, AI usage is charged separately from the managed monthly fee. You can see what the agents are using, and the management fee doesn't hide a model bill inside it.
We run client agents in DigiKat's managed AWS environment in Sydney. If a client wants the workload in their own AWS account, we can deploy there instead. Larger organisations and health businesses often prefer that, because it sits under their own security controls and billing.
We no longer install local AI hardware for clients. One managed platform is easier to secure, update and monitor.
In practice that means:
If you've read our honest write-up on replacing a hire with an AI workflow, you'll know the hard part is rarely the model. It's the plumbing around it.
If a vendor can't answer the first two quickly, that tells you something.
Two parts of the Privacy Act matter here. I'll keep them short.
APP 8, cross-border disclosure. Before you disclose personal information to an overseas recipient, you must take reasonable steps to make sure they handle it in line with the APPs. Under section 16C you can stay accountable for what they do. The OAIC's APP 8 guidelines also explain when sending data to a cloud provider can count as a "use" instead, depending on contract terms and how much control you keep. Keeping model processing in Australia removes a lot of that analysis for the model call.
Automated decision transparency, from 10 December 2026. If a computer program makes, or substantially and directly informs, a decision that could significantly affect someone's rights or interests, and it uses their personal information, your privacy policy must describe it. That includes the kinds of personal information used and the kinds of decisions involved. The OAIC has published guidance and updated its APP 1 guidelines. A human approval step helps, but it doesn't remove the need to check your policy. For health businesses, our post on where automation ends in telehealth covers the clinical side.
This is general guidance, not legal advice. Talk to your privacy adviser about your own obligations.
Know which model runs, where it's processed, where your CRM is hosted, and who approves the output. Write those four answers down. Most residency conversations get much easier once you have them.
If you want to see how we set up guardrails, approvals and regions for client agents, our AI safety page walks through it. Bring your vendor questions. I'm happy to answer them for our setup too.