The SOCI Act and AI: the questions to ask before adopting anything

Two pressures pulling in opposite directions

Australian critical infrastructure operators sit under the Security of Critical Infrastructure Act and its expansions, which reach across sectors including communications, energy, water, transport, data storage and healthcare. The obligations vary by sector and asset, but the direction is consistent: know your critical assets, manage risks to them including supply-chain and data risks, and report cyber incidents fast.

At the same time, the operational pressure to adopt AI is real, and the default path is a cloud tool: operational data flowing out to a model run by someone else, often in another jurisdiction, under terms that can change. For a regulated operator, those two pressures point in opposite directions. The asset owner is accountable for where the data goes; the cloud vendor's answer to where it goes is usually a link to a policy.

The questions that sort vendors quickly

Whatever the tool, the same short list separates architectures a regulated operator can defend from ones it cannot:

• Where, physically, is the data processed and stored, and in whose jurisdiction?
• Does anything we submit train or improve a model used by anyone else?
• Who can access it, is that access logged, and can we produce the log?
• What leaves our environment when the system runs, and can we verify that independently?
• If the vendor is compromised, acquired or shut down, what happens to our data and our capability?

Most cloud AI products answer these with contract clauses. A risk management program would rather answer them with architecture, because a clause is a promise and an architecture is a fact.

The architectural answer

Self-hosted AI answers most of the list by construction. The models run on hardware the operator owns, inside the operator's network. Nothing transits a third party, nothing trains anyone else's model, and jurisdiction is wherever the rack is. Access control and audit logging live in the operator's own environment, where the compliance team can actually inspect them. The vendor-failure question inverts: if the builder disappears, the system keeps running, because the operator owns all of it.

None of this removes the need for proper advice on your specific obligations, and nothing here is legal advice. But as a starting posture for a critical infrastructure operator looking at AI, own the machine is a defensible answer in a way that trust the cloud increasingly is not.