Over a weekend, the homepage of president.go.ke turned into a digital wall displaying a cryptocurrency wallet address and a countdown: five bitcoins, or the data would end up who knows where. Authorities in Nairobi took the site offline and launched an investigation, later stating they found no evidence that sensitive information was taken.

The news itself is brief, but beneath the surface lies a fracture that concerns anyone designing architectures for public data and artificial intelligence. The point isn’t the defacement—a ransom demand is one of the oldest web attacks—but rather who suffers the intrusion and where the data resides. A government losing control of its official domain for hours is a symptom of digital infrastructure where sovereignty is not fully achieved: it could be a problem of access management, reliance on third-party suppliers, or insufficient monitoring. In all cases, the lesson is the same one driving debates around on-premise deployments of language models and public databases: if you don’t own every cable, an incident is just a matter of time.

Kenya isn’t an isolated case. Public administrations worldwide oscillate between the convenience of the cloud and the need for direct control. But the real takeaway isn’t about picking a side; it’s understanding that the choice radically reshapes risk profiles. An infrastructure managed in-house—from fiber to server, from database to web application—offers a defensible perimeter that can be tuned and audited at every layer. Conversely, outsourcing critical portions to external providers may cut operational costs but multiplies touchpoints, and with them, the attack surface. The paradox is that the same logic applies when a ministry considers running an LLM on citizen data: hosting it in the cloud means accepting that the model sees data passing through someone else’s machines, whereas a self-hosted instance, with proper isolation, returns full control.

A second, more structural effect follows. Every time an attack succeeds against an institutional domain, the signal reaching procurement offices and IT leaders is: «We need to reduce dependency.» This isn’t an emotional reaction. It’s the recognition that cloud-only architectures, while often well-defended by providers, create an information asymmetry: the public body doesn’t know exactly how the vendor will react in a breach, nor can it be sure of intervening immediately on its own data. This pushes toward a hybrid or fully on-premise model, where recovery of a compromised site happens on one’s own clock, not under someone else’s SLA. For those designing the deployment of sensitive AI workloads—say, an analysis engine for judicial or health records—the lesson is identical: sovereignty is not ideological vanity, it’s a prerequisite for resilience.

Of course, bringing everything in-house is no magic wand. It means investing in skills, hardware, redundant networks, and physical security. The common mistake, when reading stories like this, is believing that a server in the basement is enough to sleep soundly. In reality, the line between sovereignty and fragility lies in the ability to manage the infrastructure lifecycle: updates, monitoring, offline backups, network segmentation. And this is where our observatory’s focus comes in: the same choices that govern a government portal apply to anyone needing to put into production a model with hundreds of billions of parameters. The difference is that in the latter case, the cost of an error isn’t measured only in hours of downtime, but in industrial-scale data exposure.

The Nairobi episode, filed as an attack without theft, remains a quiet reminder. When authorities say «no evidence of data exfiltration,» they are implicitly admitting they cannot guarantee with certainty what happened on every layer of the infrastructure. It’s an honest admission, but it’s precisely the kind of uncertainty that a truly sovereign architecture should eliminate.