L’idea che gli attaccanti provino a entrare dalla porta principale è, per un’infrastruttura AI modernamente difesa, sempre meno realistica. Firewall, cifratura e formazione del personale restano indispensabili, ma proteggono un perimetro che gli avversari hanno imparato ad aggirare. Il vero bersaglio, oggi, è la filiera digitale: librerie condivise, dipendenze software, firmware dei componenti hardware e, nel caso dei Large Language Models, modelli pre-addestrati scaricati da repository pubblici o da fornitori terzi.

Per un’azienda che ha scelto di tenere l’inference on-premise — magari per ragioni di sovranità dei dati, di controllo sul TCO o di conformità normativa — la fiducia nella catena di fornitura diventa l’anello più delicato. Il ragionamento è semplice: se un avversario riesce a compromettere un componente a monte, il fatto di eseguire il modello su server proprietari, in una stanza chiusa, non serve a nulla. Il codice ostile è già dentro, e può agire indisturbato.

Il paradosso del controllo locale

Chi investe in hardware dedicato — pensiamo a server equipaggiati con GPU ad alta VRAM, NVLink e reti veloci — e configura pipeline di inference in container air-gapped spesso crede di aver eliminato il rischio esfiltrazione. Ma è proprio questo senso di controllo a creare una superficie d’attacco invisibile: i modelli scaricati da Hugging Face, le immagini Docker usate per il serving (vLLM, TGI, Ollama), i driver CUDA e gli aggiornamenti dei firmware delle schede video.

Il punto non è demonizzare il software open source. È che la verifica dell’integrità, in molti flussi di deployment, si ferma a un hash sha256 controllato distrattamente. Non basta. Serve un approccio in cui ogni artefatto sia firmato criticamente, la provenienza sia tracciabile e l’esecuzione possa essere attestata da radici hardware fidate. Senza questo livello di garanzia, il self-hosted rischia di diventare una fortezza con le porte aperte sul retro.

Chi ci perde, chi ci guadagna

Le vittime principali di un attacco alla filiera digitale dell’AI non sono solo le aziende che si vedono rubare i dati. Sono anche i fornitori di componenti che perdono credibilità, e l’intero ecosistema dell’open source se la fiducia nelle librerie comuni inizia a incrinarsi. Di converso, emergono opportunità per chi propone soluzioni di attestazione hardware (TPM, enclave sicure, boot misurato) e per le realtà che offrono catene di distribuzione di modelli certificate.

A livello strutturale, il segnale è chiaro: la separazione tra «sicurezza del perimetro» e «sicurezza della catena di approvvigionamento» sta diventando artificiale. In un deployment LLM on-premise, la sovranità dei dati deve essere estesa alla sovranità della filiera: la capacità di verificare e validare ogni componente che entra in produzione, senza deleghe cieche a terzi. Non si tratta di un caveat teorico: è un requisito operativo per chiunque abbia a cuore la riservatezza a lungo termine.

La prossima ondata di attacchi potrebbe prendere di mira i pesi di un modello pre-addestrato, alterando una manciata di parametri per introdurre backdoor comportamentali difficilissime da rilevare. E se quel modello gira su un cluster on-premise, il danno è confinato dentro i confini aziendali, ma la responsabilità è tutta di chi lo ha messo in produzione senza averne verificato la filiera. La domanda non è più solo «dove girano i miei dati?», ma «chi ha messo le mani sul codice che li elabora, e come posso esserne certo?»