If you lead engineering inside an Australian bank, insurer, or health provider, the question about Claude Code is not whether it makes your developers faster. It does. The question is whether you can adopt it without tripping an obligation your risk team will later ask you about. This guide is deliberately sober. Where competitors overclaim on security, accuracy is the more useful position, so some of what follows is about limits rather than features.
What Anthropic actually provides
Start with the facts you can rely on when briefing your risk function.
On Team, Enterprise, and API plans, your data is not used to train Anthropic's models. That is a contractual position, not a setting you have to remember to switch off.
SOC 2 Type II reporting, enterprise access controls, and audit logs are available on the Enterprise tier, which is what most regulated teams will want.
Anthropic has a Sydney office and has announced plans for Australian data residency. Be precise about this: residency is announced, not live today, and current processing happens offshore. State that plainly to your risk team rather than letting them assume otherwise.
The data-residency point is where we see the most confusion. An announced plan is a reason to plan, not a reason to claim the box is already ticked. If your control framework requires onshore processing today, that constraint still applies, and you should design around it rather than wait.
None of this should read as a reason to stay on the sidelines. Teams in financial services and insurance are already running Claude Code in production with these controls in place. The point of mapping the obligations is not to slow the rollout down but to make it survivable under scrutiny, so the first hard question from an auditor has a documented answer instead of a nervous silence.
What the regulator expects of you regardless
Whatever the vendor provides, the obligations on your side do not move. Three are worth naming for Australian teams.
APRA CPS 230 operational risk. AI tooling in the development pipeline is a material service consideration. Map it, including the provider and the failure modes, rather than treating it as an invisible productivity tool.
APRA CPS 234 information security. Access controls and audit trails apply to anything that touches production data, and an AI agent acting in your pipeline is squarely in scope.
The Privacy Act. Personal information sitting in codebases, test fixtures, and logs needs handling rules before it goes anywhere near an AI tool. ASIC-regulated entities carry director-level operational obligations on top of this.
Practical guardrails for a Claude Code rollout
The good news is that the controls a regulated team needs are well understood and quick to put in place. They are mostly about discipline, not exotic technology.
Secret-handling rules: a clear definition of what may never enter a context window, enforced by tooling rather than a memo nobody reads.
Scoped repository access and environment isolation, so AI-assisted work happens away from production by default.
Audit logging of agent actions in CI, so there is a record of what was changed and by which process.
A written AI coding policy your risk team has actually read and signed off, not a draft sitting in someone's drafts folder.
The cost of getting it wrong versus right
The economics favour doing the guardrail work. A privacy incident response in Australia routinely runs past $500,000 once legal, notification, and remediation are counted, before any reputational cost. The guardrail work, by contrast, is a few days inside a $10,000 to $25,000 rollout. You are spending a small, predictable amount to avoid a large, unpredictable one, which is the kind of trade a risk committee approves quickly.
Honest limits: what we do not promise
Because overclaiming is the norm in this space, here is the part most vendors skip. We do not promise zero mistakes from an AI coding tool. We do not recommend unsupervised production changes, and we design rollouts so a human reviews anything consequential. And we do not claim live Australian data residency today, because it is announced rather than available. A rollout that respects those limits is one your auditors can actually defend.
A useful sequencing rule: decide the secret-handling and access controls before the policy document, and write the policy after, describing what you actually built. Policies written first tend to describe an ideal nobody implements. Controls built first give you a policy that matches reality, which is the version that holds up when someone checks.
We run governance-first Claude Code rollouts for regulated teams from our base in Sydney. If you need the productivity without a finding at your next review, book a call and we will map the controls before a single developer turns it on.
