Key takeaways
✓Data sovereignty for AI is not just about where data is stored. It covers where data is processed, who can access it, and what foreign laws might apply to the infrastructure you use.
✓Australian government agencies must align AI deployments with the ISM (Information Security Manual), the Protective Security Policy Framework, and the Privacy Act. OFFICIAL: Sensitive and above classifications carry specific constraints that most commercial AI tools do not meet by default.
✓Sovereign cloud options and on-premises deployments can satisfy stricter classification requirements, but they introduce cost, latency, and capability trade-offs worth understanding before committing.
✓Tool choice alone does not solve sovereignty risk. Staff who do not understand classification rules will paste sensitive data into non-compliant systems regardless of what the CISO has approved.
✓Training that is grounded in your agency's actual data classifications, approved tools, and operational context is what closes the gap between policy on paper and practice on the ground.
What does data sovereignty mean for AI in government?
Data sovereignty, in the government context, means that data collected and held by Australian agencies stays subject to Australian law, regardless of where it is stored or processed. That includes who can access it, under what legal authority, and under what circumstances a foreign government or company could compel its disclosure.
For most of the last decade, data sovereignty meant one practical question: is this data sitting in an Australian data centre, or is it offshore? Cloud adoption forced agencies to think harder about it, and AI has made it significantly more complicated.
When a public servant uses a commercial AI tool, their input, the query they type, the document they paste, the data they reference, does not necessarily stay within the Australian jurisdiction. Depending on the tool and its configuration, that content may be processed on infrastructure governed by United States law, including the CLOUD Act, which allows American authorities to compel cloud providers to hand over data even when it is stored outside the US. That is a genuine legal exposure, not a theoretical one.
AI also complicates sovereignty in a second, less obvious way. Large language models learn from data. If an agency's content is used to fine-tune or improve a commercial model, that information may persist in the model's weights indefinitely, in a form that is difficult to audit or remove. This is sometimes called model memorisation, and it is one of the reasons that default terms of service for consumer-grade AI tools are not appropriate for government use.
The core issue
Sovereignty is not just about where data is stored. It is about who can access it, under whose legal jurisdiction, and whether inputs to AI systems can be used to train models you do not control.
Australia's approach to this sits across several frameworks: the Protective Security Policy Framework (PSPF), the Information Security Manual (ISM) published by the Australian Signals Directorate (ASD), and agency-level data governance obligations. The Australian Government's Secure Cloud Strategy encourages cloud adoption but places clear expectations on agencies to assess data sensitivity, classify it correctly, and choose infrastructure accordingly. For agencies handling PROTECTED or higher classified information, those choices narrow quickly.
The challenge is that AI adoption pressure is real. Ministers, department heads, and central agencies are asking what productivity gains are possible. The tools are compelling. But the question of which AI tools can be used with which data, under what configuration, is one that many teams have not fully worked through yet.
Which data classifications create the highest AI risk?
The Australian Government's Protective Security Policy Framework (PSPF) defines four main information classifications: Official, Official: Sensitive, Protected, and the higher-tier caveated markings (Secret and Top Secret, managed under different controls). For most civilian agencies, the practical concern sits in the middle: Official: Sensitive and Protected data are common, high-volume, and the categories most likely to end up in AI workflows by accident.
Official information carries no special handling requirements beyond standard IT security practices. A staff member using a commercial AI assistant to draft a media release or summarise publicly available policy documents is, in most cases, operating well within acceptable bounds. The risk here is low, though not zero: careless prompts can still reveal internal process information even when the underlying content is unremarkable.
Official: Sensitive is where friction starts. This classification covers information that, if disclosed, could reasonably cause limited harm to an individual, organisation, or government. Think personal details held by a welfare agency, budget figures ahead of announcement, or internal legal advice. Commercial AI tools hosted outside Australia's borders should not process this material without a specific risk assessment and appropriate contractual controls. Many do not meet those requirements out of the box.
Protected information represents the highest classification tier that most APS staff regularly handle. If this data is inadvertently submitted to a consumer-grade AI tool, or even an enterprise tool without appropriate data residency controls, the agency has almost certainly breached its PSPF obligations. The consequences range from mandatory incident reporting to ministerial notification.
The classification gap in AI adoption
Most AI data incidents in government don't involve deliberate misuse. They happen because a staff member doesn't recognise that a document they're summarising contains Protected or Official: Sensitive content. Classification markings on a PDF don't prevent a user from pasting the contents into a chat window.
The interaction between AI tools and these tiers creates a specific problem that traditional information security controls weren't designed to handle. A Data Loss Prevention (DLP) rule can block a file transfer. It is harder to intercept natural language that describes protected content without explicitly naming it. A procurement officer asking an AI assistant to "summarise the vendor evaluation for the tender we discussed last week" may be exposing commercially sensitive Protected-tier information in a prompt that contains no classified keywords at all.
Agencies working with caveated material (AUSTEO, AGAO, REL markings) face an even narrower set of approved tool options. In practice, those environments are typically air-gapped or strictly network-segmented, which limits but does not eliminate the AI risk, particularly as agentic tools capable of reading documents autonomously become more common.
What do the current rules actually require?
There is no single Australian law that says "this is how government agencies must use AI." What exists instead is a layered set of obligations that collectively define what responsible AI use looks like for Commonwealth and state entities.
The Australian Privacy Act 1988 applies to all Commonwealth agencies and to state and territory agencies handling Commonwealth data. The Act's Australian Privacy Principles (APPs) govern how personal information is collected, stored, used and disclosed. When an AI system processes personal information, every one of those actions is potentially a regulated event. The Australian Government's guidance on the Privacy Act and AI makes clear that feeding personal data into a third-party model, even temporarily, can constitute a disclosure. Agencies that do this without a valid legal basis are exposed.
The Information Security Manual (ISM), maintained by the Australian Signals Directorate (ASD), sets the technical controls that government systems must implement. The ISM does not have a dedicated AI chapter, but its controls on system authorisation, data storage, encryption, and third-party service providers apply directly to AI deployments. Any cloud-hosted AI service handling PROTECTED or higher data must be assessed under the ISM framework and authorised to operate. That process is time-consuming and often the single biggest bottleneck in a government AI project.
The Protective Security Policy Framework (PSPF) adds another layer. Administered by the Attorney-General's Department, the PSPF governs how agencies classify information and manage the risks that come with that classification. When an AI tool ingests or generates content that includes OFFICIAL: Sensitive or PROTECTED material, the tool itself becomes part of the information security boundary and must be treated accordingly.
The APS AI Ethics Principles and the Department of Industry's Responsible AI framework are softer instruments. They are not legislation. But they are government policy, and they set expectations that agencies will be held to in audits, Senate estimates, and FOI requests. The principles include transparency, accountability, and human oversight, which have direct implications for how AI decisions are documented and reviewed.
No single rule covers everything
Australian government AI sits at the intersection of the Privacy Act, the ISM, the PSPF, and APS policy guidance. Compliance requires all of them to be read together. Addressing one and ignoring the others is not a defensible position.
At the state level, the picture is less uniform. New South Wales has published an AI assurance framework and data governance guidelines. Victoria has guidance through the Victorian Government's Digital Strategy. Queensland and Western Australia have issued their own data sovereignty and cloud guidance. The specifics vary, but the common thread is this: state agencies handling sensitive citizen data are expected to know where that data goes when an AI system processes it, and to be able to demonstrate appropriate controls.
What all these frameworks share is an emphasis on accountability before deployment. Agencies are expected to conduct privacy impact assessments, engage their Chief Information Security Officer (CISO) early, and document how AI tools interact with classified or personal data before those tools go live. Retrospective compliance is possible, but it is harder to defend and more expensive to fix.
How do sovereign cloud and on-premises deployments change the equation?
Where your AI infrastructure sits determines what your data sovereignty obligations look like in practice. The architecture question is not just technical; it directly shapes what tools are available, what your team can do with them, and what you have to document for your security team and auditors.
There are broadly three options, and each one involves genuine trade-offs.
Offshore SaaS (standard commercial tiers)
Most consumer-grade and entry-level commercial AI tools process data on infrastructure based outside Australia. For many day-to-day queries this is low-risk, but the moment a staff member pastes in a client record, a grant submission, or anything that touches PROTECTED data, the organisation is potentially in breach of the ISM's data residency requirements.
The other issue is that standard terms of service for offshore SaaS tools often include provisions for training on user data, or offer limited transparency about where sub-processors are located. For a federal agency or a state department handling sensitive cohorts, that ambiguity is not acceptable.
These tools are not useless in a government context. They can work well for approved low-sensitivity tasks, such as drafting internal communications or summarising publicly available policy documents. The risk is that without clear guidance, staff will reach for the convenient tool regardless of data sensitivity.
Hyperscaler sovereign cloud regions
Microsoft, AWS and Google all operate data centres in Australia, and each offers some form of sovereignty or data-residency guarantee. Microsoft's Australian regions, for example, support data residency commitments for many Microsoft 365 and Azure services, and there is ongoing work across hyperscalers to offer what are sometimes called "sovereign cloud" tiers with additional contractual controls.
This option is where most larger agencies are landing for AI workloads at OFFICIAL and OFFICIAL: Sensitive. The tools are mature, the integration with existing identity and access management is straightforward, and the compliance documentation is available to support an ASD Essential Eight or ISM review.
The honest trade-off is that "Australian region" is not the same as "Australian jurisdiction". Data can still be subject to foreign legal processes depending on the parent company's domicile. For most OFFICIAL-tier workloads this is a manageable and documented risk. For PROTECTED workloads, it requires more careful legal assessment and often additional controls.
Residency is not the same as sovereignty
Data stored in an Australian data centre can still be subject to foreign law if the provider is incorporated overseas. Agencies working with PROTECTED data need specific contractual protections and, in some cases, dedicated tenancy arrangements, not just a regional deployment.
On-premises and air-gapped deployments
For the highest classification levels, or for agencies with strong policy reasons to avoid any cloud dependency, on-premises deployment of AI models is technically feasible. Open-weight models such as Meta's Llama family can be run on agency-controlled infrastructure with no data ever leaving the building.
The trade-offs here are real. On-premises AI requires significant infrastructure investment, specialist capability to deploy and maintain, and a willingness to manage the model lifecycle internally, including security patching and updates. You will also be running models that, in many cases, are behind the capability frontier of the leading commercial offerings.
That gap is narrowing. For specific, well-defined use cases, a locally-run model fine-tuned on agency data can outperform a general-purpose frontier model simply because it is purpose-built. But this is not a drop-in replacement for a full SaaS AI suite, and agencies should be realistic about the build-versus-buy effort involved.
Choosing the right tier for the right workload
In practice, most agencies end up with a layered architecture: offshore or standard cloud tools for genuinely unclassified public-facing work, Australian-region hyperscaler deployments for the bulk of operational AI, and on-premises or private cloud for anything PROTECTED or above.
The risk with this approach is complexity. Staff working across classification levels need to know which tool is appropriate for which task, and that is fundamentally a training and policy problem, not just an infrastructure one.
Why training your people is as important as choosing the right infrastructure
Sovereign cloud accreditation and on-premises deployments solve the infrastructure problem. They do not solve the human one.
The most common data leakage vector in AI deployments is not a misconfigured API or a vendor with lax data residency controls. It is a well-intentioned public servant pasting a ministerial brief into a consumer-grade AI tool because the approved tool felt slower or harder to use. Infrastructure decisions set the boundary; your people decide whether anyone stays inside it.
This pattern shows up in a few predictable ways. Staff who have not been trained on data classification habits will treat an AI assistant the way they treat a search engine: type the question, include the context, get the answer. The context is the problem. Prompts regularly contain case details, names, policy positions, or budget figures that should never leave a secured environment. The tool does not warn them. The training should have.
The prompt is a data transfer
Every prompt sent to an AI model is, in practice, a data transfer. If the model sits outside your sovereign boundary, the prompt content travels with it. Staff need to understand this as a first principle, not a footnote in an acceptable use policy.
There is also the question of what staff do with AI outputs. Unverified outputs embedded into briefing notes, policy documents, or procurement advice carry their own risk. Accuracy is not guaranteed, and in a government context, a fabricated reference or an incorrect legal citation can cause real harm. Training needs to cover both the input discipline and the output discipline.
The practical fix is not a longer policy document. It is hands-on training built around the actual tools your teams are using, the actual classifications they work with, and the actual decisions they make day to day. Generic AI literacy courses that use retail banking examples do not transfer well to a state agency managing sensitive personal information or a federal department handling security-classified material. The context problem is real, and government environments are one of the clearest illustrations of it.
For government teams, effective AI training typically covers four areas: understanding which tools are approved for which data classifications; how to write prompts that give useful outputs without including sensitive material unnecessarily; how to evaluate and verify AI outputs before acting on them; and what to do when something looks wrong. That last point matters more than people expect. Staff who do not know the escalation path tend to either ignore anomalies or, worse, quietly stop using the approved tools and revert to workarounds.
Better People works with government teams across Australia to build training programs grounded in these realities. If your agency is rolling out an AI capability uplift, or preparing staff ahead of a sovereign cloud migration, the government training page is a practical starting point.
Frequently asked questions
Can Australian government staff use commercial AI tools like Microsoft Copilot or ChatGPT?
It depends entirely on the classification of the data involved and how the tool is deployed. For OFFICIAL information with no sensitivity markers, many agencies permit commercial tools, provided the vendor's data processing terms are assessed and meet Australian Government ICT security requirements. PROTECTED data is a different matter: commercial cloud-hosted AI tools generally cannot process it unless they hold an IRAP-assessed (Information Security Registered Assessors Program) Protected certification. ChatGPT and similar consumer-grade tools are not approved for anything above public-domain use. Agencies need a formal tool register that maps each AI product to the classifications it is permitted to handle.
Does using an AI model mean the vendor is training on my agency's data?
Not automatically, but you need to verify this contractually before deployment. Many enterprise agreements for tools like Microsoft Copilot, Google Gemini for Workspace, and Claude for Enterprise explicitly exclude customer data from model training by default. The risk is that staff use personal or free-tier accounts rather than the enterprise version, where those protections do not apply. This is a governance and procurement question as much as a technical one. Your agency's AI use policy should prohibit the use of personal accounts for any work-related AI activity.
What does an IRAP assessment actually cover, and does every AI tool need one?
An IRAP assessment evaluates whether a system's security controls meet the standards set out in the Australian Government Information Security Manual (ISM). It is not a product certification that vendors carry automatically; it is a risk-based assessment commissioned by the consuming agency or undertaken by the vendor for their cloud platform. Not every tool requires a full IRAP assessment, but any system handling PROTECTED data or operating on sensitive networks does. For AI tools, the relevant questions include where inference occurs, where prompt data is logged, and whether any fine-tuning or retrieval involves agency data.
What are staff actually required to understand about AI and data handling?
At a minimum, staff need to know their agency's data classification scheme, which AI tools are approved at each classification level, and what constitutes a data breach under the Privacy Act. For agencies handling health, law enforcement, or national security information, that baseline is higher. The practical gap most agencies face is not policy, it is comprehension: staff cannot apply a policy they have not been trained to understand. Obligations under the Privacy Act and the APS Code of Conduct mean that an agency cannot simply publish a policy and consider the obligation met. Documented, role-appropriate training matters, especially when the Office of the Australian Information Commissioner or an auditor comes looking.
How should an agency assess an AI vendor's data sovereignty claims?
Start with specifics, not marketing language. Ask where data is stored at rest and in transit, which legal jurisdiction governs the contract, whether the vendor is subject to foreign government data access laws (such as the US CLOUD Act), and what subprocessors have access to agency data. Request the vendor's IRAP assessment or equivalent documentation, and check whether their privacy policy is consistent with the Australian Privacy Principles. A vendor who cannot answer these questions in writing should not be handling government data. Your procurement team and legal counsel should review the data processing agreement, not just the standard terms of service.
Ready to build AI capability that fits your agency's obligations?
Australian government teams face a genuinely different set of constraints when adopting AI. The infrastructure decisions, the classification requirements, the APS Code, the Privacy Act obligations, all of it shapes what your people need to understand before they touch a production system.
Better People works with government agencies to design training that starts from those constraints, not from a generic AI curriculum. If you're working through a sovereign cloud migration, preparing staff for a new AI platform, or trying to close a capability gap before a major rollout, we'd welcome a conversation.
