Where Does Your Data Go When Claude Reads Your CRM?

Does Claude process your CRM data in your country?

Only if you explicitly route it there. Anthropic's API defaults to US-based processing. If your CRM integration, your Zapier zap, or your custom build doesn't specify a regional endpoint, your customer data goes to the United States for inference, regardless of where your business operates or where your customers live. Most out-of-the-box integrations don't specify a region. They use whatever the SDK default is.

This isn't a hypothetical risk. It's the default behavior of every major API-based AI tool right now.

How does API routing actually decide where data lands?

When your CRM sends a record to Claude, it's making an HTTPS request to an API endpoint. That endpoint URL determines the processing region. Anthropic currently offers a dedicated AWS-hosted inference region in Australia for Claude via Amazon Bedrock. If your integration points to the Australian Bedrock endpoint, inference happens onshore. If it points to the standard Anthropic API or a US Bedrock region, it doesn't.

The endpoint is usually buried in a config file, an environment variable, or a no-code tool's settings panel. Most people who set these integrations up didn't think about the region. They just grabbed the API key and moved on.

The region isn't decided by where your business is. It's decided by a URL string someone typed (or didn't type) six months ago.

What data is actually being sent?

This depends on how your integration is built, but in most CRM-to-Claude setups, the prompt includes whatever context the workflow passes in. That commonly includes:

• Contact names, emails, and phone numbers
• Company names and deal values
• Notes from sales calls or support tickets
• Custom fields your team has built out

In a typical summarization or enrichment workflow, you might be sending hundreds of contact records per day. Each one is a separate API call, each carrying personal data. Under Australia's Privacy Act 1988, the EU's GDPR, and Canada's PIPEDA, transferring personal data across borders requires either a compliant legal mechanism or explicit disclosure. "We used an AI tool" doesn't satisfy that requirement.

What's the actual compliance exposure?

For Australian businesses specifically, the Office of the Australian Information Commissioner (OAIC) treats cross-border data disclosure as a regulated act under Australian Privacy Principle 8. If you send a contact's data to a US-region server for AI processing without a contractual arrangement that ensures equivalent protection, that's a potential APP 8 breach. The OAIC has been increasingly active on AI-related privacy guidance since 2023.

For EU-based customers or businesses with EU contacts, GDPR Article 46 requires appropriate safeguards for data transfers to third countries. Using the standard Anthropic API without a Data Processing Agreement covering the transfer mechanism is a gap your DPA auditor will find.

None of this means you can't use Claude with your CRM. It means you need to know which endpoint you're calling.

How do you check where your integration is routing data?

Three places to look:

1. Your environment variables or config files. Search for ANTHROPIC_API_URL, AWS_REGION, or BEDROCK_REGION in whatever codebase or automation platform runs your integration. If you see us-east-1 or the standard api.anthropic.com base URL, you're on US infrastructure.

2. Your no-code tool settings. In tools like Make (formerly Integromat) or Zapier, the Anthropic or Bedrock connection usually has a region field. Check it. Many default to US East without surfacing that choice prominently.

3. Your AWS Bedrock console. If you're using Bedrock to call Claude, log into AWS, go to Amazon Bedrock, and check which region your model invocations are running in. The AWS Bedrock regional availability page shows which Claude models are available where.

| Route | Processing Region | Data Stays Onshore (AU)? | |---|---|---| | Standard Anthropic API | United States | No | | AWS Bedrock, us-east-1 | United States | No | | AWS Bedrock, ap-southeast-2 | Australia | Yes | | Azure (Claude via Azure AI) | Depends on Azure region selected | Only if ap region chosen |

Does Anthropic's data use policy protect you?

Partly. Anthropic's API usage policy states that API inputs and outputs are not used to train models by default. That addresses one concern but not the geographic processing question. Data not being used for training is different from data not leaving your jurisdiction. These are separate issues and require separate controls.

You also need a signed Data Processing Agreement with Anthropic if you're processing EU personal data. Anthropic does offer a DPA; you need to request and execute it, not just accept the standard API terms.

What about third-party CRM integrations that advertise AI features?

This is where it gets murkier. If you're using a native AI feature inside HubSpot, Salesforce, or another CRM, that vendor's infrastructure and subprocessor list governs where processing happens. The CRM vendor may itself be calling Claude or another model via an API, in a region you haven't verified.

Check your CRM vendor's subprocessor list and AI feature documentation. Ask specifically: which model, which vendor, which region. Most vendors will tell you if you ask directly. Many users never ask.

What we'd actually do

• Audit your current integrations this week. Pull every workflow or custom build that touches Claude and find the endpoint URL. Document it. If you can't find it, assume US-region and treat it as a gap.
• Switch CRM-to-Claude workflows to AWS Bedrock ap-southeast-2 (or your local equivalent region) and execute a DPA with Anthropic before your next compliance review. The routing change is usually a single config line. The DPA request is a form submission. Neither is a project; both are tasks.
• Add AI data routing to your vendor assessment template. Every new tool that touches customer data should answer: which model, which API, which region, is there a DPA. Make it a standard question, not an afterthought.

If you want help building a governance layer that catches this kind of gap before it becomes a finding, that's exactly what we work through with members at skool.com/aiforbusiness.