Sovereign Deployment
Sovereignty is control, not distance
Sovereignty spans data, software, model, infrastructure, operations and decisions. It does not always mean complete isolation — it means the organisation keeps meaningful control and has deployment choices appropriate to its requirements.
Six layers of sovereignty
Data sovereignty, software sovereignty, model sovereignty, infrastructure sovereignty, operational sovereignty and decision sovereignty — each can be dialled to the organisation’s requirements.
Honest trade-offs
Cost, latency, model capability, hardware, operations, security, updates, availability and governance all shift as you move between deployment patterns. Local is not automatically safer or better; neither is cloud.
Sovereignty as control, layer by layer
Sovereignty here means control, not isolation — the ability to decide how your AI operates across every layer, without cutting yourself off from useful providers and models. That control runs through your data, the software that governs it, the models you use, the infrastructure you run on, how it is operated, and the decisions that are ultimately made. You are not choosing between openness and control; you are deciding, per layer, where each belongs.
- Data: where it lives and who can reach it
- Software: the layer that governs actions
- Model: which models, and the freedom to change them
- Infrastructure: where workloads run
- Operations: how the system is run day to day
- Decisions: who holds final authority
Choosing a deployment pattern
The same governed layer can run in different places depending on how much of the environment you need to control. Managed cloud is the quickest to start; running in your own cloud account or a private VPC keeps data and networking under your control; on-prem and edge suit stricter residency or connectivity constraints; and a local pattern fits work that must stay on a single machine. Because governance, the gateway, and evidence travel with the deployment, the controls are consistent wherever it runs.
- Managed cloud for the quickest start
- Your own cloud account for data and network control
- Private cloud or VPC for a bounded environment
- On-prem and edge for residency or connectivity limits
- Local for work that must stay on one machine
Deployment patterns
Choose the pattern your requirements demand
Managed cloud
SupportedWe operate the platform in an Australian-region managed environment.
Fastest to start and easiest to operate; the organisation accepts a shared operational boundary.
Your cloud account
SupportedThe platform runs inside the customer’s own cloud account and network.
Data and infrastructure stay under the customer’s control; the customer owns more of the operational responsibility.
Private cloud / VPC
SupportedIsolated deployment within a private network or virtual private cloud.
Strong network isolation; requires the customer to provide and maintain the environment.
On-premises
PilotDeployment on customer-operated hardware within their own facilities.
Maximum locality; higher operational cost and slower update cadence, assessed per engagement.
Edge
PilotProcessing closer to where work happens, for latency or connectivity reasons.
Lower latency and offline resilience; constrained hardware and a narrower model choice.
Local inference
ResearchRunning smaller models locally on device where appropriate.
Data need not leave the device; model capability is more limited. Local is not automatically safer or better.
