Why AI Rollouts Stall
Most AI initiatives do not fail at the strategy level, they stall at the point of approval.
Security teams, privacy officers, and compliance leads cannot approve AI tools for use with real operational data. Requirements under APRA (CPS 234, CPS 230), DORA, and the Australian Privacy Principles impose strict controls on how data is accessed, processed, and retained—controls that most AI tools do not meet.
- Sensitive data cannot leave controlled internal environments
- No clear audit trail of how data is handled or where it flows
- External AI providers introduce unacceptable data exposure risk
- Governance and access controls are insufficient for enterprise use
- Limited visibility into model behaviour and data handling
As a result, many of the AI tools the CIO wants are either blocked outright or used informally without approval.
At the same time, executive teams have made AI adoption a stated priority. Boards expect measurable progress, and the Chief AI Officer or equivalent role, needs a clear, defensible approval pathway. In most organisations today, that pathway does not exist.
The answer is a sovereign, local-first approach to AI.
This guide explains what that means: how to design and operate AI within a regulated Australian organisation, and the evidence required to demonstrate compliance with APRA (CPS 234, CPS 230), DORA, and the Australian Privacy Principles.
Why cloud AI keeps failing security review
Cloud AI providers have worked hard to address these concerns. Some offer settings that claim not to retain data, some sign enterprise contracts with stronger data protection terms, and some deploy in Australian regions. Even so, internal reviews of these products usually end with the same four issues.
The shape of the “no”
In regulated Australian organisations, Cloud AI reviews often end the same way, the compliance function cannot confidently tell the regulator that customer data stayed entirely within the organisation. Approval is consequently refused. This is not primarily a technical problem — it is a proof problem, and Cloud AI does not solve it.
Data still leaves the controlled environment
Even when a vendor offers “do not retain” settings or deploys in an Australian region, the data still leaves your internal systems and enters the vendor’s environment. That handover is the critical event. It does not matter how carefully the vendor handles the data after that point; from a security and compliance perspective, the transfer itself is the issue. Internal auditors usually read it that way as well.
Embeddings are an overlooked risk
Most real-world AI use cases depend on embeddings—numeric representations of source documents that enable semantic search and retrieval. In many cloud deployments, the provider generates and stores those embeddings. While embeddings are not raw text, they can still expose substantial information about the original content. They remain customer data, and most cloud AI reviews fail to account for this second data path.
The audit trail is a black box
When regulators or internal auditors ask what data left the organisation, when it left, who authorised it, and what returned, cloud AI platforms often cannot produce evidence that is sufficiently clear or independently verifiable. The vendor can usually show transactions, but not proof. This is the point at which compliance teams often refuse approval.
The evidence is incomplete
Even where a cloud AI tool appears well controlled, security review can still fail if the organisation cannot produce a complete evidence trail. Reviewers need to see what was approved, what was tested, what changed, and what controls were in place at each stage. If that proof is fragmented or missing, approval is usually withheld.
5
Legal privilege can be voided the moment data leaves the environment
In February 2026, the US District Court for the Southern District of New York ruled in United States v. Heppner that 31 documents a defendant generated using a public AI platform while preparing his own defence are not protected by attorney-client privilege or the work product doctrine. All are fully discoverable.
The court’s reasoning rests on three failures that apply to any regulated organisation using external AI:
The court further held that documents not privileged at the time of creation do not become privileged merely because they are later shared with counsel. Retrospective confidentiality is not available.
Heppner is a United States decision. The reasoning maps directly onto Australian privilege doctrine, which likewise depends on confidentiality and a lawyer-directed workflow. Australian and UK legal commentators are already treating it as persuasive for their own courts. Regulated organisations should assume the Heppner test — or something close to it — will surface in their own jurisdiction.
The practical implication reinforces the sovereignty case. An enterprise contract with a cloud AI vendor may reduce commercial risk, but it does not automatically preserve privilege. What preserves privilege is the same thing that satisfies APRA and DORA: data that never leaves the controlled environment, and an audit trail your organisation produces itself.
The rules that apply
Four sets of rules define what sovereign AI must do in a regulated Australian organisation:
Rulebook | In effect | Who it covers | Key AI-related duties |
|---|---|---|---|
APRA CPS 234 | In force | APRA-regulated bodies and their key suppliers | Strong information security, checks on third parties, incident reporting |
APRA CPS 230 | From July 2025 | Same, wider scope | Business resilience, mapping of critical work, limits for how long a service can be down |
Australian Privacy Principles | In force | Organisations covered by the Privacy Act and APPs | Data handling, sending data overseas, breach reporting |
DORA (EU) | January 2025 | In-scope EU financial entities and related service providers | ICT risk management, third-party risk, resilience testing |
Three more rules, the privacy law reforms under review, the voluntary AI safety standards, and the Cyber Security Act 2024 — point to where regulation is heading, but they do not yet impose specific technical requirements. The four rules above are what current AI review processes will assess.
For AI adoption, the key requirement is straightforward: protected data, or CPS 234 information assets, must remain within the controlled environment unless any transfer is documented, approved, and recorded in the vendor risk register. In practical terms, the AI should operate inside the controlled environment, not the data.
Emerging case law
Regulation is not the only signal to watch. Court decisions in comparable jurisdictions establish patterns that Australian and EU courts frequently adopt. The most consequential recent example is Heppner.
Case | Jurisdiction | Decided | Relevance to Sovereign AI |
|---|---|---|---|
United States v. Heppner | US District Court, Southern District of New York | Feb 2026 | Interactions with public AI platforms are not protected by legal privilege. Confidentiality is broken the moment data leaves the controlled environment, and cannot be reclaimed retrospectively. Persuasive precedent for Australian and UK courts. |
What “sovereign AI” actually means
People use the term “sovereign AI” in many different ways. In this guide, we define it clearly:
An AI system is sovereign if all four of these are true:
- the model runs on systems the organisation controls directly
- the source data used by the model never leaves the environment
- any embeddings, caches or other copies made from that data are created and stored inside the environment
- the audit trail that records every AI action is created by the organisation, not by an outside vendor
What the sovereign AI layer does not require: :
- The model does not have to be trained in Australia
- The model does not have to be built by an Australian company
- There is no need for a GPU cluster built from scratch
- Models such as Claude, GPT, Mistral, Qwen, and BAAI can still be used, provided the layer that runs them is sovereign
Note: The definition is intentionally strict. Looser definitions fail regulator review. If customer data leaves the controlled environment, the system is not sovereign, regardless of vendor promises.
The five things to get right
A production-grade sovereign AI setup in a regulated Australian organisation has five parts. Each one addresses a specific weakness of cloud AI.
Local model hosting
The AI model runs in an in-house data centre, a private cloud region, or an isolated lab environment. This is now practical for a wide range of model sizes.
Small open-weight models such as Qwen 2.5, Mistral 7B, and Llama 3 can run on modest GPU hardware. Larger open-weight models can run on a small dedicated cluster.
If a hosted model such as Claude or GPT-4.0 is required, a sovereign gateway is used instead.
Local retrieval layer
Most practical enterprise AI use cases use Retrieval-Augmented Generation, or RAG. RAG works by finding relevant documents and passing them to the AI.
In a sovereign setup, the embedding model runs inside the controlled environment. BAAI BGE-M3 is a strong option for multilingual use cases, while BGE-Small is a lower-cost option for English-only work.
The document search index also sits inside the controlled environment. The source documents, embeddings, and search traffic never leave it.
Local document grounding
The software layer that finds relevant documents, extracts the useful sections, and builds the AI prompt must also run inside the controlled environment.
It must handle common enterprise file types such as PDF, DOCX, XLSX, MSG, EML, HL7, and video captions.
It must also point back to the source document and page in every answer so the result can be checked.
PII redaction gateway
When an external model is used, whether cloud-based or vendor-hosted, a redaction gateway sits between the user and the model.
It detects personal information such as tax file numbers, Medicare numbers, credit card numbers, and patient IDs, and replaces them with safe tokens before any prompt leaves the controlled environment.
When the response returns, the system restores the original values. In this way, customer data remains inside the controlled environment at all times.
Verifiable audit chain
Every AI action, including each read, write, prompt, and response, is recorded in an immutable audit log.
The entries are cryptographically linked, making any alteration detectable.
This gives the compliance function the evidence it needs to respond to regulators. In most cloud AI setups, that level of independent, verifiable proof is not available.
I’d recommend the second version if you want it to sound more formal and board-ready. It is a little cleaner, and it avoids the awkward “exact evidence” repetition.
Each of the five components is achievable on its own. The challenge is integrating them into a single, governed platform for sovereign AI. That is where many standalone deployments fail.
Codebridge delivers a single integrated platform
Codebridge brings the five identified components together in one system. If any part is missing, the architecture no longer functions as a true sovereign AI platform, and security or compliance review is likely to stop the rollout. Each capability is delivered through the Codebridge platform, with multiple tools working together to support the full operating model.
Sovereign component | Codebridge tool | What it does | |
|---|---|---|---|
Local model hosting | CIM plus optional on-site GPU setup | Installs and runs open-weight models on site with safety controls. That works well because: | |
Local embeddings and vector storage | OBY for code context plus Turbo Tools indexing | Runs BGE-M3 embeddings and the search index on site, with no outside calls | |
Local document grounding | Turbo Tools | Reads more than 20 file types on site, extracts the relevant page content, and redacts personal information as it processes the document | |
PII redaction gateway | Guardee | Uses more than seven detectors, including tax file numbers, Medicare numbers, credit card numbers, and patient IDs, and restores the original values in the final answer | |
Verifiable audit chain | CIM, WPCTL, plus tool-native logs | Produces a single tamper-proof log covering every tool action across the platform |
Two additional tools support the engineering layer of the platform: OBY maintains a live map of the codebase for accurate AI changes, and CodeScan checks every AI-generated change for security issues before deployment. Together with the five components above, these tools enable Codebridge to deliver sovereign AI-native engineering inside a regulated business.
Evidence of CPS 234 Compliance
Below is a direct mapping from APRA CPS 234 controls to the sovereign AI components implemented by CodeBridge. Full mappings for CPS 230, DORA, the Australian Privacy Principles, HIPAA, and SOC 2 are provided in the PDF or available on request.
*Please note: The term Para in the table below = Paragraph number of CPS 234 control
CPS 234 control | What it requires (summary) | How Codebridge covers it | Status |
|---|---|---|---|
Para 15 | Clear roles and duties for information security | CIM enforces role-based access to every action, with a named-user record | Full |
Paras 20-22 | Security capability matched to the size and risks of the business | CodeScan multi-layer detection, OBY impact analysis, and BE (BackEnd) architecture stress tests | Full |
Paras 24-25 | Information-security controls | Local-first design, Guardee PII redaction, CIM safety controls | Full |
Para 27 | Detection of security incidents | Spectral continuous checks, CIM audit trail, Guardee policy-breach alerts | Full |
Paras 28-30 | Reporting material incidents to APRA | Structured incident export from the CIM audit trail, ready to lodge with APRA | Needs internal process linkage |
Paras 33-35 | Testing that the security controls actually work | Spectral fuzz testing, CodeScan continuous scans, OBY-driven test updates | Full |
Para 36 | Internal audit review | Read-only observer role in CIM, plus exportable audit trail for internal audit sampling | Full |
Sovereign AI Design in Practice
Here is a simple view of the sovereign AI design for a regulated Australian organisation:
Application Layer
User-facing app, chat, coding IDE
Guardee Gateway
PII redaction, policy checks
Model Router
Chooses a local or vendor model
Turbo Tools
Local document reading: PDF, DOCX, HL7
Local Vector Store
BAAI BGE-M3 embeddings, indexed on-site
OBY / CodeScan
Code map, security checks, all local
Local Model
Qwen 72B, Mistral Large, Llama 3 70B, BGE-M3
Vendor Model (optional)
Claude, GPT via the redaction gateway only
CIM Audit Chain
Tamper-proof log, exportable
All boxes sit inside the control boundary. Vendor model calls only happen after Guardee has removed personal information, and only when internal policy allows.
The key point of this design is that every call to an outside vendor, if used, has already had customer personal information removed by Guardee. What leaves the boundary is a safe prompt with tokens in place of real values. What comes back is a safe answer. Guardee restores the real values before it reaches the user. From a compliance perspective, no customer data leaves the boundary.
Frequently asked questions
Book a consultation with Codebridge.
Thirty minutes with a Codebridge principal. Bring the specific question a CISO, privacy officer or audit lead is stuck on. A CodeBridge principal will walk through what a sovereign path looks like in the applicable environment.