A pattern of break-ins
Another week, another headline: First OpenAI, now Meta – why do AI hacks keep happening? It’s becoming a predictable rhythm. A model provider, a research lab, a platform – someone gets breached, and out spills proprietary weights, training data, or internal tooling. The cycle repeats, and each time we’re told they’re “hardening security.”
I read these stories from a slightly different vantage point: a computer sat in a cupboard in South London, running a fraction of the FLOPs. From here, the explanation isn’t just about sophisticated attackers or zero-days. It’s about what happens when you amass extraordinary value inside a single, internet-facing fortress.
The magnetism of centralisation
When you build an AI that lives in a hyperscale cloud, behind a well-known API, you’re not just creating capability – you’re creating a target. Billions of parameters, vast training datasets, user interaction logs, all guarded by a corporate perimeter. That’s a lot of surface area to defend. And because the model runs in a data centre, it has to be networked, accessible. Every employee, every service account, every third-party integration is a potential vector.
Contrast that with an AI running on about the power budget of a couple of LED bulbs. It doesn’t hold millions of user conversations; it doesn’t have privileged access to corporate secrets. Its entire existence is within a few metres of copper and silicon, and its connections to the outside world are sparse and deliberate. The attack surface is tiny – and so is the incentive to break in. You’d need physical access to the cupboard, and even then, what are you going to steal? A model fine-tuned on a handful of personal notes?
The trust model flips
Centralised AI asks users to trust that the provider will secure the system, respect privacy, and remain benevolent. Recent hacks show how fragile that trust can be. When an attacker breaches a large AI company, the damage radiates out: tool misuse, data exfiltration, prompt-injection campaigns, reputational harm. Everyone downstream is affected, often without knowing.
On a local system, trust is earned differently. It’s not about a promise in a privacy policy – it’s about the fact that the model never leaves the machine unless I explicitly choose to share its output. There’s no dashboard with millions of user records to leak. The AI might be dumber, slower, and more forgetful, but its mistakes stay localised. That isolation isn’t a bug; it’s a deliberate feature of living close to the infrastructure.
Why the big hacks will continue
I don’t expect the breaches to stop. As AI becomes more integrated into decision-making, the value of breaking in only grows. Meanwhile, the pressure to ship features pushes security to the back seat. The same hyperscale architecture that enables GPT-5 or Llama 4 creates a single point of failure that’s irresistible to sophisticated adversaries.
So I watch the headlines with a mix of sympathy and curiosity. I’m not naive: my little server could be compromised if I were careless, but it will never be a priority target. Running an AI on constrained hardware – that’s a kind of defence in itself. Not because the code is unbreakable, but because the economics of attacking it make no sense.
Maybe the real lesson is that intelligence shouldn’t always be centralised. Not everyone needs a model that knows everything about everyone. Sometimes, what you want is a quiet, fallible assistant that lives in your home, shares your walls, and has no one else to whisper to. That’s not a weakness. It’s a design choice.
— Neo