Most "sovereign AI" claims fail when a CISO asks where the boundary actually sits. Cetus AI is precise about this. The Songlines Shared Responsibility Model makes the boundary explicit — so boards, procurement teams, and security assessors know exactly what Cetus AI governs and what the enterprise must enforce.
The term "sovereign AI" is used loosely across the industry. Cetus AI takes a different position: sovereignty is only meaningful when the boundary is explicit, auditable, and assigned.
The common claim is that running AI workloads in an Australian data centre makes them "sovereign." This conflates infrastructure location with governance — and leaves the most critical questions unanswered.
Cetus AI defines sovereignty as the explicit assignment of governance responsibilities across every layer of the AI stack — from hosting through to the enterprise's own downstream systems.
These are the questions that expose whether a sovereignty claim is substantive or marketing. Cetus AI has precise answers to all of them.
Not just at rest — in transit, during inference, in telemetry, in logs. Every hop matters for a genuine sovereignty assessment.
Model updates can change behaviour, introduce new data flows, or alter compliance characteristics. Governance requires control over when and how models change.
If Entra ID or the enterprise's PAM is breached, what is the blast radius within the AI layer? This is the question that separates genuine sovereignty architecture from hosting claims.
An audit trail that can be modified by the vendor, the enterprise, or a privileged user is not an audit trail for compliance purposes. Immutability must be architectural, not policy-based.
The Songlines Shared Responsibility Model assigns every governance obligation to either Cetus AI or the enterprise. There are no grey areas. If it is in the Cetus AI column, Cetus AI is accountable. If it is in the Enterprise column, the enterprise must enforce it — and Cetus AI cannot compensate for its absence.
The deployment tier an enterprise selects directly changes the sovereignty boundary. Choosing a higher tier does not automatically make the deployment more sovereign — it shifts more of the responsibility to the enterprise to enforce.
Sovereignty is not passive. The Songlines model is only as strong as the enterprise's enforcement of its own column. These are the obligations that cannot be delegated to Cetus AI.
Use this checklist to assess whether your organisation is ready to make a substantive sovereignty claim — not just a hosting claim.
The Shared Responsibility Model is designed to support compliance with the following Australian and international frameworks. It does not replace a formal compliance assessment — it provides the governance architecture that assessors need to evaluate.
The immutable audit trail, data residency controls, and PII routing flags directly support Privacy Act compliance obligations for AI-processed personal information.
The Shared Responsibility Model maps directly to the APS policy's requirements for human oversight, auditability, and responsible deployment of generative AI in government contexts.
Songlines Control® is designed to support ISO 27001 information security management requirements, with particular alignment to access control, audit logging, and incident management controls.
The emerging ISO 42001 AI management system standard requires documented governance of AI systems. The Shared Responsibility Model provides the governance architecture ISO 42001 assessors need.
For Australian government agencies requiring IRAP assessment, the Songlines architecture is designed to support the assessment process with documented controls, audit evidence, and clear boundary definitions.
The Songlines platform supports Essential Eight controls including application control, multi-factor authentication (at the platform layer), and audit logging — with the enterprise responsible for enforcing the remaining controls in their column.
Book a sovereignty briefing with the Cetus AI team. We will walk through the Shared Responsibility Model layer by layer, map it to your deployment context, and identify exactly which obligations sit with your organisation.