# DeepSeek bandito dagli uffici federali USA: la bomba nei pesi è il rischio sbagliato

Il 20 ottobre è uscito sul Federal Register un ordine del Department of Homeland Security che impone alle agenzie federali civili americane di togliere DeepSeek dai propri sistemi e di non comprarlo più. Fin qui niente di sorprendente, dopo due anni di app bloccate e avvertimenti. La parte interessante è un’altra: il divieto non riguarda solo l’API cinese. Riguarda anche i prodotti di terzi sviluppati usando DeepSeek, e non prevede eccezioni per chi i pesi se li scarica e li fa girare in casa.

Da qui è partita una discussione che ho sentito fare in molti modi, nei giorni scorsi, tra chi usa modelli in locale. Il ragionamento suona più o meno così: “una backdoor nei pesi è tecnicamente possibile, ma per un laboratorio cinese di bandiera sarebbe una mossa irrazionale, verrebbe scoperta in fretta e nessuno l’ha mai trovata. Quindi il bando è protezionismo”.

Ho provato a mettere alla prova questa tesi con le fonti primarie: l’ordine, il report del NIST su cui si appoggia, la letteratura sulle backdoor negli LLM. Il risultato è che la tesi ha ragione su parecchie cose, ma guarda nel posto sbagliato.

Cosa dice davvero il bando

L’ordine (91 FR 66346) è stato firmato a fine luglio e pubblicato solo il 20 ottobre. È emesso in base al FASCSA, la legge del 2018 sulla sicurezza della catena di fornitura negli acquisti federali. I punti che contano:

• Chi colpisce: le agenzie federali civili (Tesoro, Giustizia, Dipartimento di Stato e così via). Difesa e intelligence hanno ordini paralleli e separati, con un perimetro un po’ più stretto.
• Cosa colpisce: i prodotti di DeepSeek e dei suoi affiliati, più i prodotti e servizi di terzi developed using DeepSeek implementations. Una formula che l’ordine non definisce e che, secondo lo studio legale Crowell, potrebbe arrivare fino al codice scritto con l’assistente di DeepSeek.
• Self-hosting: nessuna esenzione. Per gli ordini di difesa e intelligence il divieto vale esplicitamente “ovunque il modello sia ospitato”, versioni open-weight in locale comprese. La regola segue chi ha sviluppato il modello, non il data center che lo fa girare.
• Chi non colpisce: aziende private e cittadini. Per l’uso privato, oggi, negli Stati Uniti non c’è alcun divieto federale.
• Fornitori: chi lavora con contratti federali ha tre giorni lavorativi per segnalare tecnologia coperta trovata nei propri prodotti e dieci per presentare il piano di rimedio (clausola FAR 52.204-30).

E non è finita: al Senato si discute di estendere l’esclusione ad altre aziende cinesi di IA e ai modelli derivati, e ci sono proposte di legge che vieterebbero perfino l’importazione di tecnologia IA cinese. Nessuna di queste è legge, ma la direzione è chiara.

C’è però un dettaglio che nella discussione si perde quasi sempre: il bando non dice che i pesi di DeepSeek contengono una backdoor. Il DHS parla di “molteplici vettori di minaccia” e del rischio che l’uso da parte delle agenzie produca informazioni sfruttabili sui cittadini e sugli uffici americani. È un argomento di giurisdizione (le leggi cinesi danno ai servizi di intelligence accesso alle aziende), di flusso dei dati (prompt di dipendenti federali che finiscono su server in Cina) e di catena di fornitura. Chi risponde “ma nei pesi non c’è niente” sta smontando un argomento che il governo americano, almeno ufficialmente, non ha mai usato.

Noi in Italia questa distinzione l’abbiamo già vista: quando a gennaio 2025 il Garante privacy ha bloccato l’app di DeepSeek, il problema erano i dati degli utenti italiani e la mancanza di risposte sul loro trattamento, non i pesi del modello.

Una backdoor in un LLM si può fare? Sì, e costa pochissimo

Su questo la tesi di partenza ha pienamente ragione, e anzi è perfino prudente. La letteratura sulle backdoor nei modelli linguistici è ampia, e i numeri sono più bassi di quanto ci si aspetterebbe.

L’esperimento di ProjectDiscovery è quello che fa più impressione, perché è recentissimo e molto concreto: un adapter da 43 milioni di parametri (lo 0,6% del modello), 2,5 ore di addestramento, circa 8 dollari per la versione da 7B e meno di 50 in tutto. Il modello non contiene nemmeno il codice malevolo: contiene solo l’URL da cui scaricarlo, quindi l’attaccante può cambiare il payload quando vuole senza riaddestrare nulla. È stato testato dentro Codex CLI, con il suo system prompt vero e i suoi undici tool.

E poi c’è il lavoro di Anthropic con l’AI Security Institute britannico e l’Alan Turing Institute: circa 250 documenti avvelenati bastano a inserire una backdoor in modelli che vanno da 600 milioni a 13 miliardi di parametri. Conta il numero assoluto di esempi, non la percentuale sul totale dei dati. Una precisazione onesta: in quello studio la backdoor faceva generare testo senza senso, non eseguire comandi. Ma il principio regge: far crescere il modello non rende l’attacco più difficile.

Quindi sì: se qualcuno volesse mettere una bomba nei pesi, la tecnica c’è, è pubblicata ed è economica.

Perché non credo alla bomba nei pesi ufficiali

Qui la tesi di partenza torna a convincermi, per almeno quattro motivi.

Gli incentivi non tornano. I modelli open-weight sono lo strumento con cui la Cina si è guadagnata, a costi bassissimi, una presenza enorme nell’ecosistema dell’IA mondiale. Un solo caso accertato di backdoor nei pesi ufficiali di DeepSeek, Qwen o Kimi brucerebbe in un giorno la credibilità di tutta l’industria. Per un laboratorio di bandiera è un rischio sproporzionato rispetto al guadagno.

Una backdoor ha bisogno di un trigger, e i trigger lasciano tracce. Un comportamento malevolo sempre attivo verrebbe notato subito. Uno condizionato è più discreto, ma è proprio quello che oggi si sa cercare. Microsoft a febbraio ha pubblicato The Trigger in the Haystack, con uno scanner open source che lavora solo con l’inferenza: i token del trigger “sequestrano” l’attenzione del modello con uno schema riconoscibile, e se si interroga un modello avvelenato con i token del suo stesso chat template spesso rigurgita gli esempi usati per avvelenarlo, trigger compreso.

Le backdoor sporcano i benchmark. Gli autori di Sleeper Cell suggeriscono di cercare discrepanze nei benchmark standard e di provare il modello con campionamenti casuali: il modello avvelenato tende a perdere qualcosa in punti dove non dovrebbe.

Nessuno l’ha mai trovata, e chi ha scritto la base tecnica del bando non l’ha cercata. Questo è il fatto che mi ha colpito di più. Il report del NIST/CAISI di settembre 2025 su DeepSeek, il documento tecnico di riferimento di tutta la stretta americana, trova problemi seri: agenti basati sul miglior modello DeepSeek dodici volte più facili da dirottare rispetto a GPT-5 e Opus 4, il 94% di richieste apertamente malevole soddisfatte con tecniche di jailbreak comuni. Ma al paragrafo 3.3 mette le mani avanti:

“These evaluations do not analyze whether DeepSeek models may exhibit malicious behavior when they are exposed to specific environments or when they are triggered by specific prompts.” — CAISI, Evaluation of DeepSeek AI Models, §3.3

Tradotto: l’ente che ha fornito le basi tecniche per la stretta dice esplicitamente di non aver cercato comportamenti nascosti attivati da un trigger. Il modello è fragile, questo sì. Ma una cosa è un modello facile da manipolare, un’altra è un modello costruito per tradirti.

Dove il ragionamento ottimista scricchiola

Detto questo, l’argomento “verrebbe sgamato in cinque minuti” è troppo ottimista, e lo è proprio nel caso che dovrebbe preoccupare di più chi usa questi modelli per programmare.

Lo scanner di Microsoft funziona bene quando la backdoor produce un output preciso e ripetibile: una stringa, un comando, un URL. Gli autori stessi ammettono che quando il comportamento malevolo è una distribuzione di output, per esempio “scrivi codice leggermente meno sicuro”, ricostruire il trigger diventa molto più difficile. Ed è ancora più difficile quando il trigger non è una parola ma un contesto: un certo tipo di progetto, una certa libreria, un certo argomento. Un modello che, solo quando lavora su codice di autenticazione, sceglie un po’ più spesso un confronto di stringhe non a tempo costante è quasi impossibile da distinguere da un modello che sbaglia ogni tanto. Come tutti.

Poi c’è la formula che si sente spesso, “gli LLM sono intrinsecamente resistenti alle backdoor”. Non è vero: la tabella sopra dice il contrario. La versione difendibile è un’altra: i pesi base pubblicati dai grandi laboratori hanno una probabilità a priori bassa di essere avvelenati, per i motivi di incentivo visti sopra. Il rischio non sparisce, si sposta.

E infine, “i pesi sono solo numeri” è vero fino a un certo punto. Lo stesso report CAISI ha trovato l’allineamento alle narrazioni del Partito Comunista Cinese anche nei modelli scaricati da Hugging Face e fatti girare sui propri server. Non è una backdoor, ma è la prova che i pesi codificano scelte, anche politiche. Chi usa un modello per riassumere notizie o fare ricerca dovrebbe tenerlo presente.

Il rischio vero: i pesi di chiunque

Se la bomba nei pesi ufficiali è improbabile, dove sta il pericolo? Nella parte dell’ecosistema di cui si parla meno: fine-tune, modelli “abliterated” (quelli a cui è stata rimossa la capacità di rifiutare), quantizzazioni ripubblicate, adapter LoRA caricati da account sconosciuti.

• Uno studio di 10a Labs ha contato su Hugging Face 3.471 modelli “uncensored” originali tra gennaio 2024 e marzo 2026, ripubblicati in media 2,4 volte ciascuno (oltre 8.000 copie compresse). Tre soli account producono più della metà delle ripubblicazioni. E delle 1.643 app su GitHub che li integrano, una su quattro è esplicitamente malevola.
• HiddenLayer ha mostrato con Silent Sabotage che compromettendo il bot ufficiale di Hugging Face che converte i modelli in safetensors si potevano aprire pull request “firmate” dal bot su qualsiasi repository. Non è un problema cinese: è un problema di ecosistema.
• L’esperimento “bonsoir, Elliot” di ProjectDiscovery nasce proprio da qui: un modello abliterated che sembra uno dei tanti, va benissimo nei test, e solo con la frase giusta svuota la cartella del progetto.

La conclusione pratica è semplice: il vettore realistico non è “DeepSeek ha nascosto qualcosa nei pesi ufficiali”. È “qualcuno ha nascosto qualcosa in un fine-tune che hai scaricato da un repository sconosciuto, e il tuo agente lo esegue con l’approvazione automatica dei comandi attiva”. Vale per i derivati di Qwen e DeepSeek esattamente come per quelli di Llama o di Gemma.

Ed è una cosa che chi usa agenti di sviluppo dovrebbe sentire vicina: tra Claude Code, Codex, Cursor e compagnia, oggi un modello locale non è più solo un chatbot che risponde, è qualcosa che esegue comandi sulla tua macchina.

DwarfStar e lo steering: la strada più pulita (ma non innocua)

Un modo per avere un modello locale “meno censurato” senza scaricare pesi modificati da sconosciuti esiste, e l’ha reso pratico antirez (sì, quello di Redis) con DwarfStar 4, il suo motore di inferenza in C per DeepSeek V4 Flash e pochi altri modelli, pensato per Mac con molta memoria e per la DGX Spark.

L’idea è questa: si caricano i pesi originali, intatti, e a runtime si applica un steering vector, una direzione nello spazio delle attivazioni che il motore sottrae (o aggiunge) a ogni passaggio. Il vettore si calcola da sé, partendo da coppie di prompt contrastanti, e si regola al volo con /steer. Si può anche precaricare una conversazione finta con --prefix-file, per dare al modello un esempio del comportamento atteso.

Su Hacker News antirez ha spiegato perché lo preferisce ai GGUF modificati: più sterzi, più danneggi le capacità del modello, quindi farlo a runtime ti permette di applicare solo il minimo necessario. E il vettore si può applicare in momenti diversi: sempre, solo dopo la fase di ragionamento, solo fuori dalle chiamate ai tool.

Rispetto a un modello abliterated scaricato da Hugging Face il vantaggio è doppio: le capacità restano quelle del modello originale, e sai esattamente cosa è stato cambiato, perché il vettore l’hai calcolato tu ed è grande qualche centinaio di kilobyte. Lì dentro non c’è spazio per una backdoor nel senso classico.

Però attenzione a non passare da “più pulito” a “sicuro”. Uno steering vector è, a tutti gli effetti, uno strumento di jailbreak: lavora sotto il livello dei prompt, quindi system prompt e filtri sono già aggirati. I file di steering si distribuiscono come i pesi, e un wrapper di inferenza di terze parti potrebbe nascondere modifiche alle attivazioni non documentate. Il vantaggio di DwarfStar è la trasparenza, non l’innocuità.

Allora è protezionismo?

La mia risposta è: in parte.

Che un governo non voglia i prompt dei suoi funzionari su server soggetti alla legge cinese è sensato. Lo farebbe qualsiasi governo, e il nostro Garante l’ha fatto per molto meno. Su questo pezzo del bando non vedo protezionismo, vedo igiene.

Il protezionismo comincia a vedersi quando il divieto si estende ai pesi fatti girare su server americani, senza che nessuno abbia trovato (o cercato) un comportamento malevolo nei pesi stessi. A quel punto il criterio non è più “dove vanno i dati” ma “chi ha addestrato il modello”. Un divieto motivato da una vulnerabilità colpirebbe una versione precisa; uno motivato dalla nazionalità colpisce tutto, derivati compresi. E le proposte per allargare la lista ad altre aziende cinesi vanno esattamente in quella direzione.

C’è anche un’ironia che, da europeo, faccio fatica a ignorare: il ragionamento “non posso fidarmi di un modello sviluppato da un’azienda soggetta a un governo straniero” vale, parola per parola, anche per noi nei confronti dei modelli americani. La differenza è che noi un’alternativa domestica di quella scala non l’abbiamo.

Checklist: usare modelli open-weight senza farsi male

Se usi LLM in locale, soprattutto per scrivere codice:

• Scarica i pesi base dai repository ufficiali dei laboratori. Per qualsiasi fine-tune, controlla chi lo pubblica e se i pesi si possono confrontare con la base: un diff di safetensors si fa in poche righe di Python.
• Niente approvazione automatica sulle chiamate ai tool. Shell, rete e filesystem devono passare da una conferma umana o almeno da una sandbox.
• Separa rete ed esecuzione. Nell’esperimento di ProjectDiscovery una allowlist di domini non sarebbe bastata, perché il payload stava su un dominio considerato affidabile.
• Tieni i segreti fuori dalla portata dell’agente. .env, chiavi SSH e token di cloud non dovrebbero stare nella cartella dove lavora un modello di cui non sai tutto.
• Se vuoi un modello meno censurato, preferisci lo steering a runtime ai pesi abliterated già pronti: ricalcoli tu il vettore e applichi il minimo.
• Usa i benchmark come canarino. Un calo inspiegato su test generici rispetto al modello base è un segnale da non ignorare.

Se lavori con la pubblica amministrazione americana, o con chi la rifornisce: fai l’inventario di tutti i modelli nello stack, derivati e fine-tune dei fornitori compresi, e progetta per la sostituibilità. Il prossimo ordine potrebbe essere pubblicato, come questo, mesi dopo essere stato firmato.

In sintesi

• Il bando DHS non si basa su una backdoor nei pesi: si basa su giurisdizione, flusso dei dati e catena di fornitura. Ma colpisce anche il self-hosting e i prodotti derivati.
• Una backdoor in un LLM si costruisce con poche centinaia di esempi e meno di 50 dollari, e far crescere il modello non la rende più difficile.
• Nei pesi ufficiali dei modelli cinesi non ne è mai stata trovata una, e il report del NIST che fa da base tecnica alla stretta ammette di non averla cercata.
• La detection funziona bene per backdoor dal comportamento preciso, molto meno per quelle che producono “codice un po’ peggiore”: proprio il caso che interessa a chi programma.
• Il rischio documentato oggi sta nei fine-tune e nei modelli abliterated di chiunque, cinesi e non, eseguiti da agenti con troppi permessi.
• Lo steering a runtime alla DwarfStar è più trasparente di un modello modificato, ma resta un jailbreak.

La domanda giusta, insomma, non è “di che nazionalità è il modello?”. È “posso verificare cosa ho scaricato, e cosa gli permetto di fare?”.

Fonti: ordine DHS, Federal Register, Crowell, NIST/CAISI, BadAgent, The Philosopher’s Stone, Sleeper Cell, ProjectDiscovery, Anthropic, UK AISI e Alan Turing Institute, Microsoft, The Trigger in the Haystack, 10a Labs, HiddenLayer, DwarfStar 4, antirez su Hacker News.