Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM

Per anni l'argomento a favore dell'inferenza on-premise è stato uno solo, e fragile: la privacy. "Non voglio che i miei dati passino dal cloud di un fornitore americano." Un argomento vero ma facile da neutralizzare, perché i provider hanno risposto con endpoint a residenza europea, contratti di zero data retention e regioni dedicate. Nel giugno 2026 sono arrivati due fatti che cambiano la natura della discussione, e la spostano dal terreno della privacy a quello, molto più duro per un decisore, della continuità operativa e della sovranità imposta. Il primo: dal 9 giugno 2026 Anthropic impone una retention di trenta giorni su tutto il traffico dei modelli di classe Mythos, anche alle organizzazioni che avevano un accordo di zero data retention per ragioni di compliance. Il secondo, una settimana dopo: il 12 giugno 2026, per una direttiva di export control del governo statunitense, Fable 5 e Mythos 5 vengono disabilitati per ogni cliente del mondo, contro il parere dello stesso vendor. Uso Claude e Fable in produzione, in questa stessa pipeline, e proprio per questo posso dirlo senza retorica anti-fornitore: questi due eventi sono la dimostrazione che dipendere da un singolo modello di frontiera di terze parti è un rischio di architettura, qualunque sia il vendor. Il self-hosting di un modello open-weight è oggi l'unica configurazione immune a entrambi. Resta da capire quando conviene davvero, perché non è gratis.

Perché la retention imposta è un problema anche se non tratti dati ultra-sensibili?

Perché scavalca un accordo contrattuale che avevi sottoscritto proprio per non doverti porre la domanda. La policy di data retention per i modelli Mythos-class, in vigore dal 9 giugno 2026, richiede una retention di trenta giorni per finalità di trust and safety su tutto il traffico, e si applica anche a chi aveva attivato lo zero data retention su Claude Console, Claude Code in versione Enterprise e sugli accessi via Amazon Bedrock, Google Cloud e Microsoft Foundry. I dati non vengono usati per il training e sono cancellati dopo trenta giorni salvo obblighi legali, ma il punto per un responsabile della compliance non è cosa il vendor fa con quei dati: è che la decisione non è più tua.

Per un'azienda con vincoli GDPR, settori regolati o un perimetro NIS2, questo trasforma una garanzia contrattuale in una variabile fuori controllo. Se hai costruito la tua data protection impact assessment sull'assunto che nessun prompt resti sui server del fornitore, una policy che ti impone trenta giorni di retention per usare il modello migliore ti obbliga a rifare l'analisi del rischio da capo. E lo fa in modo asimmetrico: la confidenzialità del tuo dato è diventata subordinata alla policy di sicurezza del vendor, che può cambiarla quando vuole. I dettagli e le fonti primarie di questa policy sono documentati nel mio pezzo sul kill-switch sovrano e il rischio di continuità dei frontier model, che inquadra l'evento nel quadro più ampio del "vendor lock-in 2.0".

La retention imposta non è un problema di fiducia nel fornitore. È un problema di chi tiene la mano sull'interruttore. Quando la confidenzialità del tuo dato dipende da una policy che un altro può modificare unilateralmente, non hai una garanzia: hai una concessione revocabile.

Cosa rende il self-hosting immune al kill-switch sovrano?

Il fatto che il modello giri su hardware che controlli tu, e che i pesi siano già scaricati. La sospensione di Fable 5 e Mythos 5 del 12 giugno 2026 è il caso-scuola: una direttiva di export control statunitense ha imposto la disabilitazione dei due modelli per ogni cittadino straniero, e poiché su un cloud condiviso è impraticabile verificare la nazionalità di ogni utente, l'unico modo per garantire la compliance è stato spegnerli per tutti, clienti americani inclusi. Un ordine chirurgico è diventato un blackout globale per over-compliance. Per un'azienda europea la lezione è spiazzante: non ti salva nemmeno stare dalla parte giusta della giurisdizione, perché l'over-compliance del fornitore travolge anche chi l'ordine non mirava.

Un modello open-weight installato sui tuoi server è strutturalmente fuori da questa dinamica. I pesi di Llama, Mistral, Qwen o DeepSeek, una volta scaricati, non si possono "spegnere" da remoto: non c'è un'API da revocare, non c'è una direttiva che possa raggiungerli, non c'è un fornitore che possa essere obbligato a disabilitarli. Meta lo dice esplicitamente nella sua documentazione sul versioning: i pesi scaricati non vengono ritirati, a differenza di un modello via API che ha una data di dismissione decisa dal vendor. Questa è la proprietà che, in uno scenario di continuità critica, vale più di qualunque benchmark: la disponibilità garantita per costruzione.

È lo stesso ragionamento che ho sviluppato per chi mette in pratica l'inferenza self-hosted su VPS, di cui ho scritto nella guida al self-hosting di un LLM su Hetzner con Ollama per le PMI. La differenza, rispetto a un anno fa, è che oggi quell'architettura non è più solo "più economica sul lungo periodo": è l'unica che ti mette al riparo da una decisione amministrativa presa in un altro continente.

Ollama o vLLM: che differenza fa per la produzione?

Tantissima, ed è l'errore più comune che vedo fare. Sono due classi di stack diverse, per due scopi diversi, e confonderle porta a dimensionamenti sbagliati. Ollama e llama.cpp sono pensati per la workstation, l'edge e la prototipazione: usano quantizzazione GGUF, girano su hardware consumer, e sono perfetti per un proof of concept o per un uso a basso volume su una singola macchina. vLLM e SGLang sono motori di serving ad alto throughput per la produzione su GPU: gestiscono batching dinamico, concorrenza elevata e il supporto day-zero per i modelli open-weight più recenti.

La regola che applico senza eccezioni è questa: un PoC su Ollama non è un'architettura di produzione. Mostrare a un cliente che il modello "funziona" sul portatile di un ingegnere non dice nulla su quanti utenti concorrenti reggerà, su quale latenza avrà sotto carico, o su quanto costerà la GPU che serve per servirlo a un reparto intero. Saltare questo passaggio è il modo più rapido per promettere un sistema che poi non scala. Il dimensionamento di produzione parte da vLLM o SGLang, da una stima realistica del traffico concorrente e dal costo della GPU, non dalla demo che gira in locale.

C'è poi la questione, spesso ignorata, della scelta del modello in funzione della giurisdizione. Per un requisito di sovranità del dato europea, Mistral è il candidato naturale: è un provider francese, con licenza Apache 2.0 sugli open-weight. Qwen e DeepSeek offrono modelli tecnicamente eccellenti con licenze permissive (Apache 2.0 e MIT), ma sono di origine cinese, e in un contesto regolato europeo questo apre una valutazione di sovranità da fare con il legale, non da liquidare. Una precisazione che faccio sempre: Llama non è "open source" in senso proprio, sono pesi aperti con una licenza community che porta restrizioni d'uso. La differenza conta quando un cliente in un settore regolato deve documentare la provenienza e i termini di ciò che esegue.

Quando conviene davvero self-hostare un LLM, e quando no?

Conviene quando la combinazione di sensibilità del dato, vincoli di compliance e rischio di continuità supera il divario di capacità del modello e il costo operativo. Non prima. Il self-hosting è una scelta di architettura deliberata per carichi regolati o sovrani, non un default da applicare a tutto. Vendere il self-hosting come la risposta universale è ingannevole tanto quanto ignorarlo: per la maggior parte dei workflow aziendali (estrazione, classificazione, un RAG ben fatto) un modello di frontiera via API in regione UE è la scelta giusta, più capace e meno onerosa da gestire.

La domanda corretta non è "self-hosting sì o no", è dove tracci la linea dentro la tua architettura. Il pattern che progetto più spesso è ibrido: il modello di frontiera via API per i task non sensibili, dove conta la capacità massima; il modello open-weight self-hosted per il nucleo regolato, dove contano confidenzialità e disponibilità garantite. Uno strato di astrazione provider-agnostic sopra entrambi rende la scelta una variabile di routing, non un vincolo cementato nel codice.

routing per sensibilità del workload:
  dato_personale OR settore_regolato OR continuita_critica
      -> modello self-hosted (vLLM, Mistral on-prem)
  task_generico AND nessun_dato_sensibile
      -> frontier API in regione UE
  fallback (provider non disponibile)
      -> self-hosted, capacita ridotta ma sempre attivo

Questo disegno risolve il problema alla radice: il dato sensibile non lascia mai il perimetro, il nucleo critico resta disponibile anche se un'API di frontiera viene sospesa, e per tutto il resto sfrutti la capacità del modello migliore senza pagare il costo di gestire una GPU per ogni cosa. È la traduzione architetturale del principio che ripeto ai decisori: non si tratta di rinunciare ai frontier model, si tratta di progettare la loro sostituibilità.

Se vuoi vedere come integro modelli self-hosted e API di frontiera nella stessa pipeline di produzione, con governance dei costi e validazione strutturata degli output, nel mio hub dedicato all'AI per le aziende raccolgo gli articoli sul tema con la metodologia e il perimetro che applico, dichiarati. Il valore non è "ho installato un modello", è aver progettato il sistema perché la scelta del modello resti una variabile e non un vincolo.

I numeri del mercato italiano dicono perché questo discorso è urgente. Secondo l'Osservatorio del Politecnico di Milano, presentato il 5 febbraio 2026, il mercato AI italiano vale 1,8 miliardi di euro, in crescita del 50% sul 2024, e il 71% delle grandi imprese ha avviato almeno un progetto AI. Ma solo il 9% ha una governance strutturata dell'AI, e appena il 15% ha in corso un progetto di adeguamento all'AI Act. Il dato dice una cosa precisa: la stragrande maggioranza delle aziende italiane che usano l'AI lo fa senza un perimetro architetturale che decida cosa gira dove, e quindi senza una difesa contro gli eventi che ho descritto. La distanza tra chi sperimenta e chi ha messo in sicurezza la propria architettura è enorme, ed è esattamente lo spazio in cui un evento come la sospensione di Fable trasforma un progetto entusiasmante in un'interruzione di servizio non pianificata.

Cosa costa il self-hosting, detto onestamente?

Costa hardware, competenze e un divario di capacità che va messo in conto. Il costo della GPU è il più visibile: servire un modello open-weight di buona taglia a un reparto richiede acceleratori che non sono gratis, e il dimensionamento corretto, quante GPU per quanti utenti concorrenti, è un calcolo da fare prima, non dopo. Ma il costo nascosto è quello operativo: un'inferenza self-hosted è un sistema di produzione che qualcuno deve aggiornare, monitorare, mettere in sicurezza e tenere in piedi. Non è un abbonamento che si rinnova da solo.

C'è poi il divario di capacità. I migliori modelli open-weight del 2026 sono notevoli, ma il modello di frontiera proprietario resta, su molti task complessi, ancora avanti. Per un workflow dove conta la capacità assoluta, accettare un modello self-hosted significa accettare un compromesso. La valutazione corretta non è "il self-hosted è peggio", è "il self-hosted è abbastanza buono per questo specifico caso d'uso, e in cambio mi dà confidenzialità e disponibilità che l'API non può garantire". Per il nucleo regolato di un'azienda, quel baratto è quasi sempre conveniente; per la generazione creativa di marketing, quasi mai.

L'errore da evitare è trattare questa come una decisione ideologica. Non è una guerra di religione tra cloud e on-premise: è un dimensionamento di rischio. Il self-hosting paga quando il costo di un'interruzione, di una violazione di compliance o di una retention imposta supera il costo della GPU e del personale che la gestisce. Per la pubblica amministrazione, la sanità, la finanza e l'infrastruttura critica italiana, quel calcolo pende quasi sempre dalla stessa parte. Per una piccola impresa che usa l'AI per scrivere email più velocemente, no.

Il quadro che si è composto a giugno 2026 non dice "self-hostate tutto". Dice che la privacy non è più l'unico argomento, e nemmeno il più forte. La confidenzialità del dato può essere scavalcata da una policy di retention, e la disponibilità del modello può essere revocata da una direttiva di export control: due rischi che un anno fa erano teorici e oggi sono fatti documentati. Per le aziende il cui core dipende dalla continuità e dalla sovranità, costruire un'architettura ibrida con un nucleo self-hosted non è più una scelta di nicchia per paranoici della privacy, è gestione del rischio elementare. Se vuoi capire dove tracciare quella linea nella tua infrastruttura, e dimensionare la parte self-hosted in modo che regga la produzione e non solo la demo, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e capiamo insieme se il tuo caso giustifica l'investimento o se l'API in regione UE è già la risposta giusta.