Nell’arco di un weekend, la homepage di president.go.ke si è trasformata in un muro digitale con un indirizzo di wallet per criptovalute e un conto alla rovescia: cinque bitcoin, oppure i dati sarebbero finiti chissà dove. Le autorità di Nairobi hanno staccato il sito e avviato le indagini, dichiarando di non aver trovato prove che informazioni sensibili siano state sottratte.

La cronaca si esaurisce qui, ma sotto la superficie c’è una crepa che riguarda chiunque progetti architetture per dati pubblici e intelligenza artificiale. Non si tratta del fattaccio in sé – un defacement con richiesta di riscatto è tra gli attacchi più antichi del web – bensì di chi subisce l’intrusione e di dove risiedono i dati. Un governo che perde il controllo del proprio dominio ufficiale per ore è il sintomo di una infrastruttura digitale in cui la sovranità non è piena: può essere un problema di gestione degli accessi, di dipendenza da fornitori terzi, o di monitoraggio insufficiente. In tutti i casi, la lezione è la stessa che anima il dibattito sui deployment on-premise di modelli linguistici e database pubblici: quando non possiedi fino all’ultimo cavo, l’incidente è solo questione di tempo.

Il Kenya non è un caso isolato. Amministrazioni pubbliche in tutto il mondo oscillano tra la comodità del cloud e il bisogno di controllo diretto. Ma il punto non è stabilire dove stia il bene assoluto; è capire che la scelta cambia radicalmente i profili di rischio. Un’infrastruttura gestita in-house – dalla fibra al server, dal database all’applicazione web – offre un perimetro di difesa modellabile, auditabile in ogni strato. Al contrario, delegare porzioni critiche a provider esterni può ridurre i costi operativi ma moltiplica i punti di contatto e, con quelli, le superfici d’attacco. Il paradosso è che la stessa logica si applica quando un ministero valuta di far girare un LLM su dati dei cittadini: hostarlo in cloud significa accettare che il modello veda i dati transitare su macchine non proprie, mentre un’istanza self-hosted, con la giusta isolation, restituisce il controllo completo.

C’è un secondo effetto, meno visibile ma più strutturale. Ogni volta che un attacco riesce su un dominio istituzionale, il segnale che arriva agli uffici acquisti e ai responsabili IT è: «Dobbiamo ridurre la dipendenza». Non è una reazione emotiva. È il riconoscimento che le architetture cloud-only, sebbene spesso ben difese dai provider, creano un’asimmetria informativa: l’ente pubblico non sa esattamente come reagirà il fornitore in caso di breach, né ha la certezza di poter intervenire immediatamente sui propri dati. Questo spinge verso un modello ibrido o interamente on-premise, dove il recupero di un sito compromesso avviene sotto il proprio orologio, non sotto lo SLA di qualcun altro. Per chi sta progettando il deployment di carichi AI sensibili – per esempio un motore di analisi su atti giudiziari o sanitari – la lezione è la stessa: la sovranità non è un vezzo ideologico, è un prerequisito di resilienza.

Naturalmente, portare tutto in casa non è una bacchetta magica. Significa investire in competenze, hardware, reti ridondanti e sicurezza fisica. L’errore più comune, quando si leggono cronache come questa, è credere che basti un server nel seminterrato per dormire tranquilli. In realtà, il confine tra sovranità e fragilità passa dalla capacità di gestire il ciclo di vita dell’infrastruttura: aggiornamenti, monitoraggio, backup offline, segmentazione di rete. E qui si inserisce l’attualità del nostro osservatorio: le stesse scelte che governano un portale governativo valgono per chi deve mettere in produzione un modello da centinaia di miliardi di parametri. La differenza è che nel secondo caso il costo di un errore non si misura solo in ore di disservizio, ma in esposizione di dati su scala industriale.

L’episodio di Nairobi, archiviato come un attacco senza furto, rimane un promemoria silenzioso. Quando le autorità dicono «nessuna prova di sottrazione di dati», stanno implicitamente ammettendo di non poter garantire con certezza cosa sia accaduto su ogni strato dell’infrastruttura. È un’ammissione onesta, ma è esattamente il tipo di incertezza che un’architettura realmente sovrana dovrebbe eliminare.