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 Australian regions of the major enterprise cloud providers. Data stays in Australia for the duration of the inference call, and enterprise terms apply: no training on your data, AU-region routing, and audit logs you can pull. The provider is a contractual counterparty rather than a design dependency, because model choice here is configuration.

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 deployed on GPU instances inside your own AU-region VPC, served by a standard inference runtime. No third-party endpoint is involved at any point. The weights sit on your storage, the inference runs on your compute, and nothing about the request leaves 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

We stay deliberately model-agnostic and keep the exact mix under the hood. What matters to a sovereignty assessment is not the brand on the weights, it is where inference runs and who can reach the data. The choice is made on four axes:

Small open-weight models. Fit on a single GPU. The right call for edge, constrained-resource and cost-sensitive in-VPC deployments where the task is well defined.
Mid-size open-weight models. The common default for in-VPC work. Strong general capability on a single GPU or a small cluster, which keeps the operational burden proportionate.
Large open-weight models. For the hardest reasoning and long-context retrieval where a smaller model measurably underperforms. Needs a real cluster, and we will tell you when the task does not justify one.
Closed-weight models on AU-region enterprise endpoints. Highest general capability, inference in Australia, enterprise terms. Appropriate where Pattern 1 is acceptable and vendor risk has been assessed and accepted.

On the provenance question, which comes up in every government conversation. Some of the strongest open-weight models originate outside Australia and outside allied jurisdictions. Because the weights are open and the inference runs inside your environment, the sovereignty position rests on the inference and the data path rather than on where the weights were trained. That is a defensible argument, and it is also one your assessor should be walked through explicitly rather than left to infer. We do that walkthrough as part of the engagement.

Model choice is configuration, not architecture. We design deployments so swapping the underlying model is a settings change rather than a rebuild, which is what stops a sovereignty posture from being hostage to one provider’s terms, pricing or availability. Under NDA we will take your infosec and procurement teams through the full architecture and data flow.

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 (your existing directory, cloud or on premise). 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.

Are the big commercial AI services sovereign?

By default, no. The consumer and standard API tiers route inference to the provider’s own regions, commonly in the United States, and your data leaves Australia to be processed. The enterprise tiers of the major cloud providers do bring inference into Australian regions and contractually constrain data handling, which is enough for OFFICIAL and most APRA-regulated work where vendor risk has been assessed and accepted. For higher classifications, or where a foreign vendor in the data path is unacceptable regardless of contract, that is not enough and you need inference running inside your own environment. We build for either position and will tell you which one your workload actually requires rather than selling you the more expensive one by default.

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.