Sovereign AI Australia | IRAP-Aware AI Deployment

What sovereign AI means

Sovereign AI is not a marketing label. It is a set of architectural and operational decisions that mean a foreign actor cannot reach your data, your prompts, your model outputs, or the operational control of the system through legal compulsion, vendor policy change, or cross-border data routing.

In practice, sovereign AI in Australia means:

Data residency. Source data, embeddings, vector indexes, prompt history, and model outputs stored in AU regions only. Backups and replication targets also AU.
Inference locality. Model inference performed inside Australia. No cross-border routing for the LLM call or for any retrieval that touches your data.
Operational control. Privileged access subject to Australian law. Personnel with admin access in AU jurisdiction or with appropriate clearances. Vendor support pathways structured so foreign access cannot be invoked silently.
Evidence trail. The system produces the documentation an IRAP assessor, an internal audit team, or a regulator expects. Architecture diagrams, data flow, identity model, access logs, control mapping, change history.
Vendor risk management. Third-party dependencies (model weights, container images, libraries) are pinned, vendored, and reviewable. No silent over-the-wire updates that change behaviour without your consent.

Why it matters in Australia

The default AI stack assumes vendor regions, vendor-controlled inference, vendor data handling, and vendor-side personnel access. For consumer-grade and most enterprise workloads, that is acceptable. For Australian operators in regulated or sovereign categories, it is not.

The Australian Privacy Act and OAIC guidance constrain how personal information is handled and what cross-border transfers are acceptable. APP 8 specifically governs disclosure to overseas recipients.
APRA CPS 234 applies to regulated financial entities and prescribes information security controls and supplier risk obligations that affect AI vendor choice.
The Protective Security Policy Framework (PSPF) applies to non-corporate Commonwealth entities and shapes how classified information is handled, stored, and transmitted.
The Information Security Manual (ISM) sets out the controls that an IRAP assessor evaluates.
The Defence Industry Security Program (DISP) applies to suppliers working on defence contracts and structures access, personnel security, and physical security.
My Health Records Act and state health legislation govern healthcare data residency and the conditions under which it can be processed.
Sector-specific obligations in utilities, telecommunications (TSSR), and critical infrastructure (SOCI Act) introduce further constraints.

Foreign-jurisdiction AI vendors operating under foreign law create disclosure risk under those laws. The US CLOUD Act is the canonical example: it can compel a US-headquartered cloud provider to disclose data regardless of where it is stored. Sovereign AI architecture is the deliberate response.

Who this is for

Commonwealth and state agencies. Where AI workloads touch citizen data, classified material, or operational decision-making subject to public scrutiny.
Defence and defence industry. Where DISP, ITAR, or capability sensitivity require Australian-controlled deployment.
APRA-regulated financial entities. Banks, insurers, superannuation funds where CPS 234 and CPS 230 apply.
Healthcare and life sciences. Hospitals, payers, research bodies handling PHI under My Health Records Act and state legislation.
Critical infrastructure. Energy, water, telco, transport entities under the SOCI Act.
Legal practices. Where client-data privilege and confidentiality require deployment that no foreign jurisdiction can compel access to.
Universities and research bodies. Where international collaboration creates classification crossover and IP sovereignty matters.
Private operators with explicit AU-only data policies, board mandates, or customer commitments.

Frameworks we design for

Information Security Manual (ISM). The control set that IRAP assessors evaluate. Our deployments produce evidence aligned to ISM controls.
Protective Security Policy Framework (PSPF). Information classification handling, personnel security, physical security, governance.
Essential Eight maturity model. Application control, patching, hardening, restriction of admin, MFA, daily backups. We build to ML2 by default, ML3 where required.
Australian Privacy Act and APP. Personal information handling, cross-border transfer, breach notification, retention.
APRA CPS 234 and CPS 230. Information security and operational risk for regulated financial entities.
SOC 2 and ISO 27001. Where commercial obligations require them.
HIPAA-equivalent practice for healthcare workloads, with My Health Records and state law as the binding frameworks.
SOCI Act obligations for critical infrastructure designations.
NIST AI Risk Management Framework where the organisation has adopted it for AI governance.
Voluntary AI Safety Standard (DISR, Australia) where the organisation has opted in.

Deployment patterns

Three primary patterns cover most sovereign AI engagements.

Pattern 1: AU-region commercial endpoints

Inference routed to Azure OpenAI Australia East, AWS Bedrock ap-southeast-2 (Anthropic Claude, Meta Llama, Mistral, Amazon Titan), or Google Vertex AI australia-southeast1. Data stays in AU during the inference call. Vendor's enterprise terms apply (no training on customer data, AU-region routing, audit logs).

Suitable for OFFICIAL and OFFICIAL: Sensitive workloads, most APRA-regulated workloads, and commercial sovereign requirements where vendor risk is acceptable.

Pattern 2: Open-weight models in your VPC

Open-weight models (Llama 3 / 4, Mistral, Qwen, GPT-OSS, Gemma) deployed on GPU instances inside your own AU-region VPC using Ollama, vLLM, TensorRT-LLM, or AWS Bedrock self-hosted via Inferentia. No third-party endpoint involved. Data and inference are inside your environment.

Suitable for PROTECTED workloads, sensitive defence work, IP-sensitive engagements, or any workload where vendor risk is unacceptable. Comes with operational cost in GPU capacity and model lifecycle management; we handle that on retainer.

Pattern 3: IRAP-assessed sovereign cloud

Deployment to AWS sovereign regions (where applicable), Azure Australia Central (Canberra) with current PROTECTED IRAP assessment, or Vault Cloud (PROTECTED-certified sovereign cloud). Models and infrastructure inside the assessed boundary.

Suitable for PROTECTED-classified workloads where IRAP assessment of the target environment is required. We design the AI workload to fit inside the assessment boundary and produce evidence aligned with the ISM.

Sovereign model choice

Llama 3.x and 4.x (Meta). Open-weight, strong general capability, available in 8B to 405B parameter sizes. Common choice for in-VPC deployment on a single GPU or small cluster.
Mistral and Mixtral (Mistral AI). Open-weight, strong on efficiency. Suitable for cost-sensitive in-VPC workloads.
Qwen 2.5 and 3 (Alibaba). Open-weight, strong multilingual capability. Considered carefully for sovereignty given Chinese origin; weights are open and the model runs in your environment, so the actual sovereignty position is on the inference rather than the weights.
GPT-OSS (OpenAI). Open-weight models released by OpenAI, including capable mid-size variants. Strong default for in-VPC deployment.
Gemma (Google). Open-weight, strong on small-to-mid sizes. Useful for edge and constrained-resource deployments.
Anthropic Claude (via AWS Bedrock ap-southeast-2). Closed-weight, AU-region inference, enterprise terms. Strong on long-context reasoning. Suitable where Pattern 1 is acceptable.
OpenAI GPT (via Azure OpenAI Australia East). Closed-weight, AU-region inference, enterprise terms. Strong general capability. Suitable where Pattern 1 is acceptable.
Gemini (via Vertex AI australia-southeast1). Closed-weight, AU-region inference. Useful for Google Workspace integrations.

Model choice is configuration, not architecture. We design deployments so that swapping the underlying model is hours of work, not months. This matters because the model landscape moves quickly and you should not be locked in.

Identity and access

Sovereign deployment is not just about where the data sits. It is also about who can reach it and under what controls. Our deployments use:

SSO with your identity provider (Entra ID, Okta, Google Workspace, Auth0, internal directory). No separate AI-system passwords.
Conditional access policies inherited from your IdP (device compliance, IP restriction, MFA enforcement, session lifetime).
Role and attribute-based access control that mirrors what each user can already access in source systems. The AI never returns data the user could not access directly.
Privileged access management. Admin paths to the AI infrastructure require MFA, time-bound access where appropriate, and full audit trails.
Just-in-time access for support engineers where appropriate. No persistent admin access for the operate team.
Personnel security alignment. Where the engagement requires baseline checks, NV1, or NV2 clearance, the cleared work is performed by appropriately cleared personnel.

Audit and evidence trail

An IRAP assessment or APRA review is largely an evidence exercise. Either the evidence exists, in a form that can be reviewed against a control, or it does not. Our deployments produce:

Architecture diagram showing every component, network boundary, and data flow.
Data flow inventory showing every system the AI reads from, every system it writes to, where embeddings live, where logs live, and where backups live.
Identity model documentation showing how authentication, authorisation, and access scoping work end-to-end.
Control mapping aligning the deployment to the applicable framework (ISM, Essential Eight, CPS 234, or the framework your assessor is testing against).
Audit logs for every query, every retrieved record, every action taken, every admin activity. Retained for the period your framework requires.
Change history of the infrastructure-as-code, model version pins, prompt template changes, and configuration changes.
Incident response runbook for likely failure modes (model regression, integration outage, identity compromise, data exfiltration suspicion).
Operational review cadence with monthly check-ins, quarterly control evidence refresh, annual framework review.

Classification handling

OFFICIAL. AU-region commercial endpoints commonly suitable (Pattern 1) with enterprise terms and audit logging. Verification by your security team.
OFFICIAL: Sensitive. AU-region commercial endpoints suitable in most cases (Pattern 1). Where the data is particularly sensitive, in-VPC open-weight models (Pattern 2) are preferred.
PROTECTED. In-VPC open-weight models (Pattern 2) or IRAP-assessed sovereign cloud (Pattern 3). Commercial endpoints not used unless the specific endpoint has a current PROTECTED IRAP assessment.
SECRET and above. Deployment scoped on a case-by-case basis with appropriately cleared personnel, physical security review, and infrastructure on or connected to ASD-managed networks (HSCN, ICON, where applicable). Engaged through a DISP-cleared primary or in a cleared environment.

Bedstone vs alternatives

Option	Best for	Trade-off
Use ChatGPT / consumer Gemini directly	Personal productivity. Not suitable for sovereign or regulated workloads.	Data leaves Australia, vendor terms not enterprise-grade, no audit trail, no identity-aware access.
Microsoft Copilot for Government	Microsoft 365 tenants already on AU-region with PROTECTED tenancy. Useful for general productivity inside that boundary.	Limited to Microsoft surface (Word, Excel, Teams). Does not reach your CRM, ERP, ticketing, or custom systems. Locked into Microsoft for the long term.
Big-four consulting AI practice	Politically convenient choice for some agencies. Strong on framework documentation.	Often subcontracts engineering. Pricing skews high. Delivery cadence skews slow. Resulting solution often resembles a slide deck more than a working system.
Build it yourself with internal team	Agencies and operators with a strong in-house AI engineering team and a multi-year horizon.	Requires retention of specialist talent in a market where it is scarce and expensive. Six to twelve-month build plus ongoing operate.
Bedstone sovereign deployment	Operators who want production AI delivered against AU sovereignty requirements without a multi-year internal build.	External agency engagement. Sovereignty requirements add to build complexity vs an unconstrained commercial deployment.

How we engage

Sovereign engagements run on the same engagement types as the rest of our work, with classification and clearance considerations built in.

Initial scoping call covers classification, frameworks, target environment, existing identity model, and target use case. 30 to 45 minutes.
Discovery sprint typically two to four weeks for sovereign work (longer than commercial discovery because the controls mapping and architecture review take more time). Produces architecture, controls map, risk register, and fixed-price quote.
Build phase typically four to twelve weeks depending on classification, frameworks, and integration breadth. We work alongside your security architect, IRAP assessor (where engaged), and internal audit.
Assessment support where IRAP assessment is in scope. We answer evidence requests, walk the assessor through the architecture, document findings and remediations.
Operate retainer for ongoing patching, model updates, control evidence refresh, incident response, and the annual review cycle.

Commercials

Discovery sprint. From $20,000 for sovereign discovery. Higher than commercial discovery because the controls mapping is more work.
Build. From $120,000, scaling with classification, frameworks, integrations, and target environment. PROTECTED workloads, multi-region deployments, and DISP-cleared engagements scale higher.
Operate retainer. From $15,000 per month covering patching, model updates, evidence refresh, incident response, and annual review.
Assessment support. Quoted separately, from $25,000, scaling with the assessor's evidence requests and system complexity.

See the pricing page for the broader engagement structure context.

Common questions

What does sovereign AI mean in Australia?

Sovereign AI in the Australian context means the data, the compute, and the operational control all remain under Australian jurisdiction. Data does not cross borders. Inference does not run in foreign regions. The infrastructure is operated by Australian-controlled entities or by trusted vendors with appropriate certifications. Personnel with privileged access are subject to Australian law and security clearances where required.

Is OpenAI, Anthropic, or Google AI sovereign?

By default, no. Commercial LLM APIs route to vendor regions, often US-based. Vendor enterprise tiers (Azure OpenAI Australia East, AWS Bedrock ap-southeast-2, Anthropic via Bedrock, Vertex AI australia-southeast1) bring inference to AU regions and contractually constrain data handling. For higher classifications or fully sovereign requirements, we deploy open-weight models on infrastructure inside your VPC or on IRAP-assessed environments. The answer depends on your classification and risk appetite.

What is IRAP and when does it apply?

IRAP is the Australian Government Information Security Registered Assessors Program. IRAP-endorsed assessors evaluate systems against the Information Security Manual (ISM) controls. IRAP assessment is commonly required when handling government data classified OFFICIAL, OFFICIAL: Sensitive, PROTECTED, or higher, or when contracting with agencies that require it. Bedstone delivers IRAP-aware infrastructure and AI workloads, meaning the architecture, controls, and evidence trail are designed to support an IRAP assessment by your assessor.

Can you build for PROTECTED workloads?

Yes. PROTECTED workloads require deployment to PROTECTED-certified environments. The AI architecture, identity model, audit trail, and operational practices are designed accordingly. Sensitive workloads above PROTECTED are scoped on a case-by-case basis with appropriate cleared personnel and infrastructure.

Where does inference run for a sovereign deployment?

For OFFICIAL and OFFICIAL: Sensitive workloads, AU-region commercial endpoints are commonly suitable. For PROTECTED or sovereign-only requirements, inference runs on open-weight models hosted in your own AU-region VPC on GPU instances, or in IRAP-assessed sovereign clouds. Data never leaves your environment.

Which sovereign cloud regions do you use?

AWS ap-southeast-2 and AWS sovereign regions where applicable, Azure Australia East and Azure Australia Central, Google Cloud australia-southeast1 and australia-southeast2, and Vault Cloud for PROTECTED-classified workloads. The choice depends on your existing posture, your classification, and the specific compliance frameworks in play.

How do you handle data residency and cross-border transfers?

By default, no cross-border transfer of data, prompts, embeddings, vector indexes, or model outputs. The deployment is configured so that AU-region endpoints are used for every storage and compute path. We document the data flow end-to-end. Where any third-party routing is unavoidable, it is identified and removed or substituted.

Do you do DISP-cleared engagements?

Where defence industry engagements require DISP membership at a given level, we engage as a subcontractor through a primary that holds the relevant DISP status, or we structure the engagement so that the cleared work is performed by appropriately cleared personnel inside a DISP-aligned environment. We do not misrepresent clearance status.