A new whole-of-government cloud policy came into effect on Wednesday, and outside of Canberra I’m not sure many people noticed. The DTA’s Cloud Policy took effect on 1 July, and it lands alongside the updated AI-in-government policy, where the first mandatory requirements kicked in on 15 June and the rest arrive by December. Worth being precise about scope: this is a Commonwealth policy, so it binds federal (non-corporate Commonwealth) entities, not the states - though I’d be surprised if the states don’t drift the same way over time. If you don’t work with government you can be forgiven for scrolling past all of it. If you do, the thing worth paying attention to is a bit subtle: a question that has been a comfortable think-piece for years just turned into an audit item.

The question is data sovereignty, and it usually gets flattened into data residency. Residency is the easy version - is the data sitting on a server in Australia. It’s easy because you can answer it with a region setting and a ticked procurement box. Sovereignty is the harder version, and the new obligations push you toward it: who can actually access the data, whose model touched it, under which country’s laws it could be compelled, and, the part that catches people, whether you can prove any of that after the fact. The AI policy now expects agencies to keep an internal register of AI use cases with a named accountable owner for each one, plus an impact assessment before anything goes live. That’s not a storage-location question. That’s a show-me-the-chain-of-custody question.

I’ve had to answer the harder version in practice, and it changes decisions you’d otherwise make on merit alone. We built an AI system for a statutory authority in the dairy sector - digitising lab reports and summarising years of audit history. The data had to stay in Australia, the privacy requirements were strict, and the whole thing had to fit inside an existing government-hosted environment. When it came to pulling tabular data out of inconsistent PDF lab reports, we trialled AWS Textract and Azure Document Intelligence side by side. Azure won on extraction quality, which made the decision easy - but it also happened to sit inside the Azure footprint the system already lived in, which made the decision defensible. A couple of years ago that second point felt like a nice-to-have. Under the new questions it’s closer to the whole game.

That’s the shift I’d flag for anyone running government-adjacent systems. A lot of vendor and architecture choices got made a while back under a “residency is fine” assumption - data’s in-country, box ticked, move on. Those choices weren’t wrong at the time. But “the data is in Australia” and “I can prove who and what has touched this data” are different claims, and the policy is moving the bar from the first to the second. If your honest answer to “which model processed this record, and can you show it” is a shrug, then under these rules that’s a gap someone will eventually write up.

None of this is an argument that AI in government is too hard, or that sovereignty is a reason to stall. RevenueSA is the counter-example I keep coming back to: we rebuilt a tax system rather than buy off-the-shelf precisely because the legislation dictated behaviour no product could match, and working inside those constraints is what made it fit the job. Constraints like these, handled early, are just the specification you build to. The teams that will be fine in December are the ones treating the new questions as design inputs now, rather than discovering them in an audit later.

If you’re in a non-corporate Commonwealth entity, the useful exercise this month probably isn’t reading the policy cover to cover. It’s picking one AI or cloud workload you already run and trying to answer the sovereignty version of the question out loud - who can access it, whose model touched it, can you prove it. If that’s uncomfortable, better to find out now than in a review.

Sources: