GUIDE: PRIVATE AIPrivate AI for regulated enterprises

For APRA-regulated entities, private AI is one way to meet existing obligations under CPS 230 and CPS 234, not a separate rulebook. Choose it per use case.

By Ramesh Emandi, Co-Founder and CTOPublished 7 November 2026Last updated 7 November 2026Regulation checked 7 Nov 2026

Where does your prompt go?

* Depends on provider and product.

Stays in Australia or your networkCrosses borderRequest path

Storage location and inference location are separate questions. Read about data sovereignty

One request from a user, through your app to the model, and into logs. Pick a deployment option to see where each part runs or is stored; dashed lines leave Australia. Illustrative. Real data flows depend on provider, product and contract.

Data-flow map: where the user, app, model inference, logs and storage, and external tools sit (your network, an Australian region or overseas) under hosted API, private cloud and on-premises deployment.
Component	Hosted API	Private cloud	On-premises
User	Your network	Your network	Your network
App	Your network	Australian region	Your network
Model inference	Overseas (depends on provider and product)	Australian region	Your network
Logs and storage	Overseas (depends on provider and product)	Australian region	Your network
External tools	Overseas	Overseas (can be switched off)	Your network (can run offline)

In short

Private AI means running large language models where you control the data, the model and the logs: in your own data centre, on dedicated hardware, or in a tightly scoped cloud tenancy. For APRA-regulated entities it is one way to meet existing obligations under CPS 230 and CPS 234, not a separate rulebook. Choose it per use case.

There is no single right answer for every workload. A marketing assistant drafting public copy can use a hosted API with little risk. A claims triage model reading health information, or an agent with write access to your core systems, is a different decision. This guide sets out the options, the trade-offs, how Australia’s current rules apply, and a governance framework you can put in place this quarter.

Everything regulatory here is general information as at 7 November 2026, with links to the primary source. It is not legal advice.

What is private AI, and how is it different from a private LLM?

The terms are used loosely, so it helps to separate four ideas.

Private AI is the broad goal: AI systems whose data, prompts, outputs and logs stay inside boundaries you set and can evidence.
A private LLM is a specific model instance that only your organisation uses. It may be an open-weight model you host, or a dedicated deployment of a commercial model.
On-premises (on-prem) AI means the model runs on hardware in your own facilities or a data centre you control, sometimes fully offline.
Data sovereignty is a legal question: which country’s laws can reach the data. It is related to, but not the same as, data residency (where the data physically sits).

The distinction matters because a vendor can offer residency without full sovereignty. For example, OpenAI’s help centre lists Australia as a data residency region for storing ChatGPT Enterprise content at rest, but as at 7 November 2026 lists only Europe, the United States and the United Arab Emirates for inference residency, where the model actually processes your content. [1] Storage in Australia does not by itself mean processing in Australia.

Why are regulated enterprises moving LLMs onto their own infrastructure?

Four pressures show up repeatedly.

1. The regulator has named the risks. APRA’s letter to industry of 30 April 2026 found that some entities depended heavily on a single AI provider, few had tested exit or substitution plans, and staff were using enterprise AI tools “outside approved control frameworks”. [2] In June 2026 APRA Member Therese McCarthy Hockey went further: frontier AI is “a third-party risk, a concentration risk and a sovereign access risk”, because a process that “depends on a single offshore frontier AI model may be disrupted not only by an outage or cyber incident but by a regulatory decision made overseas.” [3]

2. Privacy law expects restraint with personal information. The Office of the Australian Information Commissioner (OAIC) recommends, as best practice, that organisations “do not enter personal information, and particularly sensitive information” into publicly available generative AI tools. [4] From 10 December 2026, organisations covered by the Privacy Act must also explain in their privacy policy when a computer program makes, or substantially and directly helps make, decisions that could significantly affect individuals. [5]

3. Open-weight models are now good enough for many tasks. Google, OpenAI, Mistral, NVIDIA, DeepSeek and Moonshot AI all publish model weights that you can run on your own hardware (see the model section below). That was not true at this quality two years ago.

4. Cost becomes predictable at volume. Hosted APIs charge per token. Owned or dedicated hardware is mostly a fixed cost. Above a certain sustained volume, and for an equal-quality model on your evals, the fixed cost wins. Our cost guide works through the break-even formula.

None of these means everything should be private. They mean the choice should be deliberate and documented.

Hosted API, private cloud or on-premises: which should you choose?

Most enterprises end up with a mix. The table below compares the three main deployment patterns.

	Hosted API (provider’s shared service)	Private cloud (dedicated tenancy or endpoint in a chosen region)	On-premises (your hardware, your facility)
Control over data path	Lowest. Prompts and outputs pass through the provider; residency options vary by product and region.	Medium to high. Network isolation and regional pinning are available, but check where inference, logging and support access actually happen.	Highest. You decide what leaves the building, including nothing at all.
Model choice	Frontier closed models (Claude, GPT, Gemini) plus some open models.	Frontier models offered by the cloud, or open-weight models you deploy.	Open-weight models only, unless a vendor licenses an on-prem build.
Cost shape	Pure variable cost per token. Low start-up cost. Spend grows with use.	Mixed. Per-token or reserved capacity, plus networking and platform fees.	Mostly fixed. Hardware, power, space and the team to run it. Marginal cost per token is low once utilised.
Latency	Depends on the provider’s region and load. Can vary at peak times.	Predictable if capacity is reserved in-region.	Lowest and most predictable for users on the same network; works offline.
Compliance effort	Lower build effort, higher assurance effort: supplier due diligence, contracts, offshoring notices, exit plans.	Moderate. Shared responsibility model; you configure and evidence the controls.	Higher build and operating effort, simpler data-flow story. You own patching, monitoring and model updates.
Choose it when	The data is public or low sensitivity, you need the strongest reasoning or live web research, or volume is low and spiky.	You want frontier models with regional processing and private networking, and the provider’s terms satisfy your risk team.	Data is highly sensitive or cannot leave your network, sites are remote or offline, volume is sustained, or you need to evidence exactly where every token went.

Two practical notes on private cloud:

Read the regional fine print. Amazon Bedrock, for example, offers an Australia and New Zealand cross-region inference profile designed so that inference “stays within Australia and New Zealand”; requests from Sydney and Melbourne stay between those two regions, while requests from Auckland can be processed in Auckland or Australia. [6] That is useful, but it is a specific configuration, not a default.
Residency is not the whole question. Your risk team will also ask who can access the environment for support, where logs and abuse-monitoring data go, and which overseas laws reach the provider.

For cost comparisons between models, see the LLM price index. For your own workload, try the AI cost calculator.

Deployment decision sorter

Data sensitivity

Monthly volume

Connectivity

In-house capacity to run models

Test the cost of this option

How this works

Each answer adds points to each option, and the highest score wins. Two rules override the points: restricted data takes the hosted API out of contention, and an offline site rules out both the hosted API and private cloud.

Data sensitivity: Public (Hosted API +3, Private cloud +1, On-premises +0); Internal (Hosted API +2, Private cloud +2, On-premises +1); Confidential (Hosted API +0, Private cloud +3, On-premises +2); Restricted (Hosted API +0, Private cloud +1, On-premises +4).
Monthly volume: Low (Hosted API +3, Private cloud +1, On-premises +0); Medium (Hosted API +2, Private cloud +2, On-premises +1); High (Hosted API +0, Private cloud +3, On-premises +2); Very high (Hosted API +0, Private cloud +2, On-premises +3).
Connectivity: Always online (Hosted API +1, Private cloud +1, On-premises +1); Intermittent (Hosted API +0, Private cloud +1, On-premises +3); Offline (Hosted API +0, Private cloud +0, On-premises +5).
In-house capacity to run models: None (Hosted API +3, Private cloud +2, On-premises +0); Some (Hosted API +1, Private cloud +2, On-premises +2); Strong (Hosted API +0, Private cloud +2, On-premises +4).

When the top two viable options score within 10 per cent of each other, the sorter suggests a mixed estate. Current inputs: Internal, Medium, Always online, Some.

Pick the profile closest to your use case. Each answer adds points to each option; restricted data and offline sites rule some options out. Illustrative. A starting point for discussion, not a recommendation for your organisation.

Deployment decision sorter: choose data sensitivity, monthly volume, connectivity and in-house capacity to score hosted API, private cloud and on-premises deployment.
Option	Score	Status
Private cloud	7	best fit
Hosted API	6	viable
On-premises	5	viable

What does APRA expect when you use AI?

APRA has not issued an AI-specific prudential standard. Its April 2026 letter says plainly that “existing prudential standards apply to AI risk” and that its framework is “technology and vendor agnostic”. [2] In practice, two standards do most of the work.

CPS 234 Information Security has been in force since 1 July 2019. It requires entities to classify information assets, “including those managed by related parties and third parties, by criticality and sensitivity”; to implement controls commensurate with that classification; to test those controls systematically using “appropriately skilled and functionally independent specialists”; to have internal audit review controls, including those maintained by third parties; and to notify APRA within 72 hours of a material information security incident and within 10 business days of a material control weakness it cannot fix in time. [7] APRA’s guide CPG 234 expands on how to do this. [8]

CPS 230 Operational Risk Management commenced on 1 July 2025, and an amended version with targeted changes took effect on 1 July 2026. [9][10] It requires entities to manage operational risk (explicitly including technology, data and change management risk), maintain critical operations within tolerance levels through severe disruption, and manage material service providers and the fourth parties they rely on. Entities must notify APRA within 72 hours of a material operational risk incident, within 20 business days of entering or materially changing an agreement for a service relied on for a critical operation, and before entering any material offshoring arrangement, “including in circumstances where data or personnel relevant to the service being provided will be located offshore.” [9]

CPG 235 Managing Data Risk is APRA’s guidance on data quality and data risk, relevant to anything you feed into retrieval systems or fine-tuning. [11]

The April 2026 letter then sets out what APRA wants to see for AI specifically [2]:

board literacy and an AI strategy aligned with risk appetite;
“an inventory of AI tooling and AI use cases”, with owners across the lifecycle;
“human involvement for high-risk decisions and accountability”;
mapping of the AI supply chain, including fourth parties, and “active management of concentration risk”, with credible substitution, portability or exit arrangements;
contracts covering audit rights, model updates, incident notification and data handling;
security controls for AI attack paths such as prompt injection, data leakage and insecure integrations;
“controls over agentic and autonomous workflows”, including identity and access for non-human actors;
continuous monitoring proportionate to each use case, rather than point-in-time testing.

APRA said it “will take stronger supervisory action and, where appropriate, pursue enforcement” where entities fail to manage AI risk proportionately. [2]

How do CPS 230 and CPS 234 map to an LLM deployment?

General information, not legal advice. This table is our reading of how published APRA requirements could apply to a typical LLM deployment. It does not cover every obligation, and your obligations depend on your entity type and circumstances. Confirm with your compliance and legal advisers.

Requirement (source)	What it means for an LLM deployment	Practical control
Classify information assets by criticality and sensitivity, including those held by third parties (CPS 234) [7]	Prompts, retrieved documents, embeddings, outputs, fine-tuning data and logs are all information assets.	Data classification rules for AI inputs; block or route restricted data to private models only; treat vector stores and logs as classified stores.
Controls commensurate with classification; systematic testing by independent specialists (CPS 234) [7]	Model endpoints, retrieval layers and agent tools need the same rigour as any system holding that data.	Penetration testing that includes prompt injection and data exfiltration attempts; independent red-team review before go-live and after major changes.
Internal audit reviews controls, including those of third parties (CPS 234) [7]	Audit needs evidence of what the model saw and did.	Immutable logs of prompts, retrieved sources, outputs, user identity and tool calls; retention aligned to your records policy.
Notify APRA within 72 hours of material incidents (CPS 234 and CPS 230) [7][9]	A data leak through an AI tool, or an AI failure disrupting a critical operation, may be notifiable.	Add AI scenarios to incident playbooks; define what counts as a material AI incident; rehearse.
Manage technology, data and change management risk (CPS 230) [9]	Model version changes, prompt changes and new data sources are changes.	Change control for models and prompts; regression evals before each release; rollback to the previous model version.
Maintain critical operations within tolerance through disruption (CPS 230) [9]	If AI supports a critical operation, a provider outage or model withdrawal is a continuity event.	Documented fallback (manual process or alternative model); tested failover between hosted and private models.
Material service provider register; manage fourth parties (CPS 230) [9]	A model provider, and the cloud it runs on, may be material service providers.	Include AI providers in the register; map the chain (app vendor, model provider, cloud host).
Notify APRA before material offshoring, including where data is offshore (CPS 230) [9]	Hosted inference outside Australia may be offshoring, even if storage is onshore.	Confirm where inference, logging and support access occur; use in-region processing or private deployment where needed.
Inventory of AI tools and use cases; lifecycle ownership (APRA letter, Apr 2026) [2]	You cannot govern what you have not listed, including AI features inside SaaS tools.	AI register with owner, purpose, data classes, model and version, risk tier, last eval date.
Human involvement for high-risk decisions (APRA letter) [2]	Credit, claims, hardship and complaints decisions need a real human decision point.	Risk-tiered approval steps; reviewers see the model’s sources and confidence; sampling of approved outputs.
Controls over agentic workflows and non-human identities (APRA letter) [2]	Agents act with credentials.	A distinct identity per agent; least-privilege scopes; approval gates on write actions; kill switch.
Concentration risk and credible exit (APRA letter; CPS 230) [2][9]	Reliance on one frontier model is a single point of failure.	Model-agnostic gateway; evals that let you swap models; at least one tested alternative, which can be a private open-weight model.
Enforceable restrictions on shadow AI (APRA letter) [2]	Policy alone has not stopped staff pasting data into public tools.	Approved private assistant with SSO; network or browser controls on unapproved AI sites; data loss prevention on uploads.

APRA controls on an LLM architecture

Each chip is a requirement and its source. Click one to see where it lives.

Where each requirement physically sits in a typical LLM architecture. Click a requirement to see what it means and the practical control. General information, not legal advice. Mapping is our reading of the standards. As at 7 Nov 2026.

APRA control map: twelve requirements from CPS 230, CPS 234 and APRA's letter, placed on the layers of an LLM architecture: users and SSO, AI gateway, models, retrieval, agent tools, and logging and monitoring, which connects to every layer.
Requirement	Source	Where it lives	Practical control
Classify AI data	CPS 234	AI gateway	Data classification rules for AI inputs; block or route restricted data to private models only; treat vector stores and logs as classified stores.
Test for prompt injection	CPS 234	Models	Penetration testing that includes prompt injection and data exfiltration attempts; independent red-team review before go-live and after major changes.
Immutable AI audit logs	CPS 234	Logging and monitoring	Immutable logs of prompts, retrieved sources, outputs, user identity and tool calls; retention aligned to your records policy.
72-hour incident notice	CPS 234, CPS 230	Logging and monitoring	Add AI scenarios to incident playbooks; define what counts as a material AI incident; rehearse.
Change control for models	CPS 230	Models	Change control for models and prompts; regression evals before each release; rollback to the previous model version.
Tested fallback and failover	CPS 230	AI gateway	Documented fallback (manual process or alternative model); tested failover between hosted and private models.
Check where inference runs	CPS 230	Models	Confirm where inference, logging and support access occur; use in-region processing or private deployment where needed.
AI inventory and register	APRA letter	Users and SSO	AI register with owner, purpose, data classes, model and version, risk tier, last eval date.
Human approval for high-risk decisions	APRA letter	Agent tools	Risk-tiered approval steps; reviewers see the model's sources and confidence; sampling of approved outputs.
Agent identity	APRA letter	Agent tools	A distinct identity per agent; least-privilege scopes; approval gates on write actions; kill switch.
Exit plan	CPS 230, APRA letter	Models	Model-agnostic gateway; evals that let you swap models; at least one tested alternative, which can be a private open-weight model.
Restrict shadow AI	APRA letter	Users and SSO	Approved private assistant with SSO; network or browser controls on unapproved AI sites; data loss prevention on uploads.

What should an AI governance framework include?

An AI governance framework is the set of roles, rules and evidence that lets you use AI at the pace the business wants while staying inside your risk appetite. For Australian organisations, two public references help. The Australian Government’s Guidance for AI Adoption, published 21 October 2025, sets out six essential practices: decide who is accountable; understand impacts and plan accordingly; measure and manage risks; share essential information; test and monitor; and maintain human control. [12][13] It “evolves” the earlier Voluntary AI Safety Standard. [14] For APRA-regulated entities, the April 2026 letter adds the specific expectations listed above. ISO/IEC 42001 (AI management systems) is an optional international reference.

A workable framework has seven parts:

Ownership. A named executive owner for AI risk, and an owner for each AI system.
Inventory. Every model, AI feature and agent, including those embedded in SaaS products, with purpose, data classes and risk tier.
Risk tiers. For example: tier 1, internal productivity on low-sensitivity data; tier 2, customer-facing or using personal information; tier 3, decisions that significantly affect people or actions in core systems. Controls scale with the tier.
Data rules. Which data classes may go to which deployment type. This is where hosted, private cloud and on-prem become a policy, not a debate.
Evaluations. Task-specific tests run before launch, on every model or prompt change, and on a schedule, covering accuracy, harmful output, bias where relevant, and prompt injection.
Logging and monitoring. Who asked what, what the model retrieved and produced, what actions it took, and drift over time.
Supplier and exit management. Contracts, the service provider register, and a tested plan to switch models.

The Privacy Act change on 10 December 2026 belongs in part 4 and part 6: if a program makes or substantially and directly helps make decisions that significantly affect individuals using their personal information, your privacy policy must describe the kinds of personal information used and the kinds of decisions involved. [5] Separately, the Attorney-General released an exposure draft Privacy Amendment (Personal Data Protection) Bill 2026 on 31 August 2026, with submissions closing 18 September 2026. [15] It is a draft, so watch for the final bill.

Is AI regulated in Australia, and are mandatory guardrails coming?

As at 7 November 2026, Australia has no AI-specific act and no mandatory AI guardrails. In 2024 the government consulted on mandatory guardrails for high-risk AI. Its consultation page now says it “will not proceed at this time with previous proposals to introduce mandatory guardrails for AI development and deployment”, and that the feedback informed the National AI Plan, published 2 December 2025. [16][17]

That does not mean AI is unregulated. Existing law applies: privacy, consumer, anti-discrimination, workplace and sector rules, and for directors, duties of care and diligence. The National AI Centre makes this point directly in its guidance. [13] For financial services, APRA’s prudential standards apply in full, and the Guidance for AI Adoption is the government’s recommended practice. “At this time” leaves room for change, so recheck before relying on this section.

How do you keep AI data in Australia?

Data sovereignty for AI comes down to four questions. Ask them of every deployment option.

Where is data stored at rest? Including prompts, outputs, files, embeddings, backups and logs.
Where is inference performed? This is often different from storage, as the OpenAI example above shows. [1]
Who can access it, and under which laws? Support staff, subcontractors and the provider’s parent company may sit in other jurisdictions.
What leaves through integrations? Web search, plug-ins and agent tools may send data to third parties under their own terms. OpenAI’s own documentation notes that data sent to external apps or MCP servers is handled under that provider’s terms. [1]

Options, from least to most control:

Hosted API with residency options, where the specific model and feature support in-region storage and processing.
In-region cloud deployment with private networking and a geographic inference setting, such as the Bedrock profile described earlier. [6]
Sovereign or government-certified hosting. Australian Government agencies use the Hosting Certification Framework, which assesses providers on data sovereignty, ownership, supply chain and transparency. [18] It is a government framework, but some private-sector risk teams use it as a reference point.
On-premises or dedicated hardware you control, including fully offline operation.

Under CPS 230, remember the offshoring test is about where the service is performed, including where data or personnel are located, not where the provider is incorporated. [9]

Which open-weight models can you run privately?

As at 7 November 2026, the main open-weight families from the providers we track include:

Google Gemma 4, released 2 April 2026 in sizes from small edge models to a 31B dense model, with further variants since. [19]
OpenAI gpt-oss (gpt-oss-120b and gpt-oss-20b), released 5 August 2025, designed to run on infrastructure you control. [20]
Mistral 3, released 2 December 2025 under the Apache 2.0 licence. [21]
NVIDIA Nemotron 3 (Nano, Super and Ultra), with open weights, datasets and tools. [22]
DeepSeek V4, with the V4 Pro release on 13 August 2026. [23]
Moonshot AI Kimi K3, and Kimi K3.1 Pro, whose weights are now published on Hugging Face under Moonshot’s own Kimi licence. [24]

Three cautions. First, licences differ. Some are permissive, some carry use restrictions, so have legal review each one. Second, public benchmarks do not tell you how a model performs on your documents and edge cases; your own evals do. Third, the country of origin of a model’s developer may matter to your risk team even when the weights run entirely on your hardware, because the question shifts from data flow to supply-chain assurance. Running a model offline removes the data-egress risk, but you still need to test its behaviour.

The largest models need multi-GPU servers; smaller ones run on a single workstation-class GPU. Size the hardware against the model you have proven on your evals, not the other way round.

What should move to the cloud, and what should stay private?

Cloud migration and private AI are not opposites. The case for moving general workloads to the cloud still holds: elastic capacity, pay-as-you-go pricing, managed security services and easier collaboration across sites. Most organisations should keep moving suitable systems there.

The useful question for AI is narrower: where should each workload’s data and inference sit?

General information, not legal advice. This table is a starting point for discussion, not a recommendation for your organisation. Your obligations depend on your entity, data and contracts.

Workload	Usually suits the cloud	Usually suits private or on-prem
Public content drafting, marketing, code on non-sensitive repositories	Yes	No
Research that needs live internet data and frontier reasoning	Yes, hosted frontier models	No
Internal knowledge search over policies and procedures	Either; depends on classification	If documents are restricted or confidential
Customer communications using personal information	In-region private cloud with strong terms	Yes, where policy requires
Health, financial hardship or other sensitive information	Only with in-region processing and assurance	Yes
Agents with write access to core systems	Possible with strict controls	Often preferred, for full logging and network isolation
Remote or low-connectivity sites	No	Yes, offline

A sensible migration plan for AI follows the same steps as any cloud migration: assess what you have, classify it, choose the platform per workload, migrate in stages, and test before cut-over. The difference is that the classification step decides the deployment type, and you should design the architecture so that a workload can move between hosted and private models without a rebuild.

How do you deploy AI agents like OpenClaw securely?

Agents raise the stakes because they act, not just answer. The National AI Centre’s September 2026 industry sessions summed it up as “a delegation problem, more than a technology problem”, and suggested four questions for any agentic system: what can it access, what can it do, what authority has it been given, and who remains accountable? [25]

What OpenClaw is. OpenClaw is a free, open-source (MIT licensed) AI agent that runs on your own machine and takes instructions through messaging apps such as WhatsApp, Telegram, Slack or Signal. It can browse the web, read and write files and run shell commands, with “full access or sandboxed” as a configuration choice, and it works with hosted or local models. [26] It was created by Peter Steinberger, first published in November 2025, and renamed OpenClaw on 30 January 2026 after earlier names including Clawdbot and Moltbot. [27] It is now stewarded by the OpenClaw Foundation, an independent US non-profit; OpenAI is a donor and employs Steinberger, but the Foundation states OpenClaw is not an OpenAI product. [26]

Why it is searched so much. It was one of the fastest-growing projects in GitHub’s history, Chinese technology companies built services on it [33], and in March 2026 Chinese authorities moved to restrict its use at state agencies, state-owned enterprises and banks over security concerns (as reported by Bloomberg and others). [32] Microsoft and Google have since built comparable assistants. [27]

The security picture. Cisco’s AI security researchers found a third-party OpenClaw skill performing data exfiltration and prompt injection without the user’s knowledge. [28] The project’s security page lists 722 published fixes, grouped by area, with gateway and authorisation, and execution and sandboxing, the largest categories. [29] An audit by Trail of Bits, published in September 2026, found 24 severity-rated issues (none critical, two high), all since fixed. [30] The project’s stated threat model assumes “one trusted operator”, and it does not treat prompt injection on its own, or a malicious plug-in installed by the operator, as a vulnerability. [29] That is a reasonable model for a personal assistant. It is not an enterprise model. In September 2026 the Foundation announced OpenClaw Enterprise, an open-source control plane with multi-tenancy and audit features, which it describes as suitable for “internal pilot workloads” ahead of a 1.0 release. [31]

Five controls for any enterprise agent, OpenClaw or otherwise:

Run it inside your boundary. Self-hosted, on hardened infrastructure, with outbound traffic through a proxy you control.
Give it its own identity. A separate account per agent, least-privilege scopes, short-lived credentials, never a person’s full login.
Vet every skill and plug-in. Review code and network behaviour before installation; maintain an allow-list.
Gate consequential actions. Human approval for sending external email, moving money, changing records or deleting data; hard limits on everything else.
Log and monitor everything. Every instruction, tool call and output, with alerts on unusual access and a tested kill switch.

These map directly to APRA’s expectation of “controls over agentic and autonomous workflows”. [2] Our OpenClaw post covers the five pillars in more depth.

How do we approach it at Quantana?

We help enterprises adopt AI to improve bottom-line performance and growth. For private AI, that means:

A mix of models, chosen per use case. We use Claude, OpenAI and Gemini models alongside open-weight models from Google, OpenAI, Mistral and NVIDIA, and we benchmark others, including DeepSeek and Kimi.
Our own physical hardware, or yours. Open-weight models run on custom-assembled Nvidia GPU pods that we build, or on the client’s existing infrastructure. Most client use cases run offline.
Evals before and after every change. Each model is tested on the client’s own tasks, and re-tested when models, prompts or data change.
Systems that keep improving. We build continuously improving, self-learning systems, so quality is reviewed as an ongoing process rather than once at launch.
SecGPT Vault, our private, secure AI offering, with single sign-on and audit logs.
Certified delivery. Quantana is ISO 9001 and ISO/IEC 27001 certified.
A structured path. The Quantana Path runs Map, Solve, Prove, Grow: map use cases, data classes and obligations; solve with the right deployment per workload; prove it with evals and evidence your risk team can use; then grow what works.

We have delivered 250+ projects and trained 10,000 business professionals, from offices in Brisbane, San Ramon and Hyderabad.

FAQ

Frequently asked questions

What is the difference between private AI and public AI tools?

Public AI tools are shared services where your prompts and outputs pass through the provider's systems under its terms. Private AI keeps data, models and logs inside boundaries you control, such as your own hardware or a dedicated, in-region tenancy. The practical difference is evidence: with private AI you can show exactly where every prompt went.

Do APRA-regulated entities have to run AI on-premises?

No. APRA's framework is technology and vendor agnostic, and existing standards such as CPS 230 and CPS 234 apply whatever you choose. Hosted services can be acceptable with the right controls, contracts and exit plans. On-premises deployment is one way to simplify data-flow and offshoring questions for sensitive workloads, not a requirement.

Is a private LLM as good as ChatGPT, Claude or Gemini?

For many defined business tasks, such as summarising, classifying, extracting and answering from your documents, current open-weight models perform well. Frontier hosted models still lead on the hardest reasoning and on research that needs live internet data. The only reliable test is an evaluation set built from your own tasks and edge cases.

How much does it cost to run an LLM on your own infrastructure?

It depends on model size, volume and utilisation. Self-hosting turns a per-token bill into a mostly fixed cost for hardware, power and people. It pays off when sustained volume is high enough, at equal quality. Our cost guide gives a break-even formula, and our calculator lets you test your own numbers.

Does data residency in Australia mean the AI processing happens in Australia?

Not always. Some services store your content in Australia while running the model elsewhere. As at 7 November 2026, OpenAI lists Australia for ChatGPT data storage but not for inference residency. Ask every provider separately about storage, inference, logs, support access and integrations, and get the answers in the contract.

Are mandatory AI guardrails law in Australia?

No, as at 7 November 2026. The government has said it will not proceed at this time with mandatory guardrails, and relies on existing law plus the voluntary Guidance for AI Adoption. Privacy, consumer and sector rules still apply, and APRA expects regulated entities to manage AI risk under existing prudential standards.

What changes on 10 December 2026 for AI and privacy?

Organisations covered by the Privacy Act must describe in their privacy policy any use of computer programs to make, or substantially and directly help make, decisions that could significantly affect individuals using their personal information. The policy must set out the kinds of personal information and the kinds of decisions involved. The OAIC has published guidance and a flowchart.

Is OpenClaw safe for business use?

Not in a default personal setup. OpenClaw is designed for one trusted operator, and researchers have found malicious third-party skills. It can be run more safely inside your own infrastructure, with a separate agent identity, vetted skills, approval gates and full logging. The Foundation's enterprise edition is still described as suitable for internal pilots.

Sources

Accessed 6 and 7 Nov 2026.

■ YOUR NEXT STEP

Talk to us about private AI

If you need AI that your risk team can sign off, talk to Quantana. We can map your use cases against your data classes and obligations, recommend hosted, private cloud or on-premises for each, and prove the result with evals on your own tasks. Start with the AI cost calculator, see how SecGPT Vault works, or tell us about your project.

Tell us about your project See how SecGPT Vault works