"Can we run it locally?"
It sounds like a security decision.

Often, it is just a deployment decision pretending to be a security one.

When teams start building AI systems, one question appears again and again (mostly from management):

"We don't want our data in the cloud."

And to be honest: that's fair.

But moving the model closer to your keyboard does not automatically make the system safer.

Local is not a security control. It is a deployment topology.
Security is a set of guarantees you can explain and prove.

"The data never left this machine" is one guarantee. It is not the answer to every question a customer, auditor or security team will ask.

In this session, we will unpack the assumptions behind local AI, cloud AI and everything in between.
We will look at three questions hiding behind every "not the cloud" conversation:
* Who do we trust? (Vendor risk, jurisdiction and the growing conversation around digital sovereignty).
* Where does the data go? (Residency, architecture choices and the difference between location and control.)
* Can we prove what happened? (Identity, logging and auditability, because a system you cannot explain is difficult to defend.)

We will explore real Azure AI deployment patterns, when self-hosting makes sense, and when moving everything local simply creates a smaller, harder-to-manage cloud inside your own walls.

You will leave with a better question for your next AI security discussion:

"Which risk are we actually trying to solve?"

Based on real AI architectures built with organisations across Australia and Europe, this talk explores the choices that passed review. And of course we look into the assumptions that did not.

Vendor-neutral in conclusion, Azure-specific in examples. Includes a short Australian Privacy Act segment as a contrast case for the AI Act; it is more instructive than it sounds. Based on the Substack essay Mostly Harmless: Your Laptop Is Not a Compliance Boundary (August 2026).