--- title: "Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM" description: "Dopo l'affaire Fable, due motivi per l'inference on-prem: la retention 30 giorni forzata anche su ZDR e la sospensione del modello dall'alto. Guida per PMI." canonical: "https://www.mauriziofonte.it/blog/post/self-hosting-llm-retention-imposta-kill-switch-sovranita-dato.html" author: "Maurizio Fonte" date: "2026-07-23T09:09:10+02:00" modified: "2026-07-23T09:09:10+02:00" section: "LLM" tags: ["LLM", "Cloud"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [LLM](https://www.mauriziofonte.it/blog/cat/llm.html) [Cloud](https://www.mauriziofonte.it/blog/cat/cloud-infrastructure.html) # [Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM](https://www.mauriziofonte.it/blog/post/self-hosting-llm-retention-imposta-kill-switch-sovranita-dato.html) Giovedì 23 Luglio 2026, alle 09:09 ![Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM](https://www.mauriziofonte.it/image/004920200-self-hosting-llm-retention-imposta-kill-switch-sovranita-dato.jpg) 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](https://support.claude.com/en/articles/15425996-data-retention-practices-for-mythos-class-models), 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](https://www.mauriziofonte.it/blog/post/kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.html), 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](https://www.llama.com/docs/deployment/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](https://www.mauriziofonte.it/blog/post/llm-self-hosted-vps-hetzner-ollama-produzione-pmi.html). 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. ```text 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](https://www.mauriziofonte.it/ai-aziende/ai-aziende-integrazione.html) 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](https://www.osservatori.net/comunicato/artificial-intelligence/), 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](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai): 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. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Giovedì 23 Luglio 2026, alle 09:09 [« Articolo precedenteMCP donato alla Linux Foundation: cosa cambia per gli agenti aziendali22 Luglio 2026](https://www.mauriziofonte.it/blog/post/mcp-linux-foundation-agenti-aziendali-post-donazione.html)[Articolo successivo »vLLM batte Ollama quando: guida alla scelta del runtime di inference self-hosted24 Luglio 2026](https://www.mauriziofonte.it/blog/post/vllm-ollama-runtime-inference-self-hosted-guida-scelta-2026.html) ### Articoli correlati a Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM - [Hanno spento il modello AI più potente del mondo in tre giorni: il rischio di continuità che nessun contratto copre](https://www.mauriziofonte.it/blog/post/kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.html) Il 9 giugno 2026 Anthropic lancia Fable 5, il modello più capace mai reso pubblico; il 12 giugno il governo USA ne impone la sospensione globale · 13 Giugno 2026 ![Hanno spento il modello AI più potente del mondo in tre giorni: il rischio di continuità che nessun contratto copre](https://www.mauriziofonte.it/image/004720070-kill-switch-sovrano-rischio-continuita-frontier-model-ai-aziende.jpg) - [GPU su Hetzner per inference self-hosted: aggiornamento dopo mesi di esercizio](https://www.mauriziofonte.it/blog/post/gpu-hetzner-inference-self-hosted-aggiornamento-esercizio-costi.html) Self hostare un LLM su GPU non è solo installare Ollama: dopo mesi di esercizio emergono i costi reali e le scelte che contano. Aggiornamento · 27 Agosto 2026 ![GPU su Hetzner per inference self-hosted: aggiornamento dopo mesi di esercizio](https://www.mauriziofonte.it/image/005170070-gpu-hetzner-inference-self-hosted-aggiornamento-esercizio-costi.jpg) - [Quando lo Stato può spegnere la tua AI: l'Executive Order e il regime FAA che l'industria chiede](https://www.mauriziofonte.it/blog/post/governance-frontier-model-cio-executive-order-regime-faa-rischio-paese.html) Il caso Fable non è un'eccezione ma una direzione: l'Executive Order USA del 2 giugno 2026 introduce un accesso governativo anticipato ai frontier · 15 Giugno 2026 ![Quando lo Stato può spegnere la tua AI: l'Executive Order e il regime FAA che l'industria chiede](https://www.mauriziofonte.it/image/004730070-governance-frontier-model-cio-executive-order-regime-faa-rischio-paese.jpg) - [Retention obbligatoria a 30 giorni sui modelli di frontiera: il nodo GDPR per le PMI](https://www.mauriziofonte.it/blog/post/retention-30-giorni-modelli-frontiera-gdpr-sovranita-pmi.html) I modelli Mythos class impongono una retention di 30 giorni su prompt e output, anche per le organizzazioni che avevano configurato zero data · 28 Agosto 2026 ![Retention obbligatoria a 30 giorni sui modelli di frontiera: il nodo GDPR per le PMI](https://www.mauriziofonte.it/image/005180070-retention-30-giorni-modelli-frontiera-gdpr-sovranita-pmi.jpg) - [Quanto costa oggi un LLM self-hosted su VPS dopo il rincaro Hetzner](https://www.mauriziofonte.it/blog/post/hetzner-prezzi-2026-llm-self-hosted-vps-costi-pmi.html) Il 15 giugno 2026 Hetzner ha applicato il secondo repricing dell'anno, e sulle linee che servono per l'inferenza i rincari non sono ritocchi: · 7 Ottobre 2026 ![Quanto costa oggi un LLM self-hosted su VPS dopo il rincaro Hetzner](https://www.mauriziofonte.it/image/005650070-hetzner-prezzi-2026-llm-self-hosted-vps-costi-pmi.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Retention imposta e kill-switch: il doppio argomento per il self-hosting di un LLM", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/self-hosting-llm-retention-imposta-kill-switch-sovranita-dato.html Pubblicato: 2026-07-23 · Aggiornato: 2026-07-23. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.