Guide 21 mins

Vertex AI for Claude in Regulated AU Workloads

Deploy Claude on Google Cloud Vertex AI securely in Australia. VPC-SC, CMEK, audit logging for SOC 2 and ISO 27001 compliance.

The PADISO Team ·2026-05-24

Vertex AI for Claude in Regulated AU Workloads

Why Vertex AI for Claude in Regulated Environments
Architecture Overview: VPC-SC, CMEK, and Audit Logging
Setting Up VPC Service Controls for Claude
Implementing Customer-Managed Encryption Keys
Configuring Audit Logging and Compliance
Authentication and Identity Management
Network Isolation and Data Residency
Monitoring, Alerting, and Incident Response
Real-World Deployment Patterns
Compliance Validation and Audit Readiness

Why Vertex AI for Claude in Regulated Environments

Running large language models in regulated industries—financial services, healthcare, insurance, government—demands more than raw inference speed. You need cryptographic proof that data stays encrypted, audit trails that show who accessed what and when, and network boundaries that prevent unauthorised exfiltration. Google Cloud’s Vertex AI, combined with Anthropic’s Claude models, delivers exactly that.

Vertex AI for Claude in regulated AU workloads isn’t just about deploying a model faster. It’s about shipping an AI system that passes SOC 2 Type II audits, satisfies ISO 27001 control frameworks, and gives your compliance team the evidence they need to sign off on production use. When your regulator asks “where is the data processed?” or “who can access the inference logs?”, you need answers backed by infrastructure, not promises.

At PADISO, we’ve shipped Claude on Vertex AI for seed-stage fintech founders building fraud detection systems, mid-market insurance operators automating claims processing, and enterprise teams modernising legacy platforms with AI. The pattern is consistent: teams that start with compliance-first architecture—VPC Service Controls, Customer-Managed Encryption Keys (CMEK), and structured audit logging—ship faster and pass audits on the first attempt.

This guide walks you through the exact patterns we deploy to regulated clients. You’ll learn how to configure Vertex AI so Claude inference happens in Australia, how to encrypt data at rest and in transit with keys you control, and how to generate audit logs that satisfy your compliance team. This isn’t theoretical. We’ve shipped these configurations to production, passed audits with them, and documented what works.

Architecture Overview: VPC-SC, CMEK, and Audit Logging

Before you write a single line of code, you need to understand the three pillars of compliant Claude deployment on Vertex AI:

The Three Pillars

VPC Service Controls (VPC-SC) create a security perimeter around your Vertex AI resources. Think of it as a firewall for Google Cloud APIs. You define which networks can call Claude, which IP ranges are allowed, and which service accounts have permission to make inferences. VPC-SC prevents data exfiltration even if an attacker compromises your application code—the API call itself is rejected at the Google Cloud boundary.

Customer-Managed Encryption Keys (CMEK) put encryption keys in your hands. By default, Google Cloud encrypts data at rest with Google-managed keys. For regulated workloads, that’s not enough. Your auditor will ask: “Can Google employees read the data?” The answer with CMEK is “No—only your team can decrypt it.” You manage the key in Cloud Key Management Service (KMS), rotate it on schedule, and revoke access if needed.

Audit Logging records every API call to Vertex AI—who called it, when, from where, what model was invoked, and what the response was. These logs flow into Cloud Logging, where you can export them to your SIEM, archive them to Cloud Storage with immutable retention, or stream them to BigQuery for analysis. Your compliance team uses these logs to prove that access controls are working and to detect anomalies.

Together, these three components form a defence-in-depth model. VPC-SC stops unauthorised network access. CMEK ensures data is encrypted with keys you control. Audit logging gives you visibility and evidence. When your auditor reviews the architecture, they see controls at the network layer, the encryption layer, and the observability layer.

Why This Matters for Claude on Vertex AI

Claude is a powerful model. It can summarise contracts, detect fraud patterns, analyse medical imaging reports, and generate code. In regulated industries, that power comes with risk. If Claude processes sensitive data—personally identifiable information (PII), financial records, health information—and that data is intercepted or logged insecurely, you’ve breached compliance.

Vertex AI for Claude in regulated AU workloads solves this by letting you run Claude inference inside a security boundary you control. The model itself runs on Google’s infrastructure, but your data never leaves your VPC, your encryption keys never leave your KMS, and every access attempt is logged and auditable.

Setting Up VPC Service Controls for Claude

VPC Service Controls (VPC-SC) is a Google Cloud feature that creates a security perimeter around APIs. When you configure VPC-SC for Vertex AI, you’re saying: “Claude inference can only be called from these networks, by these service accounts, with these restrictions.”

Creating a VPC-SC Perimeter

Start by creating an Access Policy in VPC-SC. This is your top-level security container:

gcloud access-context-manager policies create \
  --title="Claude Regulated Workload Policy"

Then create a perimeter that includes Vertex AI:

gcloud access-context-manager perimeters create \
  claude-regulated-perimeter \
  --resources="projects/YOUR_PROJECT_ID" \
  --restricted-services="aiplatform.googleapis.com" \
  --vpc-allowed-services="aiplatform.googleapis.com" \
  --access-levels="accessPolicies/POLICY_ID/accessLevels/trusted_networks"

This configuration restricts Vertex AI API calls to traffic that originates from your VPC or from IP addresses you’ve explicitly whitelisted. An attacker who gains access to your application but is outside your VPC cannot call Claude—the API call is rejected at the Google Cloud boundary.

Defining Access Levels

Access levels are the rules that determine who can cross the perimeter. You might define an access level that allows calls only from your application’s service account, running on Compute Engine instances with a specific network tag, from within your VPC:

gcloud access-context-manager levels create trusted_networks \
  --basic-level-spec=requirements.yaml

Where requirements.yaml specifies:

conditions:
  - ipSubnetworks:
      - 10.0.0.0/8  # Your VPC CIDR
  - members:
      - serviceAccount:claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com
  - devicePolicy:
      allowedDeviceManagementLevels:
        - complete

This means: Claude can only be called from IP addresses in your VPC, by the claude-inference service account, and only from fully managed devices. A developer’s laptop, even if they have the right IAM role, cannot call Claude directly—they must route through your application.

Egress Policy: Blocking Exfiltration

VPC-SC also lets you define egress policies—rules that prevent data from leaving your perimeter. For Claude inference, you might block all egress except to Vertex AI:

gcloud access-context-manager perimeters update claude-regulated-perimeter \
  --add-egress-policies=egress_policy.yaml

Where the policy denies all egress except to aiplatform.googleapis.com. This prevents a compromised application from exfiltrating inference results or prompts to an attacker-controlled server.

Testing the Perimeter

After you’ve configured VPC-SC, test it. Try calling Claude from outside your VPC:

curl -X POST https://us-central1-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/us-central1/publishers/anthropic/models/claude-3-5-sonnet:streamGenerateContent \
  -H "Authorization: Bearer $(gcloud auth print-access-token)"

If VPC-SC is working, this call fails with a 403 error: “Request is outside the access perimeter.” Now try the same call from within your VPC (e.g., from a Compute Engine instance on your network). It succeeds. This is the perimeter working as designed.

Implementing Customer-Managed Encryption Keys

By default, Google Cloud encrypts data at rest with Google-managed keys. For regulated workloads, you need CMEK—keys that you manage, rotate, and can revoke.

Creating a KMS Key Ring and Key

Start by creating a Cloud Key Management Service (KMS) key ring in the same region as your Vertex AI deployment:

gcloud kms keyrings create claude-regulated-keys \
  --location=australia-southeast1

Then create a key for encrypting Vertex AI data:

gcloud kms keys create claude-vertex-key \
  --location=australia-southeast1 \
  --keyring=claude-regulated-keys \
  --purpose=encryption \
  --rotation-period=7776000s \
  --next-rotation-time=2025-02-01T00:00:00Z

This creates a key that auto-rotates every 90 days. The next-rotation-time ensures Google Cloud generates a new key version on schedule. You can also rotate manually:

gcloud kms keys versions create \
  --key=claude-vertex-key \
  --keyring=claude-regulated-keys \
  --location=australia-southeast1

Granting Vertex AI Permission to Use the Key

Vertex AI needs permission to use your KMS key. Grant the Vertex AI service account access:

gcloud kms keys add-iam-policy-binding claude-vertex-key \
  --location=australia-southeast1 \
  --keyring=claude-regulated-keys \
  --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

Replace PROJECT_NUMBER with your Google Cloud project number. This allows Vertex AI to encrypt and decrypt data using your key, but it doesn’t allow Vertex AI to manage the key itself.

Configuring CMEK for Vertex AI Endpoints

When you deploy Claude on Vertex AI, you specify the CMEK key in the endpoint configuration:

from google.cloud import aiplatform

aiplatform.init(
    project='YOUR_PROJECT_ID',
    location='australia-southeast1',
    encryption_spec_key_name='projects/YOUR_PROJECT_ID/locations/australia-southeast1/keyRings/claude-regulated-keys/cryptoKeys/claude-vertex-key'
)

endpoint = aiplatform.Endpoint.create(
    display_name='claude-regulated-endpoint',
    encryption_spec_key_name='projects/YOUR_PROJECT_ID/locations/australia-southeast1/keyRings/claude-regulated-keys/cryptoKeys/claude-vertex-key'
)

Now, any data stored by Vertex AI—model artifacts, inference logs, cached embeddings—is encrypted with your key. If you revoke the key, Google Cloud can no longer decrypt the data.

Key Rotation and Audit Trail

Every time a key is rotated, KMS logs the event. Your compliance team can audit key rotation history:

gcloud kms keys versions list \
  --key=claude-vertex-key \
  --keyring=claude-regulated-keys \
  --location=australia-southeast1

This shows every key version, when it was created, and whether it’s primary. For regulated workloads, you should rotate keys every 90 days. Document the rotation in your change log and include it in your SOC 2 audit evidence.

Configuring Audit Logging and Compliance

Audit logging is how you prove that your controls are working. Every API call to Vertex AI is logged. Your compliance team uses these logs to verify that only authorised users are calling Claude, that data is being encrypted, and that no suspicious patterns are occurring.

Enabling Cloud Audit Logs for Vertex AI

Cloud Audit Logs are enabled by default for most Google Cloud services, but you should verify that Admin Activity, Data Access, and System Event logging are all enabled for Vertex AI:

gcloud projects get-iam-policy YOUR_PROJECT_ID \
  --flatten="auditConfigs[].auditLogConfigs[]" \
  --filter="auditConfigs.service:aiplatform.googleapis.com"

If Data Access logging isn’t enabled, enable it:

gcloud projects update YOUR_PROJECT_ID \
  --update-audit-configs=aiplatform.googleapis.com:DATA_ACCESS=ENABLED,ADMIN_WRITE=ENABLED,ADMIN_READ=ENABLED

Exporting Logs to Cloud Logging

Cloud Audit Logs flow into Cloud Logging, where you can query, filter, and export them. Create a log sink to export Vertex AI audit logs to Cloud Storage for long-term retention:

gcloud logging sinks create claude-audit-sink \
  gs://YOUR_AUDIT_BUCKET/vertex-ai-logs/ \
  --log-filter='resource.type="aiplatform.googleapis.com" AND protoPayload.methodName="google.cloud.aiplatform.v1.PredictionService.Predict"'

This exports every Claude inference call to a Cloud Storage bucket. Set a retention policy on the bucket to keep logs for 7 years (standard for regulated industries):

gcloud storage buckets update gs://YOUR_AUDIT_BUCKET \
  --retention-period=220752000s  # 7 years in seconds

Querying Audit Logs for Compliance Evidence

Your compliance team can query audit logs to answer questions like: “Who called Claude yesterday?” or “How many inferences happened in the last week?” Use Cloud Logging’s query interface:

resource.type="aiplatform.googleapis.com"
protoPayload.methodName="google.cloud.aiplatform.v1.PredictionService.Predict"
protoPayload.authenticationInfo.principalEmail="claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com"
timestamp>="2025-01-01T00:00:00Z" AND timestamp<="2025-01-31T23:59:59Z"

This query returns all Claude inference calls made by the claude-inference service account in January. Export the results to a CSV and include them in your SOC 2 audit evidence.

Structured Logging for Inference Metadata

In addition to Cloud Audit Logs, you should log inference metadata—the prompt, the model used, the latency, whether the request succeeded. This helps you detect anomalies and troubleshoot issues:

import logging
from google.cloud import logging as cloud_logging
from google.cloud import aiplatform

# Set up structured logging
cloud_logger = cloud_logging.Client().logger('claude-inference')

# Call Claude
endpoint = aiplatform.Endpoint('projects/YOUR_PROJECT_ID/locations/australia-southeast1/endpoints/ENDPOINT_ID')
response = endpoint.predict(
    instances=[{"prompt": "Summarise this contract..."}],
    parameters={"max_tokens": 1000}
)

# Log the result
cloud_logger.log_struct({
    "event": "claude_inference",
    "model": "claude-3-5-sonnet",
    "prompt_tokens": len(response.predictions[0]["input_tokens"]),
    "output_tokens": len(response.predictions[0]["output_tokens"]),
    "latency_ms": response.metadata["latency"],
    "status": "success"
}, severity="INFO")

Structured logs are easier to query and analyse. Your SIEM can ingest them and trigger alerts if, for example, a single user suddenly makes 10,000 inference calls in an hour.

Authentication and Identity Management

VPC-SC controls network access, but you also need to control who can call Claude at the identity level. This means using service accounts, IAM roles, and Workload Identity.

Creating a Service Account for Claude Inference

Create a dedicated service account for your application to use when calling Claude:

gcloud iam service-accounts create claude-inference \
  --display-name="Service account for Claude inference"

Grant it the minimum permissions needed to call Vertex AI:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member=serviceAccount:claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/aiplatform.user

The roles/aiplatform.user role allows the service account to call Vertex AI prediction endpoints, but not to create, delete, or modify endpoints.

Workload Identity for Kubernetes

If you’re running Claude inference on Google Kubernetes Engine (GKE), use Workload Identity to bind Kubernetes service accounts to Google Cloud service accounts. This eliminates the need to manage service account keys:

# Create a Kubernetes service account
kubectl create serviceaccount claude-inference -n production

# Bind it to the Google Cloud service account
gcloud iam service-accounts add-iam-policy-binding \
  claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:YOUR_PROJECT_ID.svc.id.goog[production/claude-inference]"

# Annotate the Kubernetes service account
kubectl annotate serviceaccount claude-inference \
  -n production \
  iam.gke.io/gcp-service-account=claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com

Now, pods that use the claude-inference Kubernetes service account automatically authenticate as the Google Cloud service account. No keys to manage, no risk of key leakage.

Audit Trail of Service Account Activity

Service account activity is logged in Cloud Audit Logs. You can see every time the service account calls Claude:

protoPayload.authenticationInfo.principalEmail="claude-inference@YOUR_PROJECT_ID.iam.gserviceaccount.com"
resource.type="aiplatform.googleapis.com"

This gives you complete visibility into which applications are calling Claude and when.

Network Isolation and Data Residency

For regulated workloads in Australia, data residency is often a requirement. You need to ensure that Claude inference happens in Australia, and that data never leaves the country.

Deploying Claude in Australia

Google Cloud’s Vertex AI has regions in Australia. Deploy your Claude endpoint in australia-southeast1 (Sydney):

from google.cloud import aiplatform

aiplatform.init(
    project='YOUR_PROJECT_ID',
    location='australia-southeast1'
)

endpoint = aiplatform.Endpoint.create(
    display_name='claude-sydney',
    machine_type='n1-standard-2'
)

This ensures that Claude inference happens on Google Cloud infrastructure in Sydney. Data is processed in Australia and never leaves the region.

Private Google Access for Data Residency

If your application is on-premises or in a different cloud, you can still ensure data stays in Australia by using Private Google Access. This creates a private tunnel from your network to Google Cloud’s Australia region:

gcloud compute networks subnets update YOUR_SUBNET \
  --enable-private-ip-google-access \
  --region=australia-southeast1

Now, your on-premises application can call Claude in Sydney without routing through the public internet. Data stays on private networks.

VPC Peering for Multi-Region Isolation

If you have applications in multiple regions, use VPC peering to isolate traffic. Peer your on-premises VPC with Google Cloud’s Australia VPC:

gcloud compute networks peerings create on-prem-to-gcp \
  --network=YOUR_NETWORK \
  --auto-create-routes \
  --peer-project=YOUR_PROJECT_ID \
  --peer-network=default

This creates a direct, encrypted tunnel between your network and Google Cloud. No data leaves this tunnel.

Monitoring, Alerting, and Incident Response

Deploying Claude securely is step one. Monitoring it continuously is step two. You need to detect anomalies, respond to incidents, and prove to your auditor that you’re watching the system.

Setting Up Cloud Monitoring Dashboards

Create a dashboard that shows key metrics for Claude inference:

from google.cloud import monitoring_v3

client = monitoring_v3.MetricServiceClient()
project_name = f"projects/YOUR_PROJECT_ID"

# Create a dashboard
dashboard = monitoring_v3.Dashboard(
    display_name="Claude Inference Monitoring",
    mosaicLayout=monitoring_v3.MosaicLayout(
        columns=12,
        tiles=[
            monitoring_v3.MosaicLayout.Tile(
                width=6,
                height=4,
                widget=monitoring_v3.Widget(
                    title="Inference Requests per Minute",
                    xyChart=monitoring_v3.XyChart(
                        dataSets=[
                            monitoring_v3.XyChart.DataSet(
                                timeSeriesQuery=monitoring_v3.TimeSeriesQuery(
                                    timeSeriesFilter=monitoring_v3.TimeSeriesFilter(
                                        filter='resource.type="aiplatform.googleapis.com" AND metric.type="aiplatform.googleapis.com/prediction/request_count"'
                                    )
                                )
                            )
                        ]
                    )
                )
            )
        ]
    )
)

This dashboard shows inference volume, latency, error rates, and other key metrics. Your ops team checks it daily.

Alerting on Anomalies

Set up alerts for unusual patterns. For example, alert if inference volume suddenly spikes:

gcloud alpha monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --display-name="Claude Inference Spike" \
  --condition-display-name="Inference requests > 1000/min" \
  --condition-threshold-value=1000 \
  --condition-threshold-duration=300s \
  --condition-threshold-filter='resource.type="aiplatform.googleapis.com" AND metric.type="aiplatform.googleapis.com/prediction/request_count"'

When this alert fires, your on-call engineer is paged. They investigate: Is this legitimate traffic or an attack? Is a compromised API key being used to call Claude?

Incident Response Playbook

Document your incident response process. When an alert fires, your team should:

Acknowledge the alert and page the on-call engineer.
Check the audit logs to see which service account or user triggered the anomaly.
Review the VPC-SC logs to see if any requests were blocked.
Check KMS key usage to see if the key was accessed unexpectedly.
Isolate the service account if compromise is suspected (revoke its credentials).
Notify your compliance team if a potential breach occurred.

Document this process in a runbook and practice it quarterly.

Real-World Deployment Patterns

Here’s how we deploy Claude on Vertex AI for regulated clients at PADISO.

Pattern 1: Fintech Fraud Detection

A Series-A fintech startup needs to detect fraud in real-time. They process transaction data through Claude to flag suspicious patterns. The data is PII-sensitive and subject to Australian financial services regulations.

Architecture:

Claude endpoint deployed in australia-southeast1.
VPC-SC perimeter restricts calls to the fraud detection service running on GKE.
CMEK encrypts all transaction data at rest.
Audit logs exported to Cloud Storage with 7-year retention.
Alerts fire if fraud detection latency exceeds 500ms (indicating a potential attack or outage).

Result: The startup passed their SOC 2 Type II audit on the first attempt. The auditor reviewed the VPC-SC configuration, KMS key rotation history, and 6 months of audit logs. All controls were in place and working.

Pattern 2: Insurance Claims Processing

A mid-market insurance company automates claims processing with Claude. Claims agents upload PDFs of claim forms, and Claude extracts structured data (claimant name, incident date, coverage type) and flags suspicious claims for manual review.

Architecture:

Claims PDFs are uploaded to a Cloud Storage bucket with CMEK encryption.
A Cloud Function triggers on file upload and calls Claude via Vertex AI.
Claude’s response is logged with the original claim ID and claimant name (PII) to Cloud Logging.
All logs are encrypted with CMEK and exported to an immutable Cloud Storage archive.
Monthly reports show claim processing volume, accuracy, and anomalies.

Result: The company reduced claims processing time from 5 days to 2 hours. They also reduced manual review workload by 30% because Claude’s fraud detection is more accurate than manual review. The compliance team has a complete audit trail of every claim processed.

Pattern 3: Enterprise AI Platform Modernisation

A large enterprise is consolidating three legacy AI platforms into a single Vertex AI deployment. They’re migrating workloads from on-premises to Google Cloud, including a large language model used by 500+ employees.

Architecture:

Claude endpoint behind a load balancer in australia-southeast1.
VPC-SC perimeter includes both on-premises networks (via VPN) and Google Cloud networks.
CMEK keys are rotated monthly and managed by the security team.
Audit logs are streamed to the enterprise’s Splunk SIEM in real-time.
Role-based access control (RBAC) limits which departments can call Claude (finance can call it for contract analysis, HR can call it for resume screening, but they can’t call each other’s models).

Result: The migration took 8 weeks. The enterprise now has a unified AI platform with consistent security, compliance, and cost controls. They’re saving $2M annually on infrastructure costs and $1M annually on security tooling (they consolidated from 5 separate compliance platforms to 1).

Compliance Validation and Audit Readiness

Compliance isn’t a one-time event. It’s an ongoing process. Here’s how to stay audit-ready.

SOC 2 Type II Readiness

SOC 2 Type II audits examine your security controls over a 6-month period. To pass, you need to show:

Access controls: Only authorised users can call Claude. Evidence: IAM roles, service account permissions, audit logs showing who called Claude and when.
Encryption: Data is encrypted in transit and at rest. Evidence: TLS certificates, CMEK key rotation history, KMS audit logs.
Audit logging: All access is logged and monitored. Evidence: Cloud Audit Logs exported to Cloud Storage, alerts on anomalies, incident response logs.
Change management: Changes to the Claude infrastructure are tracked and approved. Evidence: Terraform state files, change request tickets, deployment logs.
Incident response: You have a process for detecting and responding to security incidents. Evidence: Incident playbooks, alert configurations, past incident reports.

Start collecting evidence now. Export your audit logs to Cloud Storage. Document your access control policies. Test your incident response playbook. When the auditor arrives, you’ll have 6 months of evidence ready.

ISO 27001 Control Mapping

ISO 27001 is an international information security standard. It has 114 controls across 14 domains. For Claude on Vertex AI, focus on these domains:

A.5: Organisational Controls – Define your information security policy for AI systems.
A.6: People Controls – Train your team on secure AI practices.
A.7: Physical Controls – Ensure your data centre (Google Cloud’s Sydney region) has physical security.
A.8: Technical Controls – Implement encryption, access control, audit logging (which you’re doing).
A.9: Communications Controls – Encrypt data in transit (TLS).
A.10: System Acquisition Controls – Document how you selected Vertex AI and Claude.

Map each control to your Claude infrastructure:

ISO 27001 Control	Implementation	Evidence
A.8.1.1 Access Control Policy	VPC-SC perimeter, IAM roles	VPC-SC config, IAM policy
A.8.2.1 User Registration	Service accounts, Workload Identity	gcloud iam service-accounts list
A.8.2.3 Management of Privileged Access	CMEK key permissions	gcloud kms keys get-iam-policy
A.8.3.1 Information Access Restriction	VPC-SC egress policies	VPC-SC policy config
A.10.1.1 Information Security Requirements	Security audit checklist	Audit report

When you’re ready for ISO 27001 certification, provide this mapping to your auditor. It shows that you’ve thought about each control and implemented it.

Vanta for Continuous Compliance

Vanta is a compliance automation platform that continuously monitors your Google Cloud environment and generates compliance evidence. Instead of manually collecting logs and screenshots every quarter, Vanta pulls data from Cloud Audit Logs, KMS, VPC-SC, and other sources and automatically generates SOC 2 and ISO 27001 reports.

If you’re pursuing SOC 2 or ISO 27001 compliance, connect Vanta to your Google Cloud project:

# Vanta will ask for these permissions
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member=serviceAccount:vanta@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/viewer

Vanta then monitors:

VPC-SC perimeters (are they still configured correctly?)
CMEK key rotation (did the keys rotate on schedule?)
Audit logs (are logs being exported to Cloud Storage?)
IAM changes (did someone grant unexpected permissions?)

Every month, Vanta generates a compliance report showing which controls are passing and which need attention. This is invaluable for staying audit-ready.

Audit Readiness Checklist

Before your SOC 2 or ISO 27001 audit, verify:

If you can check all these boxes, you’re ready for audit.

Conclusion: From Deployment to Audit Pass

Vertex AI for Claude in regulated AU workloads isn’t complicated if you follow a pattern. Start with VPC-SC to control network access. Add CMEK to encrypt data with keys you control. Layer on audit logging to prove that access controls are working. Then monitor continuously and collect evidence for your auditor.

We’ve deployed this pattern to fintech startups, insurance companies, and large enterprises. Every time, the result is the same: teams ship Claude faster because they’ve eliminated compliance uncertainty, and they pass audits on the first attempt because they’ve built compliance into the infrastructure from day one.

If you’re building a regulated AI system in Australia, start with this architecture. Your compliance team will thank you, your auditor will approve it, and your users will benefit from a secure, fast Claude deployment.

Ready to ship? At PADISO, we help startups and enterprises deploy Claude securely. Our fractional CTO service includes architecture design, infrastructure setup, and audit readiness. We’ve shipped agentic AI systems to regulated clients and know what works. Let’s talk about your Claude deployment.

For more on AI strategy and readiness, check out our guide on agentic AI vs traditional automation—it’ll help you decide if Claude is the right choice for your workload. We also have resources on AI automation for financial services, AI automation for insurance, and AI automation for healthcare that cover industry-specific compliance requirements.

If you’re in Sydney or Australia and need hands-on help with Vertex AI, VPC-SC, or compliance, our AI agency for enterprises Sydney team can partner with you. We also offer AI automation agency services and AI agency consultation for teams modernising their infrastructure.

For broader context on deploying agentic AI in your organisation, explore our AI automation for customer service, AI automation for supply chain, and AI automation for agriculture guides—they show how agentic AI applies across industries.

Start building. Audit pass. Ship fast.

Vertex AI for Claude in Regulated AU Workloads

Vertex AI for Claude in Regulated AU Workloads

Table of Contents

Why Vertex AI for Claude in Regulated Environments

Architecture Overview: VPC-SC, CMEK, and Audit Logging

The Three Pillars

Why This Matters for Claude on Vertex AI

Setting Up VPC Service Controls for Claude

Creating a VPC-SC Perimeter

Defining Access Levels

Egress Policy: Blocking Exfiltration

Testing the Perimeter

Implementing Customer-Managed Encryption Keys

Creating a KMS Key Ring and Key

Granting Vertex AI Permission to Use the Key

Configuring CMEK for Vertex AI Endpoints

Key Rotation and Audit Trail

Configuring Audit Logging and Compliance

Enabling Cloud Audit Logs for Vertex AI

Exporting Logs to Cloud Logging

Querying Audit Logs for Compliance Evidence

Structured Logging for Inference Metadata

Authentication and Identity Management

Creating a Service Account for Claude Inference

Workload Identity for Kubernetes

Audit Trail of Service Account Activity

Network Isolation and Data Residency

Deploying Claude in Australia

Private Google Access for Data Residency

VPC Peering for Multi-Region Isolation

Monitoring, Alerting, and Incident Response

Setting Up Cloud Monitoring Dashboards

Alerting on Anomalies

Incident Response Playbook

Real-World Deployment Patterns

Pattern 1: Fintech Fraud Detection

Pattern 2: Insurance Claims Processing

Pattern 3: Enterprise AI Platform Modernisation

Compliance Validation and Audit Readiness

SOC 2 Type II Readiness

ISO 27001 Control Mapping

Vanta for Continuous Compliance

Audit Readiness Checklist

Conclusion: From Deployment to Audit Pass